From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
even if you do this the end system identifier needs to be globally
scoped, and you need to be able to use the end system identifier
from anywhere in the net, as a means to reach that end system.
DNS is a bright and successfull example of such deal.
actually, DNS is slow, unreliable, and often out of sync with reality.
DNS reverse lookup tables (PTR) are not as well maintained as forward
lookup tables (A) so they're even less reliable.
(Bill Manning has another mind here - read it, please)
hosts often don't know their own DNS names, so they wouldn't know
their connection endpoint names either.
DNS names are often ambiguous - because a single DNS name corresponds
to multiple hosts (all implementing the same service) or because a
single host supports multiple DNS domains (a different name for each
service) or both.
Yes, it is a reason why we can't use today domain names as system ID.
But it means that we should shift consideration to appropriate level -
- IP addresses. The second level of indirection arises but it is not
bad as long as we do not decrease a setup speed.
the binding between a DNS name and an address is not the same thing
as the binding between an address and a connection endpoint. the
two have different purposes and different lifetimes.
I agree here.
when people say "DNS can do the job" they may be saying different
things, e.g.
(a) they are thinking in terms of using existing DNS servers,
(b) they are thinking in terms of using the DNS protocol, having
translation occur at the boundaries between routing goop realms
(similar to NAT's DNS ALG), or
(c) they are thinking in terms of a DNS-like system, but not DNS
I speak about (c). Routing addresses may be handled by providers
but not end-user. It should be
(1) more accurate
(2) more fast
(3) independent in terms "rule of game" (may be chanded later
without rewriting all)
with separate servers (whether they are existing DNS servers or not)
there is the problem of keeping the servers updated as to the
current condition of the network.
with DNS at translation boundaraies there is the problem of
"call setup overhead" (having queries propagate through
multiple layers of translation until they reach their destination
network) also in this case DNS becomes a routing protocol of
sorts, since the thing you advertise from one realm to another
becomes a DNS suffix rather than than an address prefix.
it's not at all clear that this scales.
Keith, it depends from design. I can propose
(1) caching,
(2) implicit router resolution on each DNS A? query (each TCP setup
precedes DNS A? query or using cached values) - "router DNS" may track
each DNS query/response and append routing prefix to response.
In this case there isn't any time lag... at least up to TTL expiration.
(3) Separate network datagram service addresses from connection-oriented.
We have two real network datagram services now - DNS and may be NTP
(Voice RTP traffic or like UDP is in real a connection-oriented srvs)
But I don't afraid "call setup overhead" (see previous) because I afraid
only call setup speed decrease and support issues. As long as call setup
speed is not changed and support simple I like it.
in either case having to do a DNS-like query before you can transmit
is slow compared to just sending a packet to an IP address.
We can implement technics which do both in the same time.
We do not need to replicate DNS again. We should admit that DNS is
network service in conrast with end-customer srvs and handle it different.
It means that different service rules and may be different set of addresses
may be used for this. The same is in BGP - there is a practice to hide
inter-router addresses of provider backbone, for exam to increase security
and give additional flexibility of backbone configuration.
Keith
p.s. if there's ever going to be a split between endpoint names and
routing goop, I'm convinced that endpoint names have to be usable
by themselves
Yes.
(perhaps with some speed penalty), that the
mapping between endpoint names and routing goop needs to be maintained
by the routing infrastructure rather than in some separate database,
Yes ! Yes !
and that the lookup needs to be able to be done implicitly (as a side
effect of sending packets without routing goop to their destination)
rather than explicitly. I think such a separation might be a good idea,
because our current means of propagating reachability information
and computing routes does have limitations. but I don't see any need
to change the packet format seen by hosts (from IPv6), or any need to
change end hosts at all, in order to do this.
Keith, sorry, didn't read this p.s. before I wrote answer on main
mail body. You absolutely understand me, thank you.
- Leonid Yegoshin, LY22