>From: Keith Moore <[EMAIL PROTECTED]>
>
>> >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
