[dns-operations] NS records in Authority for NOERROR responses

Jan Včelák jan.vcelak at nic.cz
Mon Sep 21 14:53:31 UTC 2015


On Friday, September 04, 2015 07:40:42 PM Paul Vixie wrote:
> >> the extra round trip per delegation-crossing you're proposing sounds
> >> expensive to me, compared with having the zone include its apex NS RRset
> >> as BIND does today.
> > 
> > Yes, it's one more RTT. It will get cached though...
> does any validating recursive server detect this condition and do the
> extra query today?

I did a small research:

- BIND trusts glue. 

- Unbound trusts glue unless 'harden-referral-path' is enabled. The default
  is off and it's documented to "burden authoritative servers" and "could
  cause performance problems". I don't fully agree with that and I think it
  could be enabled by default. (Btw, it's enabled by default in Fedora and
  Red Hat.)

- Knot DNS Resolver explicitly asks for the NS record and doesn't "trust" the
  glue (the project is work-in-progress, I tried the last version from the

I'm not aware of any other open-source resolver doing validation. (Dnsmasq is 
out of the game as it can do the validation but can't do the full recursion, 
just query forwarding.)

I also tried a similar experiment with Google resolvers. I set up a secure 
delegation in my testing zone. The NS record in the parent zone pointed to a 
name in the authority of the child zone. The authoritative server for the 
child zone was assigned two IP addresses - the first one was used in the glue 
record in the parent zone, the second one was used in the child zone in the 
authoritative record.

Then I started asking a Google resolver for names in the child zone. No matter 
what I did, the resolver was contacting my server only on the address from the 
glue. I also tried asking the resolver for the address of the name server, but 
still all subsequent queries were happening on the address from the glue. And 
yes, I tried both with Knot DNS and BIND on the authoritative. So adding the 
NS into NOERROR responses seems not to help at least for Google resolvers.

Best regards,


More information about the dns-operations mailing list