On Aug 4, 2014 7:05 PM, "Lennart Poettering" <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: > > On Tue, 29.07.14 14:48, Michael Marineau (<a href="mailto:michael.marineau@coreos.com">michael.marineau@coreos.com</a>) 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 *.<a href="http://redhat.com">redhat.com</a> 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 <a href="http://google.com.example.com">google.com.example.com</a>. and only then <a href="http://google.com">google.com</a>. unless I manually added "." at the top of the list... -- Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> // sent from phone