Am 13.04.2014 03:07, schrieb Paul Wouters:
On Sun, 13 Apr 2014, William Brown wrote:
When they change records in their local zones, they don't want to have to flush caches etc. If their ISP is unreliable, or their own DNS is unreliable, a DNS cache will potentially mask this issue delaying them from noticing / solving the problem.
This is becoming really contrived. Again, if you think this is a real scenario (I don't think it is) than you could run unbound with ttl=0
i would run BIND and not unbound in any case and now? would you pull me unbound as dependency?
But a requirement of automagically understanding what a local zone is and automagically understanding when a remote authoritative dns server changes data, and not willing to enforce that with ttl=0, and using that as argument why any solution of unbound to provide a security feature (DNSSEC) is getting a little unrealistic. If you want your laptop to start validating TLSA and SSHP and OPENPGPKEY records, you need DNSSEC validation on the device. The question should be "how do you change your network requirements to meet that goal". Yes, enforcing security comes at a price.
boah it is *not* a security feature having a local resolver which may bypass my DHCP provided DNS which may be the only one with the correct DNS view
if you ask him anyways the result can't be more secure than aksing him directly, if not your breaking real world
in other words: if you are in a untrustable LAN you can not make it more trustable without good changes to break things in trustable ones
Let me use your scenario based on TLS. You want to be able to change your TLS certificates and the private CA you regenerate at any time, without any browser on your network ever giving you a popup warning. You know you cannot ask this - it goes against the security model. The same applies for DNS with DNSSEC. The security demands we need to do validation and caching and we should try to make that as flexible and painless as possible
uhm no - there is a CA signed root zone -> signed TLD -> signed domain
and if you believe that in a not trustable network you don't know if you get the signing informations at all - fine, but you hardly an enforce that with a local software
if i control the network i control the whle traffic and without your own satellite link you can't change that
Case 4, 5, 6 and 7: DNS cache, again, isn't needed.
Again, DNSSEC validation on the device requires caching.
the question is if i gain aynthing doing it on the end-device
The infrastructure is well setup, and caching is done by the business servers. DNS outages at the business level, mean there are other issues and they will likely be resolved quickly. You don't want to reboot / reset interfaces for each time you make a change or as the first result of an issue (Again, this would give fedora a bad name). DNS caching may mask a bigger problem.
I don't really understand this paragraph.
have fun debugging DNS troubles of a road-warrior in your network without realize that he brings his own DNS server
In conclusion, I don't percieve that a DNS cache in Fedora is a good idea, as it solves few real world problems, and may in fact create issues, mask issues and create a bad stigma about Fedora network reliability. If it is to become available to users I would like:
I believe you will need to re-think that in light of running a validating DNSSEC resolver on your laptop or servers.
no
- DNS cache is not the default. It bust be enabled on a connection (IE
user's in case 1 can enable it if needed)
- DNS cache should be able to be enabled from the NM Gui
- DNS cache should be able to be flushed live from the NM Gui
- DNS cache should be flushed on route or interface state change.
- If two interfaces are active, the default route DNS cache setting
takes precedence.
You cannot separate dns cache from DNSSEC. DNS caching is not a problem, it is a feature. If you don't want your records cached, use ttl=0
the cache already is running in my LAN for good reasons that DNS cache is pushed with DHCP that DNS cache already does DNSSEC validation
if you don't trust the network itself you are lost anyways