[conspire] DNS & nameservers ... 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 8-O ...

[Michael Paoli]

> Message: 1
> Date: Sun, 25 Mar 2018 14:45:52 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: conspire at linuxmafia.com
> Subject: Re: [conspire] DNS & nameservers ...
> Message-ID: <20180325214551.GT15622 at linuxmafia.com>
> Content-Type: text/plain; charset=utf-8
>
> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> Well, nowadays, to *some* extent, ... that kind'a depends.
>
> No, it really doesn't depend,

Well, I don't think we're *that* far apart on our perspective ;-) ...
some of the context was also lost in the (partial) quoting
(http://linuxmafia.com/pipermail/conspire/2018-March/009116.html) but ...

> Five reliable, network-dispersed authoritative nameserver domains is
        ^^^^^^^^! :-)

Yes, key word *reliable*.  Heck, I'd even go beyond that and say effectively
symmetrical - even if sort'a kind'a flakey and/or just not very high
availability/reliability/robustness (at least short of generally serving
up *bad* data), e.g 5 (or more) such DNS servers, is still much better than 3.

> better than four, which is better than three.

> Seriously. Michael, why are you always wanting to play Edge-Case Theatre?

Yum, ... Edge-Case Theatre ... "fun"!  ;-)

So, ... let's say one has 3 rock solid highly reliable DNS servers,
with good relevant geographic and network diversity for all or most all
of the coverage area of interest (yes, well distributed over the entire
planet *may* be better, but if 99.5% of the users of the data are, say, in
the US and Canada, adding more DNS servers outside of the US and Canada,
and if those in the US and Canada are already well diversified in terms of
geographic location and network location and even DNS server software,
adding more DNS servers outside of the US/Canada is of negligible benefit).
Anyway, 3 rock solid DNS servers - excellent availability, network connections
bandwidth, some nice DNS server software diversity, super high capacity and
bandwidth so they can well withstand most or all, even massive, DDoS attacks.
So, ... let's say we've got option to add more, ... but quite dissimilar,
oh, say, some folks's DNS servers running on some Raspberry Pis over some
minimal ("slow", but today's standards) DSL links, maybe locations
with no UPS coverage, and power/DSL lines that frequently drop out and
fail throughout the year (Winter storms, Summer tornados, oops, the SysAdmin
botched the update/upgrade again, that DNS server will be offline for
3 days again, latencies well over 500ms again because the user of the  
Pi is streaming lots of video again and their ISP does big buffering  
on the router
to make the bandwidth speeds (slightly) better ... at cost of latency, and Pi
admin is doing nothing to (slightly) throttle/shape traffic to keep latencies
relatively low) ... anyway, adding DNS servers like that of such
low reliability compared to our super reliable robust initial 3 DNS servers,
well, in such case, adding such DNS servers beyond those initial 3 typically
wouldn't make the performance and reliability of DNS for the authoritative
servers for the domain(s) being served better now, would it?
So, yeah, ... *most* any rules, some exceptions.  ;-)
But heck, if *all* of the DNS servers were "no better than" (and about the
same as) those Pi examples, then in such case then yes, still, 5 or 7 of
such would be better than 3.  So, yes, it *does* depend.  ;-)

And yes, *not* less than 3, and ... egad sure as hell not less than 2!  8-O

Okay, so *I* could've also better specifically quoted and/or called out
exactly what I was/wasn't referring to on "it depends".

And yes, ... hell no to only one.  Egad.  Just dealt with something like
that in production (8-O!) on *somebody*'s DNS out there somewhere on 'da
Ineterwebs and/or Intranets.  Egad.  "Of course" upon seeing what I saw,
was my first reaction anything like, "ooh, nice, one NS IP only, supper
reliable - that is or would be cool" ... hell no, quite to the contrary.
My reaction upon seeing that was more like WTF!  Did I actually see what
I thought I saw (me double and triple checks the data and various
checks).  And ... after quite verifying, the language, I, "of course"
send the communication that's "WTF!  Are you idiots friggin' crazy?" ...
uhm, ... no, unfortunately not quite, ... have to do it in the environment
in the appropriately politically correct way :-/ ... "unreliable", ...
"fragile", "not robust", "production", "fails to comply with absolute
minimum RFC requirements", etc.  Oh boy, and, egad, too, ... TTLs ...
20 ... yeah, 20 seconds.  Egad.  So, ... even if the *one* (!!!!) IP were
"super reliable", well, Mr. Murphy and his laws ... more than 20 seconds
of loss of connectivity to that *one* (!!!! 8-O) DNS NS IP, and ... sh*t
fails hard (all caching expired ... in 20 seconds!), and, yeah, stuff
breaks.  <sigh>  So, yeah, ... hell no, one is *never* okay, and
so sayeth (require!) the RFCs!

