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 108.5.242.66
.
.
.
$ grep mournblade /etc/hosts
1.1.1.1 mournblade.imrryr.org
$ getent hosts www.imrryr.org
108.5.242.66 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
