[dns-operations] CNAME into a delegated zone goes wrong.... any ideas?

Jeroen Massar jeroen at unfix.org
Sun Jun 12 22:43:47 UTC 2011


On 2011-06-13 00:31 , Steven Carr wrote:
> On 12 June 2011 23:15, Jeroen Massar <jeroen at unfix.org> wrote:
>> I agree, but why does 'dig' not go forward and ask nsX.sixxs.net for the
>> final answer then? Authoritive servers (eg the root ones) are not
>> recursive either, they also, just like the nsX.paphosting.net ones just
>> return a referral to the NS that does have the answer. the paphosting
>> NS's don't claim authority for ntp.sixxs.net thus it is not a final...
> 
> Because dig is a lookup tool, not a recursive nameserver.
> 
>>> Querying 8.8.8.8 normally returns the correct list...
>>
>> Yep, and I assume that that is because the google DNS servers are
>> non-BIND, as with unbound recursors it also works, but if I use anything
>> which builds upon BIND-based tech it fails...
> 
> Because there is an error in the zone configuration, the logs on my
> BIND server show:
> 
> 12-Jun-2011 23:23:07.419 DNS format error from 62.220.146.194#53
> resolving ntp.us.sixxs.net/A for client 172.16.0.20#62548: multiple NS
> RRsets in authority section
> 12-Jun-2011 23:23:07.502 DNS format error from 94.142.245.3#53
> resolving ntp.us.sixxs.net/A for client 172.16.0.20#62548: multiple NS
> RRsets in authority section
> 
> The authority records that come back from a "dig @ns.paphosting.net
> ntp.us.sixxs.net" show...
> ;; AUTHORITY SECTION:
> ntp.sixxs.net.		3600	IN	NS	ns1.sixxs.net.
> ntp.sixxs.net.		3600	IN	NS	ns2.sixxs.net.
> ntp.sixxs.net.		3600	IN	NS	ns3.sixxs.net.
> sixxs.net.		3600	IN	NS	ns.paphosting.net.
> sixxs.net.		3600	IN	NS	ns.paphosting.nl.
> sixxs.net.		3600	IN	NS	ns.paphosting.eu.
> 
> ...therefore BIND doesn't know who to query and drops it - the
> sixxs.net. servers should not be being returned in the Authority,
> there is no real need to return them at all, but if it does then they
> should be in the Additional section.

That is it.... thanks!

Now to figure out which box actually does it and why. Fortunately it is
all NSD, thus this then most very likely is a nsd bug.

Now to get over to the nsd list to see if either we got it wrongly
configured or it is some kind of a bug ;)

Greets,
 Jeroen



More information about the dns-operations mailing list