On Mon, Aug 04, 2014 at 06:05:05PM +0200, Lennart Poettering wrote: > On Tue, 29.07.14 14:48, Michael Marineau (michael.marin...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel