On Mon, 1 Jun 2015, Tomas Hozza wrote:
Yes, we think the change makes sense for Server. It is still beneficial from the security point of view to do the DNSSEC validation on Server.
Agreed.
Even though the configuration on Server will be static, dnssec-trigger + unbound can be used for this. Otherwise it would require manual configuration from the administrator, to enable DNSSEC validation.
That really depends on the network. If there are no split-view DNS, and no DNS firewall rules, just running unbound and resolv.conf pointing to localhost as default would work. But it would be better to use the LAN's DNS server. It will be faster due to the upstream cache, and it will avoid any DNS ports being firewalled. This is either something the admin configures (eg during install or anaconda, or in ifcfg-* files that unbound could use for an unbound-control forward_add) or something that comes in via DHCP. If via DHCP, unbound could have a hook into that (or NM if used) without dnssec-trigger. I see dnssec-trigger only as a tool for roaming devices such as phones and laptops, that have a GUI and an enduser. On servers, the various states of dnssec-trigger makes no sense - especially with the lack of the hotspot problem on servers.
As for the Cloud, we are not sure. Maybe it makes sense on the Atomic Host, but we want to discuss this with people involved in the Cloud product(s).
For lean single application containers or small cloud instances, the focus is probably on not duplicating unbound 1000x times on the same hardware. So yes, those considerations are quite different, and still a hot topic. Does one trust a cloudy DNSSEC server, or do validation within the instance/container. If inside, per-app or per-container? Those would most likely not want to run an unbound daemon, but rely on something like getdns or edns-query-chain and just the DNSSEC root key to do their validation. Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
