- dns-wg - mailman.ripe.net

2nd Draft DNS WG Agenda for RIPE 62
by Peter Koch 01 May '11

01 May '11

DNS WG, here's an updated agenda for our Wed and Thu meetings. Slots are mostly booked now with two pending confirmations. Regards, Peter ----------------------------------------------------------------------------- Wednesday, 2011-05-04 11:00-12:30 (09:00-10:30 UTC) // EIX ----------------------------------------------------------------------------- A Administrivia [chairs] B Report from the RIPE NCC [Wolfgang Nagele] C IETF report TBD/TBC D OpenDNSSEC [Jakob Schlyter] E BIND10 Live Demo [Shane Kerr] F Update on .uk DNSSEC Deployment [Brett Carr] G DNS Anomaly Detection [Ondrej Sury] ----------------------------------------------------------------------------- Thursday, 2011-05-05 11:00-12:30 (09:00-10:30 UTC) // Address Policy ----------------------------------------------------------------------------- N NSD4 Plans [Wouter Wijngaards] O DNSSEC client behaviour TBC P Changes to JP DNS traffic by DNSSEC [Masato Minda] Q IP6.ARPA and IN-ADDR.ARPA Changes [Dave Knight] R The "Dancing F-Root" Story [Wilfried Woeber] S Towards a Name Server Control Protocol [John Dickinson] Z A.O.B. -----------------------------------------------------------------------------

1 0

Draft DNS WG Agenda for Amsterdam RIPE 62
by Peter Koch 30 Apr '11

30 Apr '11

Dear WG, here's the draft agenda for next week's two meeting slots. Some of the contributions may have to be moved between Wed and Thu due to presenters' travel constraints. -Peter ----------------------------------------------------------------------------- DRAFT Agenda for the DNSWG at RIPE 62, Amsterdam ----------------------------------------------------------------------------- Wednesday, 2011-05-04 11:00-12:30 (09:00-10:30 UTC) // EIX ----------------------------------------------------------------------------- A Administrivia [chairs] B Report from the RIPE NCC [Wolfgang Nagele] C IETF report TBD/TBC D OpenDNSSEC [Jakob Schlyter] E BIND10 Live Demo [Shane Kerr] F Update on .uk DNSSEC Deployment [Brett Carr] G DNS Anomaly Detection TBC ----------------------------------------------------------------------------- Thursday, 2011-05-05 11:00-12:30 (09:00-10:30 UTC) // Address Policy ----------------------------------------------------------------------------- N NSD4 Plans [Wouter Wijngaards] O DNSSEC client behaviour TBC P DNS reverse mapping for IPv6 TBC Q IP6.ARPA and IN-ADDR.ARPA Changes [Dave Knight] Z A.O.B. -----------------------------------------------------------------------------

2 1

PGP Key-Signing Party at RIPE 62
by Anand Buddhdev 21 Apr '11

21 Apr '11

Dear colleagues, During RIPE 62, we will have a PGP Key-Signing Party, on Tuesday, 3 May at 17:30 in the Seasons Room at the Krasnapolsky Hotel. If you'd like to participate, please see the following page for details on how to sign up for it: http://ripe62.ripe.net/programme/social-events/pgp-key-signing-party Regards, Anand Buddhdev RIPE NCC

1 0

DNSSEC outage in ripe.net and 0.a.2.ip6.arpa
by Wolfgang Nagele 21 Apr '11

21 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, As some of you have noticed we had another DNSSEC outage last week. The zones affected were: ripe.net: 11:29 - 16:00 UTC on 14 April 0.a.2.ip6.arpa: 02:31 - 10:00 UTC on 15 April After analysis with our vendor, we determined that the cause of this outage was the same bug that caused the outage in e164.arpa on 15 February 2011. Our vendor concluded that the bug on 15 February was caused by an unusually high load on the signer system, but this time the system was in normal day-to-day operation, so that can't explain the failure. We've collected a sufficient amount of data from this incident to allow us to reproduce the circumstances and have found the bug in the system together with our vendor. We will receive an updated version of the software within the coming weeks. We have agreed to this timeline because this bug is only triggered in specific circumstances during a Key Signing Key rollover. We apologise for this outage. I would like to use the opportunity to point out that our long-term mitigation plan is to have a DNSSEC verification proxy in place. I am happy to say that our efforts for this have been well-received and a group of other interested parties has formed to work on it. If you would like to join the mailing list, please see: http://nlnetlabs.nl/mailman/listinfo/dnssexy Regards, Wolfgang Nagele DNS Group Manager RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2vytoACgkQjO7G63Byy8eKfACgs7HMEleAz0pEHIe03npMqUG6 xB4AoLBYtGOYyrk3X2VPOVjcsmpHIIIG =NFDn -----END PGP SIGNATURE-----

