- dns-wg - mailman.ripe.net

DNSSEC and DNS slowdown
by Max Tulyev 30 Jul '10

30 Jul '10

Hello! I have a strange problem. When I enable DNSSEC in my resolver (bind 9) - it slows down in several times. What do I do wrong? Or may be it is a feature? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

3 2

ACTION REQUIRED: Comment to US DoC NTIA on Signing the Root
by Daniel Karrenberg 30 Jun '10

30 Jun '10

Folks, it has come to my attention that the US government is still looking for comments about the plan to sign the root. We have said we want to see this happen before, but they apparently want to hear it again. So if you want to see this happening soon, please send them a note, however short. The relavant notice is attached. Written comments may be submitted by electronic mail to DNSSEC(a)ntia.doc.gov. I would recommend copying Ashley Heineman at aheineman(a)ntia.doc.gov. If you have questions, Ashley can be reached at +1 202 482?0298. Daniel

1 1

Reverse DNS operational considerations in an IPv6 environment
by Kostas Zorbadelos 16 Jun '10

16 Jun '10

I guess this is a question suited for this WG. References to other technical forums that can address this, or any pointers to established or not operational guidelines, are highly welcome. The question has to do with the provisioning of the reverse DNS entries of customers of a broaband provider in an IPv6 environment (PTR records in ip6.arpa). In the IPv4 world, each user receives mainly a single IP. There are dynamic and static users and most providers (including us) have pre-populated PTR records in their allocations in in-addr.arpa. PTR records can point to different namespaces depending on the address space use (eg static.<domainname> and dynamic.<domainname> for static and dynamic customers respectively). In the IPv6 case the problem is obvious because of the huge IPv6 address space. Since each customer can receive a /56, this is an assignment of 2^72 possible /128 addresses which is a tremendously HUGE number. We cannot possibly have pre-populated any zone with that many entries and this is just a single customer. The main question therefore is: how can we address this issue, if we need to have reverse DNS resolution for IPv6 ranges? The first thing that comes to my mind is using wildcard records in BIND, or skipping reverse DNS alltogether. Do you know of any operational recommendations? Thanks, Kostas Zorbadelos

4 8

DNSSEC KSK Rollover Event for RIPE NCC Zones
by Anand Buddhdev 14 Jun '10

14 Jun '10

[Apologies for duplicates] Dear Colleagues, On Tuesday, 23 March 2010, the RIPE NCC published new DNSSEC trust anchors. They can be found in a new location on the RIPE website at: https://www.ripe.net/dnssec-keys/ Today the RIPE NCC has started signing all of our zones with the new keys found in those trust anchor files. If you have both the old and the new keys configured you do not need to make any changes right now. On Wednesday, 16 June, we will remove the old trust anchors from our website. With today's key rollover event the RIPE NCC has completed the migration to new DNSSEC signers. We have updated our DNSSEC Policy and Practice Statement (DPS). The updated DPS can be found at: https://www.ripe.net/rs/reverse/dnssec/dps.html During the migration we did experience a small issue. Our processes failed to pre-publish the previous Zone Signing Key (ZSK) into the zones on our new signers. While our zones were propagating to the secondary servers, some validating resolvers may have fetched signed answers and DNSKEY records from different servers, and not been able to validate these answers. However, the time-to-live on the old ZSK DNSKEY record was one hour, so the window during which validation failures could have occurred is quite small. We have taken steps to ensure that this will not happen in the future. If you have any questions or comments, please send an email to <dns-help(a)ripe.net>. Regards, Anand Buddhdev DNS Services Manager

1 0

RE: Root Zone DNSSEC Deployment Technical Status Update
by Brett Carr 10 Jun '10

10 Jun '10

