- dns-wg - mailman.ripe.net

DNS Lameness Statistics and Notifications
by Anand Buddhdev 27 Feb '09

27 Feb '09

Dear Colleagues, In January 2007, the RIPE Document ripe-400 was created to address lameness in the reverse DNS tree. This RIPE Document can be found online at: http://www.ripe.net/ripe/docs/ripe-400.html We have been monitoring name servers for some time now and statistics from the data gathered are published online each month at: http://www.ripe.net/info/stats/dns-lameness/ In October 2008, we sent out notifications to a small number of randomly selected server administrators. Replies to these messages indicated a need for further refinements to our probes and the interpretation of the results. Since then, we have made these improvements and fixed some bugs in our code. We now have better data and are ready to begin sending email alerts about lame delegations to name server operators. The email messages will point to the DNS Lameness FAQs, which explain the possible problems and give some pointers to help solve them. The FAQs can be found online at: http://www.ripe.net/info/stats/dns-lameness/faq.html We will begin sending small batches of email alerts from Thursday, 26 February 2009, using data collected over the month of February. This process will continue until all alerts have been sent out. The alerts will show which zone was checked and what error conditions were detected for its name servers. If you have any questions, please contact <dns-help(a)ripe.net>. Regards, Anand Buddhdev DNS Services Manager RIPE NCC

2 2

Interim Trust Anchor Repository
by Kim Davies 17 Feb '09

17 Feb '09

Dear colleagues, Last year, this working group wrote to ICANN requesting it implement a trust-anchor repository for top-level domains which deploy DNSSEC. After a couple of months of quiet usage by some of you since the RIPE meeting in Dubai, today we are announcing it publicly. It is available at https://itar.iana.org/ We of course are very interested in feedback and evolving the service, implementing any operational experience we gain into future procedures for key management in the trust anchor repository and the root zone itself. In its letter, the working group enumerated a number of requirements which I believe we have addressed in the implementation: 1) The service should be technology neutral, supporting different flavours of trust anchors: The trust anchor repository supports different algorithms and digest types, and doesn't seek to unnecessarily prohibit these. We'll try and adopt any future types and methodologies as they are standardised. 2) The service should be operating system and DNS neutral: There is nothing we are aware of that makes the trust anchor repository dependent on a specific implementation. As some implementations don't accept DS records as trust anchors, we have provided a tool to convert these to DNSKEY records. 3a) The service should verify keying material comes from an authorised source: We verify all listing requests with the same contacts we use to verify root zone changes. 3b) The trust anchors should be correctly formatted and consistent with the TLD zone. We compute the DS record from the DNSKEY records in the child zone, and ensure it matches before a listing request will succeed. 4) A process is needed to revoke a trust anchor: We have a revocation process, and we have set up a mailing list to send key revocation notifications to. Clearly, revoked keys will be removed from the machine readable formats immediately after they are verified. 5) It should be clear what support is available: ICANN is providing this as a clearly marked experimental service, with a limited lifespan. Hopefully events will overtake it and we'll have a signed root zone before we consider it leaving the experimental state. 6) It should have a clear exit strategy: ICANN has made it clear this is an interim service (hence the name "ITAR"), and that we will be decommissioning it after an appropriate time once the root zone is signed. 7) The respective manager must consent to list keying material: It is a requirement they consent before we list keys. We will not list keys without their explicit consent, even if we know they exist through other means. Thanks! Kim Davies Internet Assigned Numbers Authority

1 0

RIPE NCC trust anchors in zone-file format
by Anand Buddhdev 09 Feb '09

09 Feb '09

[Apologies for duplicate e-mails] Dear colleagues, We are pleased to announce that the trust anchors of the RIPE NCC's signed zones are now also available in zone-file format. This file is suitable for use with the Unbound validating resolver, for example. The file and its PGP signature are available at: https://www.ripe.net/projects/disi/keys/index.html If you have any questions or comments, please send them to <dns-help(a)ripe.net>. Regards, Anand Buddhdev DNS Services Manager RIPE NCC

1 0

RIPE NCC trust anchor file signature verification
by Anand Buddhdev 09 Feb '09

09 Feb '09

Dear colleagues, It was brought to our attention that the PGP signature of the trust anchor file we publish for all our signed zones was failing to verify with versions of GnuPG 1.4.8 and higher. This was caused by a combination of the following conditions: 1. A plain text file contains white space at the ends of lines and 2. A detached signature is generated In this case, the signature generated by versions of GnuPG lower than 1.4.8 will not verify with GnuPG 1.4.8 and higher. We have corrected this situation by ensuring that the trust anchor file we publish does not have extra white space at the end of any line. Therefore, the signature over this file will verify with any version of GnuPG. We have published an updated trust anchor file on the RIPE NCC website. We also took this opportunity to introduce trust anchors for two new reverse zones that we signed recently, which are 109.in-addr.arpa and 178.in-addr.arpa. The file and its signature are available at: https://www.ripe.net/projects/disi/keys/index.html Regards, Anand Buddhdev DNS Services Manager RIPE NCC

1 0

rev delegation robot and selection of NS to pull zone from
by Wilfried Woeber, UniVie/ACOnet 21 Nov '08

21 Nov '08

Another question regarding v6 reverse delegation, but possibly also applicable to v4 reverse... One of our customers has a somewhat complex DNS setup which makes us face the situation that in the SOA record the name of the NS where the zone originates is not in the set of responses to NS queries. While this is not the common case, I presume, it seems to NOT be "illegal". The domain has to on-site name servers and is configured to have a slave at the NCC. For this zone we received an alert that the ZXFR has failed from the machine with the name given in the SOA. That box will never be serving external zone transfer requests. So - this may just be a glitch in the alerting script, but I am still left with the question: how does the robot at the NCC's end determine the "appropriate" host to try zone transfers from? Any recommendations? Thanks, Wilfreid.

10 15

question re the "fate" of ns-v6.ripe.net
by Wilfried Woeber, UniVie/ACOnet 20 Nov '08

20 Nov '08

I am following up on some v6-related hickups (on our side) and found that our reverse zones specify ns-v6.ripe.net as one of the slaves. I am pretty sure that we didn't "invent" that out of the blue :-) but the documentation does not know about the "-v6" variant, and, checking the responses, queries to ns-v6.ripe.net and ns.ripe.net seem to yield the same A and AAAA responses. It may be a left-over from the time when the NCC's Services were not "transparently" IPv6-aware. What is the current recommendation? Wilfried.

1 0

Survey on a "Technology Backdrop": please participate
by Mohsen Souissi 19 Nov '08

19 Nov '08

[Apologies for multiple copies due to mailing-lists overlapping] Dear all, Our R&D team at AFNIC (The French ccTLD Registry), with the help of its Scientific Council, is carrying out a survey on a "Technology backdrop" for AFNIC in a medium-to-long term (10-15 years). The main objective is to get a common view of the future (trends, uncertainties) when assessing R&D opportunities in the future. We believe that the outcome of this survey may be of interest to people answering it, as most questions sit indeed in a a quite wide technology perimeter/scope. Here's a short description of the context & goals of the survey: ------------------------------------------------------------------------ This survey aims at helping AFNIC to develop a technology backdrop (i.e., a shared vision of technology evolution) in a medium-to-long term. Three axes have been chosen: "A. Global Internet Architecture", "B. Internet Naming, Identifiers and Digital Identities" and "C. User trends". : ------------------------------------------------------------------------ The survey is open from the 1st October to 31st of December 2008. Please feel free to participate: - "Canonical" URL: http://www.surveymonkey.com/s.aspx?sm=V0j_2fSEbCuIRb4EwwMPcyOA_3d_3d - "Tiny" URL: http://tinyurl.com/4xn2xc We commit to sharing the results with contributors who desire it (the survey includes a question to that effect). Looking forward to your contribution and thank you in advance for your time! Best Regards, Mohsen.

1 0

one more effort on the NTIA response
by Jim Reid 18 Nov '08

18 Nov '08

