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

[Mantas Mikulėnas]

On Aug 4, 2014 7:05 PM, "Lennart Poettering" <lennart at poettering.net> 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...

On the one hand, it certainly saves a lot of time typing, and I don't see
how it affects DNSSEC given that the validator always sees full names.

On the other hand, it *does* break TLS certificate validation, as well as
Kerberos authentication, both of which want an exact FQDN match.

So 'ping' and 'mtr' is probably 99% of my use of the search list; full
domain name everywhere else. So I probably wouldn't miss the search list
much, myself.

(glibc has a nice alternative, $HOSTALIASES, allowing each user to
configure alias › domain name mappings. Interestingly, setuid programs
ignore that completely for security reasons, so it's unusable with
ping/mtr/traceroute, precisely where I'd want it most.)

>
> 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"?

If I remember correctly from the resolv.conf manpage or somewhere such,
there's *no* difference other than 'domain' being limited to one suffix.

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

In other words, the Linux resolver is finally as smart as Windows has been
for a decade :D

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

Well, I imagine admins *do* filter DHCP packets from untrusted devices.
I've even seen switches capable of this.

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

The one label restriction sounds like an improvement, though I wonder if
someone actually relies on the old behavior.

I always disliked how Windows would first attempt resolving
google.com.example.com. and only then google.com. unless I manually added
"." at the top of the list...

-- 
Mantas Mikulėnas <grawity at gmail.com>
// sent from phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140804/1d4b5faa/attachment.html>