- dns-wg - mailman.ripe.net

"Final" Draft agenda DNS-WG
by Jaap Akkerhuis 26 Apr '10

26 Apr '10

And it is packed as usual jaap DNS WG, Thursday May 6th 11:00-12:30, Morning Session A. Administrative matters o Welcome o Scribe selection/introduction o Jabber selection/introduction o Microphone Etiquette o Finalise agenda B. Matters arising from RIPE-59 Minutes C. Review of Action items (No open items) D. IETF Reports - Matthijs Mekking What expired on the DNSEXT & DNSOP meetings during the IETF E. IETF report ire & regops - Ed Lewis "At the Corner of Registration Operations and DNS Operations" F. The RIPE-NCC DNSmon service - Franz Schwarzinger G. DNS operations at RIPE-NCC - Anand Buddhdev K-root's preparations and experiences of the DURZ roll-out, updates about our new reverse DNS infrastructure, and plans for changes in the provisioning software. H. The DNSSEC Testbed in DE - Peter Koch I. Joe Abley - IDNs on the fast track ___________________ DNS WG, Thursday May 6th 14:00-15:30, Afternoon Session K. An OARC Update - Wayne MacLaurin OARC's new executive director will provide an update on OARC. L. DNSSEC-Support by Home routers - Thorsten Dietrich M. News from Opendnssec - Matthijs Mekking N. DNSSEC for Humans - Joao Damas O. Ondrej Surnic - A Firefox DNSSEC Validator plug-in P. Dave Knight - Signing ARPA's children Q. Jaromir Talir - Anycast IPv4+IPv6 DNS in .CZ Z. AOB (Any Other Business) Dave Knight - Last Root server DURZed. Did the sky dropped? If you have another AOB thingy, let the chair person know in advance so some time might be reserved for that

1 0

Reverse DNS Delegations to Name Servers in the .YU Domain
by Anand Buddhdev 19 Apr '10

19 Apr '10

[Apologies for duplicates] Dear colleagues, On 1 April 2010, IANA removed the delegation of the .YU domain from the root zone. You can read more about this here: http://www.iana.org/reports/2010/yu-report-01apr2010.html With this removal, all names ending in .YU stopped resolving. Berislav Todorovic has informed the RIPE NCC about reverse DNS delegations to name servers in the .YU domain. These reverse delegations are now partially or completely lame. We would like to encourage all users using these name servers to update their delegation information in the RIPE Database to ensure that their reverse delegation continues to work properly. For more information on requesting reverse delegation, please see our 'how to': http://ripe.net/rs/reverse/reverse_howto.html Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC

1 0

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 15 Apr '10

15 Apr '10

This is the fourth 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. DOCUMENTATION The following draft document was recently published: - Resolver Testing with a DURZ - TCR - Proposed Approach to Root Key Management ICANN has begun the process of formally soliciting expressions of interest for volunteers from the technical community to act as Trusted Community Representatives. These volunteers will witness cryptographic key ceremonies and also carry out various important roles relating to KSK key management. For more information, see: http://www.icann.org/en/announcements/announcement-12apr10-en.htm Expressions of interest can be submitted here: http://www.root-dnssec.org/tcr/ DEPLOYMENT STATUS KSR exchanges continue between production platforms at VeriSign and ICANN. 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. Twelve of the thirteen root servers have now made the transition to the DURZ. No harmful effects have been identified. Some early analysis of packet captures from many root servers surrounding each event was recently presented at the IETF meeting in Anaheim, CA, USA and can be found with other presentation materials at <http://www.root-dnssec.org/presentations/>. 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 To come: 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 unforeseen 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/>.

1 0

TCR Approach to DNSSEC Root Key Management now online
by Jakob Schlyter 12 Apr '10

12 Apr '10

Greetings RIPE DNSWG members, I'd just like to inform you that the Trusted Community Representatives Approach to DNSSEC Root Key Management is now online and statements of interests may be submitted via http://www.root-dnssec.org/tcr/. See also the ICANN announcement at http://www.icann.org/en/announcements/announcement-12apr10-en.htm. jakob

1 0

Slight Increase in DNS Resolvers Doing Priming Queries after .arpa Signing - Why?
by Emile Aben 07 Apr '10

07 Apr '10

[Apologies for duplicates] In the latest blog on RIPE Labs, we discuss priming queries to K-root: http://labs.ripe.net/content/slight-increase-dns-resolvers-doing-priming-qu… We have seen a slight increase in the number of sources that issue priming queries to K-root since 18 March, the day after the signed .arpa zone was rolled out. This increase is visible on three out of five global nodes and seems to be caused primarily by resolvers that are not EDNS capable. While this is not causing any significant operational strain on K-root, and we don't believe a significant number of clients have problems with DNS resolution, we still want to know what is going on. We plan to further characterise this (look at TTLs) and hopefully isolate some sources that caused this increase. If you have any insight on this, or have suggestions on what we should look into, please let us know. Best regards, Emile Aben Research Engineer RIPE NCC

1 0

RIPE-60 coming up
by Jaap Akkerhuis 05 Apr '10

05 Apr '10

Now everyone has recovered most of the eastern eggs from this year and he left-overs from last year I would remind you that there is a RIPE meeting coming up. There is still space on the agenda so we welcome suggestions. Remember, it is your WG meeting. jaap

1 0

RIPE NCC Operated K-Root Server Now Distributing Root Zone Signed with DNSSEC
by Anand Buddhdev 24 Mar '10

24 Mar '10

[Apologies for duplicate emails] Dear Colleagues, The K-root server, operated by the RIPE NCC, is now serving the signed root zone as part of a staged global deployment of DNSSEC across the root zone system. Starting with L-root in January 2010, the root servers began serving the signed root zone in batches in the form of a Deliberately Unvalidatable Root Zone (DURZ). This roll out period is scheduled to end in May 2010 and ICANN is scheduled to sign the root zone with real keys and release the trust anchor after 1 July 2010. For more information, please see: http://www.ripe.net/news/k-root-signed-dnssec.html If you have any questions about this, please don't hesitate to contact <dns-help(a)ripe.net>. Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC

2 1

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

Re: Signing of the ARPA zone
by Joe Abley 17 Mar '10

17 Mar '10

Colleagues, This is a follow-up to the operational announcement regarding changes to the ARPA top-level domain that was sent on 2010-03-10. Apologies in advance for duplicates received through different mailing lists. As of 2010-03-17 1630 UTC all the authoritative servers for ARPA are serving a signed ARPA zone. We would like to solicit feedback from the technical community to allow us to identify any operational ill-effects that this change has caused. We will monitor this mailing list for feedback, and I will also distribute any feedback sent to me personally so that it can be considered. If no harmful effects have been identified by 2010-03-21 the trust anchor for the ARPA zone will be published through the IANA ITAR at <https://itar.iana.org/>. Regards, Joe Begin forwarded message: > From: Joe Abley <joe.abley(a)icann.org> > Date: 10 March 2010 16:13:46 EST > To: Joe Abley <joe.abley(a)icann.org> > Subject: Signing of the ARPA zone > > Colleagues, > > This is a technical, operational announcement regarding changes to the ARPA top-level domain. Apologies in advance for duplicates received through different mailing lists. > > No specific action is requested of operators. This message is for your information only. > > The ARPA zone is about to be signed using DNSSEC. The technical parameters by which ARPA will be signed are as follows: > > KSK Algorithm and Size: 2048 bit RSA > KSK Rollover: every 2-5 years, scheduled rollover to follow RFC 5011 > KSK Signature Algorithm: SHA-256 > Validity period for signatures made with KSK: 15 days; new signatures published every 10 days > ZSK Algorithm and Size: 1024 bit RSA > ZSK Rollover: every 3 months > ZSK Signature Algorithm: SHA-256 > Authenticated proof of non-existence: NSEC > Validity period for signatures made with ZSK: 7 days; zone generated and re-signed twice per day > > The twelve root server operators [1] will begin to serve a signed ARPA zone instead of the (current) unsigned ARPA zone during a maintenance window which will open at 2010-03-15 0001 UTC and close at 2010-03-17 2359 UTC. Individual root server operators will carry out their maintenance at times within that window according to their own operational preference. > > The trust anchor for the ARPA zone will be published in the ITAR [2], and in the root zone in the form of a DS record once the root zone is signed. > > If you have any concerns or require further information, please let me know. > > Regards, > > > Joe Abley > Director DNS Operations, ICANN > > [1] <http://www.root-servers.org/> > [2] <https://itar.iana.org/>

1 0

Signed .ARPA Zone Roll Out On K-root
by Wolfgang Nagele 16 Mar '10

16 Mar '10

[Apologies for duplicate emails] Dear Colleagues, We successfully rolled out the signed .ARPA zone on K-root. Regards, Wolfgang Nagele RIPE NCC DNS System Engineer

1 0