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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Aug 04, 2014 at 06:05:05PM +0200, Lennart Poettering wrote:
> 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?
Yes, totally makes sense. But the name UseDomains is confusing though.
IIUC, we have two separate concepts:
 1. using a specific interface (and a set of DNS resolvers tied to it)
    when resolving specific fqdns (resolve list)
 2. using specifc fqdns when a single-label name is given (search list)

Your description sounds like DHCP.UseDomains=yes would mean using
the DHCP-supplied list for 2. I think it should be used for 1 too.
So maybe there should be

   UseDomains=resolve|search|all

(all in case we add futher options later on).

> 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.

Zbyszek