Wrong names for NS and glue records not in the child zone

Kalman Feher kalman.feher at melbourneit.com.au
Mon Dec 20 12:50:42 UTC 2010




On 20/12/10 11:05 AM, "Laurent Bauer" <l.bauer at mailclub.fr> wrote:

> 
> Hello,
> 
> We (my company) are registrar for a domain name which is delegated to
> our client NS. Our client wanted to change the NS records (just the
> names, same IP addresses) but the registry put the wrong names and
> created glue records instead.
> Obviously the glue records are not present in the child zone, and the NS
> names do not match either, as this is not what the client had configured.
> 
> The registry NS return an authority section like :
>   domain.tld. IN NS ns1.domain.tld.
>   domain.tld. IN NS ns2.domain.tld.
> and an additional section with these glue records.
> 
> The delegation should be :
>   domain.tld. IN NS ns1.domain.com.
>   domain.tld. IN NS ns2.domain.com.
> which are also glue records, by the way, but domain.com. resolution is OK.
> 
> Anyway, my cache NS (bind 9.7.1-P2) still resolves A records for
> www.domain.tld. I flushed the cache before.
> Does it mean that bind ignores the authoritative answer for glue records
> and the NS records ?
Glue records are not authoritative, although depending on the registry in
question they may reply as such. In any case the apex of the zone is
considered the most trustworthy by BIND so it will cache the child zone NS
records in preference to the glue records. Of course once the cache expires,
unless one of the delegation points is accessible from the parent zone (are
all NS records for the domain wrong in the parent?) the domain will no
longer be accessible. You've already proven as much with the +trace. Your
only option is to fix the glue records.
> Is it just because the IP addresses are the same,
> or some kind of tolerance to this kind of configuration error ? Could
> this be an implementation-dependant behaviour ?
> 
> A "dig +trace" query fails with "connection timed out; no servers could
> be reached" when trying to query the authoritative NS for domain.tld.
> While I might find this is the right behaviour that dig only follows
> authoritative NS, is it not supposed to connect to ns1.domain.tld. and
> then return NXDOMAIN for ns1.domain.tld. ?
> 
> My main problem is that the registry tells us there is no problem, as
> the resolution is still OK for www records.
> I would like to explain this, and have other arguments than "the client
> does not want that" or "this will stop resolving the moment the glue
> records change for ns1.domain.com."
> 
> Thanks in advance for any answer to my questions.
> 
> Laurent
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 




More information about the bind-users mailing list