April 2011 - dns-wg - mailman.ripe.net

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