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

[Rick Moen]

Quoting Ruben Safir (ruben at mrbrklyn.com):

> 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.

Good, confirmed:

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

Funny thing, that:  People will do your secondary for years and then
suddenly cease doing it for no particular reason and without notice.

These days, I actually have a cron job that runs every Sunday to check
up on my secondaries.

> 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". 

The parent is the next layer of domains up towards the root.

uncle-enzo.linuxmafia.com. is under linuxmafia.com.
linuxmafia.com. is under com.
com. is under .  (the root).

> 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.  

Yes, you need the in-zone NS lines -- but no, you _do_ have access to
the parent-zone records for mrbrklyn.com. inside the zonefile for com.:
You edit them via changing the nameserver roster inside your domain
registrar's admimistrative tools for your domain.

That's what I was telling you.  Now, I'm telling it to you again in
slightly different wording.  


> 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

You really don't need those things (i.e., that CGI and the other ones
I cover at http://lists.svlug.org/archives/svlug/2013-March/058021.html). 
All you need is dig and whois, along with a tiny bit of attention to
what you're doing.


> so I left the third domain in the registers until I could speak to the
> TMM.NET team.

Look, how many times do I have to say it?  _Always_ verify that a
nameserver is actually serving up a domain's zone data _before_ making
it authoritative at the registrar.  Always.  Never the other way.


> Domain Check Results from the website were as follows:

Look, did you _really_ need to dump that entire thing into a mailing
list posting when you already provided the URL?



> 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!.  

1.  The DNS _root_ is not directly invoved except as the notional origin
point from which authority descends.  Your phrase 'based on...the root'
doesn't really make sense.  I suspect you're making some sort of bad
assumption about authority.

2.  dig's AUTHORITY-section return values are intimately connected to
the flow of DNS authority from the notional root through the parent-zone
nameservers (com.'s, in this case) to your nameservers.

Anyway, the AUTHORITY section merely states for a given query result
what servers can give an authoritative answer to your query.


For your longer term, I suggest getting clear about: 
How DNS authority works.
What glue records are.
Correct user of the CNAME type.
How to use dig for various RR types including PTR (and the -x option).
How delegation works.
How to use rndc.
How to use named-checkconf.
How iterative and recursive queries differ.