Re: Joint DNSEXT & NGTRANS agenda

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

    Date:        Sun, 05 Aug 2001 09:18:47 -0700
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <E15TQc3-000A3p-00@psg.com>

  | You're saying that the I.AM administrators _chose_ to make their domain
  | only sporadically reachable by BIND 8 caches around the Internet?

No, of course not.   That seems to have been the result of a straight out
implementation bug.   When that kind of thing happens, the domain admins
will generally find a way to avoid the bug (which seems to be what happened
here), at the same time, the implementation should be fixing the bug
so it doesn't bite others.

  | A cache can't let a single lookup consume
  | arbitrary amounts of memory! See RFC 1034, section 5.3.3.

Of course it can't.   So an administrator will make sure not to ask too
much of caches, by creating  rational configuration that remains well
within reasonable limits.

That's what people are doing now - the DNS actually works... (despite
all these theoretical demonstrations that it can't possibly work... and
the occasional reported case of things not working).

  | If people start relying on A6 and DNAME, this type of failure---and the
  | other two types described in http://cr.yp.to/djbdns/killa6.html---will
  | become much more common. Are you going to claim that the victims _chose_
  | to screw up their own DNS service?

No, and perhaps for a while, we will see some more failures, while people
experiment, and before they learn what works.  Everything has costs, A6
included, A6's added complexity, and hence more opportunities to accidentally
configure things badly is one of those costs.  Fortunately, A6 also has a
trivial workaround for anyone who isn't sure what is a good config, and
what isn't - they can always just use A6 0, and be just as safe as if they
had used AAAA.   No question about it.   But with A6, I can use a more
complex config if I feel confident of it.   With AAAA I cannot.

What's more, you can always use A6 as a chance to demonstrate your server
indirection if you like - implement A6, and for any A6 n (n > 0) that gets
loaded, have your server go and fetch all of the rest of the chain, and keep
it up to date, so it is always there to be sent to clients in one packet,
so the client can always get all of the data quickly.  Sure the client will
need to expend a little more CPU time combining the RR values (either
the end resolver, or some back end resolver doing AAAA synthesis), but in
the grand scheme of things, that's trivial.

[Aside: just in case anyone thinks otherwise, this isn't just a challenge
to do something I think is a dumb idea - on the contrary, I have for a long
time believed that this is just what servers should be doing, for MX, and
NS, and everything else where there could be a benefit - it is only the
"too much work" arguments that have persuaded me not to try to make this
at the very least a BCP as recommended practice for all servers].

kre