February 2010 - dns-wg - mailman.ripe.net

RIPE - ARIN cooperation when registering signed legacy reverse zones?
by Chris Thompson 11 May '10

11 May '10

I hope this is the appropriate place to raise this. There are legacy network allocations whose reverse zone is managed via RIPE, but actually delegated from higher level reverse zones run by ARIN. To take a specific example, 131.111/16 is allocated to the University of Cambridge, we manage the delegation info for 111.131.in-addr.arpa via RIPE, but 131.in-addr.arpa belongs to ARIN. Now 111.131.in-addr.arpa is signed (since September 2009), and currently registered at dlv.isc.org. Along with the other high-level ARIN reverse zones, 131.in-addr.arpa is also signed, and https://www.arin.net/resources/dnssec/ indicates that they may be accepting signed delegations Fairly Soon Now (depending on what you think "the first part of 2010" means). Is it understood yet how (or even if) this will work for legacy network allocations? Ideally, this would just be a matter of supplying RIPE with the "ds-rdata" attributes as described in https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html and they would get transferred seamlessly into the ARIN zones (and signed there). -- Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.

8 11

DNSSEC Signer Replacement Project
by Andrei Robachevsky 24 Mar '10

24 Mar '10

Dear Colleagues, As noted during RIPE 59, the RIPE NCC is upgrading the current DNSSEC provisioning infrastructure. This project includes the replacement of current software signers with a more secure hardware solution. During this migration, an exception will be made to the double signing policy outlined in our key maintenance procedure, which is available at: https://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html In order to reduce the likelihood of validation errors as much as possible during the migration, a one-time exception will be made to the policy of double signing our Key Signing Keys (KSKs). This is because it is not possible to exchange keys between our old and new signers. To prevent signing all our zones on two signers and then merging the results, we will pre-publish the new KSK in March 2010 as a one-time exception. The DNSSEC signer migration will involve the steps detailed below. The dates align with our standard key rollover timings, as detailed on our website at: https://www.ripe.net/projects/disi//keys/ On Tuesday, 2 March 2010, our signer will switch to the currently pre-published Zone Signing Key (ZSK). This ZSK will not be rolled over again until Monday, 14 June 2010. No new trust anchors need to be configured for resolvers at this point. On Tuesday, 23 March 2010, we will pre-publish a new KSK and ZSK in our zones. The new KSK will be available in our trust anchor repository, also available at: https://www.ripe.net/projects/disi//keys/ One KSK will be in use, but both KSKs must be configured as trust anchors in DNSSEC validating resolvers. On Monday, 14 June 2010, the old KSK and ZSK will be deprecated. Only the new keys will be able to validate. One KSK will be in use. On Tuesday, 21 September 2010, we will publish a new KSK on our website and continue with our usual double signing policy. Two keys will then be in use. Given that the parent zones of the RIPE NCC's zones are likely to be signed in the near future, we will continue to follow the current key maintenance procedure and lifetimes after the migration in completed. This will allow us to make a more informed decision on the RIPE NCC's key lifetimes when the policies for our parent zones are known. Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC

2 1

specify dns for reverse lookup
by Athiqur Rahman 25 Feb '10

25 Feb '10

I have the 217.73.64.0/20 IP block assigned to me. I am trying to setup some reverse DNS records. I created the zone 64.73.217.in-addr.arpa which is answering queries fine. However when I create any other zone files withing that /20, they do not answer the queries. I have logged into the RIPE website and am trying to find where the DNS is specified for an IP range but can not seem to find it. Any advice on how to proceed with this problem?

2 1

Outdated RIPE NCC Trust Anchors in Fedora Linux Repositories
by Anand Buddhdev 08 Feb '10

08 Feb '10

[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

10 15

Measuring DNS Transfer Sizes - First Results
by Daniel Karrenberg 05 Feb '10

05 Feb '10

Apologies for the inevitable duplicates. You might be interested in reading about our measurements of real obtained DNS transfer sizes in relation to clients requesting DNSSEC responses. See here http://labs.ripe.net/content/measuring-dns-transfer-sizes-first-results Daniel

1 0