- dns-wg - mailman.ripe.net

RIPE-61 coming up
by Jaap Akkerhuis 23 Sep '10

23 Sep '10

All, Yes, it sneaks up on you before you know. Please send in your suggestions and requests for agenda time. It is your working group after all and your chairs don't want to dctate al the entertainment, pardon, the agenda items. The Draft meeting plan is already up <http://www.ripe.net/ripe/meetings/ripe-61/meeting-plan.html> and you can see that the DNS-WG is oppoiste the EIX and the Anti-Abuse WG. In case your suggestions etc. clash with that let us know which slot is preferred. jaap

3 3

Postponement of DNSSEC KSK Roll-over for RIPE NCC Zones
by Anand Buddhdev 22 Sep '10

22 Sep '10

[Apologies for duplicates] Dear colleagues, Yesterday, 21 September, we were scheduled to perform a roll-over of Key Signing Keys (KSKs) of all our signed zones. However, during the roll-over we had some issues with our signing infrastructure, which caused some zones to be generated with expired signatures. We therefore rolled back to the state before the roll-over. In order to allow proper resolution of the problems we encountered, we are delaying our roll-over to the end of October. We will announce a new date before the event. Regards, Anand Buddhdev DNS Services Manager, RIPE NCC

1 0

Publicering av .SE:s DS-poster i rotzonen/Putting .SE's DS records into the root zone
by Anne-Marie Eklund-Löwinder 30 Aug '10

30 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Information in English will follow. Publicering av .SE:s DS-poster i rotzonen Med anledning av att rot nu är signerad har .SE lagt till sina DS-poster till rotzonen. Detta innebär rent tekniskt inga omedelbara problem för de som använder .SE som tillitsankare (Trust Anchor). Det gör det dock möjligt för den som så vill att byta till rot som tillitsankare för DNSSEC, något som vi rekommenderar att göra före nästa årsskifte då .SE kommer att rulla nycklar för DNSSEC enligt våra normala rutiner. Som en följd av att vi lägger våra DS-poster i rotzonen kommer .SE även att ta bort dem ur IANA:s ITAR. ITAR är en interimslösning som har fungerat väl för sitt syfte innan roten signerats, men fyller för vårt vidkommande nu ingen roll. DS-posterna kommer att tas bort från ITAR 30 dagar efter att de har publicerats i rotzonen. Vi råder er att prenumerera på meddelanden från dnssec-announce(a)lists.nic.se för att få information om viktiga förändringar av DNSSEC i .SE. Eventuella frågor kan ställas till dnssec-info(a)iis.se. Anne-Marie Eklund Löwinder Kvalitets- och säkerhetschef .SE (Stiftelsen för Internetinfrastruktur) Adress: Ringvägen 100 Postadress: Box 7399, 103 91 Stockholm Växel: 08-452 35 00 Direkt: 08-452 35 17 Mobil: 0734-31 53 10 E-post: anne-marie.eklund-lowinder(a)iis.se Webbplats: http://www.iis.se Putting .SE’s DS records into the root zone Since the root zone is now signed, .SE has submitted its DS records to the root zone. From a technical view this should not affect anyone using .SE as Trust Anchor. It will, however, make it possible to switch to using the root as Trust Anchor for DNSSEC. We recommend that you make this switch before the turn of the year when .SE’s next DNSSEC key rollover is scheduled to occur. As we publish our DS records in the root zone, we will remove them from IANA’s ITAR. ITAR is a temporary solution that served our needs well while the root zone was not signed, but it is to our concern no longer necessary. The DS records will be withdrawn from ITAR 30 days after they have become available in the root. We do advice you to subscribe to the dnssec-announce(a)lists.nic.se mailing list to get notified about key rollovers and any other important changes regarding DNSSEC in .SE. Questions may be addressed to dnssec-info(a)iis.se. Anne-Marie Eklund Löwinder Quality & Security Manager .SE (The Internet Infrastructure Foundation), PO Box 7399, SE-103 91 Stockholm, Sweden Phone: +46 (0)8-452 35 00/17 Mobile: +46 (0)734 315 310 E-mail: anne-marie.eklund-lowinder(a)iis.se Web: http://www.iis.se -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wj8DBQFMe3h+pdzwAUKxz5QRAqmlAJ9A9sLTuwtTqm0nhxzZ6uT8i1ndIACg1KoL 1xLrob4+MeHAhfK2M7JrO6s= =qZP1 -----END PGP SIGNATURE-----

1 0

Health of Domain Name system report
by Kostas Zorbadelos 25 Aug '10

25 Aug '10

A lot of people in here might be aware of this, but I think it is interesting enough to share it :) http://www.enisa.europa.eu/media/news-items/health-of-domain-name-systems-r… Kostas Zorbadelos

1 0

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