Date: 5 May 2001 08:43:22 -0000
From: "D. J. Bernstein" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| > An implementation may expire a cached NS RR when its glue expires,
|
| That isn't the RFC 1034 algorithm either. If you're going to claim that
| the IETF specifications are right and that all of us cache implementors
| are wrong, perhaps you should start by reading the specifications.
Huh? That was about records in the cache, right? Implementations are
free to expire any cache record any time they like, up to when the TTL
expires. Bind used to (maybe still does) wind down the TTL quickly as
more queries were made on a name - which sounds exactly backwards, but was
very convenient if you noticed some bad data in a cache somewhere and wanted
it to go away (just send a lot of queries for the name, the TTL would
quickly drop to 0, and the record would be dropped). Of course, bind
most likely should never have had the bad record to begin with, but that's
beside the point - which is that how or when you expire records in your
cache (provided it is done no later than when the TTL expires, or at least
immediately before the next query which would have found the entry, which
from outside looks the same) is your business - use whatever algorithm you
feel best meets performance and reliability aims.
| DNS reliability problems
|
| Out-of-bailiwick pointers destroy DNS lookups in three ways:
|
| * Every out-of-bailiwick pointer means more queries and more
| opportunities for delay: packets are lost and have to be resent.
| The chance of finding an answer before client timeout decreases
| exponentially with the number of out-of-bailiwick pointers.
True. Then we have a balancing act between what is more convenient for
me to maintain, and what is going to work well (enough) in practice.
There's nothing very unusual about that kind of cost/benefit trade off.
The important part is that it is for me, as a zone administrator, to make
that decision. And that is the same for NS records and A6 records.
| * Caches have to limit the number of queries and the amount of
| memory that they dedicate to a single lookup. When these limits
| are exceeded, lookups fail.
Also true. And that is certainly something that I need to take into
account when I am deciding how I will set up my zone.
| * As illustrated by the AOL suicide example, every
| out-of-bailiwick pointer is another opportunity to create a
| loop. When a loop appears, lookups fail.
Nonsense. With proper glue, not being improperly ignored, the aol
example is just fine.
| These problems are not new. Lookups occasionally fail because system
| administrators have used too many out-of-bailiwick NS records, for
| example.
Yes, there can be problems - it is possible for people to break their
setups.
| (I tell my users to select in-bailiwick server names. My
| software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default
| server names for fqdn. I also tell my users to avoid CNAME records.)
That's fine - if I were setting up my domain(s) now for the first time, I'd
be naming my nameservers something like that (I might just use ns1 ns2
instead of a.ns - just to save one byte in each name in the packets - but
that's so trivial as to be close to irrelevant). That's for when I am
delegating my domain to nameservers I run myself. On the other hand, if
I were an ISP with 5000 clients domains delegated to me, then the very last
thing I am going to be doing is creating 5000 different names for each of
my servers, and then having the absolute maintenance nightmare any time I
want to change one of their IP addresses.
CNAMES are often best avoided, but when used in the simple case "a CNAME b"
(where neither "a" nor "b" contains any dots) they work just fine, and
doing this can make maintenance easier.
But by all means, continue to give operational advice to people on what
works well, and why, and what the costs are both ways. Do that for A6
as well as NS records and CNAMES.
| What is new with A6 and DNAME is that out-of-bailiwick pointers are
| _encouraged_. System administrators are _encouraged_ to set up giant
| A6 chains and giant DNAME chains reflecting their corporate
Nonsense - we don't yet know what is to be encouraged. What is in the
doc is just some possibilities on how they might be used. Until we get
operational experience we don't know what to encourage, and what to
discourage.
But you would certainly be free to give whatever you consider to be
good advice to your users as to how to use the things. By all means tell
people that only "A6 0" will ever be reliable enough to use, and that
they should only ever use A6 in that format. That may even turn out to
be correct, though I doubt it.
| I refuse to implement A6 and DNAME.
That's fine, except ...
| I recommend that the A6 and DNAME proposals be terminated.
You will therefore certainly be ignored now. What is relevant at this
point is operational experience, how easily they can be implemented, and
what effects they have on operations when deployed. If you're not even
trying to implement them, then you cannot possibly have anything relevant
to say on either issue.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
