- dns-wg - mailman.ripe.net

Call for Agenda Items for the DNS WG meeting(s) at RIPE58
by Peter Koch 14 Apr '09

14 Apr '09

Dear DNS WG, it is a bit less than four weeks until the RIPE 58 meeting in Amsterdam and your WG chairs would like to collect proposals for contributions to the agenda. According to the most recent meeting plan we will meet Wed, 2009-05-06, 14:00-15:30 CEDT (//EIX) Thu, 2009-05-07, 09:00-10:30 CEDT (//Address Policy) (See also <http://www.ripe.net/ripe/meetings/ripe-58/meeting-plan.html>) Anyone who would like to suggest a presentation or would like to see a particular topic covered during the meeting is encouraged to submit ideas to <dns-wg-chairs(a)ripe.net>. Also, please keep in mind that there are several DNS related events scheduled for the RIPE meeting week, starting with a CENTR Technical Meeting (CENTR members only) on Sunday, the DNS WG on Wednesday and Thursday and the OARC Workshop on on Saturday, 9 May. Even though we expect different audiences, the organizers have agreed to coordinate on presentations to avoid undue overlap. To allow for this coordination and feedback to presenters, we'd appreciate suggestions to be sent prior to Friday next week, April 17. For new subscribers (and for everybody else as a refresh), the RIPE DNS WG homepage is at <http://www.ripe.net/ripe/wg/dns/>. Best regards, Peter [for the co-chairs]

1 1

Q: "lameness checks" - error messages for servers at the NCC?
by Wilfried Woeber, UniVie/ACOnet 30 Mar '09

30 Mar '09

Dear DNS-Folks, I'd like to understand whether receiving error messages that report problems related to the name server(s) run by/at the NCC is a rare case or rather "widespread". I am working on one such case now for a university served by our team. Please report back to me privately as I don't intend to see the list spammed with "mee too" messages :-) and I'll summarize to the list if useful. Thanks, Wilfried.

1 0

DNS lameness question
by Matus UHLAR - fantomas 23 Mar '09

23 Mar '09

Hello, We have received informations about DNS lameness in our reverse delegations. We have delegated (most of) our reverse zones to: ns.nextra.sk ns1.nextra.sk dns.nextra.sk dns.gtsi.sk Some time ago, since there were some problems, I removed the dns.nextra.sk record from the nextra.sk zone, and assigned its IP address to ns.nextra.sk. No direct zones were delegated to it (hopefully, not by us), this caused no problem there (at least not caused by us). However the delegations in RIPE do still point to dns.nextra.sk. There are plenty of them, and I plan to change the NS scheme to make it more reliable, easier to implement and harder to abuse (e.g. naming only some of NS records), so the structure will change even more. For this reason I decided not to change all delegations (to spare our RIPE contacts from modifying it all twice) until I will do that. However on Feb 24, RIPE sent lameness notifications to us and our RIPE contact got angry at me for not notifying them about this change, and requesting that I add the record back. I prefer not to do that, since my plans are very different and customers tend to put anything to NS records without asking. Adding CNAME record would not solve this problem since NS must not point to CNAME (scripts at RIPE check for that, right?). So I'm asking you for an advice - is it possible to mass-remove the "dns.nextra.sk" from delegations? - would it cause big problem if I kept it as it is, even if dns.nextra.sk does not exist? (I hope no delegations will be removed because of this) - is there anything other to advise me? Thank you -- Matus UHLAR - fantomas, uhlar(a)fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "To Boot or not to Boot, that's the question." [WD1270 Caviar]

2 4

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