From roque at lacnic.net  Tue Feb  9 17:08:11 2010
From: roque at lacnic.net (Roque Gagliano)
Date: Tue, 9 Feb 2010 20:08:11 +0100
Subject: [lacnog] Fwd: [dns-wg] Outdated RIPE NCC Trust Anchors in Fedora
	Linux Repositories
References: <4B6C1BE7.9050400@ripe.net>
Message-ID: <6A77CB55-5B25-4974-B261-5B2E55ED7495@lacnic.net>

Hola Amigos,

Este es un mensaje para aquellas personas que usan en sus servidores recursivos Fedora + BIND y tienen la validaci?n de DNSSEC encendida. Resulta que BIND viene con un paquete llamado "dnssec-conf" que instala claves de confianza ("trust anchors") que est?n desactualizadas. Esto ha afectado zonas que servidores de LACNIC y otros RIRs son autoritativos. Aqu? les env?o el informe que arm? el personal de RIPE y si se encuentran en las condiciones detalladas, ser?a bueno que revisaran vuestras configuraciones. Nosotros hemos contactado a algunos ISPs que hemos detectado en nuestros servidores que estaban siendo afectados.

Cordiales saludos,
Roque Gagliano


Dear Friends,

This message is for those people that use recursive servers based on Fedora + BIND and have DNSSEC validation enabled. BIND ships a packet called "dnssec-conf" that includes outdated trust-anchors. This problem has affected zonas where LACNIC's  and other RIRs servers are authoritative. I am attaching the report from RIPE's staff. We have already contacted ISPs that we have detected as affected by analyzing requests to our servers.


Best Regards,
Roque Gagliano


Begin forwarded message:

> From: Anand Buddhdev <anandb at ripe.net>
> Date: February 5, 2010 2:23:51 PM GMT+01:00
> To: dns-wg at ripe.net
> Subject: [dns-wg] Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories
> 
> [Apologies for duplicates]
> 
> Dear Colleagues,
> 
> We have discovered that recent versions of the Fedora Linux distribution
> are shipping with a package called "dnssec-conf", which contains the
> RIPE NCC's DNSSEC trust anchors. This package is installed by default as
> a dependency of BIND, and it configures BIND to do DNSSEC validation.
> 
> Unfortunately, the current version of this package (1.21) is outdated
> and contains old trust anchors.
> 
> On 16 December 2009, we had a key roll-over event, where we removed the
> old Key-Signing Keys (KSKs). From that time, BIND resolvers running on
> Fedora Linux distributions could not validate any signed responses in
> the RIPE NCC's reverse zones.
> 
> If you are running Fedora Linux with the standard BIND package, please
> edit the file "/etc/pki/dnssec-keys//named.dnssec.keys", and comment out
> all the lines in it containing the directory path "production/reverse".
> Then restart BIND.
> 
> This will stop BIND from using the outdated trust anchors. If you do
> want to use the RIPE NCC's trust anchors to validate our signed zones,
> we recommend that you fetch the latest trust anchor file from our
> website and reconfigure BIND to use it instead of the ones distributed
> in the dnssec-conf package:
> 
> https://www.ripe.net/projects/disi/keys/index.html
> 
> Please remember to check frequently for updates to our trust anchor
> file, as we introduce new Key-Signing Keys (KSKs) every 6 months.
> 
> Regards,
> 
> Anand Buddhdev,
> DNS Services Manager, RIPE NCC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.lacnic.net/pipermail/lacnog/attachments/20100209/72554a32/attachment.htm>

From francisco at arias.com.mx  Thu Feb 11 06:05:01 2010
From: francisco at arias.com.mx (Francisco Arias)
Date: Thu, 11 Feb 2010 00:05:01 -0800
Subject: [lacnog] Fwd: A.root-servers.net. DURZ
In-Reply-To: <alpine.LSU.2.00.1002101937560.28066@hermes-2.csi.cam.ac.uk>
References: <alpine.LSU.2.00.1002101937560.28066@hermes-2.csi.cam.ac.uk>
Message-ID: <e5de97e21002110005k358b9c9er832664d78515ae2b@mail.gmail.com>

Ahora tambi?n el servidor ra?z A est? sirviendo la zona ra?z firmada,
no verificable.

Saludos,

Francisco.

P.D. Al parecer los problemas para ver la zona firmada sobre IPv6 eran
s?lo de propagaci?n.



---------- Forwarded message ----------
From: Tony Finch <dot at dotat.at>
Date: 10 February 2010 11:44
Subject: [Dnssec-deployment] A.root-servers.net. DURZ
To: dnssec-deployment at dnssec-deployment.org


I saw the DURZ turn up on A.root-servers.net at about 18:00 UTC. However
a friend pointed out to me that it is still not available via IPv6:

; <<>> DiG 9.3.2 <<>> -6 +dnssec dnskey . @a.root-servers.net.
; (1 server found)
;; global options: ?printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22178
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?IN ? ? ?DNSKEY

