On Wed, 21 Sep 2011, Tomas Mraz wrote: >> solve a part of the problem how can you even consider removing the >> ability for disabling dnssec when implementing and deploying and running >> dnssec increases the complexity times hundred and people and isp's alike >> cant even implement and properly run a simple dns server as it is now? Let's not try and turn this into a dnssec bashing thread please. Fedora has been shipping with turn on dnssec aware servers that do a pretty decent job. ISPs can simple install bind or unbound in Fedora or RHEL and dnssec just works. (especially on ISP networks that have no broken cheap consumer hardware issues) > You probably did not understand the meaning of "removing the ability for > disabling dnssec" in the Adam's e-mail. It is not meant to disable the > ability to not use of dnssec completely but that it should not be > possible to simply click away any failures to verify dnssec for domains > that are marked as that they should be validated by dnssec. right. the big problem is not working around a broken network or a network with an attacker. The problem is false positives due to the pletora of hotspot mangling techniques out there. Ideally, NetworkManager would deal with the whole "hotspot detection" and lift any blocking done by the hotspot pre-login, and then dnssec-triggerd in some way or shape can deal with the DNS investigation and caching resolver reconfiguration. For example, the Apple iOS hotspot detection consists of simple trying to fetch: http://www.apple.com/library/test/success.html Once NM detects something like this, it can: 1) use dnssec-triggerd to put unbound in "readonly cache mode" to avoid insecure/bad DNS 2) fire of a webrequest that triggers the user into portal authentication 3) detect with above test the access has opened (or will never get better) 4) signal dnssec-triggerd to see if it can go to either "use ISP DNS server" or "auth mode". > Simply if a > domain is marked as dnssec enabled in the parent record then it must > have correct dnssec entries or it should not be accepted. If you never contacted that domain before, you cannot always perform that check on a pre-login hotspot. Even if they do not mangle DNS but grab you at the IP layer, then you run into the DNSSEC DANE record telling you about a TLS cert that is mismatching due to the portal. Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
