Looking for dnssec-triggerd alpha testers!
dcbw at redhat.com
Thu Sep 22 16:27:41 UTC 2011
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:
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.
> 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.
More information about the devel