Date: 23 Jan 2001 21:47:40 -0000
From: "D. J. Bernstein" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Your ``alternative scheme'' is server-side indirection.
Matt's scheme was server side indirection, but done by humans, not by
the server. That solves the worst of the problems (how to sign the
data) but introduces all the others that are typical of human maintained
data.
| You go on to complain about the occasional effort required for the
| server to sign records after renumbering.
It isn't the effort, it is access to the key that matters. If the
server (software) is doing the indirection, the software needs access
to the key, or it cannot sign the records. Software access to the
key (on an on-line system like a DNS server) makes it available to
other software to misappropriate.
| This complaint applies to your
| ``alternative scheme'' too. You haven't proposed any way to avoid this
| without creating reliability problems.
Not really - Matt's scheme gave two A6 record chains to the host.
One of them might happen to contain an invalid address sometimes, if
the server hasn't been updated with the new one yet. That address may
turn out to be unreachable on occasion. Nothing different to what we
have now really. It didn't have the server reaching out and building
its own address.
But if we stop postulating servers that are irrational about what glue
they accept from where -- they're willing to take an NS, or A6 record, but
not the glue necessary to make it work? The glue is less reliable than
authoritative data, certainly, but simply refusing it out of hand is
irrational - if the querying server (cache, resolver) doesn't have any
better data available, it ought start by accepting the glue and using it,
not just claiming "that isn't your data to give me" and ignoring it.
If it wants, it can go verify the glue with an authoritative server
after making use of it the first time.
If clients can be expected to use the glue they're given, then the
hard cases can mostly be gotten around by supplying appropriate glue
from the server. Glue has been a part of the DNS from the beginning,
invented precisely to get around the client side indirection in NS
records. I wasn't around that far back, but I wouldn't be surprised
if the client/server side argument wasn't held back then as well,
and we know what the outcome of that obviously was.
I have had about enough of this debate for now - we need to get some
real experience of using A6 records, rather than theories of why they
might not sometimes work. We know that NS and MX records work, despite
client side indirection (even if it is possible to find some odd cases
where the configuration is bad enough that it causes problems). Let's
just find out whether A6 works or not. If it doesn't, we will change
it, or drop it. If it does, they arguments based upon the theory of
why it cannot possibly work (despite the evidence) can be put where they
belong.
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]
--------------------------------------------------------------------
