On Sun, 27.07.14 19:09, Zbigniew Jędrzejewski-Szmek (zbys...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
