Re: Joint DNSEXT & NGTRANS agenda

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        1 Aug 2001 12:44:45 -0000
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <20010801124445.30844.qmail@cr.yp.to>

  | This ``perverse method'' has been used by all versions of BIND since
  | 1997, and of course by every version of my cache. The need for it is
  | explained in detail in http://cr.yp.to/djbdns/notes.html.

I haven't looked to see whether BIND really does that or not, but there
is certainly no need for it (and I actually doubt it a bit).

To be more clear, the web page (originally) referred to suggests that
the DNS should have originally used

	foo.example.com.	IN	NS	192.168.1.17

instead of

	foo.example.com.	IN	NS	ns.example.com.
	ns.example.com.		IN	A	192.168.1.17

That is, advocating server resolution of indirection.

If one were to assume that that is how things should be done, then
one must also assume that a DNS packet containing

	foo.example.com.	IN	NS	192.168.1.17

encoded in some DNS format binary form would be acceptable.

But apparently it isn't, if the DNS binary form is ...

	foo.example.com.	IN	NS	trash-name.
	trash-name.		IN	A	192.168.1.17

where the 2nd occurrence of "trash-name." is, of course, just a pointer
back to the first one using internal DNS name compression techniques.

Given the currently adopted format for DNS packets, which contains a
(compressible) label as the value of a NS RR, encoding the server side
resolution of the NS record indirection in this (2 RR) way is the obvious
thing to do - it retains compatability with the rest of the deployed DNS.

The pair of RRs given there allow the IP address of the nameserver for
the foo.example.com. domain to be located, which is what is needed to
actually use it to lookup names in the foo.example.com. domain of course.

That's exactly the same as if the NS record had contained the address
in the first place.  The two encoding methods are isomorphic.

For anyone to seriously claim that server side resolution of the
indirection is the way things should be done, and that for some
security or reliability related reason, this cannot be be made to
work, begs credulity.

Note: no-one said anything about caching the "trash-name. IN A .."
record anywhere, or using it for any purpose at all, other than
for finding the address of the nameserver for the domain.

This works for NS records, it works for A6, it works for anything else,
and is exactly as reliable and secure as would putting all of the data
into one RR.

The only difference is in the cases where the extra A record is not
included with the original response, which is a deliberate choice to
trade off some extra round trips (queries) (and hence lower reliability
a little) for the extra flexibility it gives.

  | > for NS records, A6 0 should be used...
  | How is that going to be enforced?

I didn't say it needed to be enforced - I was reacting to the suggestion
that people were being encouraged to use A6 in the way your web page suggests.

But if it were to be enforced, the place to do it would be when the
delegation is done.

eg: right now, if you attempt to delegate a domain in a zone I manage,
your listed NS list will be checked, and if any of those is a CNAME,
rather than having an A record (for IPv4 delegations) then I simply
won't do the delegation.  You either give the name an A record, or
use a different NS name, or your domain isn't delegated.  For IPv6
I can, if I desire, simply check that the A6 record of the NS is an
A6 0 format - if that turns out to be the right thing to do (which the
A6 RFC suggests it probably will be, but until we get it tested it is
hard to know for sure).

  | Are caches going to abort NS lookups that involve A6 indirection?

I expect not, as they don't necessarily abort NS lookups when a CNAME
is found.   That the resolver (a cache is just a storage mechanism for
results that have been obtained previously, it is the resolver that is
doing the lookup) is able to translate the name doesn't mean that it
is the way that it should be deployed.

  | What about all the other ways that A6 can lead to loops?

They will result in lookup failures - just as do CNAME loops, and NS
loops, and all of the other ways that people can shoot themselves.

If you want your names to be useful for people, you make sure they're
entered in a way that works.  If you don't care, then you don't, and
people won't be able to use your name.   That's the way it is now, it
is the way it should remain.

kre