DURZ published in root - you ready?

Mailman List Mirror (Read Only)
1

Figured I'd drop a note here reminding folks of the
signed root zone publication timeline, which calls for
L root to begin serving a 'DURZ' the "week of 1/25/2010"
-- which is now - depending on what timezone you're in:

<http://www.root-dnssec.org/2010/01/14/status-update-january-2010/>

If you've not evaluated the *systemic effects* of a signed
root zone in your operating environment (prepped operations
and helpdesk staff, your own resolvers, etc..) I'd strongly
suggest you do so ASAP.

If you're not concerned because you're not signing anything -
do note that 'systemic' is the operative word above, as this
will impact you, whether you make any explicit changes in
your environment or not.

G'luck,

-danny

2

Good point, tomorrow/today we'll start seeing what gets broken and
hopefully why.

Regards.
Jorge

3

Good point, tomorrow/today we'll start seeing what gets broken and
hopefully why.

Regards.
Jorge

I don't expect to see much until the last root server (J) switches
over. DNS implemententations are remarkably robust at routing around
percieved "damage".

Week of 2010-05-03: J starts to serve DURZ

Mark

4

Danny/NANOG'ers

L-Root will start serving DURZ 2010-01-27 2000 UTC.

Let me know if you have any questions

Mehmet Akcin
ICANN/L-ROOT

5

Figured I'd drop a note here reminding folks of the
signed root zone publication timeline, which calls for
L root to begin serving a 'DURZ' the "week of 1/25/2010"
-- which is now - depending on what timezone you're in:

<http://www.root-dnssec.org/2010/01/14/status-update-january-2010/>

We published more detailed target maintenance windows that we are aiming for in the deployment document (<http://www.root-dnssec.org/wp-content/uploads/2010/01/draft-icann-dnssec-deployment-00.txt>) but we'll try to make it easier to find. Here it is:

   o Group 1, Week beginning Mon 25 Jan 2010: L

      L: 2010-01-27 1800 UTC -- 2010-01-27 2000 UTC

   o Group 2, Week beginning Mon 08 Feb 2010: A

   o Group 3, Week beginning Mon 01 Mar 2010: M, I

      M: 2010-03-03 0400 UTC -- 2010-03-03 0600 UTC

      I: 2010-03-03 1500 UTC -- 2010-03-03 1800 UTC

   o Group 4, Week beginning Mon 22 Mar 2010: D, K, E

      D: 2010-03-24 1400 UTC -- 2010-03-24 1500 UTC

      K: 2010-03-24 1500 UTC -- 2010-03-24 1700 UTC

      E: 2010-03-24 1800 UTC -- 2010-03-24 2000 UTC

   o Group 5, Week beginning Mon 12 Apr 2010: B, H, C, G, F

      H: 2010-04-14 1400 UTC -- 2010-04-14 1500 UTC

      C: 2010-04-14 1500 UTC -- 2010-04-14 1700 UTC

      G: 2010-04-14 1700 UTC -- 2010-04-14 1900 UTC

      B: 2010-04-14 1900 UTC -- 2010-04-14 2100 UTC

      F: 2010-04-14 2100 UTC -- 2010-04-15 0000 UTC

   o Group 6, Week beginning Mon 03 May 2010: J

      J: 2010-05-05 1700 UTC -- 2010-05-05 1900 UTC

Joe

6

There's some evidence within the traffic to the authoritative servers for the now-signed berkeley.edu zone that answers from the authoritative servers are not being received by certain queriers. These queriers, who are setting DO (and of course EDNS0) in their queries, are retrying the same queries until they reach the one "sacrificial lamb" server that is set to give out minimal answers and limit EDNS0 responses to 512 bytes (thereby frequently triggering failover to TCP for those minimal answers that still exceed 512 bytes).

It will be interesting to see how traffic patterns to the various root servers evolve as more servers get the DURZ.

Also, I got my first apparently DNSSEC-related "your server is attacking me" notice. It was little more than a log snippet that indicated that a UCB authoritative server was perpetrating a "big bomb" attack on a system behind this firewall. "Big bomb" is a notification from Netgear firewalls and CPE routers. Not sure how much activity the abuse contacts for the various rootops netblocks get, but you'll probably see more.

michael