Colleagues, I am sorry to say that we have still not reached consensus on the proposed response to the NTIA NoI. After discussing this yesterday the WG co-chairs felt that further work is needed. We have also had reliable feedback that Friday's draft was being misinterpreted by some of the likely audience for this response outside the WG. I have taken guidance from an informal editing group to tweak the response to clear up the ambiguity and potential for misunderstanding. So we now have an updated draft response to consider. The intention is still to try and get consensus in the WG, ideally on the text below. If that can be achieved in the next few days, we will then endeavour to get consensus from the RIPE community. And if that is done, the agreed text will go to NTIA as a statement of the RIPE community. The NTIA deadline makes this a delicate balancing act. On the one hand, there's little time left for further discussion. On the other, there needs to be reasonable discussion time in both the WG and RIPE lists so that the validity of our procedures are not undermined. Please bear this in mind before commenting about the latest draft on the list. Please take a look at the latest revised version below. As before, I would ask you to only comment about any matters that you consider to be showstoppers and provide suggested alternate text. Please try not to focus on minor tweaks to the language as that will divert us all from the matter at hand. And take time we don't really have to spare. Remember too that we're trying to get consensus within the WG. This is hard because there are differing views about how the root could or should be signed. There may be wording in the text below that is not to your personal taste. And other WG members may well be uncomfortable with the stuff in the draft that you like. However I hope we can all agree the latest draft is a fair reflection of the collective view of the WG. Some compromise and good sense from all of us is needed to keep this thing on track. Don't forget that what we're doing here is expressing the view of the WG (or the RIPE community?) *as a whole*. This does not prevent any of you from making your own personal or professional representations to the NTIA, something I encourage all of you to do. If some of the detail is not to your personal taste, please think carefully about whether it's better to handle that inside the WG in the time available or by making a personal submission to NTIA. So unless there's something in the draft below that you think makes us look bad/stupid/ wrong, can I ask for your support on this latest version? Oh, and if you are happy with the latest draft, please say so on the list. Your WG co-chairs will feel a lot more comfortable declaring consensus when there are positive statements to that effect on the list. This is far better than presuming a default of silence implies consent. # # $Id: ntia-draft,v 1.8 2008/11/09 17:28:20 jim Exp $ # The RIPE community (or DNS WG?) thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC. It is to be expected that a community as diverse as RIPE cannot have a unified set of detailed answers to the NTIA questionnaire. However several members of the RIPE community will be individually responding to that questionnaire. We present the following statement as the consensus view of our community (or the DNS Working Group?) about the principles that should form the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. 2. The introduction of DNSSEC to the root zone must be made in such a way that it is accepted as a global initiative. 3. Addition of DNSSEC to the root zone must be done in a way that does not compromise the security and stability of the Domain Name System. 4. When balancing the various concerns about signing the root zone, the approach must provide an appropriate level of trust and confidence by offering an optimally secure solution. 5. Deployment of a signed root should be done in a timely but not hasty manner. 6. Updates from TLD operators relating to DNSSEC should be aligned with the operational mechanisms for co-ordinating changes to the root zone. 7. If any procedural changes are introduced by the deployment of DNSSEC they should provide sufficient flexibility to allow for the roles and processes as well as the entities holding those roles to be changed after suitable consultations have taken place. 8. Policies and processes for signing the root zone must be transparent and trustworthy, making it straightforward for TLDs to supply keys and credentials so the delegations for those TLDs can benefit from a common DNSSEC trust anchor, the signed root. 9. There is no technical justification to create a new organisation to oversee the process of signing of the root. 10. No data should be moved between organisations without appropriate authenticity and integrity checking, particularly the flow of keying material between a TLD operator and the entity that signs the root. 11. The public part of the key signing key must be distributed as widely as possible. 12. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key. 13. Changes to the entities and roles in the signing process must not necessarily require a change of keys.

19 32

Call for Support of our NTIA response posted
by Peter Koch 15 Nov '08

15 Nov '08

