[dns-operations] Broken delegation

[Dave Warren]

On 2014-03-08 14:08, Paul Vixie wrote:
> in general, delegations have to meet only two conditions. first, every
> name server that's designated by an NS RR above or below a delegation
> point has to be authoritative. second, the set of NS RR's below a
> delegation point (so, at the zone apex) has to be equal to or a superset
> of the set of NS RR's above that delegation point (so, the parent's
> zone-leaf).


So what actually breaks if a zone contains a subset of the NS? Or an 
alternate set of authoritative servers completely?

For example, if existing-customer.example uses some combination of 
ns[1-5].old-isp.example, and my servers have a zone that only has NS 
records for ns[1-5].hireahit.com, what will break?

(All servers will be slaved to my master, all NS records will point to a 
server willing to answer authoritatively, and eventually 
ns[1-5].old-isp.example will match ns[1-5].hireahit.com's IPs)


> note that scraping the TLD's isn't a reliable way to find all the
> invocations of your NS RR name, partly because not all TLD's have ZFA,
> and partly because not all delegations are in TLD's. passive DNS is your
> better answer here.


Given that I already have a list of zones that are on the server now, 
I'm not really sure how passive DNS would help, although I may be 
missing something obvious -- The goal isn't to discover the list of 
zones, I have that list already; my goal is to discover the NS records 
that are delegating to zones that I now control so that I can match 
those NS records within the zone itself, ensuring that my zone equals or 
contains a superset of the appropriate NS records.

Without this process, I'll end up offering an entirely different set of 
also-valid name server records, which from what you described above, 
might be a problem.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren