Re: [nznog] Enabling DNSSEC for the .nz Second Level Domains

On 2012-05-27, at 23:33, Andy Linton wrote:

On Mon, May 28, 2012 at 1:20 PM, Craig Whitmore wrote:

...

You can try http://dnssec.geek.nz which will tell you if your DNS Server Validates DNSSEC

The Code is not written by me but works.

So let's say I try that and I get the message "No, your DNS resolver does NOT validate DNSSEC signatures."

So what should I do next? Where would I go for help?

There is enthusiasm in some circles for the idea that deployment of DNSSEC validation is only really practical on the end host (or in the application, even). Problems with validation in a third-party cache (the resolver service that an ISP provides for use by its customers, etc) include: - if you suppress a response because validation fails, the result is largely indistinguishable from a broken cache - customers who see broken services complain to the people they think are providing the services - experience elsewhere (e.g. Comcast's multiple millions of residential customers) suggests that in general the actual source of the problem is poor zone signing hygiene - validation failures result in increased support costs for the ISP - validation failures result in perceived unreliability of the ISP - there is little direct pressure on whoever has broken signers to fix their problems Not much of a business case for an ISP to start validating, here. Expend effort to increase support costs, reduce perceived reliability, and attract no additional revenue. This is not a pretty picture. Further: - there is inadequate signalling available between the cache and the application to allow the application to describe a security problem rather than a non-existent name - there is no practical, deployed security between the cache and the stub resolver However, if you validate in your application (or in the OS with a useful API available to applications): - you can ascribe problems in validation to problems with a domain name, rather than problems with a cache - you can potentially re-try in intelligent ways, perhaps avoiding a potentially-poisoned cache and going direct to authority servers - you can have local confidence in the security of the responses you receive, rather than having to trust an insecure path to a cache If this line of thinking becomes more prevalent, then we can expect to see Chrome/Mozilla/Safari/IE/name-your-app take up the validation workload. There are a relatively small number of vendors who would need to jump on board with this to see fairly widespread deployment, and they have incentives to do so other than protecting users (e.g. see DANE vs. the browser list). In this scenario, the barriers to widespread deployment of DNSSEC are a lack of zone signing, not a lack of validation on the part of ISPs, and zone signing in the absence of validation in ISP caches is not as pointless as it seems. Incidentally, the nice people at NLNet Labs wrote a little package which allows you to run up a local copy of unbound and use it to validate from the end-user host. It's available for Windows and for the Mac, and it might be fun to play with if you're a user who is not also a systems administrator. http://nlnetlabs.nl/projects/dnssec-trigger/ Joe