;; AUTHORITY SECTION:
. ? ? ? ? ? ? ? ? ? ? ? 86400 ? IN ? ? ?SOA ? ? A.ROOT-SERVERS.NET.
NSTLD.VERISIGN-GRS.COM. 2010021001 1800 900 604800 86400

;; Query time: 80 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Wed Feb 10 19:39:03 2010
;; MSG SIZE ?rcvd: 103

; <<>> DiG 9.3.2 <<>> -4 +dnssec dnskey . @a.root-servers.net.
; (1 server found)
;; global options: ?printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57112
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?IN ? ? ?DNSKEY

;; ANSWER SECTION:
. ? ? ? ? ? ? ? ? ? ? ? 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=
. ? ? ? ? ? ? ? ? ? ? ? 86400 ? IN ? ? ?RRSIG ? DNSKEY 8 0 86400
20100224235959 20100210000000 19324 .
dgF9oKtxShTOdKdti6HjXf9duCs/u+SoBVP5cpQVgbGmU8t2+Q6QVOwR
mYVkIJIiTuCRpigOf0S9s7shHvh7bzcDh9P+QtWCWapBSKCveKaDqGdm
yAPSyiQU8pwFNpEiDYYhzxr+CNZz5582LgKi67DEb6BX7a3BAwZsvJvm
7swMhHOMS71+9ObDuhHacUQp0YzRRrNIZofliZNq/jZcZeWgTpjtLKQo
TUfehyr+UKPz/0w4shXtm98GfeIhT0Lm/n03T/5n8ESWyn5yCXef8cY6
a8ls64R4QJ3mMJvb2MZk37DFx2o82rQ3szwuX0Zn9MLwKjOLAtgthcYU C26svg==

;; Query time: 92 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Wed Feb 10 19:39:23 2010
;; MSG SIZE ?rcvd: 736

traceroute to a.root-servers.net. (198.41.0.4), 30 hops max, 40 byte packets
?1 ?gw-808.net.cam.ac.uk (131.111.8.62) ?0.274 ms ? 0.189 ms ? 0.199 ms
?2 ?route-cent.route-enet.net.cam.ac.uk (192.153.213.193) ?0.423 ms
0.335 ms ? 0.216 ms
?3 ?gi5-0-0.camb-rbr3.eastnet.ja.net (193.63.107.157) ?0.187 ms
0.202 ms ? 0.208 ms
?4 ?po2-0.chel-rbr1.eastnet.ja.net (193.63.107.30) ?2.313 ms ? 2.339
ms ? 2.328 ms
?5 ?lond-sbr1.ja.net (146.97.40.45) ?3.427 ms ? 3.426 ms ? 3.327 ms
?6 ?so-6-0-0.lond-sbr4.ja.net (146.97.33.154) ?3.707 ms ? 3.690 ms ? 3.704 ms
?7 ?if-4-0-0.core4.LDN-London.as6453.net (80.231.76.37) ?3.715 ms
3.627 ms ? 3.810 ms
?8 ?if-13-1-0.mcore3.LDN-London.as6453.net (195.219.195.149) ?3.922 ms
? 3.808 ms ? 3.987 ms
?9 ?if-5-0-0.mcore3.L78-London.as6453.net (195.219.195.10) ?4.207 ms
4.197 ms ? 4.474 ms
10 ?if-15-0-0-890.core2.NTO-NewYork.as6453.net (216.6.97.97) ?100.524
ms ? 100.271 ms ? 100.021 ms
11 ?Vlan13.icore1.NTO-NewYork.as6453.net (216.6.97.6) ?97.021 ms
97.146 ms ? 106.388 ms
12 ?ix-12-42.icore1.NTO-NewYork.as6453.net (209.58.26.18) ?95.386 ms
95.138 ms ? 94.761 ms
13 ?* * *

traceroute to a.root-servers.net. (2001:503:ba3e::2:30), 30 hops max,
40 byte packets
?1 ?gw-808.net.cam.ac.uk (2001:630:200:8080::1) ?0.491 ms ? 0.266 ms ? 0.209 ms
?2 ?2001:630:202:8000::19d (2001:630:202:8000::19d) ?0.175 ms * *
?3 ?2001:630:202:10::1e (2001:630:202:10::1e) ?2.511 ms ? 2.384 ms ? 2.369 ms
?4 ?2001:630:0:8040::505 (2001:630:0:8040::505) ?3.598 ms ? 3.584 ms ? 3.473 ms
?5 ?so-6-0-0.lond-sbr4.ja.net (2001:630:0:10::9a) ?3.701 ms ? 3.722 ms
? 3.723 ms
?6 ?2001:630:0:10::152 (2001:630:0:10::152) ?3.722 ms ? 3.723 ms ? 3.722 ms
?7 ?linx.he.net (2001:7f8:4::1b1b:1) ?4.349 ms ? 14.742 ms ? 14.217 ms
?8 ?10g-2-3.core1.ny4.ipv6.he.net (2001:470:0:3e::1) ?72.134 ms
72.049 ms ? 80.269 ms
?9 ?10g-2-3.core1.ash1.ipv6.he.net (2001:470:0:36::1) ?78.261 ms
78.389 ms ? 86.010 ms
10 ?2001:504:0:2::2641:1 (2001:504:0:2::2641:1)(N!) ?79.264 ms (N!)
79.507 ms (N!) ?79.380 ms

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

