[dns-operations] It's begun...

[Chris Thompson]

On Oct 24 2013, Dan York wrote:

>On 10/24/13 9:12 AM, "Chris Thompson" <cet1 at cam.ac.uk> wrote:
>
>
>>At 13:01 23-10-2013, Edward Lewis wrote:
>>>My sensors show 4 new gTLDs in the last hour or so...IDN,
>>>non-ccTLD...added between 1800 and 1900 UTC.
>>
>>Not mentioned yet is that all four appeared already signed and with
>>DS records in the root zone.
>
>Funny you should mention that... I just published a post this morning
>promoting that fact:
>
>http://www.internetsociety.org/deploy360/blog/2013/10/4-newgtlds-launched-y
>esterday-marks-dawn-of-dnssec-from-the-start-tlds/

There have been a few new TLDs signed from the start before this "dawn".
I may have missed some, but these certainly were:

  sx               on 2011-12-10   (ccTLD for Sint Maarten)
  post             on 2012-08-08
  xn--mgbx4cd0ab   on 2012-09-21   (IDN for MY = Malaysia)
  xn--l1acc        on 2013-08-18   (IDN for MN = Mongolia)

(the dates may suffer from off-by-one-or-even-more errors).

The last of those is a sad case, however, as a few days after its
initial appearance they performed a KSK rollover, omitting to change
the DS records in the root zone, and the zone has failed validation
ever since.

>From a DNSSEC-advocacy point of view, this is a great step forward as all
>new domains registered under these newgTLDs will at least have the
>*option* of being secured by DNSSEC.
>
>>But... the two Cyrillic gTLDs (xn--80asehdb & xn--80aswg) are a bit
>>broken, in that NXDOMAIN responses don't validate properly. Neither
>>dnssec-debugger.verisignlabs.com nor dnsviz.net are able to analyse
>>validations problems for NXDOMAIN responses, so I am not quite sure
>>why yet, but e.g.
>>
>>  dig +dnssec www.xn--80asehdb.
>>  dig +dnssec www.xn--80aswg.
>>
>>give SERVFAILs which can be avoided by adding the +cd option.
>
>Hmmm... interesting.  Perhaps some work is still needed on the operational
>front there...

Part of the problem is that only one NSEC3 record is returned - the
one covering the zone apex, which doesn't necessarily cover the
name queried for. But validation seems to fail even in cases when
the name is so covered. 

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1 at ucs.cam.ac.uk    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.