This is the promised news roundup, which may be my last, at least for
some time. It covers 30 June to 27 September this year.
The roll-out of "new generic" TLDs continues apace. The missing DS record
for "bio" was created in mid-July. The algorithm statistics are now:
Algorithm NSEC3 Opt Number of newgeneric TLDs
Out 2014-06-30 2014-09-27
RSASHA1 No - 12 +5 17
RSASHA1 Yes No 0 +2 2
RSASHA1 Yes Yes 31 +7 38
RSASHA256 No - 20 +31 51
RSASHA256 Yes No 172 +27 199
RSASHA256 Yes Yes 77 +17 94
RSASHA512 Yes No 10 +3 13
Total 322 +92 414
See http://people.ds.cam.ac.uk/cet1/newgeneric-tlds-20140927 for a
full list. Since mid-August, all new domains (and some delegated
earlier) have been using the "Name Collision Occurrence Management
Framework" - see https://www.icann.org/news/announcement-2-2014-08-01-en
Among "traditional" TLDs, there have been two additions and four
changes of status:
Traditional TLD Algorithm NSEC3 Opt DS @ DLV @ DLV.
Out ROOT ISC.ORG
> tn. RSASHA256 No - Yes No
> xn--pgbs0dh. RSASHA256 No - Yes No
< es. RSASHA256 Yes Yes No Yes
> es. RSASHA256 Yes Yes Yes Yes
< hr. RSASHA256 Yes Yes No No
> hr. RSASHA256 Yes Yes Yes No
< kg. RSASHA1 No - Yes No
> kg. RSASHA1 No - Yes Yes
< xn--l1acc. RSASHA1 No - (Yes) Yes
> xn--l1acc. RSASHA1 No - Yes Yes
See http://people.ds.cam.ac.uk/cet1/traditional-tlds-20140927 for a
full list. "tn" and "xn-pgbs0dh" (both Tunisia) are recent, while
"es" (Spain) and "hr" (Croatia) got their DS records back in July.
"kg" also re-established its DLV entry back then (one wonders why).
Finally, "xn--l1acc" (IDN for Mongolia), after more operational ups
and downs in August, have finally managed to get their DS record
matching their KSK - it took them over a year to sort this out!
"ke" (Kenya) who have been using algorithm 5 (RSASHA1) have
just one of their ZSKs using algorithm 7 (RSASHA1-NSEC3) since
early August. If this is the start of an algorithm rollover, it
is proceeding rather slowly.
Changes in the known-to-me state of signed children of "ac.uk"
involve 3 additions and 2 removals:
Signed zone Algorithm NSEC3 Opt DS @ DLV @ DLV.
Out JANET ISC.ORG
> lancaster.ac.uk. RSASHA256 Yes No Yes No [Lancaster]
> lancs.ac.uk. RSASHA256 Yes No Yes No [Lancaster]
> lmc.ac.uk. RSASHA256 Yes No Yes No ]Lancaster]
< portal.ac.uk. RSASHA256 No - Yes No [Bath]
< rdn.ac.uk. RSASHA256 No - Yes No [Bath]
The last two domains have been deleted entirely. (Well, actually
a "lame" delegation, including DS record, for portal.ac.uk still
exists, but Rob Perkins tells me "JANET are in the process of
removing the domain, and so we have removed the zone".) See
http://people.ds.cam.ac.uk/cet1/signed-ac.uk-20140927 for a
full list.
For operational errors, I have a note about a botched key rollover
for nasa,gov (a domain that tends to gets noticed) around 9 July,
which was discussed on the dnssec-deployment mailing list. I wish
I could give you a URL for that, but the mailing list is "moving"
and its archives seem to have disappeared entirely.
There was some discussion of a new validating public resolver service
(dns.watch) in the thread starting at
https://lists.dns-oarc.net/pipermail/dns-operations/2014-July/011948.html
A discussion about a difference between BIND and Unbound in whether
they set the AD bit in certain cases involving wildcards was discussed
in the thread starting at
https://lists.dns-oarc.net/pipermail/dns-operations/2014-September/012086.html
The conclusion seems to have been that BIND was wrong, and it is has
been changed in the most recent versions, with this change file entry:
3942. [bug] Wildcard responses from a optout range should be
marked as insecure. [RT #37072]
The CDS/CDNSKEY proposal for automating the maintenance of parental
DS records is now published as RFC 7344 "Automating DNSSEC Delegation
Trust Maintenance", e.g. at https://tools.ietf.org/html/rfc7344
I am not aware of any public implementations yet. The related
Internet Draft
https://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
is still in Working Group Last Call.
On 16 September, Joe Abley posted the following on several mailing lists,
which I think is worth quoting in full:
| ICANN will facilitate an open, technical workshop to discuss operational
| plans for a future root zone KSK rollover, during the upcoming ICANN 51
| meeting to be held in Los Angeles in October 2014.
|
| The workshop is intended for participants who have a technical, operational
| perspective and is an opportunity to explore potential options, operational
| considerations, and other aspects of rolling the root zone KSK.
|
| The workshop will be held on Thursday October 16, 2014 at the ICANN meeting
| venue in Los Angeles. This will be an open event, and remote participation
| will be available.
|
| More details including a tentative agenda, will be made available soon.
| If you are able to participate, please join the ksk-rollover mailing list
| at <https://mm.icann.org/mailman/listinfo/ksk-rollover> which will be
| used to coordinate this workshop, and to function as a venue for technical
| discussion as this work proceeds in the future.
The mailing list referred to has been busy but I haven't had time to
follow it.
The same is true of the DNS Privacy mailing list - maybe Tony Finch can
bring us up to date on that.
--
Chris Thompson University of Cambridge Information Services,
Email: [log in to unmask] Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom.
|
