On Jan 18, 2010, at 6:08 AM, Joel M. Halpern wrote:
It seems pretty obvious that you handle DNS addresses just the way
you do today. You configure the client (either directly, or via
DHCP, or ...) with the I/L pairs of the DNS servers. Since DNS
transactions are short, the client simply uses each one as a server
individually, and does not try any address agility or other fancy
techniques.
Yes, this should be written down. But it is not hard, nor
complicated, and it certainly doesn't lead to recursion.
It does mean that, just as today, if the DNS server one is using
gets renumbered, the configuration information has to get changed.
Well, it is pretty hard not to need that anyway. For any mapping
system, the mapping data requester has to avoid using the mapping
system to find the mapping system.
Yours,
Joel
PS: If you and Tony want to relax the 500 word limit, I am happy to
add a small discussion of the need for more clarity on this issue.
But given the word limit, I felt I needed to focus on things that
had more impact.
hey ietf motto is "rough consesus", so I suppose our word limit is
also just a "rough limit" as I cannot see why 499 words vs 510 words
would make a writing better or worse. Some text in the original
writing could also be removed without losing much
I think here is how I see the issue:
1/ people argue all the time that every host and every application
depend on DNS.
2/ however DNS itself cannot depend on DNS. This translates to that
all DNS servers must have IP addresses as defined today, i.e. no
composition of two parts.
- All DNS authoritative servers must have their glue RRs carrying full
IP address and stored at their parent zones; no composition. And
- the same for DNS caching resolvers whose addresses must be the full
length without any composition/lookup/whatever, to be configured into
end hosts.
Another specific detail here is that caching resolvers are
not necessarily close to end hosts (e.g. I'm among those
who use own resolver no matter where I go).
My earlier statement seems an accurate summary of the situation: we
are seeing an architecture with at least two types of IP6 addresses,
one for all DNS servers (both authoritative and resolver types),
one for everything else.
(this picture gets me worry, as human beings are not known to always
keep their head straight to tell what is what...)
Lixia Zhang wrote:
I'm late catching up email.
This critique is clearly written, though I do see one important
issue that is missing, i.e. the one Robin tried to raise a few
times: how to handle DNS server IP addresses.
Let me try an example here: say that UCLA implemented ILNP, that
would imply all DNS servers for UCLA.edue that are located on
campus would have ILNP addresses, correct?
But UCLA.edu also needs to put its NS RRs and glue RRs (IP
addresses for NS RRs) on .edu servers, and I assume these glue RRs
must be treated as traditional 16-byte IP6 addresses? (i.e. they
are not subject to further interpretation/composition, a DNS
resolver gets a glue RR and uses it directly to reach the DNS server)
Then are we talking about an architecture with two types of IP6
addresses?
My personal view is that this is not details, it shows that the
design has a recursion: we need DNS to get IP addresses; we need IP
addresses to reach DNS servers.
Lixia
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