Dear DNS WG, the draft NTIA response has now been forwarded to the general RIPE discussion list <http://www.ripe.net/ripe/maillists/archives/ripe-list/2008/msg00048.html> for endorsement. Find below the differences between version 1.8 last called here and version 1.9, which went to the list. The changes clarify the originating entity and add a reference to RIPE's previous effort w.r.t. signing the root. -Peter Koch [for the DNS WG co-chairs] --- version1.8 2008-11-14 19:34:14.000000000 +0100 +++ version1.9 2008-11-14 09:40:15.000000000 +0100 @@ -1,21 +1,23 @@ # -# $Id: ntia-draft,v 1.8 2008/11/09 17:28:20 jim Exp $ +# $Id: ntia-draft,v 1.9 2008/11/13 20:20:41 jim Exp $ # -The RIPE community (or DNS WG?) thanks the NTIA for its consultation -on proposals to sign the root and is pleased to offer the following -response to that consultation. We urge the adoption of a solution that -leads to the prompt introduction of a signed root zone. Our community -considers the introduction of a signed root zone to be an essential -enabling step towards widespread deployment of Secure DNS, DNSSEC. +The RIPE community thanks the NTIA for its consultation on proposals +to sign the root and is pleased to offer the following response to +that consultation. We urge the adoption of a solution that leads to +the prompt introduction of a signed root zone. Our community considers +the introduction of a signed root zone to be an essential enabling +step towards widespread deployment of Secure DNS, DNSSEC. This view +is supported by the letter from the RIPE community to ICANN as an +outcome of discussions at the May 2007 RIPE meeting in Tallinn: +http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf. It is to be expected that a community as diverse as RIPE cannot have a -unified set of detailed answers to the NTIA questionnaire. However -several -members of the RIPE community will be individually responding to that -questionnaire. We present the following statement as the consensus -view of our community (or the DNS Working Group?) about the principles -that should form the basis of the introduction of a signed DNS root. +unified set of detailed answers to the NTIA questionnaire. However +several members of the RIPE community will be individually responding +to that questionnaire. We present the following statement as the +consensus view of our community about the principles that should form +the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control.

1 0

final? draft of NTIA response
by Jim Reid 13 Nov '08

13 Nov '08

Colleagues, here is what I hope is the final draft of our response to the NTIA. I trust we can reach consensus on this. There is very little time to continue with update/review cycles, so I would appreciate if any comments were confined to showstoppers. We might have reservations or quibbles about some of the detail or phrasing. However unless these materially affect the response, could I ask you to please keep these to yourself? My worry here is that further tweaks lead to yet more comments and tweaks, and this goes on and on and on. The current langauge may not be perfect. However I hope it is something that we can all agree is good enough. I would also ask WG members to say they support the text (assuming you do of course). It would be better to have positive statements of support instead of declaring that silence on this topic is consensus for the WG. # # $Id: ntia-draft,v 1.7 2008/11/07 11:55:18 jim Exp $ # The RIPE community (or DNS WG?) thanks the NTIA for its consultation on proposals to sign the root and is pleased to offer the following response to that consultation. We urge the adoption of a solution that leads to the prompt introduction of a signed root zone. Our community considers the introduction of a signed root zone to be an essential enabling step towards widespread deployment of Secure DNS, DNSSEC. It is to be expected that a community as diverse as RIPE cannot have a unified set of detailed answers to the NTIA questionnaire. However several members of the RIPE community will be individually responding to that questionnaire. We present the following statement as the consensus view of our community (or the DNS Working Group?) about the principles that should form the basis of the introduction of a signed DNS root. 1. Secure DNS, DNSSEC, is about data authenticity and integrity and not about control. 2. The introduction of DNSSEC to the root zone must be recognised as a global initiative. 3. Addition of DNSSEC to the root zone must be done in a way that does not compromise the security and stability of the Domain Name System. 4. When balancing the various concerns about signing the root zone, the chosen approach must provide an appropriate level of trust and confidence by offering a maximally secure technical solution. 5. Deployment of a signed root should be done in a timely but not hasty manner. 6. To assist with a timely deployment, any procedural changes introduced by DNSSEC should be aligned with the current process for coordinating changes to and the distribution of the root zone. However those procedural changes should provide sufficient flexibility to allow for the roles and processes as well as the entities holding those roles to be changed after suitable consultations have taken place. 7. Policies and processes for signing the root zone should make it easy for TLDs to supply keys and credentials so the delegations for those TLDs can benefit from a common DNSSEC trust anchor, the signed root. 8. There is no technical justification to create a new organisation to oversee the process of signing of the root. 9. No data should be moved between organisations without appropriate authenticity and integrity checking. 10. The public part of the key signing key must be distributed as widely as possible. 11. The organisation that generates the root zone file must sign the file and therefore hold the private part of the zone signing key. 12. Changes to the entities and roles in the signing process must not necessarily require a change of keys.

7 8