[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:

> > 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. Or if you do lookups in parallell,
you ask for A, AAAA and SRV instead of just A and AAAA.

> 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.

> 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. (To be precise, I'd say that if a
client that asks for SRV records, gets a NODATA answer, and then falls
back to the good old A, AAAA and getservbyname, then SRV is "not
used". You may say there are security issues, but from reading the
security considerations section of RFC2782, I don't think there's a
real problem).

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. The effect is that the client
applications delegate the decision "should I be using SRV records for
this particular <domain,service>" to the operator of the corresponding
DNS domain.

This depends on how you want to deploy SRV, I guess. To me, it makes
sense with a gradual deployment per <domain,service>. And then it
seems useful if applications by default use SRV records whenever the
operator of a domain has bothered to configure relevant SRV-records
in the right DNS server.

My current interest in SRV is that I'm hacking Ian Jackson's resolver
library "adns" to support IPv6 and SRV. This includes an
adns_getaddrinfo function which asks for SRV-records, and in the
absense of SRV-records, constructs a fake SRV-record from A and AAAA
records and getservbyname. Unlike getaddrinfo, SRV lookup is an
advertised feature, and the function returns SRV records, not just a
list of addresses. 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.

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). What about the others, does there exist
any standards track spec, as required by the RFC2782 applicbility
statement, endorsing SRV-records for e.g. ftp, http and kerberos? For
example, try

  host -l sunet.se sunic.sunet.se |grep SRV
  host -l ingate.se usagi.ingate.se |grep SRV

for two domains that are operated by people who I believe are not
clueless about the DNS.

Best regards,

PS. I'm afraid API and deployment issues border on off-topic on the
ipv6 list. Feel free to send followups elsewhere (and Cc: me), or to
answer privately.

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