Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC

From: Mehmet Akcin <[email-masked]>
Date: Wed, 27 Jan 2010 09:31:18 -0800

Hello,
 
L-Root maintenance is starting in 30 mins ( 2010-01-27 1800 UTC )

Regards

Joe Abley / Mehmet Akcin / Dave Knight
ICANN DNS Ops / L-ROOT

>> Hi
>>
>> As part of staged, incremental deployment of DNSSEC in the root
>> zone L-Root will begin serving a Deliberately Unvalidatable
>> Root Zone (DURZ) after the completion of its scheduled
>> maintenance at 2010-01-27 1800 UTC - 2000 UTC
>>
>> Please contact L-Root NOC via [email-masked] or
>> T: +1.310.301.5817 if you have any questions.
>>
>> Please contact with [email-masked] if you have any
>> questions regarding DNSSEC Deployment at root zone.

---

From: Mehmet Akcin <[email-masked]>
Date: Wed, 27 Jan 2010 10:59:46 -0800

Hello World,

L-Root has completed it's maintenance and now serving DURZ.

You can observe L-Root DSC Stats by visiting
http://stats.l.root-servers.org

Please contact L-Root NOC via email [email-masked] or T: +1.310.301.5817
if you have any questions

Please contact [email-masked] if you have any questions regarding DNSSEC
Deployment at root zone.

Joe Abley / Mehmet Akcin / Dave Knight
ICANN DNS Ops / L-ROOT / AS20144 / AS-LROOT
Peering info: http://as20144.peeringdb.com

On 1/27/10 12:31 PM, "Mehmet Akcin" <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jan 2010 09:25:20 +1100

The DNSKEY RRset size seems small for testing.  We really should
be looking the biggest key set sizes that occur during rollover
simultaneous ZSK/KSK rollovers.  Hopefully that is in the planning.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Wed, 27 Jan 2010 19:58:36 -0700

And a revoked key with flag "385" as the high level design calls for RFC
5011 compatible rollovers.

/S
----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Mark Andrews
> Sent: Wednesday, January 27, 2010 11:25 PM
> To: [email-masked]
> Subject: Re: [DNSOP] L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
> 
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Jan 2010 14:26:36 +0000

> simultaneous ZSK/KSK rollovers.  Hopefully that is in the planning.

The key rollover timetable staggers ZSK and KSK rollovers. See page 5 of
http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-arch-v1dot2dot1.pdf
However that document is a bit light on emergency procedures.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Matt Larson <[email-masked]>
Date: Thu, 28 Jan 2010 11:59:11 -0500

> simultaneous ZSK/KSK rollovers.  Hopefully that is in the planning.

The design allows for ZSK rollovers at calendar quarter boundaries and
KSK rollovers in the middle of a quarter, which are intentionally
non-overlapping so that the are never more than three keys in the root
DNSKEY RRset.  (Please see the diagram on page five of
http://www.root-dnssec.org/wp-content/uploads/2009/12/draft-icann-dnssec-arch-v1dot2dot1.pdf,
which Tony already referred to.)

There will be a ZSK rollover at the end of Q1/start of Q2 and a KSK
rollover in the middle of Q2.  But because the signed root currently
being published has deliberately obscured key material, essentially
only the key IDs will change: the DNSKEY RDATA will contain the same
human-readable base64[*], padded to produce the same key ID as the
actual, non-published key.

So there will be periods between now and the anticipated completion of
deployment on July 1 when the root key set will contain two ZSKs and
one KSK, and one ZSK and two KSKs.

> 5011 compatible rollovers.

The KSK rollover in mid-Q2 will use RFC 5011 semantics, as will every
KSK rollover.  (But since the KSK is 2048 bits, I hope to not see a
rollover of the initial published KSK for a long time.)

> However that document is a bit light on emergency procedures.

That's a high-level architecture document and intentionally doesn't
cover every detail.  There is much more detail in the policy and
practice statements (one each for VeriSign and ICANN at
http://www.root-dnssec.org/documentation), including detail about
emergency key rollovers.  Is there something missing, in your opinion?

Matt

[*] $ dig +nocmd +noquestion +nocomments +nostats @l.root-servers.net dnskey .
.                       86400   IN      DNSKEY  256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8
.                       86400   IN      DNSKEY  257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Jan 2010 17:37:56 +0000

On Thu, 28 Jan 2010, Matt Larson wrote:
> emergency key rollovers.

Ah that's where I should have been looking, thanks.

Tony.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 28 Jan 2010 09:41:25 -0800

> which Tony already referred to.)

Stupid question on Figure 2:  What is the approximate size of responses during these different periods?  In particular, do any particular "magic limits" in the network (namely the 1500B ethernet MTU, the 1492 PPPoE MTU, the "likely to be in path MTU hole" of 1480-1500B MTU, or the somewhat common 1280 EDNS MTU) get hit?