Two points
1) Let us bury the idea that more parts reduces reliability. If anyone thinks
that they do not understand the function of TCP and should go and read some
basic networking architecture texts. TCP + IP is more reliable than IP. Ergo it
is entirely possible to onfigure a service such that DNS + TCP + IP is more
reliable than TCP + IP.
It is also possible to design systems such that more layers create less
reliability.
2) From an application point of view example.com and 10.1.2.3 may both be
regarded as names. They are both rendered as an ascii/unicode string. They both
require translation into IP format.
10.1.2.3 is simply a string litteral that may be used in place of a DNS name.
In neither case should the application require knowledge of the IP address
itself. In fact you don't want that as at some point in the distant future,
10.1.2.3 is actually going to map to an IPv6 address, not an IPv4 address.
________________________________
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Bryan Ford
Sent: Sun 12/14/2008 2:51 PM
To: Keith Moore
Cc: tae(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: The Great Naming Debate (was Re: The internet architecture)
So, after being distracted by OSDI last week, I'm now trying to catch
up on the raging debates on TAE that are already exceeding all the
wildest dreams I had before setting up the list... :)
On the issue of weaning applications (and potentially transports) away
from IP addresses in favor of names of some kind, I feel that a lot of
the disagreement results from a misunderstanding of exactly what I
(and perhaps others who have made similar proposals) was proposing...
On Dec 4, 2008, at 10:29 PM, Keith Moore wrote:
Hallam-Baker, Phillip wrote:
I am trying to parse this claim.
Are you saying that the DNS is fragile and raw IP relatively robust?
DNS is layered on top of IP. So for a large class of IP failures, DNS
won't work either. And if IP routing fails, DNS is likely to be
irrelevant because the application using DNS won't work anyway.
And in practice, DNS is quite likely to fail due to configuration
errors, inadequate provisioning, outdated cache entries due to
unanticipated changes, brain-damaged DNS caches built into NATs,
failure
of registries to transfer a DNS name in a timely fashion, etc.
So it's not a question of whether DNS is less reliable than IP (it
is),
or even whether the reliability of DNS + IP is less than that of IP
alone (it is). It's a question of whether increasing reliance on
DNS by
trying to get apps and other things to use DNS names exclusively,
makes
those apps and other things less reliable. And I'd argue that it
does,
except perhaps in a world where renumbering happened frequently, at
irregular intervals, and without notice. And I don't think that's a
realistic scenario.
I entirely agree in principle with your concerns about reliability: if
everything has to work correctly in two layers (DNS and IP), then
that's strictly less likely to happen than hoping everything will work
correctly in only one layer (just IP) - unless DNS can somehow make up
for unreliability in the IP layer, which it occasionally might be able
to do with some effort (e.g., via DNS-based load balancers that take
end-to-end IP reachability information as input), but it usually
doesn't because that's not the purpose of DNS. And I agree that some
applications (and some users) sometimes need to deal with IP addresses
directly, and probably still will need to for a long time, maybe
forever. You seem to be assuming that my proposal was to disallow
such "visibility into the network" entirely, but that wasn't my intent
at all. I just would like it to become no longer _mandatory_ for
every application to know about the structure IP addresses in order to
accomplish anything.
To be specific, there are (at least) three positions we might be in:
1. ALL applications MUST know about IP addresses, in each IP address
format that exists, in order to operate at all. This is the current
state of the world for applications that use the sockets API, because
apps have to call gethostbyname etc. and copy the resulting IP
address(es) into sockaddr_in or sockaddr_in6 structs to pass to
connect() et al. Even though the sockets API is "generic" in that it
supports multiple address families, its design forces the application
to have code specific to each family in order to support that family
at all, which is the key problem.
2. ALL applications MUST use only DNS names for all operations, and
never provide or see IP addresses for any reason. This seems to be
what you're assuming I'm suggesting (i.e., where you say "...by trying
to get apps and other things to use DNS names >>exclusively<<").
That's a world we might hold up as an ideal to strive for eventually,
but it's indeed not realistic in the short term, and it's not what I'm
pushing for. Besides, there may be many different naming or host
identity schemes we might eventually want to support besides DNS names
- e.g., UIA personal names, HIP cryptographic host identities, ...
3. Applications MAY be aware of IP addresses if they need to be for
whatever reason, but aren't ALWAYS forced to have hard-coded
dependencies on the existence and structure of IP addresses by the
API's design. Applications see IP addresses as variable-length string
blobs of some kind - e.g., along the lines Florian Weimer suggested in
another message. Applications can parse/interpret or create these
blobs if they want/need to, but don't necessarily have to if they're
just passing the blob through from the GUI or URL parser to the OS's
protocol stack. This is the position I think we need to be pushing for.
In short, I don't think either the current fascist extreme of an "IP-
address-only API" or the opposite fascist extreme of a "DNS-name-only
protocol stack" is very appealing; we need an environment in which
different kinds of names/addresses/identities can coexist. You'll
still be able to enter an IPv4 or IPv6 address instead of a host name
when you need to, and applications will be able to tell when you do
when they want to, but hopefully not all applications will always need
to care what the difference is.
Cheers,
Bryan
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf