Date: 25 Jan 2001 19:45:53 -0000
From: "D. J. Bernstein" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I agree with Elz
I'm not sure how you know you agree with me, or how much, but ...
| 1. Servers fetch glue,
This is something I have wanted for a very long time, and have
asked about on the odd occasion. I keep getting told that the
load on the servers for the big zones (COM especially of course)
would simply be too much - considering the number of domains that
have servers that are unreachable (or simply don't know they're
supposed to be servers at all) much of the time, and the number
of queries to be made, the theory is that without spending too
much of the server resources on this, the data for the whole zone
couldn't be fetched before the parts fetched first had timed out
and need to be fetched again.
I've never run a server for a zone that big, so I don't know if this
is an accurate assessment or not of course, but it is hard to argue
against - especially when I know how busy my server gets, serving
a lot more zones it is true, but a lot smaller and less frequently
accessed ones.
| 2. Caches save the NS+A combination: aol.net NS+A 152.163.159.232.
| They don't save the A record separately.
I'm not sure that this as a requirement makes a lot of sense though.
The NS and A records are likely to have different TTLs, and one expire
before the other. Further, should the cache receive the A record from
its authoritative server, and it happens to be different, I think I'd
prefer the cache to keep (and use) that one.
| Of course, this is functionally identical to putting IP addresses into
| NS records,
It is functionally equivalent from the point of view of solving the
problem that you have been referring to recently, yes. Aside from
that though, it is barely even similar. In particular, this way,
the SIG that accompanies the A record would have been fetched by the
server from the auth server for the A record, when the A record was
fetched, and will be passed back to the cache (along with the SIG
for the NS record which comes from the child zone, though there's
probably some technicality of DNSSEC I'm skipping there, DNSSEC around
zone cuts is a mysterious thing).
If the NS record had been designed with the A record in it directly,
then that address would be being signed by the owner of the zone that
uses the nameserver, instead of the owner of the server that uses the
address, which would be the wrong place indeed (correct from a DNSSEC
point of view, but incorrect from a rational point of view).
On the other hand, if the A in the NS was being generated by the
parent zone server as part of the delegation (automatically) then
either it isn't going to be signed at all (and would this be
rejected out of hand by some servers that are configured to only
accept signed data - sometime in the future when this is practical)
or would be signed by the parent zone, which is simply bogus all
around (even assuming that the server can get some kind of access
to the key to do the signing).
| which is exactly how the protocol should have been designed
| in the first place.
And there we don't agree at all.
But I think we should cease discussing the DNS protocols on the
ipng list - this has slipped rather far away from issues directly
relating to A6 records. If there is to be any more on this, perhaps
it ought to be raised again on namedroppers, where there are far
more DNS experts around, including some who were part of the
original DNS design (which I don't think this WG includes any of).
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]
--------------------------------------------------------------------
