Another collection of odds and ends.

No need to recap the progress on ac.uk here!

VeriSign have announced a more detailed schedule for the signing of "com".
A version with obscured keys will be put into service on Monday 28 February
(possibly gradually on the different *.gtld-servers.net servers: that wasn't
clear). The keys will be unobscured towards the end of March, and insertion
of a DS record for it in the root zone is planned for Thursday 31 March.

In the December news round-up I wrote

>The authoritative nameservers for "ip6.arpa" (signed since last
>April) have been changed to [abcdef].ip6-servers.arpa in accordance
>with the plan in RFC 5855. ICANN haven't solicited DS records from
>the RIRs to put in it yet, but there's been a suggestion that if
>the RIRs pushed from their side, they could have them now.

In fact the RIPE delegations from "ip6.arpa" do now have such DS records.
(As usual, RIPE are well ahead of the other RIRs.) So there is now a
chain of trust from the root zone to (e.g.) "6.0.1.0.0.2.ip6.arpa".
So JANET could sign "0.3.6.0.1.0.0.2.ip6.arpa" and register a DS
record for it in the parent (RIPE have had the apparatus for doing
that for a long time now) and get a chain of trust to that as well.

>The work to change the authoritative nameservers for "in-addr.arpa"
>is scheduled for 2011-Q1 and it will be signed only after that has
>been done.

A schedule has been announced for that change of nameservers: it will
happen on Wednesday 16 February, but the copies on the root servers
will be maintained for a while after that.

There have been two new signed TLDS and (arguably) 4 changes of
status since 8 January:

  Signed TLD          Algorithm NSEC3 Opt DS @ DLV.ISC.ORG
                                      Out ROOT

> am.                 RSASHA1    Yes  Yes  Yes     Yes
> lu.                 RSASHA256  Yes  Yes   No      No

< kg.                 RSASHA1     No    -   No     Yes
> kg.                 RSASHA1     No    -  Yes     Yes

< la.                 RSASHA1    Yes  Yes   No     Yes
> la.                 RSASHA1    Yes  Yes  Yes     Yes

< xn--fzc2c9e2c.      RSASHA1     No    -   No      No
> xn--fzc2c9e2c.      RSASHA1    No*    -   No      No

< xn--xkc2al3hye2a.   RSASHA1     No    -   No      No
> xn--xkc2al3hye2a.   RSASHA1    No*    -   No      No

The last two (which are IDN tlds for Sri Lanka) require some
explanation. They were signed with algorithm 5 (RSASHA1), and
are now signed with both algorithms 5 and 7 (RSASHA1-NSEC3).
They still use NSEC, but the intention must surely be to drop
algorithm 5 and then convert to NSEC3.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [log in to unmask]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.