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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf