On Tue, Jul 25, 2017 at 08:45:44AM -0700, Russ Allbery wrote: > "Roland C. Dowdeswell" <roland.dowdesw...@twosigma.com> writes: > > > In the longer term, we should likely stop using getaddrinfo(3) for names > > obtained from DNS SRV RRs and directly query DNS for them as this matches > > expectations. That is: you wouldn't expect that if you find > > > _kerberos._udp.my.realm IN SRV 0 0 88 foo.my.realm > > > that an entry for foo.my.realm in /etc/hosts would then override the > > DNS for it. > > Eh? I *absolutely* would expect that and would consider it a bug if it > did not. It is incredibly useful for testing to be able to temporarily > override the IP address of a host in /etc/hosts, and I expect all software > to honor that.
SRV RRs are essentially a generalisation of CNAMEs or perhaps MX records. It is counter-intuitive to expect that /etc/hosts will interpose in the middle of a lookup. Even using getaddrinfo(3) as demonstrated below, we see that /etc/hosts does not interpose when resolving CNAMEs into addresses. $ dig www.imrryr.org . . . www.imrryr.org. 600 IN CNAME mournblade.imrryr.org. mournblade.imrryr.org. 600 IN A 220.127.116.11 . . . $ grep mournblade /etc/hosts 18.104.22.168 mournblade.imrryr.org $ getent hosts www.imrryr.org 22.214.171.124 mournblade.imrryr.org www.imrryr.org As you can see, getaddrinfo(3) will only use DNS to chase the CNAME defined in DNS and does not consult /etc/hosts in the middle of a single lookup. This is exactly analogous to our proposal which is to eventually disable the /etc/hosts lookup by not using getaddrinfo(3) when resolving the intermediate DNS results returned by the SRV RRs. MTAs, e.g., expressly go out of their way to resolve the hostnames obtain from MX record via DNS and not getaddrinfo(3). However, just as we are proposing, MTAs will use names directly from /etc/hosts if no MX RRs are found---or if they are configured to directly communicate with a host via a transport/mailer table override or the like. There are many reasons for this behaviour but the main ones are: 1. it isn't intuitive to bounce back and forth between different name spaces in the midst of a query, and 2. DNS SRV RRs contain fully qualified domain names and getaddrinfo(3) does not have a standard way of disabling the search path. The fact that Heimdal appends a dot to disable the search is a work-around which causes additional unintended confusion as we have previously seen on this thread. So, I think that our best short term path forward is to restrict the current dot-appending work-around to names obtained via DNS SRV RRs. This matches the current MIT Kerberos behaviour as seen in: https://github.com/krb5/krb5/blob/master/src/lib/krb5/os/dnssrv.c#L235 -- Roland C. Dowdeswell