- dns-wg - mailman.ripe.net

RIPE58 minutes
by Jim Reid 10 Jan '10

10 Jan '10

Colleagues, a combination of miscommunication and confusion by the WG co-chairs has meant that the RIPE58 minutes went astray. Until now.... Sorry about that. I thought the minutes had been circulated just before RIPE59. They hadn't. And then assumed in Lisbon that the WG's silence about the RIPE58 minutes meant they could be approved by the WG. Which was wrong too. Oh well. Apologies are also due to the NCC staff who (a) sent your WG co-chairs the minutes before RIPE58 ended; (b) politely nagged us a few times to get the minutes out; (c) had extra hassle keeping the WG web pages up to date. Here they are. Please submit any comments or corrections to the list.

1 0

A Review of Administrative Tools for DNSSEC
by Rickard Bellgrim 22 Dec '09

22 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi .SE (The Internet Infrastructure Foundation) has together with Certezza produced a report that show the current state of administrative tools for DNSSEC. The report is a summary of the functionality of some leading DNSSEC management tools. The focus of the examination has been on DNSSEC signing and key management functionality. An important part of the work has been to specify a set of user review points. It is our belief that the review points are fairly general and as such can be used in similar reviews in the future. The key finding in the study is that there has been a substantial development of DNSSEC tools during the last year, but in a few areas some improvement work still remains. In general the product standard is good and the tested products work as expected. We hope that this product review facilitates the deployment of DNSSEC and would also encourage others to follow up on this work. Please, read the review here: http://www.iis.se/docs/DNSSEC-Admin-tools-review-1.01.pdf // Rickard Bellgrim -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSzC73+CjgaNTdVjaAQg0oAf+JuByCwfqLWCqje4DV/lg1ih9+9+MAeFe kS2HEEVd2rX0x7z+IjRyYz06U39lQsfeOURl2Eby/nOHc54Anw7TLR8u2zTmDZ68 UFCND/8DY7be6AY6uuvPRLx8L0RUpjRMLZSEjbkECXydmNslejuxZkm5nVVl+EKQ 2oc0BioEZ1uyQuvfT+BBD3g4D/gdZihlpF4pg2ey+nGC5bhO2PaTMjBYq+Y//M7L 2JvT/sesT+5KJDkwnBY1aVeplqWS823fIcbdK89bP36GZTjt9gV61OoYuY+PK4h3 47z3MIFyVpDA447i/YH4yxKd5qNpHfEOOwgCRR6nlOHfmMOMXhEkkg== =S0WO -----END PGP SIGNATURE-----

1 0

RIPE NCC Reply-size Test Application
by Anand Buddhdev 22 Dec '09

22 Dec '09

Dear Colleagues, The RIPE NCC is pleased to release an application for the purpose of determining the maximum size of DNS responses that a resolver can receive. This application is meant to assist users and network administrators to prepare their networks and resolvers for a signed root zone. To download this application, and learn how to use it, please see the RIPE Labs website: http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues If you have any questions or comments, please feel free to post them on the RIPE Labs website. Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC

1 0

RIPE NCC Confirms Commitment to DNSSEC Deployment in the Root Zone
by Andrei Robachevsky 16 Dec '09

16 Dec '09

[Apologies for duplicate emails] Dear Colleagues, On 1 December 2009, ICANN and VeriSign began to deploy DNSSEC across the root server system when they signed the root zone using DNSSEC. They noted that the signing would become public from January 2010, when the process of signing each of the 13 root servers in turn would begin. This process will continue until July 2010, when ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys. On 15 December 2009, the root zone DNSSEC deployment team launched a website that provides information about DNSSEC for the root zone: http://www.root-dnssec.org/ The website is a repository for the documentation relating to the deployment of DNSSEC in the root zone, and it includes information such as technical status updates and the full timetable for the deployment of DNSSEC. The RIPE NCC, operator of K-root, confirms its commitment to support the ICANN/VeriSign initiative and coordinate with the other root zone server operators in the deployment of DNSSEC in the root zone. The RIPE NCC also provides data collection and measurements that allows monitoring of the effects the transition has on the overall performance of the root server system. This information is available on RIPE Labs at: http://labs.ripe.net/content/preparing-k-root-signed-root-zone Further details on the RIPE NCC's operation of K-root are available at: http://k.root-servers.org Best regards, Andrei Robachevsky Chief Technical Officer RIPE NCC

1 0

DOMAIN object proposals
by Denis Walker 14 Dec '09

14 Dec '09

Dear Colleagues, The RIPE NCC made two proposals recently concerning DOMAIN objects: 22 October New rules for reverse domain object creation in the RIPE Database http://www.ripe.net/ripe/maillists/archives/dns-wg/2009/msg00104.html 23 November Removal of Forward DOMAIN data from the RIPE Database http://www.ripe.net/ripe/maillists/archives/dns-wg/2009/msg00119.html There have been no comments for or against either of these proposals on the mailing lists. They were both discussed at RIPE Meetings, without any negative comments. We would like to ask for any final comments by this Friday, 4 December 2009, so the working group chairs can then draw a consensus. Regards, Denis Walker Business Analyst, Database Group RIPE NCC