1 0

DNS WG action item list update
by Peter Koch 20 Apr '11

20 Apr '11

Dear DNS WG, during the preparation of the upcoming meeting it was noted that the maintenance of our action item list at <http://www.ripe.net/ripe/wg/dns/actions> has fallen behind a bit. This message attempts to clean up the list and resolve any ambiguity. Please do not hesitate to contact the WG co-chairs if you have any questions or concerns. ----------------------------------------------------------------------------- During RIPE 58, we addressed 57.1 "DLV for NCC maintained TAs" during the RIPE NCC report: Anand talked first about AP 57.1: The RIPE NCC supports signing of the root and had planned to upload its trust anchors into the ISC DLV. He noted that somehow, this has happened without RIPE NCC knowledge. Contact has been made with ISC to investigate how this came about. Further on: ACTION POINT: Anand to document the overhaul of provisioning methods to submit the Trust Anchors of zones signed by the RIPE NCC into ISC DLV. The draft solution to be distributed to the DB WG. This became 58.1 with only being slightly different from 57.1. ----------------------------------------------------------------------------- The summary from RIPE 58 reads: ACTION 58.1: NCC's KSKs in DLV RIPE NCC to followup on the inclusion of RIPE NCC's TAs into ISC DLV ACTION 58.2: IN-ADDR.ARPA objects in the database Child objects for reverse zones in the RIPE DB were causing confusion when a parent object was also present. Since the parent zone was already provisioned the child zone would have no effect. ACTION 58.3: RIPE NCC to evaluate feedback on Lameness Delegation checking and incorporate this into any future work. Report back at RIPE 59. ----------------------------------------------------------------------------- The minutes for RIPE 59 <http://www.ripe.net/ripe/groups/wg/dns/minutes/ripe-59> say: 58.2 IN-ADDR.ARPA objects in the database This has created an action item for the database WG. 58.3 Feedback on lame delegations Research into the lame delegation project will be presented by Shane Kerr (ISC) later in the agenda. Finally, the RIPE 59 minutes say: Peter proposed to keep action item 58.2 open so that the RIPE NCC can take care of this. He recommended closing NCC's KSKs and DLV action items (57.1 and 58.1). There were no objections. and later: Shane said he'd be happy to continue discussion on the mailing list. Peter proposed to close this action item (58.3). The WG agreed with this proposal. The issue of parent/child domain objects in the database for the reverse tree(s) was reported done by the DB group in a mail sent 09 Dec 2010: <http://www.ripe.net/ripe/maillists/archives/dns-wg/2010/msg00113.html> ----------------------------------------------------------------------------- Summary: We are going to list new action items 58.1, 58.2, and 58.3 as described above. All of these plus 57.1 can be marked "done" as per the minutes of RIPE 59 and subsequent email from the NCC's DB group. No Action Items from RIPE 59, Lisbon, October 2009 No Action Items from RIPE 60, Prague, May 2010 No Action Items from RIPE 61, Rome, November 2010 ----------------------------------------------------------------------------- Best regards, Peter

4 3

Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects
by Denis Walker 18 Apr '11

18 Apr '11

