[conspire] DNS: parent-zone records should match in-zone ones
Ruben Safir
ruben at mrbrklyn.com
Tue Apr 2 18:20:37 PDT 2013
On Tue, Apr 02, 2013 at 04:55:49PM -0700, Rick Moen wrote:
> 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.)
Yeah - George, my cousin who owns TMM.NET stopped resolving without
recursion my domains. Not sure why, but I removed them.
>
> 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.
>
I wasn't sure what you meant by parent, but more importantly, there is a
behavior within dig results that caused me to become confused about the
term "parent". Obviously the whois records propagate to the root
servers (otherwise, whats the point, right?) the dig results did not
return the proper AUTHORITY section reply at either ns1.linuxmafia.com
or www2.mrbrklyn.com until I added the proper NS line in the zone
records, the only zone records I have access to.
I always thought that AUTHORITY section would be populated by the root,
com or org zones. I guess not. BTW - this did not ping as trouble on
this DNS set up check website
http://www.webdnstools.com/dnstools/chk-domain?domain=nylxs.com&nameserver=ns1.linuxmafia.com
so I left the third domain in the registers until I could speak to the
TMM.NET team.
Domain Check Results from the website were as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Running domain configuration checks for nylxs.com...
Specific Name Server Tests (using ns1.linuxmafia.com)
Test Detail Result
SOA Record Checking SOA on name server:
Serial: 2013040202
Refresh: 43200 seconds
Retry: 3600 seconds
Expire: 2419200 seconds
Minimum (default) TTL: 86400 seconds
Primary name server: www2.mrbrklyn.com
Contact: ruben at www2.mrbrklyn.com Info
SOA Serial Number The SOA serial number appears to be in
YYYYMMDDnn format. (Which is the recommended format). This would mean
that this is revision 02 from 02 Apr 2013. Pass
DNS Contact Checking DNS contact email address is valid.
ruben at www2.mrbrklyn.com seems to be valid. Pass
DNS Master Name Your SOA record lists www2.mrbrklyn.com as the Primary
nameserver. This server is listed as a valid nameserver at the parent
servers, which is correct. Pass
Check Missing NS Records 1 All nameservers listed on the parent
servers are listed on this nameserver, which is correct. Pass
Check Missing NS Records 2 All nameservers listed on this
nameserver are also listed on the parent servers, which is correct.
Pass
Glue Record Consistency No inconsistencies were found between the glue
records on the parent servers and the glue records on this nameserver.
Pass
A Record The 1 A record for nylxs.com: 96.57.23.82 [US] Pass
www A Record The 1 A record for www.nylxs.com:
96.57.23.82 [US] Info
MX Record MX Records:
10 www2.mrbrklyn.com. [96.57.23.82] Info
SPF Record No SPF Record. This means that any mail you send from
this domain may get flagged as spam (depending on the configuration of
anti-spam software on the destination mail server). Warn
Check Mail Server Greeting The mail server greeting is
'mrbrklyn.com ESMTP '. Pass
Check Postmaster Mailbox The mail server for nylxs.com accepts
mail for mailbox 'postmaster at nylxs.com'. Pass
Check Abuse Mailbox The mail server for nylxs.com accepts mail for
mailbox 'abuse at nylxs.com'. Pass
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It didn't mind the third record in the registry record. I've changed it
to two NS servers now at the registry. Now that I found the user name
and passwords for them, its not so bad. :)
>
> 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?
Exactly! That is why I didn't understand how dig can return AUTHORITY
information based on the NS record in the zone record from my name
server rather than the root!.
Just because I claim to be the cops don't make me the cops! Ask the
Gardnier Museum in Boston.
> 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
>
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
More information about the conspire
mailing list