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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
