Looking for dnssec-triggerd alpha testers!

[Paul Wouters]

On Sun, 18 Sep 2011, Nicolas Mailhot wrote:

>> We are trying to get DNSSEC validation on the end nodes. One way of doing
>> that is to run a caching resolver on every host, but that strains the
>> DNS infrastructure because all DNS caches would be circumvented.
>
>> However, there are many networks out there that mess with DNS,
>
> I'm sure lots of Fedora users would love to get rid of their isp's idea
> of 'enhancing' dns (plus sometimes the isp dns' are not only enhanced,
> they're flacky making the whole network access unreliable)
>
> Could the well-integrated caching dns option be considered as well,
> given we live in an unperfect world ?

DNSSEC cannot tell the difference between "enhancing DNS" and "attacking
DNS". If your ISP's nameservers are returning DNSSEC data, any rewrites
would get rejected as spoofed. (for domains not using DNSSEC that cannot
be easilly detected and the rewrites will just work). dnssec-triggerd
currently does not attempt to detect this, so in the current setup, you
would just "lose" DNS access to rewritten DNS answers. An option could
be added to force it into "auth mode", or a probe for some "well known"
domains that get rewritten could be written.

Things are a little more complicated because some hotspots temporarilly
mess with DNS to get you to the login/payment page before they "free"
DNS, though luckilly most portals these days just grab the port 80/443
traffic and give the browser a redirect at the HTTP level, as that does
not suffer from TTL/caching the browsers are doing. But that throws an
SSL warning on 443.

But yes, that's something that can be looked at for the next version :)

Paul