[Apologies for duplicate emails] Dear Colleagues, What follows is a short proposal to change the process of creating and updating reverse DOMAIN objects in the RIPE Database. Because this is a proposed RIPE Database change, please direct any discussion to the RIPE Database Working Group mailing list to keep it focused in one place. Regards, Denis Walker Business Analyst RIPE NCC Database Group Proposal to change the dash ('-') notation in reverse DOMAIN objects Introduction ------------ Reverse delegation DOMAIN objects allow the use of a dash ('-') in the syntax. The current arrangement causes problems with DNSSEC. We propose to drop the current behaviour. We would also introduce a new syntax using the dash notation to avoid the need for manual intervention for classless delegations. Both the current and the new behaviour described in this document only apply to IPv4 delegations. Feature to be deprecated ------------------------ Currently, we allow a dash in the third octet of an IPv4 reverse delegation. So, for the address range 10.2.1.0 - 10.2.100.255, the syntax allows a reverse delegation DOMAIN object to be submitted as 1-100.2.10.in-addra.arpa. The RIPE Database update software will expand this into 100 separate objects in the database with prefixes from 1.2.10.in-addra.arpa to 100.2.10.in-addra.arpa. Apart from the prefix, all the other data in the submitted object will be duplicated in all 100 objects. To modify or delete this set of objects, the user has to process all 100 objects individually. No bulk operations are possible after the original object has been expanded in the database. This feature is not compatible with using DNSSEC. The value of the "ds-rdata:" attribute is a hash that includes the delegation. By definition, this must be different for each DOMAIN object. These different hash values for multiple objects cannot be entered by submitting a single object with the dash notation. This issue was raised by members of the DNS community, and the RIPE NCC now proposes to deprecate this update feature. Feature to be added ------------------- Classless delegations, according to RFC2317 (http://www.ietf.org/rfc/rfc2317.txt), are currently handled manually by the DNS Department at the RIPE NCC. Although the objects can be created in the RIPE Database, they will not be propagated to the zone files. The RIPE NCC proposes to allow a dash in the fourth octet of an IPv4 reverse delegation. So, for the address range 10.2.1.6 - 10.2.1.25, the syntax would allow a reverse delegation DOMAIN object to be submitted as 6-25.1.2.10.in-addra.arpa. This object would not be expanded by the RIPE Database update software into 20 separate objects, as it is with the feature described above. It would be created in the database as a single object, including the dash in the range. New DNS provisioning software would handle the new dash notation and propagate this delegation to the zone file. However, the range 0-255 is a special case and would not be allowed in the fourth octet. Modification and deletion can be performed on the single object in the database. Any change would be propagated into the zone file by the new delegation software.

7 11

Re: [Dnssec-deployment] IN-ADDR.ARPA Nameserver Change Complete
by Wolfgang Nagele 13 Apr '11

13 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, >> RIPE have signed high-level IPv4 reverse zones, and trust anchors for >> them have been imported into dlv.isc.org >> have signed high-level IPv6 reverse zones, and actually have DS >> records for them in IP6.ARPA > We are going to submit our DS records for zones below in-addr.arpa during our > next KSK rollover. This rollover is currently scheduled for mid April 2011. See: > https://www.ripe.net/data-tools/dns/dnssec/dnssec-keys I am happy to announce that this has been completed today. RIPE NCC IPv4 reverse space is now fully linked to the chain of trust from the root zone down. Regards, Wolfgang Nagele DNS Group Manager, RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2lcUkACgkQjO7G63Byy8fFcQCfbJb92cKGxeG+H7AWCGdoiCxF t18An0tdcGvyRi1SCemsf3Oa1+eyW9bw =WcDF -----END PGP SIGNATURE-----

1 0

Deletion of Forward DOMAIN object data from the RIPE Database
by Denis Walker 07 Apr '11

07 Apr '11

[Apologies for duplicate emails] Dear Colleagues, The RIPE NCC announced to the mailing lists on 29 March that Forward DOMAIN object data will be deleted this week: http://www.ripe.net/ripe/maillists/archives/db-wg/2011/msg00074.html All Forward DOMAIN object data has now been deleted from the RIPE Database, except for the four top-level domain (TLD) operators who are still actively using the RIPE Database. It is not possible for any user to re-create a top-level Forward DOMAIN object in the RIPE Database. Without the TLD object, no second-level DOMAIN object creations can be authorised. When the last four TLD operators have moved their data to their own systems, we will modify the update software so it will not recognise any Forward DOMAIN objects. Regards, Denis Walker RIPE NCC Database Group

3 4

Call for RIPE 62 DNS-WG agenda items
by Peter Koch 04 Apr '11

04 Apr '11

Dear DNS WG, the RIPE62 meeting in Amsterdam is four weeks away and we need to eventually populate the agenda. Please note we have, as usual, two slots available. This time they are on Wed and Thu morning, in parallel with EIX and one of the address policy sessions. We plan to have the usual round of updates from the IETF and other international fora (volunteers still welcome) as well as from the RIPE NCC. There are some presentation proposals already, but your chairs would like to encourage even more contributions from the broader community. You will likely sense an overall theme of IPv6 across the various WG and plenary slots and while this might be an inspiration to some, it doesn't have to constrain any ideas you have. Do not believe that what you present would have to be next year's research project. Short demonstrations of operational practice are fine! Just let me know of any suggestions. -Peter <http://www.ripe.net/ripe/wg/dns>

1 0

Deletion of Forward DOMAIN data from the RIPE Database
by Denis Walker 29 Mar '11

29 Mar '11

[Apologies for duplicate emails] Dear colleagues, The RIPE NCC is ready for the next stage of this clean-up process, as discussed at the last few RIPE Meetings. The RIPE Database still contains many forward DOMAIN objects, listed below. Only four TLD Registries are still actively using the RIPE Database for their whole provisioning or for a second-level dataset, .SM, .MC, .NO, .IL. These four Registries are working on alternative solutions and their data will remain in the RIPE Database until their arrangements are complete. Looking at the update logs for the last year, there has been very little activity on all the other DOMAIN data (summarised below). The occasional updates are End Users who maintain their own DOMAIN objects. Even though the activity logs show that these Registries were not actively using the RIPE Database, we still contacted them for confirmation. In some cases, we received no response. The RIPE NCC will delete all the forward DOMAIN data (except for the four active users) in the week beginning Monday, 4 April 2011. Regards, Denis Walker Business Analyst RIPE NCC Database Group List of registries with forward DOMAIN data in the RIPE Database 2 al 12 at 2 az 9 ba 2 by 2 cm 24 com 1 cx 1 dz 8 ee 2 es 56 fi 2 ga 668 gm 26 hu 8 ie 176 il 2 ir 1 jj 3 jo 1 ke 1 kg 1 kr 4 kz 1 lb 1 lc 1 lv 1 ly 1 ma 702 mc 1 mt 55 net 82 no 9 org 1 pk 99 pl 20 pt 4 ru 6 sa 2210 sm 33 tr 1 va Activity over last year 2010 1 Create Modify delete fo 34 29 12 il 0 2 0 sm 27 12 15 2010 2 Create Modify delete fo 26 21 41 md 0 2 0 pl 0 1 0 sm 18 44 12 2010 3 Create Modify delete TLD si 0 0 1 es 0 0 1 fo 34 48 24 ly 0 0 3 sm 24 23 15 2010 4 Create Modify delete fo 38 34 13 net 0 0 1 si 0 0 1 sm 26 9 13 2010 5 Create Modify delete TLD de 0 1 0 fo 32 27 13 gr 0 1 0 il 0 2 0 mc 0 1 0 org 0 1 0 sm 37 10 10 2010 6 Create Modify delete TLD dk 0 1 0 fo 3 10 2 mc 2 8 0 sm 9 5 12 2010 7 Create Modify delete TLD fo 0 1 0 fo 0 0 1 gr 0 2 0 mc 2 2 0 sm 18 8 16 2010 8 Create Modify delete TLD fo 0 3 0 fo 0 0 3109 sm 16 14 10 2010 9 Create Modify delete mc 2 0 0 sm 20 20 9 2010 10 Create Modify delete be 0 0 1 gr 0 1 0 mc 1 0 0 sm 25 16 119 2010 11 Create Modify delete be 0 0 30 bg 0 0 5 cz 0 0 3 de 0 0 1 fi 0 1 0 gl 0 0 22 gr 0 0 75 it 0 0 2 lv 0 0 62 md 0 0 15 ro 0 0 1 se 0 0 6 sm 29 15 11 tn 0 0 2 ug 0 0 1 uk 0 0 4 2010 12 Create Modify delete sm 11 272 7 2011 1 Create Modify delete mc 2 0 0 sm 22 9 23 2011 2 Create Modify delete TLD is 0 1 0 fi 0 2 0 sm 13 3 66

1 0