From leo.vegoda at icann.org  Wed Feb 17 16:56:02 2010
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Wed, 17 Feb 2010 10:56:02 -0800
Subject: [lacnog] 50/8 and 107/8 allocated to ARIN
Message-ID: <DAAADC6C-BF1C-482E-9A75-B75F98047A54@icann.org>

Hi,

The IANA IPv4 registry has been updated to reflect the allocation
of two /8 IPv4 blocks to ARIN in February 2010: 50/8 and
107/8. You can find the IANA IPv4 registry at:

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt

Please update your filters as appropriate.

There are 22 unallocated unicast IPv4 /8s.

Regards,

Leo Vegoda
Number Resources Manager, IANA
ICANN

From francisco at arias.com.mx  Fri Feb 26 16:13:03 2010
From: francisco at arias.com.mx (Francisco Arias)
Date: Fri, 26 Feb 2010 11:13:03 -0800
Subject: [lacnog] Fwd: Root Zone DNSSEC Deployment Technical Status Update
In-Reply-To: <64AE6786-404D-4D58-94D2-7BC8786D668E@hopcount.ca>
References: <64AE6786-404D-4D58-94D2-7BC8786D668E@hopcount.ca>
Message-ID: <e5de97e21002261113u1405590dydc8cb760b09060ca@mail.gmail.com>

Por si no lo han visto.

Saludos,

Francisco.




---------- Forwarded message ----------
From: Joe Abley <jabley at hopcount.ca>
Date: 26 February 2010 09:02
Subject: [dns-operations] Root Zone DNSSEC Deployment Technical Status Update
To: dns-operations at dns-oarc.net
Cc: rootsign at icann.org


This is the third of a series of technical status updates intended to
inform a technical audience on progress in signing the root zone of
the DNS. Apologies if you receive multiple copies of this message.


RESOURCES

Details of the project, including documentation published to date,
can be found at http://www.root-dnssec.org/.

We'd like to hear from you. If you have feedback for us, please
send it to rootsign at icann.org.


DOCUMENTATION

The following draft document was recently published:

- Root Zone DNSSEC KSK Ceremonies Guide


DEPLOYMENT STATUS

KSR exchanges continue between development platforms at VeriSign
and ICANN. Test exchanges between production servers, exercising
regular operational staff and subject to production monitoring and
availability measurements is scheduled to begin on 2010-03-01.

Build-out of KSK Key Ceremony facilities at ICANN continues, and
both facilities (east- and west-coast USA) are expected to be ready
on schedule.

The incremental deployment of DNSSEC in the Root Zone is being
carried out first by serving a Deliberately-Unvalidatable Root Zone
(DURZ), and subsequently by a conventionally-signed root zone.
Discussion of the approach can be found in the document "DNSSEC
Deployment for the Root Zone", as well as in the technical presentations
delivered at RIPE, NANOG, IETF and ICANN meetings.

L-Root made the transition to the DURZ on 2010-01-27, and A-Root
did the same on 2010-02-10. No harmful effects of either transition
have been identified. Some early analysis of packet captures from
many root servers surrounding each event was recently presented at
NANOG 48 in Austin, Texas, USA and can be found with other presentation
materials at <http://www.root-dnssec.org/presentations/>.

Those who are tracking the impact of the DURZ transition on root
servers should note that the maintenance window for the M-Root DURZ
transition has changed to 2010-03-03 0600--0800 UTC, two hours later
than was originally advised. This change has been reflected in the
deployment plan, which can be found with other project documentation
at <http://www.root-dnssec.org/documentation/>.


PLANNED DEPLOYMENT SCHEDULE

Already completed:

?2010-01-27: L starts to serve DURZ

?2010-02-10: A starts to serve DURZ

To come:

?2010-03-03: M, I start to serve DURZ

?2010-03-24: D, K, E start to serve DURZ

?2010-04-14: B, H, C, G, F start to serve DURZ

?2010-05-05: J starts to serve DURZ

?2010-07-01: Distribution of validatable, production, signed root
? ?zone; publication of root zone trust anchor

?(Please note that this schedule is tentative and subject to change
?based on testing results or other unforseen factors.)

A more detailed DURZ transition timetable with maintenance windows
can be found in the document "DNSSEC Deployment for the Root Zone",
the most recent draft of which can be found on the project web page
at <http://www.root-dnssec.org/>.
_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations