Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness

[Paul Vixie <[e-mail]>]

> Date: Thu, 24 Feb 2011 01:36:10 -0400
> From: Brian Dickson <[e-mail]>
> 
> > in this context it means making sure the delegation still exists.
> 
> There is an odd corner case to consider, but I'm not sure if it's been
> considered, and I think it is something which is slightly more likely
> to occur nowadays than in the distant past:
> 
> Suppose a nameserver serves both a particular zone, and a
> great(^n)-grandchild zone.
> (E.g. a nameserver serving some TLD, and simultaneously doing DNS
> hosting for third parties.)
> Suppose also, that some intermediate zone(s), great(^n-1)-grandchild,
> parent of the great(^n)-grandchild zone, is *not* served by this
> nameserver,. but is delegated elsewhere. That "other" server then
> delegates back to "this" server, for the great(^n)-grandchild zone.
> 
> An iterative resolver, directed to this (TLD) server by the root
> server(s), when querying for the great(^n)-grandchild zone, gets back
> an answer for the great(^n)-grandchild *directly* (no passing "go"),
> including that zone's authority data.
> It gets that without ever chaining through the delegations from the
> TLD through the great(^n-1)-grandchild zone(s).

that's fine.

> (Obviously in the DNSSEC case, there would need to be explicit DS
> chasing and proofs included in serving the answer, if DO=1 on the
> client query.)

yes.

> Should not the iterative resolver look for the intermediate referrals,
> if they aren't already in the cache?
> I think it *needs* those to "validate" the delegation... (i.e. for the
> optimization of the present proposal.)

no.

resimprove does not propose any change to the delegation model.  if a
cached ns rrset is received from the servers for the closest bailiwick
then known (for example, from a server for the root zone or a server for
a tld zone) then the 1034/1035 assumption (wrong though it may be, as
shown by your example) is that there are no zone cuts between the
bailiwick and the referral, and this assumption is still valid for a
resimprove implementation.

---

on another topic:

> Consider a query for "foo.bar.no-chickens.example.net.".
> 
> Suppose that "no-chickens.example.net." does not exist (NXDOMAIN and
> no descendants).
> 
> The authority server for example.net returns "NXDOMAIN", which applies
> to the FQDN of the original query (and gets cached there only),
> "foo.bar.no-chickens.example.net."
> 
> I don't think there's anything in the answer that indicates *where* in
> the FQDN, while matching downward, that there was an NXDOMAIN.

right.

> For optimization purposes, it would be good (I think) to establish the
> "best" place to put an NXDOMAIN.
> I.e. Query downward from the zone apex, iteratively, until an NXDOMAIN
> is found. QTYPE = NS is benign and/or informative. This should be in
> parallel, since it isn't needed for answering the original query.

that's way more traffic and complexity than we're proposing in resimprove.

> Putting the NXDOMAIN as close to the root of the DNS tree as possible
> is a clear optimization, since subsequent queries for any sibling of
> the first query, wouldn't succeed.

agreed but that would be a protocol change which we're not proposing here.
in effect, this is what i took florian to mean when he suggested that a
caching recursive name server be able to synthesize nxdomain based on a
cached and secure NSEC or NSEC3.  that's a good idea but it's beyond the
scope of the resimprove proposal.