[systemd-devel] [PATCH] resolved: re-add support for getting local domain from DHCP

[Lennart Poettering]

On Tue, 29.07.14 14:48, Michael Marineau (michael.marineau at coreos.com) wrote:

> When the code for generating resolv.conf was moved from networkd to
> resolved the DHCP domain name code was dropped.

Hmm, we really should figure out how we want to support all of this in
the long run, between networkd and resolved.

Quite frankly I believe the entire "domain" and "search list" logic is
idiotic. It's an invitation for a security breach without bounds. In a
world where DNSSEC is supposed to validate full hostnames, and what they
refer to it's simply wrong to mangle user input like that.

But then again, I figure we cannot just not support it. Administrators
traditionally used that and most would probably defend it as the most
useful thing on earth. But I guess we can at least try to make this less
broken...

For example, I don't really understand where the effective difference
between resolv.conf's "domain" and "search" setting is supposed to be
for resolvers. Why would anyone configure "domain", if he could just
as well configure "search"?

resolved's DNS resolver is actually aware of multiple interfaces and
their specific DNS servers (at least when used in conjuncion with
networkd). It will issue DNS requests in parallel on all interfaces, in
order to deal with the VPN vs. local LAN problem where a company VPN and
the local LAN might both define local, private names, and we should be
able to resolve them both at the same time. For this kind of setup it is
sometimes useful however to bind a specific domain exlcusively to one
interface though, i.e. to disable the logic of simulatenously asking all
interfaces after all. For example, declaring that *.redhat.com should
strictly go into the VPN is a good thing, in order not leak information
about redhat-internal hosts onto public DNS servers... Now, for this
kind of stuff we should allow defining a list of exclusive domains per
interface. This is different from a search list however, as this is
simply about where to route DNS requests to, and not about appending
suffixes.

I think if we apply search lists then we should probably restrict this
to single-label names, for security reasons. That way it will only
compete against LLMNR (since llmnr is used exclusively for single-label
names, too), but never be applied to fqdns. Given that one can trust
LLMNR and DHCP pretty much to the same degree that should be OK. 

So, maybe we should have just two options:

    [Network]
    Domains=list of domains

    [DHCP]
    UseDomains=yes/no (default: no)

Domains= configures a list of domains specific to the interface. This
would be used for DNS routing by resolved, as pointed out above. It
would also be used as search list for single-label names.

And UseDomains= in the [DHCP] section would have the result of adding a
search list supplied via DHCP (either option 119 or 15) to the manually
configured search list (at the end). It would be off by default, for
security reasons.

Does this make any sense? Opinions?

Note that this would be different from glibc's resolver, where the
search list is applied to *all* domains names, regardless if they are
single-label or not. Also, it will be different from existing DHCP
clients, as they all tend to apply the search list supplied from DHCP
without any restrictions.

Lennart

-- 
Lennart Poettering, Red Hat