Looking for dnssec-triggerd alpha testers!

[Dan Williams]

On Wed, 2011-09-21 at 11:23 -0400, Paul Wouters wrote:
> 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

There's long notes on how to do this in the TODO file in NM git, just
needs the time to implement.  It's essentially what Windows does as
well, they just fetch a known URL and compare the result to a known
response, and if there isn't a match, you're not connected to the
internet.  Various other plugins could check the response for known
portal junk (and we can use the various portal auto-login standards like
WPAD) to handle portal auto-login if we can.

Dan

> 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