[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals andAI_ADDRCONFIG)
> > > As far as I can see, the only good reason to have the service argument
> > > in getaddrinfo is to make it possible for getaddrinfo to perform SRV
> > > lookups.
> > that's not a good reason, that's a disaster.
> That's a strong word, given that the only effect on lookups in the
> majority of domains that haven't deployed SRV, is one more roundtrip
> to the local caching dns-server.
Wrong. One problem is that the various apps that don't use SRV
now won't all get upgraded at once. So when you turn on a SRV record
you will break all of the clients and servers that don't support SRV
yet. Either that or you have to configure the server to support both
old and new ports. Another part of the problem is that the server has to be
explicitly configured to listen on the alternate port - there's no reliable
way for the server to automatically determine this. So SRV creates yet
another way for DNS to get out of sync with host configuration - another
knob that can be set incorrectly.
And yes, we went through a similar transition with MX records and email;
but the net was much smaller then, and this was a deliberate change to a
single app by the people who maintained that app rather than a change to
every app made by people who had nothing to do with most of those apps.
Even so, my recollection that it wasn't until the mid-1990s that you could
count on MTAs recognizing MX records, even though RFC 974 was published
in 1986. I'd expect the net to transition even more slowly today.
> > it would also tempt NATs to tweak DNS in even more preverse
> > ways than they already do.
> I don't understand how this is relevant. It should work fine unless
> the NAT operator does anything stupid, and that's the highest level of
> NAT-support we can expect for any protocol.
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?
> > there's a reason that RFC 2782 contains the following text:
> > Service SRV records SHOULD NOT be used in the absence
> > of such specification.
> Right, for each particular domain and service, there's a choice that
> has to be made before deploying SRV. In order for SRV-records to be
> used for a particular service, both ends must have it: There must be
> SRV records configured in the DNS-server for the domain, and the
> client must ask for and use them.
and the server has to listen on that port and honor requests.
> The effect of of having getaddrinfo try SRV lookup (or generally,
> having a random client application ask for SRV records by default) is
> to make it possible for the operator of the domain in question to
> easily implement her choice.
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)
SRV can be useful, but its utility varies widely depending on the
application. For some apps it's completely inappropriate. Should
ping honor SRV? What about ssh? SNMP? NFS? FTP? Sometimes a
domain names a service; sometimes it names a host.
and is it really worth it to double the time required to do DNS lookups
FOR EVERY APP, when DNS lookups are already abysmally slow and unreliable?
> My current interest in SRV is that I'm hacking Ian Jackson's resolver
> library "adns" to support IPv6 and SRV.
That's fine and useful as long as you make the SRV lookup optional.
Apps need to choose whether they want to do SRV or not; not have that
choice made for them.
> If there's any good reason why I shouldn't
> recommend random client applications to use this function, I'd like to
> know about it.
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.
> Ah, and one more question: After a first look around for SRV records
> in the current DNS infrastructure, I've found SRV records for the
> following services: ftp, http, kerberos, kpasswd, and sip. I imagine
> SIP, being a recent protocol, actually specifies the use of SRV (I
> haven't read the SIP specs).
It does. I believe there's a spec for use of SRV with Kerberos also.
I am fairly confident that ftp, http SRV records are bogus and should
not be honored by standards-conforming clients.
IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6