[systemd-devel] [systemd-commits] factory/etc

[Lennart Poettering]

On Sun, 27.07.14 19:09, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> Hi Kay,
> 
> I know that traditionally myhostname is added at the end. But local
> configuration should be more trusted than DNS (*). It is also more
> trusted then guest machines. So imho the right order is
> 
>   files myhostname mymachines resolve

"myhostname" does two things:

1. resolve "localhost" to 127.0.0.1/::1
2. resolve the local hostname to locally configured IP addresses

Now, 1) is something that should never hit DNS, remote machines should
not have the chance to play games with what "localhost" resolves
to. However, nss-resolve actually refuses to resolve "localhost" anyway,
hence the order between it and nss-myhostname for this doesn't matter.

2) is something where DNS configuration is usually preferable to though,
since DNS generally is administrator controlled, who might have select
one specific IP address to expose, rather than just all of the local
ones, which might include local ones on internal or private
interfaces. Also, for reverse resolution it is usually preferable to get
an fqdn from DNS back instead of the exact string set with
sethostname(). nss-myhostname in this regard is just the fallback for
the cases where DNS information is incomplete or not available.

The result of this is that myhostname should appear after resolve in the
nsswitch line. mymachines should probably have higher priority than both:

  files mymachines resolve myhostname

> 
> (*) One specific example that I've encountered is when local DNS is
> tied with DHCP server, and registers names automatically. Then a
> misconfiguration of the DNS server is likely, and it wreaks havoc.
> Common examples starting to resolve 'localhost' when a computer without
> a hostname configured (and thus using localhost.localdomain as the fqdn)
> acquired an address, or resolving the name of a computer to the address
> of previous lease.

We protect specifically against this by refusing to ever lookup any
hostname for which is_localhost() is true in DNS.

> Also, since DNS is not (usually) secure against attack over the local
> network, by giving DNS higher priority, we open up an attack vector
> where 'localhost' can be spoofed to refer to a different machine, even
> with a correctly functioning server. There's no valid reason to make
> the resolution of localhost* names configurable through DNS, so we may
> just as well do it locally for speed and robustness. The same logic
> is true for the other names returned by myhostname.

I think the locally configured hostname is different here from
"localhost". The latter should never spill into DNS, and we never
will. The former OTOH is something where DNS probably matters more...

Lennart

-- 
Lennart Poettering, Red Hat