[conspire] What happens when ... DNS ...

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> Do not presume malice for that which can be explained by incompetence[1]

Possibly you missed my own explicit invocation of Hanlon's Razor (in my
initial post to Mark Olsen et al.).

Even in my sharpest-worded (and latest) response, I didn't claim anyone
was lying.  I merely said that x7hosting's claim (that this all is a
domain registration) makes no sense and is a bit pathetic.

> So, let's check/confirm ...
> and I typically wouldn't *start* with registrar and whois, if it is or
> presumably is a DNS proble/issue ... though that is *also* a fine
> starting point (and especially fine if one wants to check through
> everything from top, to bottom).

Which is why I started there.  ;->

> So, first, let's start by finding NS records for org.  I do this via
> +trace, to get us the basic top-down, from DNS on that.

Doesn't tell us anything we didn't already know from the WHOIS list of
authoritative nameservers, though.

(In my very first comment to Mark Olsen and the others, I mentioned that
there were two ways to find the authoritative nameservers.  One is the
method I used, selecting it as least painful for very non-technical
readers.  The other is explicitly following the chain of authority from
the root nameservers to the TLD to the domain.)

> The +trace option of dig(1), well, man page words it better than I could:

One of my favourite tools for investigating DNS problems -- but also one
likely to scare off newbies.


> So, now I check against one of those NS servers for org.  This is teensy
> bit of shortcut, as I've not looked at whois(1) data for the domain, but
> if things look as expected at org., then I don't particularly need to
> look at whois(1), unless perhaps I want to also confirm that that
> matches as expected to data I'm seeing from the org. nameserver(s).

I'm pretty sure you actually don't need to consult WHOIS at that point 
(having done +trace).  In all cases, WHOIS reflects for its 'Name
Server' lines the parent-zone records, and you'd just (at that point in
your narrative) traced down to those records using dig.


[...]
> Well, that's both a bit odd/unexpected (until we take their incompetence
> into account).
> 
> We see above, that the DNS server *is* answering, and not that the
> domain doesn't exist (which would have shown as NXDOMAIN), but it's
> response has exactly no records - so the answer is, according to that
> DNS server, that the record doesn't exist - no SOA record for that
> domain, and likewise no NS records.  Both incorrect answers, but a
> rather odd one.  

Not a complaint, just an observation, Michael:  This whole passage
duplicates what I already reported.  However, you then go on to add
something interesting & useful that I hadn't figured out before:

> It's not NXDOMAIN, so the domain exi[s]ts.  But no SOA
> record and no NS records.  So that implies it's directly under org., and
> not delegated ... not true, but that's what the data implies.  And DNS
> clients will presume the data is correct.  So, from that, they may cache
> that result.  How long?  Well, not delegated (per what the server
> claims), so we go up to a domain that exists - org. in this case - and
> use its
> MINIMUM a.k.a. Negative Cache TTL

Hey, now that's interesting, and I just learned something about a fine
point.  A little history (that you are doubtless familiar with):

The last subfield in the SOA record _used_ to denote default TTL.
Starting 1998, RFC 2308 repurposed that subfield to mean 'negative TTL'
http://tools.ietf.org/html/rfc2308 
If you wanted to declare a default TTL for the zone, you could do so
using the (I assume invented for that occasion) '$TTL' directive.

Anyway, I commonly think of negative TTL as meaning the caching duration
that will be applied to NXDOMAIN ('this thing you asked about doesn't
exist') answers.  Skimming RFC 2308, however, revealed that NXDOMAIN is
one of only several 'negative responses' to which this caching value
will be applied -- and one of them is 'NODATA', described in section 2.2
as 'an answer with the RCODE set to NOERROR and no relevant answers in
the answer section'.  Which is indeed what that nameserver gave out.

Thank you for solving the mystery of what caching value would apply to
that bizarre erroneous DNS answer.


> Oh, and possible ugly kludge of a work-around?  If the DNS server that's
> giving bad answers is consistent in its DNS name, remove the NS records
> that delegate to it.  So, remove the NS record:
> fanac.org. IN NS ns4.x7hosting.com.
> and likewise remove the delegation ... so for fanac.org.,
> that would be remove ns4.x7hosting.com from among its listed DNS
> servers.

Yeah, but, y'know?  I'd just fire the whole outfit.

I erred on the side of tact and restraint in talking to these three good
folks (one of whom I know pretty well, the other two not really),
because I didn't want them to dismiss me as a crank techie jumping to
the conclusion that their hosting provider is incompetent and should be
fired.  So, instead I said you _could_ ask them to fix these three
problems, but I have low expectations about that, and mentioned the
alternative of just using different DNS -- which I pointed out exists 'a
la carte' relative to Web hosting.

Had I not been erring on the side of tact and restraint, I'd have said
'Fire these bozos immediately.  Use DNS providers who don't make grave
DNS errors and try to blame others when those are pointed out.'

> As only one of the four accepts TCP connections, well, if one reduced to
> single DNS server, there are at least two potential problems.  That's
> generally a no-no per RFCs (and for good reason - only one and there's no
> redundancy or fail-over capability if that IP can't be reached) - should
> have at least two, and preferably at least three.

FYI, RFC 1912 recommends minimum three, maximum seven.  Two is the
minimum _permitted_[1], and domain owners should always set three as the
smallest amount of redundancy to settle for.  (I personally go with five
as a good middle value.)

> One can also get good competently managed DNS for free*!

Heck yes.

RFC 1918 section 2.8:  'You are required to have at least two
nameservers for every domain, though more is preferred.'