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? 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel