With ILNP (and probably some of the other proposals that use DNS) there
are not two kinds of addresses.
The addresses used for DNS servers are just like the ones used for the
rest of the system.
The only difference in ILNP is that clients get thos I/L pairs directly
rather than needing to do a DNS lookup to get the pair of fields.
Yours,
Joel
Lixia Zhang wrote:
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
