[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG)

Keith Moore <moore@cs.utk.edu> writes:

> NAT vendors do stupid things all the time, like producing NATs that
> modify the contents of packets where they don't even know what protocol
> is being used.  What makes you think they would stop there?

*No* protocol can work under the assumption that there's a NAT box on
the path that makes arbitrarily stupid changes to packets. Therefore,
it's not possible or useful to consider that scenario in protocol or
application design.

> Funny, you want the admin to have this choice, but you apparently
> don't want the application specification to have a choice (as RFC 2782
> insists must be done)

The default ssh port is 22. Say that I operate an ssh server, and for some
arbitrary reason I want it to listen on a different port, say 80. To
make this work, I can send out a mail to all my users telling them to
use ssh -p 80, and hope they read and remember that. Or I could
install an SRV record in the DNS tree that says that I'm using port
80, and hope the the users' ssh clients will notice. Or both.

The ssh spec only says that "the server normally listens for
connections on port 22", and that the number is registered with IANA.
Just descriptive, no normative language at all. Given that, I can't
read the ssh spec as saying which methods, email or SRV or a sign on
the wall, I may use to tell my user's and their ssh clients that I use
a different port.

> SRV can be useful, but its utility varies widely depending on the
> application.  For some apps it's completely inappropriate.  Should
> ping honor SRV?

To use SRV for ICMP ping seems quite far out.

> What about ssh?  SNMP?  NFS?  FTP?  Sometimes a
> domain names a service; sometimes it names a host.

If the server administrater wants it: Sure. Nobody else can really
decide whether or not SRV is "useful" or "appropriate" for a
particular service instance.

> The reason is: it violates the SRV specification to use SRV with an app
> that doesn't specify the use of SRV, and it also violates the specifications 
> of those applications that specify a port number to be used.

> I am fairly confident that ftp, http SRV records are bogus and should
> not be honored by standards-conforming clients.

Thanks for the answers, even if I'm not totally convinced.

Let's look at http again, where the spec for http-url:s says clearly
that of no port number is given explicitly, port 80 should be used
(the text is descriptive here too, "if the port is empty or not given,
port 80 is assumed"). Say I have a SRV aware browser that breaks the
spec and looks up _http._tcp SRV records, and uses ports given in SRV
records instead of the default port 80. Then my SRV aware browser and
a traditional browser will get different content for the same URL,
which seems like a bad thing. But that's not a new problem. One
example is http://www.kame.net (CNAME orange.kame.net), where you,
intentionally, get slightly different content for the same URL
depending on whether or not your browser and operating system happen
to use IPv6. I'm not sure it's a real problem that this kind of
"misconfiguration" is possible.


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6