Enabling DNSSEC for the .nz Second Level Domains
Dear Technical Community, The next step towards completing the DNSSEC deployment for .nz is to sign the second level domains, thus allowing registrants to enable DNSSEC for their domains. We have prepared a staggered deployment schedule for the unmoderated second level domains, which is available in full at http://nzrs.net.nz/dns/dnssec As a summary, geek.nz will be the first DNSSEC signed second level domain, closely followed by ac.nz, gen.nz, maori.nz and school.nz, all during June. In July, net.nz and org.nz will be signed, ending with co.nz during early August. As a reminder, the SRS has been able to receive DS records for domains under .nz since last year, and those records will be included in their respective zone when DNSSEC is fully enable for the second level domain. We advise against using any of the Second Level Domains DS records as a trust anchors. If you have any questions around this process, don't hesitate to contact us at support(a)nzrs.net.nz Kind Regards, -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535
On 25/05/12 19:46, Jed Laundry wrote: Hi Jed,
At the risk of asking something that may have been covered already; is there an indication of when the moderated SLDs will be signed?
There have been initial discussions with some of the moderators, we need to agree on a schedule on a case-by-case basis before making any schedule available. Kind Regards,
-- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535
On 27/05/12 10:50, Daniel Richards wrote:
So far we are not aware of any active validating nameserver in NZ, or heard plans about it. We definitely can find out based on the nameservers data. Cheers,
-- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535
On 28/05/12 9:48 AM, "Sebastian Castro" <sebastian(a)nzrs.net.nz> 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. Craig Geek
On Mon, May 28, 2012 at 1:20 PM, Craig Whitmore <craig(a)voyager.co.nz> wrote:
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? A Google search for "does my dns server validate dnssec" leads to: http://askubuntu.com/questions/51367/how-do-i-configure-my-caching-nameserve... http://www.unbound.net/documentation/howto_anchor.html Of course, turning it on blindly may exercise the Principle of Least Astonishment for you.
On 2012-05-27, at 23:33, Andy Linton wrote:
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
[resent from proper address] Joe Abley (jabley) writes:
[...]
Right, but it's going to take a little time before most applications validate or even check for TLSA/DANE, although there there is progress. See Tony Finch's recent draft for SMTP (http://tools.ietf.org/html/draft-fanf-dane-smtp-02) What should we do in the meantime ? I completely understand the rationale for *not* enabling DNSSEC validation at the moment, based on your arguments, but where does that leave the users ? Is it better to enable validation, protect the users and absorb the increased support cost, and even risk losing business ?
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.
That's a very good point.
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.
Very much recommended, yes. But until application and OS developers catch up, we'll need some interim solution. If the ISPs aren't the one to deploy it... Cheers, Phil
On 2012-06-01, at 12:02, Phil Regnauld wrote:
Right, but it's going to take a little time before most applications validate or even check for TLSA/DANE, although there there is progress.
For sure. I wasn't saying it was quicker. However, if I was betting on which would happen first: (a) four browser vendors deploy DNSSEC validation and N% of users upgrade their browsers and start to enjoy validation, or (b) ISPs across the planet swallow the costs and reputational harm associated with doing so and turn on validation such that N% of users receive pre-validated answers I don't think I'd be putting much money on (b). (And note again that (b) doesn't close the door to DNS poisoning attacks, it just moves the target from the cache to the stub resolver. This is a harder target, but it's still a target.) Joe
Joe Abley (jabley) writes:
(And note again that (b) doesn't close the door to DNS poisoning attacks, it just moves the target from the cache to the stub resolver. This is a harder target, but it's still a target.)
Last mile is always the most expensive. Forget FTTH, it's DTTA/DTTH we want :)
On 28/05/2012 8:55 p.m., Craig Whitmore wrote:
https://en.wikipedia.org/wiki/DNS_spoofing#Prevention_and_mitigation -- Ciao, Dave
On 28/05/12 20:55, Craig Whitmore wrote:
It's a chicken-and-egg problem. 1. Why should I sign my domain if no one will be able to validate it? 2. Why should I enable a validating nameserver? It will cause more troubles, and no one will use it because there are few signed domains The short answer is to learn! In the same way you Craig have been exploring DNSSEC, and signing your domains, and likely running a validating nameserver on your workstation. In the last few months, every time we had a meeting with an ISP, we mentioned: "We are going to sign the second level domains, we are implementing DNSSEC, you should try to run your own validating nameserver, even for a small controlled population". If Comcast could do it, why not a smaller ISP in NZ?
I'm wondering at this point how much help could NZRS provide towards that objective. Do geeks in NZ need more reading material? More testing environments? More meetings? Cheers,
-- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535
On 29/05/12 08:36, Sebastian Castro wrote:
Another trick is to set up IPSEC to use DNSSEC signed public key certificates and do away with the need for CRL lists on your VPN servers! Works for racoon as far as I know... And then get latest Google Chrome with the new HTTPS pubkey in DNSSEC thingy Have a look at http://www.imperialviolet.org/2011/06/16/dnssecchrome.html Cheers! Matthew Grant
-- Regards, Matthew Grant | Systems Engineer *Phone:* 0800 5000 24 | +64 3 962 9510 <http://www.voyager.co.nz> Voice & Data www.voyager.co.nz <http://www.voyager.co.nz/> +64 9 444 4444 <http://www.net24.co.nz> Hosting & Cloud www.net24.co.nz <http://www.net24.co.nz/> 0800 5000 24 <http://www.1stdomains.co.nz> Domains & Email www.1stdomains.co.nz <http://www.1stdomains.co.nz/> +64 3 962 9520
Are there any NZ registrar's that actually support DNSSEC at all? The current registrar i'm using doesn't (and doesn't even support AAAA records!) so i'm running my own NS servers, but obviously I still need to be able to push a DS record to my registrar. If not currently, are there any that are planning on supporting DNSSEC properly, with any kind of API for managing it? (Without registrar support, this is pointless) On Fri, May 25, 2012 at 3:54 PM, Sebastian Castro <sebastian(a)nzrs.net.nz> wrote:
Hi Daniel, Yes there are some .nz registrars who already support DNSSEC. As of tomorrow DNCL will be updating the table at http://dnc.org.nz/registrars to identify those registrars who can 'Handle DS Records', and those who meet a higher level of service and have been deemed to be 'DNSSEC Friendly'. More information on these statuses and how to apply can be found here: http://dnc.org.nz/story/dnssec-registrars-faq Regards, Paul. Paul McKitrick (ITCP) Manager Compliance and Security Domain Name Commission Email: mcs(a)dnc.org.nz Fax: +64 4 495 2115 PO Box 11-881, Wellington, 6142 New Zealand On 30/05/2012, at 10:48 AM, Daniel Richards wrote:
Hi All, Apologies, I am a day ahead of myself the update to the Registrars table as per below is schedule for Friday, 1 June, 2012. Regards, Paul. Paul McKitrick (ITCP) Manager Compliance and Security Domain Name Commission Email: mcs(a)dnc.org.nz Fax: +64 4 495 2115 PO Box 11-881, Wellington, 6142 New Zealand On 30/05/2012, at 11:05 AM, Paul McKitrick wrote:
participants (10)
-
Andy Linton -
Craig Whitmore -
Daniel Richards -
David Taylor -
Jed Laundry -
Joe Abley -
Matthew Grant -
Paul McKitrick -
Phil Regnauld -
Sebastian Castro