Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

[Brian Dickson <[e-mail]>]

 TL;DR tidbit: IF the combined authority+resolver case (when switching
ISP hosting companies) is not handled  by the QNAME minimization draft,
IMHO it should consider adding it. It is a real-world problem edge-case
seen frequently.


> On Tue, Oct 07, 2014 at 12:04:22AM -0400, Tim Wicinski wrote:
> > Please review this draft to see if you think it is suitable for adoption
> > by DNSOP, and comments to the list, clearly stating your view.
> I do not support accepting the draft (or the proposal it carries) as a
> work item.
> Other than the author - and obviously others - I believe that the
> resolution
> algorithm of RFC 1034 is pretty clear about the QNAME being sent in full
> and that has been operational reality for 25+ years.  A whole system has
> been successfully built around it with complex interdependencies.
> 'parent centric' and 'child centric' resolvers and query patterns
> evolved along that algorithm.  The fact that certain services may have
> experimented
> (successfully, to them) with the proposed algorithm already gives anecdotal
> evidence at most, but no evidence for the absence of harm.
> Making the zone cut, an otherwise arbitrary boundary, a central search
> element, is another huge paradigm shift that I see "with great interest".
> Please don't anyone tell me that's the case with DNSSEC already - the story
> there is different.
> Finally, QNAME minimization is providing little gain in the traditional
> forward tree and already needs kludges in deeper, nested name spaces.
> Comparing the (little) gain with the unclear risk, I'd rather see work and
> energy devoted to a long term solution.
> -Peter


There are two places where there is potential impact, by definition:
- recursive resolvers
- authority servers

The case for recursive resolvers is plain: any QUERY below an NXDOMAIN
can avoid querying the parental unit of the original NXDOMAIN.
The problem being solved is DOS of recursive resolvers.

The argument implicit in Peter's message is, there is little or no gain on
the
authority server side.

I would like to illustrate one example case which, however rarely it occurs,
can be made moot by QNAME minimization.

Here is an example case in bullet form, showing delegations and a change.

example.com is administered by one department, and delegates administration
of other departments to their respective nameservers. The group that does
the administration of example.com is a sub-department of one of the
delegates.

Now imagine that the sub-department migrates its own zone from the shared
nameserver of example.com, to its own separate nameserver. In doing so,
imagine an error is made - the zone in question is not removed from the
example.com nameserver. (It is like a lame delegation only in reverse.)

Nomenclature for the example: X:Y means server X hosts zone Y.
Before:
X:example.com -> Y:foo.example.com -> X:bar.foo.example.com
After:
X:example.com -> Y:foo.example.com -> Z:bar.foo.example.com
(but X:bar.foo.example.com still exists).

No QNAME minimization: Querying X for www.bar.foo.example.com
returns the values on X, instead of the values on Z. Admins looking
at servers Y and Z fail to see why this is occurring.

QNAME minimization: Querying X for www.bar.foo.example.com
gives delegation to Y, etc., eventually returning values from Z.
The presence of the undelegated instance on X never causes problems.

This might happen rarely in Academic institutions, but is more likely to
happen
when a ETLD registrant changes hosting providers/ISPs, and where the old
hosting provider/ISP does not follow BCP, and combines authoritative service
and resolution on the same DNS servers. Old (and now undelegated) zone
data gets served.

Brian