[conspire] DNS: parent-zone records should match in-zone ones

[Rick Moen]

Ruben --

tl;dr version:  Your NS records at the registrar don't match those
in-zone in your domains' DNS.  Fix.  (Make sure future changes of the
two match.)

(Minor second point: /usr/bin/dig and /usr/bin/whois are your friends.
Learn them well.)



I pointed out on the telephone that the NS lines in the _parent_
zone (the ones reflected in whois) are the ones that most matter, not
the in-zone NS lines, and that you most need to ensure the former are
correct.  I infer from our brief conversation that my point was unclear.

Looking over your current setup of mrbrklyn.com.[1]:

rmoen at borgia:~$ whois mrbrklyn.com | grep 'Name Server'
   Name Server: NAMED1.TMM.NET
   Name Server: NS1.LINUXMAFIA.COM
   Name Server: WWW2.MRBRKLYN.COM
rmoen at borgia:~$ 


Those are the three nameservers that are set to actually take all public
traffic (i.e., be authoritative for mrbrklyn.com.).  /usr/bin/whois is
querying the worldwide whois databases adjunct to the central domain
registry.  Changes you make to a domain's data at your registrar get
sent by your registrar ovre the Shared Registry System software to the
back-end registry database that records who owns domains, until when,
with what people in charge of them, and what DNS nameservers are
authoritative for them.

At the same time, the latter item also gets updated to the zonefile for
the parent zone, in this case the com. zone.  Yes, I literally mean that
the zonefile for com. has NS lines saying what the nameservers are for
second-level domain mrbrklyn.com.  

If you think about it for a moment, you'll see why there _must_ be lines
like that for any domain in its parent's zone:  Otherwise, how would
anyone _find_ the domain's nameservers?  If you put NS lines for domain 
mrbrklyn.com. _only_ in mrbrklyn.com.'s own zonefile, there's a
chicken-and-egg problem:  People would be expected to find
mrbrklyn.com.'s nameservers by... asking mrbrklyn.com.'s nameservers?
Plainly, that could not work.  So, instead, any second-level domain
(like mrbrklyn.com.) gets found by looking up the NS lines for it in its
parent zone (like com.).

And because all DNS records can be queried using /usr/bin/dig, that's 
exactly how you can check your glue records:

First, ask what com.'s nameserver are, because you need to ask one of
them a question:

rmoen at borgia:~$ dig -t ns com. +short
m.gtld-servers.net.
l.gtld-servers.net.
k.gtld-servers.net.
j.gtld-servers.net.
i.gtld-servers.net.
h.gtld-servers.net.
g.gtld-servers.net.
f.gtld-servers.net.
e.gtld-servers.net.
d.gtld-servers.net.
c.gtld-servers.net.
b.gtld-servers.net.
a.gtld-servers.net.
rmoen at borgia:~$ 

Then, ask any one of those 'What are mrbrkln.com.'s namservers?'


rmoen at borgia:~$ dig -t ns mrbrklyn.com. @m.gtld-servers.net. +nocmd +nocomments +nostats +noquestion [2]

; <<>> DiG 9.7.3 <<>> -t ns mrbrklyn.com. @m.gtld-servers.net. +nocmd +nocomments +nostats +noquestion
;; global options: +cmd
mrbrklyn.com.           172800  IN      NS      named1.tmm.net.
mrbrklyn.com.           172800  IN      NS      ns1.linuxmafia.com.
mrbrklyn.com.           172800  IN      NS      www2.mrbrklyn.com.
named1.tmm.net.         172800  IN      A       184.172.50.89
ns1.linuxmafia.com.     172800  IN      A       198.144.195.186
www2.mrbrklyn.com.      172800  IN      A       96.57.23.82
rmoen at borgia:~$ 


Notice that m.gtld-servers.net. returns the same three FQDNs
that we got using /usr/bin/whois, and that it throws in the 'A' 
records that corresponds to the name in each NS line.  Those 'by the
way' A-record return values are called 'glue records'.


Anyway, the parent-zone NS lines matter because they are consulted
_first_ to determine where to send the queries.  If your parent zone NS
lines are wrong, your nameservers might not even get the queries at all.

The second thing to note is that the two sets of NS lines for domain --
the ones in the parent zone and the ones in-zone in the domain's own DNS
-- need to match.[3]  When you change one, always change the other to
match.  And you are not yet doing that:

rmoen at borgia:~$ dig -t ns mrbrklyn.com. @WWW2.MRBRKLYN.COM +nocmd +nocomments +nostats +noquestio

; <<>> DiG 9.7.3 <<>> -t ns mrbrklyn.com. @WWW2.MRBRKLYN.COM +nocmd +nocomments +nostats +noquestio
;; global options: +cmd
mrbrklyn.com.           86400   IN      NS      ns1.linuxmafia.com.
mrbrklyn.com.           86400   IN      NS      www2.mrbrklyn.com.
www2.mrbrklyn.com.      86400   IN      A       96.57.23.82
rmoen at borgia:~$ 

Notice two NS items versus three.  (As I mentioned earlier,
named1.tmm.net. appears to be NOT accepting queries, so should 
either be fixed immediately or removed.)


[1] Fully-qualified domain names include the trailing period, which
stands for the notional root of global DNS namespace.  It's a good idea
to get in the habit of including it for use with DNS tools.  (Oddly, 
/usr/bin/whois is confused by the period and does the wrong thing.)

[2] That bunch of options at the end prunes output to just what matters.
No, I don't have that committed to memory.  Just adding '+short' prunes
too much, and no option results in absurd verbosity, so I played with it
until I cut out the fat.

[3] Some consequences of failure to do so:
http://stackoverflow.com/questions/636084/dns-do-the-ns-names-set-for-a-zone-have-to-match-the-ns-names-reported-by-the-u