Christian Vogt wrote:
Keith -
thanks for the careful elaboration. I agree with you that it is very
important to consider the DNS-related issues that you identified when
designing methods that make new use of the DNS. But note that the
hostname-oriented network protocol stack architecture, as proposed in
[1], does not change the semantics of DNS hostnames. It continues using
DNS hostnames as an alias for a set of IP addresses. And as today, for
this is does not matter whether the IP addresses in a set are from a
single host or from multiple hosts. I therefore do consider the use of
the DNS in [1] feasible.
Perhaps I wasn't "careful" enough in my elaboration, because in my mind
the problem with an API that tries to make all endpoint names be DNS
names is NOT a problem with some "new use of DNS", but rather with DNS,
and DNS names, as they are currently used.
In a nutshell, the hostname-oriented stack architecture functions like
this: It provides a new, backwards-compatible API through which
applications can initiate connections by specifying a pair of service
name and DNS hostname. [...]
Yes, I did read the document before labeling that approach as naive.
The service name is a well-known string replacing the overloading of
port numbers for the same purpose, and the hostname maps to the set
of IP addresses through which the service is currently reachable.
I'll never forget the time, back when I ran a mail server for a few
thousand users, that mail started dropping on the floor because a call
to getservbyname ("smtp", "tcp") inside sendmail started failing.
The call failed not just because some dim bulb at Sun decided that it
would be a good idea to take an API that originally did a flat file
lookup and reimplement it with an RPC to an NIS server that didn't share
fate with the caller (not to mention several other fragilities
associated with NIS). On a deeper and more important level, the
failure happened because the whole idea of getservbyname (and similar
things, including the service name parameter to getaddrinfo) is
brain-damaged [*]. "smtp" is not better than 25, and adding an extra
layer of indirection just to make the port number be human readable is
not an improvement. The SMTP protocol specification says that
connections are to be made to port 25, not to the port returned by some
indirection layer.
When a protocol specification says that a connection is to be made to
port 25, the correct way to write code to implement that specification
is to tell it to connect to port 25. htons(25) doesn't fail nearly as
often as getservbyname("smtp", "tcp").
So I have to really wonder what you mean by "overloading" ports when
they're being used exactly for their intended purpose.
The right time to start insisting on use of ASCII endpoint names in APIs
(and this includes ports) is when destination hosts start using ASCII
endpoint names to demultiplex traffic. Doing it anytime sooner is just
asking for more failures in a network that's already inexcusably fragile.
Similarly, a
DNS hostname can be specified to filter incoming connections based on
the IP addresses that this hostname currently maps to.
And that way, if someone can spoof the DNS response, or compromise the
DNS server, it becomes possible to bypass the filter. nice.
I am not a big fan of using a source IP address as an authentication
token. But if people are going to use them, they should do it right. A
network admin who believes that all sources of traffic coming from
prefix X/Y are benign (or hostile), should specify specify his filters
in terms of permit (or deny) prefix X/Y and NOT in terms of some DNS
name which might or might not equate to prefix X/Y at some point in time
(depending on whether the network is up, the servers are up and
reachable and correctly configured, nobody is spoofing DNS or you have
all of your DNSsec configuration right, etc.)
And yeah, everybody complains about renumbering pain these days because
nobody has yet figured out how to make core routing scale without
renumbering from time to time. But trying to make it easy to renumber
everything might just be optimizing for the wrong case, especially if
doing so compromises the reliability and security of enterprise networks.
The three main benefits of the hostname-oriented stack architecture are
consequently as follows:
- Application programming becomes potentially easier.
only if (a) the application can reasonably avoid dealing with that
complexity (some can, some cannot) and (b) setting up a network
connection is the one of the more difficult thing the app has to do.
these days, in my experience, it's really far down on the list.
- IP address changes, such as for mobility or multi-homing, do not
disrupt ongoing sessions.
uh, no. not unless you're changing a lot more than the API (like the
transport protocols), and you're also providing a way to do secure
signaling of changes to endpoint addresses (consider that the endpoints
are often the last to know about such changes, and once their addresses
are changed they have no way of reaching their peers), and you're also
providing a way to make all referrals work in terms of the DNS - another
significant challenge, BTW.
solve these problems first and then your API might deserve serious
consideration.
- Transition to IPv6 no longer affects applications.
wrong again, because (among other reasons) IPv4 only hosts will still
not be able to talk to IPv6 only hosts.
The reason for all of these benefits is that applications use DNS
hostnames exclusively and do not have to deal with IP-address-related
functions. And still, the semantics and the use of DNS hostnames remain
as they are today. And I hope this resolves your concerns.
I'm afraid you've made me even more concerned.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf