- dns-wg - mailman.ripe.net

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

DNSSEC Provisioning for ERX Space Held with ARIN
by Wolfgang Nagele 24 Mar '11

24 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, ARIN has just announced that they are now supporting DNSSEC-enabled delegations for their reverse space. For more information, see: https://www.arin.net/announcements/2011/20110321.html This means that RIPE NCC members with ERX space assignments in the ARIN region can now also make use of DNSSEC. To do so, please submit a domain object which includes the ds-rdata field as you would for any other DNSSEC-enabled delegation. For more information on how to do this, see: http://www.ripe.net/data-tools/dns/dnssec/procedure-for-requesting-dnssec-d… We will enable this service for ERX space held in other RIR regions as soon as DNSSEC becomes available with those RIRs. For more information on ERX space in the RIPE NCC service region, see: http://www.ripe.net/lir-services/resource-management/erx 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/ iEYEARECAAYFAk2KFYYACgkQjO7G63Byy8fLrwCfVa6M28DwHHk1xjgpyeFLWdKq +1wAnAk/hIkgK16fbr7iRGeWJgYHwlEM =H3jm -----END PGP SIGNATURE-----

2 2

Announcement: New E-Learning Module DNS Vulnerabilities
by Sandra Bras 15 Mar '11

15 Mar '11

[Apologies for duplicate emails] Dear colleagues, The RIPE NCC is pleased to announce the launch of "DNS vulnerabilities", the second module of our DNSSEC E-Learning course. This module explains two common DNS security problems: "Man in the Middle" and "Kaminsky Attack". It can be viewed at: http://www.ripe.net/lir-services/training/e-learning/dnssec/dns-vulnerabili… We will be releasing more modules in the coming months, including: Module 3 DNSSEC and RIPE Database Modules. The RIPE NCC E-Learning is a free service that is available to everyone. If you have any questions, please feel free to contact us at e-learning(a)ripe.net. Happy learning, Sandra Brás Trainer/E-Learning Coordinator RIPE NCC

1 0

New article on RIPE Labs: Large-scale PCAP Data Analysis Using Apache Hadoop
by Mirjam Kuehne 12 Mar '11

12 Mar '11

Dear colleagues, Please find a new article on RIPE Labs: "Large-scale PCAP Data Analysis Using Apache Hadoop" http://labs.ripe.net/Members/wnagele/large-scale-pcap-data-analysis-using-a… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Wanted: DNS WG Agenda items
by Jaap Akkerhuis 12 Mar '11

12 Mar '11

Dear all, Maybe it is was a bit early, but my previous request didn't raise a lot of responses, so here is it again. We still have agenda slots available for the WG meetings. Do claim the slot you want before they are gone or suggest topics to discuss; to be informed about etc. Remember, it is your working group and you meeting. Regards, jaap

1 0

Request for Comments on IANA
by Jim Reid 07 Mar '11

07 Mar '11

Colleagues, NTIA has just issued an RFC on IANA's operation and governance. [No, not an IETF one!] Comments have to be in by the end of March. Response to this RFC will help NTIA to decide about what happens when its current IANA contract ends in September. Here's the URL: http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf It's not clear to me if this is something the WG collectively could or should respond to. That's up you all of you to decide. However some of you may want to submit your own responses to NTIA.

3 3