Re: Joint DNSEXT & NGTRANS agenda

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

    Date:        Wed, 01 Aug 2001 11:44:37 -0700
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <E15S0yz-000Ja9-00@psg.com>

  | For example, when a .com server says barclays.com NS ns1.barclays.co.uk,
  | the client has to go look up the ns1.barclays.co.uk address. Is this
  | because the client is protecting itself against poison? No. It's because
  | the .com servers DO NOT HAVE THAT ADDRESS.

What your web page said was ...

       Even if the address is provided, the cache won't accept it
       because .net addresses are not within the bailiwick of a .com server;
       this is the standard protection against poison.

If the address is needed for correct operation, it is trivially easy
for the COM server to be told it (or even go look it up, as a part of
a server side indirection, other than the volume requirements in that
particlar case).   This is just standard glue processing (the way it
is supposed to be done anyway).

It is only this "standard protection against poison", which is totally
bogus, as I showed in my last message, that would actually cause this
to be a problem that can't easily be fixed.

  | Server-side indirection means that the server _does_ have the address.
  | In this case, the server can easily use an in-bailiwick name for the
  | address, so the normal anti-poisoning rules once again have no effect.

But there's no poison involved, no-one ever said anything about
putting anything in the cache.   All that's relevant is that the
address be associated with the NS record for the purposes of finding
the nameserver, right now.   What the name is should be 100% irrelevant.

  | The client avoids the extra lookups and the possibility of loops.

And instead, the server does the extra lookups, and gets the possibility
of loops?

One of the design goals of many protocols (I wasn't around for the original
DNS design, so I can't say for sure it was one here, but I wouldn't be
surprised if it was) is to take the hard work away from the critical point,
and distribute it.   In this scenario, the DNS server is the critical
point, the clients are distributed all over.   DNS servers typically have
lots of queries to answer - clients usually have nothing much else to do
while doing the name lookup.  Having the client do more work to make less
work for the server is an attractive proposition - even if that means more
overall work for the internet as a whole.

  | The reason I recommend in-bailiwick names within the existing DNS
  | architecture is that those names force the server to collect the
  | address. Putting IP addresses into NS records directly would have the
  | same beneficial effect.

As my previous message showed, if implemented properly, any name can have
the same benefit of the server knows the address, so can supply it.
If the server doesn't know the address, then we're asking that the
additional work be done at the point where it can be done with less impact.

kre