- dns-wg - mailman.ripe.net

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 18 Feb '09

18 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