And ... only two?!  I'd *never* recommend it.  Yeah, I've seen folks,
even major companies(!) ... at least in certain limited circumstances,
do it and "get away with it", and (manage to luckily) not have issues
(those two were high availability, robust, ...).  But still, only two
is still playin' with fire.  'Cause, ya know, Mr. Murphy 'n all (and RFC
writers were generally quite familiar with Mr. Murphy, and how surprisingly
regular and predictable - at least in some ways, Mr. Murphy would be
with enforcement of his laws).  So, let's say, hypothetically one only
has 2 - albeit high availability, etc.  So, ... stuff happens - Mr. Murphy,
some required maintenance that's eventually got to be done, whatever ...
then one is - at least temporarily down to only one 8-O - yeah, that's
bad, 'cause then there's zero redundancy, etc. - any additional failure
or issue or whatever and it's zero and one is down hard and fully on the DNS.

So, ... I'd *never* recommend less than 3 ... period.  Certainly not for
DNS (and ditto for NTP, and some other relatively comparable infrastructures).
DNS ain't all that incredibly huge a thing/resource to put in place, so
should always do (at least!) 3 ... period.

Now, when it gets to redundancy of, oh, like an entire friggin' data center -
that's *much* more expensive and takes a whole lot more resources etc. to go
from say, 2, to 3.  I'd still typically recommend 3 or more ... but does
also depend what and how critical are those data centers and what they
provide and keeping at least one on-line at all times.  For some, quite
low but non-trivial probability of both going off-line simultaneously
for some bit 'o time is acceptable or more on the cost/benefit analysis
and the downside risk of both off-line for some bit is (unpleasant but)
acceptable.  Then hey, 2 data centers may be quite "good enough".  But
for a whole lot 'o stuff 3 or more is the way to go.  And ... DNS, really
sure as hell ought always be 3 or more.  Period.  :-)

Anyway, hope that clarifies a wee bit.

Mmmm, Edge Case Theatre!  :-)

Maybe I get a wee bit 'o "revenge" on all the dang English rules and all
their multitude of exceptions I never ever got fully right and complete.

Maybe I ought start with relevant caveats, ... e.g.,
The following only applies to a special/particular < 10% ... < 2% ...
<< 0.0001% of cases, and you're not one of 'em even if you think you
are.  ;-)

And too, often the edge cases are where interesting/critical/important
stuff happens, ... okay, maybe not of interest/use for most/many, but
also, at least sometimes useful/important to at least *some*.

E.g. programming ... a whole lot 'o bugs/flaws etc. are in the edge
case scenarios ... off-by-one errors - yes, just that exactly one case that
goes one bit/byte "too far" or farther than expected or where nobody ever
quite anticipated.  "Oops".  Or temporary file and race condition
vulnerabilities.  Folks commonly forget - Unix/Linux ... multitasking
multi-user operating system.  A whole lot 'o stuff can happen/change
between one system call in a program, and it's next system call, ...
and for many system calls, even much can happen/change between making
the system call, and when the system call returns.

So, ... I tend to call out exceptions when I see 'em ... especially when
they're not mentioned, or when something isn't 100.0000000...% technically
correct without their mention.  Because, well, *sometimes* that stuff
matters ... okay, maybe not *most* of the time, but ... certainly
sometimes.  :-)

And yep, some 'o us may be mucking about in the weeds (which may get some
lost or misdirected ... especially if they're not paying close attention),
while others are whacking down the kudzu.  :-)

Good to whack down the (invasive) kudzu, ... also often of use/benefit
to also study the weeds.  ;-)

And too, ... mix of readers/audience - at a (wide) range of levels.
Some will be quite advanced, and well recognize the exceptions and edge
cases for what they are - while others will find themselves mislead by
such.  Tutorials, introductions, etc., great for many - even often most,
and ... mentioning exceptions in such ... sometimes that's just a
counter-productive distraction ... other times not (and especially /
more so not if it's a mere slight mention/hint that exceptions do
or might exist, without piling on all the gory detail of the all too
rare/unusual/atypical exceptions).

So, ... yep, ... exceptions.  ;-)  DNS servers.  More is better?  ;-)
Well, yes, *generally*, and ... even that, only to some certain point!
Root DNS nameservers (yes, highly exceptional - only a modest handful of
people on the planet deal with the actual administration of such).  And,
how many root DNS nameservers?  13.  And, that is highly and exactly
optimized for that edge case ... of which I'll skip much of the technical
detail as to exactly why.  Suffice it to say the name is very (ultimately)
short for the RR itself.  In the DNS protocol, the name is given (in the
query/response of the actual DNS packets), without the penultimate .
to specify relative to the root - that's implied, and thus omitted, so,
a query for, oh, NS record for ., goes, in the DNS packets (and replies)
as length zero - ending . omitted.  So, that leaves (more) room to fit
other data in ... at least up to the point of certain optimal maximum
use of a *single* UDP packet.  But ... for most or all other domains,
13 DNS servers would be *too many* and sub-optimal.  Good rule-of-thumb?
Something in the range of 5 to 7.