How to disable DNS lookups?

Roland C. Dowdeswell Roland.Dowdeswell at
Tue Jul 25 20:58:29 CEST 2017

On Tue, Jul 25, 2017 at 08:45:44AM -0700, Russ Allbery wrote:
> "Roland C. Dowdeswell" <Roland.Dowdeswell at> 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
> >	IN SRV 0 0 88
> > that an entry for 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

$ dig
.         600     IN      CNAME  600     IN      A
$ grep mournblade /etc/hosts
$ getent hosts

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:

    Roland C. Dowdeswell

More information about the Heimdal-discuss mailing list