Date: 26 Jan 2001 17:29:10 -0000
From: "D. J. Bernstein" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| In fact, those servers provided glue for all NS records until recently,
| and they still provide glue for the vast majority of NS records.
Yes, it isn't providing the glue that is hard.
| How do they avoid the efficiency problems? Easy: the glue is pushed to
| the servers by the registrants, rather than being pulled.
Which is exactly what turns out to not work at all well. Either there
is what we have now, a (potentially anyway) secure out of band channel
with which to advise on updates, which then just doesn't get used, or
we have the client's server do the pushing. But it is quite common for
there to be several servers configured to serve the same domain (client
has left one ISP and gone to another - the old one doesn't take down
the server for ages sometimes). Then we have two servers, each wanting
to update the A record for the glue to match what it believes it
ought be (and if the client has used the ns.my.domain type NS value
in both cases, then the registry doesn't even get a clue which is
correct from the name of the glue being updated). Further, it is
quite likely that both might be signed, with SIGS that have not
expired.
All this just gets hard, which is why server pull is the simple
implementation - it just means extra work for the server (actually
receiving and processing the updates is about the same either way,
but the server has to do more checking).
| The TTL on the combination is the minimum, of course.
Which removes useful functionality.
| This doesn't make
| a big difference in cacheability; see my analysis of MX records. (In
| fact, the TTLs are typically the same.)
You mean that not a lot of people know how to use TTLs intelligently,
so let's not allow anyone to do so?
| Excuse me? A moment ago you didn't want to generate extra queries.
I don't think I said that: extra queries will sometimes be necessary.
(I did say that an argument against doing server pull of glue is the
extra work - that isn't my argument though). But that wouldn't be a
result here. The SIG accompanies the A record when the server obtains
it (which would happen with pull or push methodology). It then attaches
it to the answers it sends others (and the others verify it if they
feel inclined, the parent server doesn't need to).
| The SIG semantics don't have to be modified. When the server copies the
| A record, it can also move it into its own zone, sign it, and change the
| NS record accordingly.
No, you keep failing to understand - the server cannot sign anything,
it has no keys available (in general). Signing is (sometimes) done
only by a human (or for even better security, perhaps even a team of
humans).
| Of course, this is functionally identical to signing an NS record that
| contains an IP address. You have to do a lot more parsing, and check
| more signatures, but the end result is the same.
It would be if it were done that way, but that isn't the way to do it
(quite apart from which, the server can't "change the NS record" or
the NS RRSet from the server, and the NN RRSet from the client wouldn't
be the same - which is a configuration bug - a fairly common one, but
still not one we should be encouraging).
| > this has slipped rather far away from issues directly
| > relating to A6 records.
| No. The issues are exactly the same.
But these are all internal DNS issues now, none of it is specifically
related to IPv6 - it would still be better discussed on the namedroppers
list where there is more DNS expertise available than exists here.
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]
--------------------------------------------------------------------
