[dns-operations] Broken delegation
davew at hireahit.com
Sun Mar 9 07:37:47 UTC 2014
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
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.
More information about the dns-operations