Joe, > Subject: [dns-operations] Root Zone DNSSEC Deployment Technical Status > Update > > Root Zone DNSSEC Deployment > Technical Status Update 2010-06-09 > > This is the eighth of a series of technical status updates intended > to inform a technical audience on progress in signing the root zone > of the DNS. > > > 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(a)icann.org. > > > PUBLIC NOTICE > > The US Department of Commerce National Telecommunications and > Information Administration (NTIA) has issued a Public Notice regarding > the deployment of DNSSEC in the root zone. > > http://www.ntia.doc.gov/frnotices/2010/FR_DNSSEC_Notice_06092010.pdf > > The Public Notice makes reference to the final report submitted to > NTIA by ICANN and VeriSign which contains a summary of the project > work to date together with a recommendation that full deployment > should proceed. > > http://www.ntia.doc.gov/reports/2010/DNSSEC_05282010.pdf > > The Public Notice includes a public review period. Comments may be > submitted by postal mail, fax or e-mail before 2010-06-21. > Instructions > for the submission of comments are included in the Public Notice. > > > PLANNED DEPLOYMENT SCHEDULE > > Already completed: > > 2010-01-27: L starts to serve DURZ > > 2010-02-10: A starts to serve DURZ > > 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 > > To come: > > 2010-06-16: First Key Signing Key (KSK) Ceremony > > 2010-07-15: Distribution of validatable, production, signed root > zone; publication of root zone trust anchor > Congratulations on the progress so far. Apologies if this question has been asked/answered before but do you have a timeline on the acceptance of DS records for publication into the root from TLD operators? Brett Carr Systems Administrator Nominet UK

1 0

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 09 Jun '10

09 Jun '10

Root Zone DNSSEC Deployment Technical Status Update 2010-06-09 This is the eighth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. 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(a)icann.org. PUBLIC NOTICE The US Department of Commerce National Telecommunications and Information Administration (NTIA) has issued a Public Notice regarding the deployment of DNSSEC in the root zone. http://www.ntia.doc.gov/frnotices/2010/FR_DNSSEC_Notice_06092010.pdf The Public Notice makes reference to the final report submitted to NTIA by ICANN and VeriSign which contains a summary of the project work to date together with a recommendation that full deployment should proceed. http://www.ntia.doc.gov/reports/2010/DNSSEC_05282010.pdf The Public Notice includes a public review period. Comments may be submitted by postal mail, fax or e-mail before 2010-06-21. Instructions for the submission of comments are included in the Public Notice. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 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 To come: 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-15: 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 unforeseen factors.)

1 0

Draft minutes for RIPE60 - take 2
by Jim Reid 31 May '10

31 May '10

Here are the draft minutes again. I hope the attachment is more easily readable this time. It appears my mail client (Apple Mail) is crippled by a DOS legacy. Sigh. It seems that when the file name of a text attachment doesn't have a .txt suffix, the file gets encoded as application/octet-steam (=> base64 weirdness) instead of a text/plain MIME type. Ho hum. Hopefully this is more readable for you all. Apologies for any trouble and please let me know if there are any problems this time round. Oh and comments on the minutes would be welcome too. :-)

1 0

draft RIPE60 minutes
by Jim Reid 29 May '10

29 May '10

Folks, here are the draft minutes from Prague. Please let me know if there are any errors or omissions.

1 0

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 18 May '10

18 May '10

Root Zone DNSSEC Deployment Technical Status Update 2010-05-17 This is the seventh of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. CHANGE IN DEPLOYMENT SCHEDULE The date for the publication of the root zone trust anchor and the distribution of a validatable, signed root zone originally planned for 2010-07-01 has been changed. This final stage of root DNSSEC deployment is now scheduled to take place on 2010-07-15. The schedule change is intended to allow ICANN and VeriSign an additional two weeks for further analysis of the DURZ rollout, to finalise testing and best ensure the secure, stable and resilient implementation of the root DNSSEC production processes and systems. Prior to 2010-07-15 the U.S. Department of Commerce (DoC) will issue a public notice announcing the publication of the joint ICANN-VeriSign testing and evaluation report as well as the intent to proceed with the final stage of DNSSEC deployment. As part of this notice the DoC will include a public review and comment period prior to taking any action. This change has been reflected in the deployment plan and other documentation, and updated documents will be published at <http://www.root-dnssec.org/>. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 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 To come: 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-15: 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 unforeseen factors.)

1 0

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