3 2

Removal of Forward DOMAIN data from the RIPE Database
by Denis Walker 23 Nov '09

23 Nov '09

[Apologies for duplicates] Dear Colleagues, The RIPE NCC has published an implementation plan for the removal of forward DOMAIN objects from the RIPE Database. It can be found at: http://www.ripe.net/db/support/forward-domain-objects-removal.html Please focus the discussion, if possible, on one working group mailing list. Because it is a data clean-up process, we suggest the Database Working Group. Regards Denis Walker Business Analyst Database Group RIPE NCC

1 0

DNSSEC - DS RR provisioning
by Edward Lewis 17 Nov '09

17 Nov '09

I have a short time slot to discuss these slides on Thursday, http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads/presentatio… but I want to try to get comments from people ahead of time. The presentation is trying first collect requirements, not present a solution to a problem in DNSSEC management. Most of the discussion I have had on this is with a smallish circle of people involved in TLD registry operations which I fear is not inclusive enough. In case you don't want to go through the slides, I'd like to ask these questions: 1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.) 2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents? 3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)? Although I have just 15 mins to run through the 35-odd slides, I really want to get input from various people while RIPE is in session - or via email. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.

10 13

RIPE 59 minutes
by Jim Reid 27 Oct '09

27 Oct '09

Here are the draft minutes from the Lisbon meeting. Thanks to Emil for taking comprehensive notes from the extensive discussions which took place. Please get in touch if you have corrections or updates to the minutes. And, as always, any comments are welcome.

1 0

Solving lameness in the reverse zones
by Shane Kerr 23 Oct '09

23 Oct '09

All, DNS Lameness Philosophy ----------------------- There are two fundamentally different philosophies about lameness in reverse DNS. The first (mine): DNS misconfiguration - lameness in this case - is bad when it causes operational problems for a human being somewhere. This may be a network administrator, or a system administrator, or an end user. The second: Lameness is bad because the maintainers of the zone data (the RIPE NCC and the administrator of the reverse domain) have a responsibility to keep this information correct. Proposals Based on Reducing User Pain ------------------------------------- Because I wrongly assumed that there was only one way to think about lameness, I made a set of proposals to how we deal with lameness in the reverse delegation at the RIPE meeting in Lisbon: 1. Stop mass-mailing to lame delegations 2. Include lameness information in an annual report to LIRs (possibly a good thing to have along with the annual bill anyway) 3. Perhaps check for the lame delegations causing the worst problems and send targeted mails based on those These suggestions were based on my philosophy that lameness is bad only inasmuch as it causes problems for actual human beings. So, that is one set of proposals. Proposal Based on DNS as a Platonic Form ---------------------------------------- I thought about it, and if we as a community decide that the 2nd philosophy is more appropriate, then our current strategy of asking people nicely to please fix the problems is ridiculous. A lame delegation is at best worthless, and often harmful. We can find lame delegations with very high certainty. The delegation is the responsibility of the parent as well as the child. So, I propose we modify the current process to work something like this: 1. Tell users that their delegations are lame. 2. Wait, then tell them again if not fixed. 3. Wait, then PULL THE DELEGATION if not fixed. If having clean data is important, lets stop with these half-measures, and do it right. Speaking only if we decide that we believe in clean data as a goal, of course. :) -- Shane

5 7

New rules for reverse domain object creation in the RIPE Database
by Denis Walker 22 Oct '09

22 Oct '09

Dear Colleagues, Please find below a proposal for additional checks on creating reverse delegation DOMAIN objects. Regards, Denis Walker Business Analyst, Database Group RIPE NCC Introduction ------------ At RIPE 59 in Lisbon, it was suggested to the DNS Working Group to extend the rules covering the creation of reverse delegation DOMAIN objects. The proposed additional rules are very simple: - If a parent (less specific) DOMAIN object exists at any level, do not allow creation of a child DOMAIN object. - If a child (more specific) DOMAIN object exists at any level, do not allow creation of a parent DOMAIN object. Apply these rules to both in-addr.arpa and ip6.arpa DOMAIN objects. Consequences ------------ If the parent exists, there is no benefit in creating child objects. So we keep the RIPE Database clean and free of objects that have no operational benefit. If the child exists, it is not possible to simply create a parent object and overrule the child object, maybe without even realising it exists. The child object will have to be deleted before the parent object can be created. In the event that an existing child object prevents the creation of a parent object, causing operational problems, the RIPE NCC will assist LIRs to resolve the issue. Cleanup ------- Currently, there are approximately 15,000 child objects that have an overruling parent object. These child objects have no operational effect. We propose to delete these child objects. Maintainers will be notified of the intention to delete the objects. The objects will then be deleted one month later. In order to allow simple searching up and down the address space, any DOMAIN objects for IPv4 /8s and IPv6 equivalents that currently exist in the RIPE Database will be deleted. Again, these objects have no operational benefit. Results ------- The RIPE Database will only contain reverse delegations for allocations and assignments at LIR and End User levels. There will be no overlaps or hierarchies. All DOMAIN objects will be operationally effective.

1 0