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

[Jan Včelák]

Hello,

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
  repo).

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,

Jan