- dns-wg - mailman.ripe.net

New key-signing keys (KSKs) for RIPE NCC forward and reverse zones
by Anand Buddhdev 17 Mar '09

17 Mar '09

Dear Colleagues, On 12 March 2009, the RIPE NCC generated new key-signing keys (KSKs) for all the DNSSEC-signed zones that it operates. We have published updated trust anchor files for inclusion in validating resolvers. A list of all the zones that we sign and the trust anchor files are available at: https://www.ripe.net/projects/disi/keys/index.html The old KSKs are deprecated and will be removed from the zones on 15 June 2009. Please update your trust anchors before this date. Regards, Anand Buddhdev DNS Services Manager RIPE NCC

5 8

DNS lameness notifications
by Gilles Massen 10 Mar '09

10 Mar '09

Dear colleagues, I was wondering if there is a detailed description of what and how is tested in order to check the lameness of a server (i.e. how are the names resolved, timeouts and retransmits of the queries, checks made,....)? Any pointer would be welcome. The background is that I got notifications ("Unable to resolve nameserver ") which are most probably wrong, unless the resolving algorithm is very delicate... Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

12 13

RE: [dns-wg] DNS lameness notifications
by Stream Service 10 Mar '09

10 Mar '09

Hello, We did also receive that message for nameservers in: - 3 networks - 4 class c-subnets - 4 nameservers (on different servers) All nameservers where not resolved if I read it correctly. I did check it a few seconds ago for another time on all nameservers with dig: rDNS records are correctly returned. With kind regards, Mark Scholten Stream Service -----Original Message----- From: dns-wg-admin(a)ripe.net [mailto:dns-wg-admin@ripe.net] On Behalf Of Gilles Massen Sent: maandag 9 maart 2009 13:45 To: dns-wg(a)ripe.net Subject: [dns-wg] DNS lameness notifications Dear colleagues, I was wondering if there is a detailed description of what and how is tested in order to check the lameness of a server (i.e. how are the names resolved, timeouts and retransmits of the queries, checks made,....)? Any pointer would be welcome. The background is that I got notifications ("Unable to resolve nameserver ") which are most probably wrong, unless the resolving algorithm is very delicate... Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

1 0

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