From gilles.massen at restena.lu Mon Mar 9 13:44:56 2009 From: gilles.massen at restena.lu (Gilles Massen) Date: Mon, 9 Mar 2009 13:44:56 +0100 Subject: [dns-wg] DNS lameness notifications Message-ID: <200903091344.57135.gilles.massen@restena.lu> 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 From nuno.vieira at nfsi.pt Mon Mar 9 13:47:47 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Mon, 9 Mar 2009 12:47:47 +0000 (WET) Subject: [dns-wg] DNS lameness notifications In-Reply-To: <200903091344.57135.gilles.massen@restena.lu> Message-ID: <1871503879.81771236602867439.JavaMail.root@zimbra.nfsi.pt> We got a few notices aswell. We are monitoring our DNS servers from several locations and we had no outages during this period. --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Gilles Massen" wrote: > 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 From md at Linux.IT Mon Mar 9 16:01:17 2009 From: md at Linux.IT (Marco d'Itri) Date: Mon, 9 Mar 2009 16:01:17 +0100 Subject: [dns-wg] DNS lameness notifications In-Reply-To: <200903091344.57135.gilles.massen@restena.lu> References: <200903091344.57135.gilles.massen@restena.lu> Message-ID: <20090309150117.GB15061@bongo.bofh.it> On Mar 09, Gilles Massen wrote: > The background is that I got notifications ("Unable to resolve nameserver ") > which are most probably wrong, unless the resolving algorithm is very > delicate... Many people got those, I can definitely confirm that there are some unexplained false positives. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From anandb at ripe.net Tue Mar 10 00:36:25 2009 From: anandb at ripe.net (Anand Buddhdev) Date: Tue, 10 Mar 2009 00:36:25 +0100 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <200903091344.57135.gilles.massen@restena.lu> References: <200903091344.57135.gilles.massen@restena.lu> Message-ID: <49B5A7F9.6030709@ripe.net> Gilles Massen wrote: Hello Gilles, > 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. This is currently not documented. However, I can provide a quick explanation here. The first phase of the lameness checks involves generating a canonical list of name servers for a zone. The process gathers all the name servers, and queries each name once for A and AAAA records, with a 3-second timeout. Once it has a complete list of zone and nameserver address pairs, it queries each address for a SOA record for the zone, with a 3-second timeout. If a particular address yields no response, it is queued, and queried up to 4 more times at varying intervals. > The background is that I got notifications ("Unable to resolve nameserver ") > which are most probably wrong, unless the resolving algorithm is very > delicate... We are aware that around 1% of the servers we have in our list did not resolve to addresses, which resulted in these false positives. We are taking steps to ensure that we eliminate as many of these as possible in future probes. -- Anand Buddhdev DNS Services Manager, RIPE NCC From info at streamservice.nl Tue Mar 10 01:19:45 2009 From: info at streamservice.nl (Stream Service) Date: Tue, 10 Mar 2009 01:19:45 +0100 Subject: [dns-wg] DNS lameness notifications Message-ID: <002601c9a115$eb5c7520$c2155f60$@nl> 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 at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of Gilles Massen Sent: maandag 9 maart 2009 13:45 To: dns-wg at 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 From dougb at dougbarton.us Tue Mar 10 05:02:21 2009 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 09 Mar 2009 21:02:21 -0700 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <49B5A7F9.6030709@ripe.net> References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> Message-ID: <49B5E64D.5040003@dougbarton.us> Anand Buddhdev wrote: > Gilles Massen wrote: > > Hello Gilles, > >> 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. > > This is currently not documented. It needs to be documented for at least 2 reasons that come immediately to mind. First, it will allow operators to perform the same tests that you(pl) are performing, thus hopefully catching problems before they happen. Second, it will allow for peer review of the procedure. Given that there are a non-trivial number of operators reporting that your system is generating false positives, I think both of these goals are relevant. In an effort to be helpful (not critical) I will ask some questions about the details you've left out below. Hopefully fleshing this process out can help everyone involved. > However, I can provide a quick explanation here. > > The first phase of the lameness checks involves generating a > canonical list of name servers for a zone. How is this done? IOW, what sources are queried to generate the list? > The process gathers all the name servers, and queries each name > once for A and AAAA records, with a 3-second timeout. What source is queried? If a query times out are other authoritative sources for that name tried? I would say off hand that 3 seconds is probably not long enough for a timeout, but it might be acceptable if more than one source is tried (for example, if you're looking for the address records for ns1.example.com and you try all of the name servers for example.com). > Once it has a complete list of zone and nameserver address pairs, I think I know what you mean by this, but I'm not sure. Could you please flesh this out? > it queries each address for a SOA record for the zone, with a > 3-second timeout. If a particular address yields no response, it is > queued, and queried up to 4 more times at varying intervals. That sounds a little more reasonable, although if it were me I would double the timeout on each successive query. hope this helps, Doug From Niall.oReilly at ucd.ie Tue Mar 10 10:00:18 2009 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 10 Mar 2009 09:00:18 +0000 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <49B5A7F9.6030709@ripe.net> References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> Message-ID: <1236675618.18880.92.camel@d410-heron> Hello, Anand. On Tue, 2009-03-10 at 00:36 +0100, Anand Buddhdev wrote: > We are aware that around 1% of the servers we have in our list did not > resolve to addresses, which resulted in these false positives. Rather than false positives, doesn't that indicate a different kind of lameness -- of the delegation, rather than of the server? /Niall From bins at denic.de Tue Mar 10 08:57:27 2009 From: bins at denic.de (Elmar K. Bins) Date: Tue, 10 Mar 2009 08:57:27 +0100 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <49B5A7F9.6030709@ripe.net> References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> Message-ID: <20090310075727.GY27070@ronin.4ever.de> Re Anand, anandb at ripe.net (Anand Buddhdev) wrote: > > The background is that I got notifications ("Unable to resolve nameserver ") > > which are most probably wrong, unless the resolving algorithm is very > > delicate... > > We are aware that around 1% of the servers we have in our list did not > resolve to addresses, which resulted in these false positives. We are > taking steps to ensure that we eliminate as many of these as possible in > future probes. Actually, I personally would be more interested in more detailed error messages, especially in the case of those false positives. We dream of our stuff being always resolvable... Yours, Elmar. -- --[ bins at denic.de ]-----------------------------[ http://www.denic.de/ ]-- DENIC eG | Elmar K. Bins | Networking, Security Kaiserstr. 75-77 | AS8763, AS31529 | Tel +49 69 27235 0 D-60329 Frankfurt am Main | EKB2 @ RIPE | Fax +49 69 27235 239 -------------------------------------------------------------------------- Eingetr. Nr. 770 im Genossenschaftsregister Amtsgericht Frankfurt am Main Vorstand: Sabine Dolderer, Dr. J?rg Schweiger, Marcus Sch?fer, Carsten Schiefner. Vorsitzender des Aufsichtsrats: Elmar Knipp From gilles.massen at restena.lu Tue Mar 10 10:42:56 2009 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 10 Mar 2009 10:42:56 +0100 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <1236675618.18880.92.camel@d410-heron> References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> <1236675618.18880.92.camel@d410-heron> Message-ID: <200903101042.56769.gilles.massen@restena.lu> Hi Niall, > Rather than false positives, doesn't that indicate a > different kind of lameness -- of the delegation, rather > than of the server? Actually it depends on the test. If I interpret Anand's comment correctly, and only 1 query per name is made, then you'd only need one server to be slow or one packet to be lost (and isn't that what udp is for? :)) to become flagged as 'unresolvable'. But I'd like to believe that the DNS can do better than that. Besides, flagging too many nameserver as unresolvable means that the actual lameness test won't be performed, so the statistics could end up to be seriously tainted... Best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From Niall.oReilly at ucd.ie Tue Mar 10 14:03:27 2009 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 10 Mar 2009 13:03:27 +0000 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <200903101042.56769.gilles.massen@restena.lu> References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> <1236675618.18880.92.camel@d410-heron> <200903101042.56769.gilles.massen@restena.lu> Message-ID: <1236690207.18880.160.camel@d410-heron> On Tue, 2009-03-10 at 10:42 +0100, Gilles Massen wrote: > Actually it depends on the test. [...] Gilles, I think we're not disagreeing, but just identifying different edge and corner cases. I'm sure Anand knows how to merge hint-streams. 8-) /Niall From info at streamservice.nl Tue Mar 10 14:25:34 2009 From: info at streamservice.nl (Stream Service) Date: Tue, 10 Mar 2009 14:25:34 +0100 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <1236690207.18880.160.camel@d410-heron> References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> <1236675618.18880.92.camel@d410-heron> <200903101042.56769.gilles.massen@restena.lu> <1236690207.18880.160.camel@d410-heron> Message-ID: <000001c9a183$b2a3b270$17eb1750$@nl> Hello, Also a test page like SIDN has for the nameservers and some other registries have should be nice so we can check what RIPE registers. So a web frontend for the current test so people can test it when they want to test it and not waiting for a new email from RIPE to see if it is changed correctly. With kind regards, Mark Scholten Stream Service -----Original Message----- From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of Niall O'Reilly Sent: dinsdag 10 maart 2009 14:03 To: Gilles Massen Cc: dns-wg; Anand Buddhdev Subject: Re: [dns-wg] Re: DNS lameness notifications On Tue, 2009-03-10 at 10:42 +0100, Gilles Massen wrote: > Actually it depends on the test. [...] Gilles, I think we're not disagreeing, but just identifying different edge and corner cases. I'm sure Anand knows how to merge hint-streams. 8-) /Niall From fweimer at bfk.de Tue Mar 10 14:51:42 2009 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 10 Mar 2009 14:51:42 +0100 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <20090310075727.GY27070@ronin.4ever.de> (Elmar K. Bins's message of "Tue, 10 Mar 2009 08:57:27 +0100") References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> <20090310075727.GY27070@ronin.4ever.de> Message-ID: <8263ih5vv5.fsf@mid.bfk.de> * Elmar K. Bins: >> We are aware that around 1% of the servers we have in our list did not >> resolve to addresses, which resulted in these false positives. We are >> taking steps to ensure that we eliminate as many of these as possible in >> future probes. > > Actually, I personally would be more interested in more detailed error > messages, especially in the case of those false positives. We dream of > our stuff being always resolvable... I second that, especially if DNSSEC validation is involved. The current message format is good enough for trivial cases, but it's a bit terse in case of complex failure scenarios. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Ed.Lewis at neustar.biz Tue Mar 10 14:36:46 2009 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 10 Mar 2009 09:36:46 -0400 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <49B5A7F9.6030709@ripe.net> References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> Message-ID: At 0:36 +0100 3/10/09, Anand Buddhdev wrote: >We are aware that around 1% of the servers we have in our list did not >resolve to addresses, which resulted in these false positives. We are >taking steps to ensure that we eliminate as many of these as possible in >future probes. Servers that cannot be reached are not "lame" per se. The origin of the concern over lameness (excepting the desire for complete correctness by some) was in an old resolver implementation that didn't know that a referral to the root was an indication of lameness and not a referral to be followed. When this old resolver queried a server without a response (including not finding an IP address for the server's domain name), it stopped asking and thus was not a problem. When the resolver got a response and it was a referral to the root problems ensued. In at least three RFCs lame servers are defined to be servers that are not authoritative for the zones they are thought to be authoritative for. To detect that, the querier has to get a response. So, for a server to be considered lame by a resolver (that's the "eye of the beholder" here), the server must have an IP address, be reachable, and respond. For the lame testing I've written, I've always listed servers by IP address and not domain name. That is because some registrants would list multiple NS records with different domains, all pointing to the same IP address. In one instance, three NS records each pointed to three IP addresses, but all sets of the three IP addresses were identical. That is: silly.example. NS ns1.silly.example. silly.example. NS ns2.silly.example. silly.example. NS ns1.silly.example. ns1.silly.example. AAAA ::1 ns1.silly.example. AAAA ::2 ns1.silly.example. AAAA ::3 ns2.silly.example. AAAA ::1 ns2.silly.example. AAAA ::2 ns2.silly.example. AAAA ::3 ns3.silly.example. AAAA ::1 ns3.silly.example. AAAA ::2 ns3.silly.example. AAAA ::3 So, my recommendation when implementing a lame server test - stick to the IP addresses and test them. If there is no IP address available, don't try to test - the problem may lie in the forward map, getting to the forward map, etc., and may just be too confusing to explain. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Getting everything you want is easy, if you don't want much. From marco.davids at sidn.nl Tue Mar 10 15:02:58 2009 From: marco.davids at sidn.nl (Marco Davids) Date: Tue, 10 Mar 2009 15:02:58 +0100 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: <000001c9a183$b2a3b270$17eb1750$@nl> References: <200903091344.57135.gilles.massen@restena.lu> <49B5A7F9.6030709@ripe.net> <1236675618.18880.92.camel@d410-heron> <200903101042.56769.gilles.massen@restena.lu> <1236690207.18880.160.camel@d410-heron> <000001c9a183$b2a3b270$17eb1750$@nl> Message-ID: <49B67312.9040505@sidn.nl> Stream Service wrote: > Also a test page like SIDN has for the nameservers and some other registries > have should be nice so we can check what RIPE registers. > So a web frontend for the current test so people can test it when they want > to test it and not waiting for a new email from RIPE to see if it is changed > correctly. To be just a little bit more precise: the SIDN testpage currently only checks for domains with an.nl extension. We are in the process of renewing our DNScheck. It might in the future even be able to check more than just .nl We are working closely together with our fine collegues from .SE regarding these improvements and hence I would like to recommend their great dnscheck-page: http://dnscheck.iis.se/ It should be able to test al zones, include in-addr.arpa. But bear in mind it is new software, which may not be entirely free of errors. Feel free to contribute to it, in order to improve it! :-) http://opensource.iis.se/trac There is also a mailinglist. Best regards, -- Marco Davids SIDN From jaap at NLnetLabs.nl Tue Mar 10 15:30:08 2009 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 10 Mar 2009 15:30:08 +0100 Subject: [dns-wg] Re: DNS lameness notifications In-Reply-To: Your message of Tue, 10 Mar 2009 14:25:34 +0100. <000001c9a183$b2a3b270$17eb1750$@nl> Message-ID: <200903101430.n2AEU8Ac063953@bartok.nlnetlabs.nl> Also a test page like SIDN has for the nameservers and some other registries have should be nice so we can check what RIPE registers. There is already for this purpose. jaap From anandb at ripe.net Thu Mar 12 16:09:49 2009 From: anandb at ripe.net (Anand Buddhdev) Date: Thu, 12 Mar 2009 16:09:49 +0100 Subject: [dns-wg] New key-signing keys (KSKs) for RIPE NCC forward and reverse zones Message-ID: <49B925BD.3000702@ripe.net> 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 From denic at eng.colt.net Thu Mar 12 19:01:15 2009 From: denic at eng.colt.net (Ralf Weber) Date: Thu, 12 Mar 2009 19:01:15 +0100 Subject: [dns-wg] New key-signing keys (KSKs) for RIPE NCC forward and reverse zones In-Reply-To: <49B925BD.3000702@ripe.net> References: <49B925BD.3000702@ripe.net> Message-ID: <81970793-C5DD-4044-8D8E-795AA710BF6A@eng.colt.net> Moin! On 12.03.2009, at 16:09, Anand Buddhdev wrote: > > 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 This may be my error, but for me the pgp signature isn't correct: RitterRost:Downloads rw$ gpg -v --verify ripe-ncc-dnssec-keys- new.txt.asc ripe-ncc-dnssec-keys-new.txt gpg: armor header: Comment: For info see https://www.ripe.net/rs/pgp/ gpg: Signature made Thu Feb 5 11:57:16 2009 CET using DSA key ID 4BD4468C gpg: using classic trust model gpg: BAD signature from "RIPE NCC " gpg: textmode signature, digest algorithm SHA1 RitterRost:Downloads rw$ ls -l ripe-ncc-dnssec-keys-new.txt*-rw-r--r-- @ 1 rw rw 58977 Mar 12 18:53 ripe-ncc-dnssec-keys-new.txt -rw-r--r-- 1 rw rw 206 Mar 12 18:55 ripe-ncc-dnssec-keys- new.txt.asc RitterRost:Downloads rw$ gpg --fingerprint 4BD4468C pub 1024D/ 4BD4468C 2008-12-02 [expires: 2010-02-02] Key fingerprint = 44DB B621 ABC8 9A30 A8F1 916B F7D3 6B18 4BD4 468C uid RIPE NCC sub 2048g/7D91E9E5 2008-12-02 [expires: 2010-02-02] RitterRost:Downloads rw$ cat ripe-ncc-dnssec-keys-new.txt.asc -----BEGIN PGP SIGNATURE----- Comment: For info see https://www.ripe.net/rs/pgp/ iD8DBQFJisYM99NrGEvURowRAt8cAJ0fQ8p70WnKkeYmrAjLaduz2fZeMgCeMvtd 3+B7Bot3cSTImZvWsAjhi/Y= =a+JU -----END PGP SIGNATURE----- Any idea why? So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Dr. J?rgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From anandb at ripe.net Thu Mar 12 22:28:52 2009 From: anandb at ripe.net (Anand Buddhdev) Date: Thu, 12 Mar 2009 22:28:52 +0100 Subject: [dns-wg] Re: New key-signing keys (KSKs) for RIPE NCC forward and reverse zones In-Reply-To: <81970793-C5DD-4044-8D8E-795AA710BF6A@eng.colt.net> References: <49B925BD.3000702@ripe.net> <81970793-C5DD-4044-8D8E-795AA710BF6A@eng.colt.net> Message-ID: <20090312212852.GA7110@cat.ripe.net> On Thu, Mar 12, 2009 at 07:01:15PM +0100, Ralf Weber wrote: Hello Ralf, > >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 > > This may be my error, but for me the pgp signature isn't correct: Apologies for this. This wasn't your error - the new signature file had been generated, but not propagated to the RIPE NCC website. I have pushed out the correct signature file now. If you fetch it again, it should verify. Regards, -- Anand Buddhdev DNS Services Manager, RIPE NCC From denic at eng.colt.net Thu Mar 12 23:10:10 2009 From: denic at eng.colt.net (Ralf Weber) Date: Thu, 12 Mar 2009 23:10:10 +0100 Subject: [dns-wg] Re: New key-signing keys (KSKs) for RIPE NCC forward and reverse zones In-Reply-To: <20090312212852.GA7110@cat.ripe.net> References: <49B925BD.3000702@ripe.net> <81970793-C5DD-4044-8D8E-795AA710BF6A@eng.colt.net> <20090312212852.GA7110@cat.ripe.net> Message-ID: <59C2DC0D-69EB-4ECC-A35A-9BDE507717BB@eng.colt.net> Moin! On 12.03.2009, at 22:28, Anand Buddhdev wrote: >>> 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 >> >> This may be my error, but for me the pgp signature isn't correct: > > Apologies for this. This wasn't your error - the new signature file > had been generated, but not propagated to the RIPE NCC website. I have > pushed out the correct signature file now. If you fetch it again, it > should verify. Yes it does. Thanks for the prompt response. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: rw at colt.net http://www.colt.net/ Data | Voice | Managed Services Sch?tze Deine Umwelt | Erst denken, dann drucken ***************************************** COLT Telecom GmbH, Herriotstra?e 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 * Gesch?ftsf?hrer: Dr. J?rgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 From lutz at iks-jena.de Mon Mar 16 11:10:07 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 16 Mar 2009 10:10:07 +0000 (UTC) Subject: [dns-wg] New key-signing keys (KSKs) for RIPE NCC forward and reverse zones References: <49B925BD.3000702@ripe.net> Message-ID: * Anand Buddhdev wrote: > 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. Are you going to use RFC 5011 to remove the old keys? From uhlar at fantomas.sk Tue Mar 17 11:36:43 2009 From: uhlar at fantomas.sk (Matus UHLAR - fantomas) Date: Tue, 17 Mar 2009 11:36:43 +0100 Subject: [dns-wg] DNS lameness question Message-ID: <20090317103643.GA10671@fantomas.sk> 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 at 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] From ondrej.sury at nic.cz Tue Mar 17 11:43:36 2009 From: ondrej.sury at nic.cz (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Tue, 17 Mar 2009 11:43:36 +0100 Subject: [dns-wg] DNS lameness question In-Reply-To: <20090317103643.GA10671@fantomas.sk> References: <20090317103643.GA10671@fantomas.sk> Message-ID: On Tue, Mar 17, 2009 at 11:36 AM, Matus UHLAR - fantomas wrote: > 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? Write an script to mass change all your delegations and send it all as GPG/PGP signed mail. - 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? Put dns.nextra.sk back into the zone until you resolve this issue. Ondrej. -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From anandb at ripe.net Tue Mar 17 12:26:57 2009 From: anandb at ripe.net (Anand Buddhdev) Date: Tue, 17 Mar 2009 12:26:57 +0100 Subject: [dns-wg] Re: New key-signing keys (KSKs) for RIPE NCC forward and reverse zones In-Reply-To: References: <49B925BD.3000702@ripe.net> Message-ID: <49BF8901.7090106@ripe.net> Lutz Donnerhacke wrote: >> 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. > > Are you going to use RFC 5011 to remove the old keys? Hello Lutz, The toolset that we're using does not have support for setting the revocation bit, so we won't be setting it. Are many people actually running resolvers that understand RFC 5011? -- Anand Buddhdev DNS Services Manager, RIPE NCC From lutz at iks-jena.de Tue Mar 17 13:22:56 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 17 Mar 2009 12:22:56 +0000 (UTC) Subject: [dns-wg] Re: New key-signing keys (KSKs) for RIPE NCC forward and reverse zones References: <49BF8901.7090106@ripe.net> Message-ID: * Anand Buddhdev wrote: > The toolset that we're using does not have support for setting the > revocation bit, so we won't be setting it. Clear statement. Thank you. > Are many people actually running resolvers that understand RFC 5011? Unbound has support for RFC5011 as well as the current developement version of bind (might be 9.7). So it's hard to say how many people are deploying this RFC. It seems to become the default algorithm for standalone resolvers. From matthijs at NLnetLabs.nl Tue Mar 17 13:38:55 2009 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Tue, 17 Mar 2009 13:38:55 +0100 Subject: [dns-wg] Re: New key-signing keys (KSKs) for RIPE NCC forward and reverse zones In-Reply-To: References: <49BF8901.7090106@ripe.net> Message-ID: <49BF99DF.1000203@nlnetlabs.nl> Furthermore, there are resolver independent implementations of RFC 5011, like autotrust and trustman. - Matthijs Lutz Donnerhacke wrote: > * Anand Buddhdev wrote: >> The toolset that we're using does not have support for setting the >> revocation bit, so we won't be setting it. > > Clear statement. Thank you. > >> Are many people actually running resolvers that understand RFC 5011? > > Unbound has support for RFC5011 as well as the current developement version > of bind (might be 9.7). So it's hard to say how many people are deploying > this RFC. It seems to become the default algorithm for standalone resolvers. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 544 bytes Desc: OpenPGP digital signature URL: From paul at xelerance.com Tue Mar 17 16:54:00 2009 From: paul at xelerance.com (Paul Wouters) Date: Tue, 17 Mar 2009 11:54:00 -0400 (EDT) Subject: [dns-wg] Re: New key-signing keys (KSKs) for RIPE NCC forward and reverse zones In-Reply-To: <49BF8901.7090106@ripe.net> References: <49B925BD.3000702@ripe.net> <49BF8901.7090106@ripe.net> Message-ID: On Tue, 17 Mar 2009, Anand Buddhdev wrote: > The toolset that we're using does not have support for setting the > revocation bit, so we won't be setting it. > > Are many people actually running resolvers that understand RFC 5011? Autotrust can update the keys and restart the resolver with the new keys primed for it. This is the setup currently in Fedora-11 Beta. Paul From uhlar at fantomas.sk Thu Mar 19 18:47:41 2009 From: uhlar at fantomas.sk (Matus UHLAR - fantomas) Date: Thu, 19 Mar 2009 18:47:41 +0100 Subject: [dns-wg] DNS lameness question In-Reply-To: References: <20090317103643.GA10671@fantomas.sk> Message-ID: <20090319174741.GA19404@fantomas.sk> Hello, > On Tue, Mar 17, 2009 at 11:36 AM, Matus UHLAR - fantomas > wrote: > > 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? On 17.03.09 11:43, Ond?ej Sur? wrote: > Write an script to mass change all your delegations and send it all as > GPG/PGP signed mail. > > - 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) Since nobody other replied and you did not comment on this question, may I safely assume thet it would cause no problems if I'll leave it here, except those lameness warnings? > - is there anything other to advise me? > > > Put dns.nextra.sk back into the zone until you resolve this issue. -- Matus UHLAR - fantomas, uhlar at 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. 2B|!2B, that's a question! From ondrej.sury at nic.cz Thu Mar 19 22:10:30 2009 From: ondrej.sury at nic.cz (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Thu, 19 Mar 2009 22:10:30 +0100 Subject: [dns-wg] DNS lameness question In-Reply-To: <20090319174741.GA19404@fantomas.sk> References: <20090317103643.GA10671@fantomas.sk> <20090319174741.GA19404@fantomas.sk> Message-ID: >> - 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) > > Since nobody other replied and you did not comment on this question, may I > safely assume thet it would cause no problems if I'll leave it here, except > those lameness warnings? I am not aware of any RIPE policy which would remove those lame records on basis of ugliness ;). Ondrej -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From uhlar at fantomas.sk Mon Mar 23 09:53:14 2009 From: uhlar at fantomas.sk (Matus UHLAR - fantomas) Date: Mon, 23 Mar 2009 09:53:14 +0100 Subject: [dns-wg] DNS lameness question In-Reply-To: References: <20090317103643.GA10671@fantomas.sk> <20090319174741.GA19404@fantomas.sk> Message-ID: <20090323085314.GA26307@fantomas.sk> On 19.03.09 22:10, Ond?ej Sur? wrote: > >> - 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) > > > > Since nobody other replied and you did not comment on this question, may I > > safely assume thet it would cause no problems if I'll leave it here, except > > those lameness warnings? > > I am not aware of any RIPE policy which would remove those lame records > on basis of ugliness ;). if there's no ripe policy that would remove those delegations... Yes I want to solve the problem fast. But it will still take some time... -- Matus UHLAR - fantomas, uhlar at 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. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows." From shane at time-travellers.org Sat Mar 28 19:55:26 2009 From: shane at time-travellers.org (Shane Kerr) Date: Sat, 28 Mar 2009 19:55:26 +0100 Subject: [dns-wg] Turning off lameness checks for reverse Message-ID: <49CE729E.2080408@time-travellers.org> All, Is there any support for disabling lameness checks for reverse DNS? 1. It seems that they cause some annoyance to administrators. 2. As far as I know there has never been a study showing improvement for DNS users based on removing lameness in reverse DNS (or in any DNS). These two things suggest to me that the pro-active lameness checks should be disabled, at least until it is shown that lameness actually causes problems. Cheers, -- Shane From Woeber at CC.UniVie.ac.at Mon Mar 30 17:09:35 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 30 Mar 2009 16:09:35 +0100 Subject: [dns-wg] Q: "lameness checks" - error messages for servers at the NCC? Message-ID: <49D0E0AF.30708@CC.UniVie.ac.at> 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. From brettlists at gmail.com Tue Mar 31 14:32:50 2009 From: brettlists at gmail.com (B C) Date: Tue, 31 Mar 2009 13:32:50 +0100 Subject: [dns-wg] Turning off lameness checks for reverse In-Reply-To: <49CE729E.2080408@time-travellers.org> References: <49CE729E.2080408@time-travellers.org> Message-ID: <5c494b510903310532k5b5fb21dt75ec8a0074f8414@mail.gmail.com> On Sat, Mar 28, 2009 at 7:55 PM, Shane Kerr wrote: > All, > > Is there any support for disabling lameness checks for reverse DNS? > > 1. It seems that they cause some annoyance to administrators. > My feeling is that they only cause annoyance to administrators if the checks are not working correctly, personally if I have lame reverse zones I would be very happy if the NCC ran a service that warned me. > 2. As far as I know there has never been a study showing improvement for > ? DNS users based on removing lameness in reverse DNS (or in any DNS). I'm not aware of any study either but I think we are all aware that certain applications work much better if reverse DNS is setup and functioning correctly. If those applications no longer had a dependency on reverse dns working then I may find it easier to agree with your point of view. > > These two things suggest to me that the pro-active lameness checks > should be disabled, at least until it is shown that lameness actually > causes problems. > As I remember there was a lot of support for this work around the time of the publication of ripe-400 and my feeling is that providing the checks are being done in a sensible way and they are documented that this support is still there. Brett From jabley at hopcount.ca Tue Mar 31 16:28:32 2009 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 31 Mar 2009 10:28:32 -0400 Subject: [dns-wg] Turning off lameness checks for reverse In-Reply-To: <5c494b510903310532k5b5fb21dt75ec8a0074f8414@mail.gmail.com> References: <49CE729E.2080408@time-travellers.org> <5c494b510903310532k5b5fb21dt75ec8a0074f8414@mail.gmail.com> Message-ID: On 31 Mar 2009, at 08:32, B C wrote: > On Sat, Mar 28, 2009 at 7:55 PM, Shane Kerr travellers.org> wrote: > >> 2. As far as I know there has never been a study showing >> improvement for >> DNS users based on removing lameness in reverse DNS (or in any >> DNS). > > I'm not aware of any study either but I think we are all aware that > certain applications work much better if reverse DNS is setup and > functioning correctly. If those applications no longer had a > dependency on reverse dns working then I may find it easier to agree > with your point of view. A lame delegation (a delegation to a working nameserver which does not offer an authoritative answer to the question) might well have similar impact on application to the case where there is no delegation at all. In both cases you get some form of negative response that indicates that the reverse mapping is not available. Delegations to nameservers which don't respond probably cause more annoyance than lame delegations, since they involve a timeout. Note that if the nameserver doesn't respond you can't tell whether the delegation is lame or not. Encouraging peoople to fix unresponsive nameservers seems like a more obviously good idea than encouraging people to fix measurably-lame delegations. The other consideration that has come up in other regions (and which I have also not seen a study supporting) is that lame delegations caused increased traffic for the servers that publish them, and that the increased traffic presents an operational problem. Philosophically, it makes sense to me for the zone operator (the NCC) to care about the accuracy of the data published in the zone. It's not clear to me that doing so has any operational benefit to the NCC, however. What I hear Shane saying is that since he sees no operational benefit in the checks, as the operator of the number resource, he ought to have the option of opting out of them. I note that opting out of lame delegation checks is possible at ARIN (since I happened to get some robot lame delegation checker mail from them the other day, and the mail mentioned it). Joe