From anandb at ripe.net Mon Feb 9 16:11:09 2009 From: anandb at ripe.net (Anand Buddhdev) Date: Mon, 09 Feb 2009 16:11:09 +0100 Subject: [dns-wg] RIPE NCC trust anchor file signature verification Message-ID: <4990478D.4070601@ripe.net> 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 From anandb at ripe.net Mon Feb 9 16:17:53 2009 From: anandb at ripe.net (Anand Buddhdev) Date: Mon, 09 Feb 2009 16:17:53 +0100 Subject: [dns-wg] RIPE NCC trust anchors in zone-file format Message-ID: <49904921.9090900@ripe.net> [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 . Regards, Anand Buddhdev DNS Services Manager RIPE NCC From kim.davies at icann.org Tue Feb 17 23:57:36 2009 From: kim.davies at icann.org (Kim Davies) Date: Tue, 17 Feb 2009 14:57:36 -0800 Subject: [dns-wg] Interim Trust Anchor Repository Message-ID: 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 From anandb at ripe.net Tue Feb 24 14:02:47 2009 From: anandb at ripe.net (Anand Buddhdev) Date: Tue, 24 Feb 2009 14:02:47 +0100 Subject: [dns-wg] DNS Lameness Statistics and Notifications Message-ID: <49A3EFF7.50805@ripe.net> 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 . Regards, Anand Buddhdev DNS Services Manager RIPE NCC From shane at time-travellers.org Tue Feb 24 15:19:28 2009 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 24 Feb 2009 15:19:28 +0100 Subject: [dns-wg] DNS Lameness Statistics and Notifications In-Reply-To: <49A3EFF7.50805@ripe.net> References: <49A3EFF7.50805@ripe.net> Message-ID: <1235485168.15655.386.camel@shane-macbook-pro> Anand, On Tue, 2009-02-24 at 14:02 +0100, Anand Buddhdev wrote: > 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/ I'm curious about the numbers here, and the meaning of the counts of servers. That is, if I have: 2.0.192.in-addr.arpa NS ns1.example.com NS ns2.example.net 3.0.192.in-addr.arpa NS ns1.example.com NS ns2.example.net ns1.example.com A 192.0.2.1 ns2.example.com A 192.0.3.1 Does this count as 2 servers or 4 servers? Further, if I have: 2.0.192.in-addr.arpa NS ns1.example.com NS ns2.example.net 3.0.192.in-addr.arpa NS ns1.example.com NS ns2.example.net ns1.example.com A 192.0.2.1 A 192.0.3.1 ns2.example.com A 192.0.2.2 A 192.0.3.2 How many servers does this get counted as? It might also be informative to show the amount of address space that is affected by bad servers. It could be that the overall 6% of servers that are lame only affects 1% of the space... or it could affect 50%. Another useful metric may be to look at the amount of traffic that arrives to the RIPE NCC parents and gets directed to lame servers. I think this is should give a reasonable guesstimate of how lameness affects actual users. The NCC can look at the answers they send, and since they know both the NS-sets they are answering with as well as the lameness for each of the servers in those answers, this information can be used to determine the likely effect of lameness on users. So, for example, if a user gets an NS-set where 1 of 4 servers is lame, we can estimate that they will have a 25% chance of sending a query to a lame server and have to retry. If a user gets an NS-set where 2 of 4 servers are lame, then they have a 50% chance of sending a query to a lame server, and a 33% chance of their retry going to a lame server as well. Combining a bit of analysis with actual traffic measurement could help us to understand what the actual impact of lameness on Internet users is(*). I suppose the NCC would need to be careful about how it publishes results, as LIRs or DNS operators might be sensitive about someone publishing how much DNS traffic they get. I doubt it actually matters, but people may still get upset. -- Shane (*) And perhaps help me in my quest to rid the world of the evil of reverse DNS completely. ;) From anandb at ripe.net Fri Feb 27 15:06:36 2009 From: anandb at ripe.net (Anand Buddhdev) Date: Fri, 27 Feb 2009 15:06:36 +0100 Subject: [dns-wg] Re: DNS Lameness Statistics and Notifications In-Reply-To: <1235485168.15655.386.camel@shane-macbook-pro> References: <49A3EFF7.50805@ripe.net> <1235485168.15655.386.camel@shane-macbook-pro> Message-ID: <49A7F36C.1060106@ripe.net> Shane Kerr wrote: Hello Shane, > On Tue, 2009-02-24 at 14:02 +0100, Anand Buddhdev wrote: >> 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/ > > I'm curious about the numbers here, and the meaning of the counts of > servers. > > That is, if I have: > > 2.0.192.in-addr.arpa NS ns1.example.com > NS ns2.example.net > 3.0.192.in-addr.arpa NS ns1.example.com > NS ns2.example.net > > ns1.example.com A 192.0.2.1 > ns2.example.com A 192.0.3.1 > > Does this count as 2 servers or 4 servers? If the 2 servers are lame for both zones, it counts as 4 servers. > Further, if I have: > > 2.0.192.in-addr.arpa NS ns1.example.com > NS ns2.example.net > 3.0.192.in-addr.arpa NS ns1.example.com > NS ns2.example.net > > ns1.example.com A 192.0.2.1 > A 192.0.3.1 > ns2.example.com A 192.0.2.2 > A 192.0.3.2 > > How many servers does this get counted as? If none of the addresses of both servers return authoritative answers to queries for the two zones, then this counts as 8. We query every IP address of every name server of a zone, and each unique combination of zone and name server IP address counts as a server. > It might also be informative to show the amount of address space that is > affected by bad servers. It could be that the overall 6% of servers that > are lame only affects 1% of the space... or it could affect 50%. > > Another useful metric may be to look at the amount of traffic that > arrives to the RIPE NCC parents and gets directed to lame servers. I > think this is should give a reasonable guesstimate of how lameness > affects actual users. > > The NCC can look at the answers they send, and since they know both the > NS-sets they are answering with as well as the lameness for each of the > servers in those answers, this information can be used to determine the > likely effect of lameness on users. > > So, for example, if a user gets an NS-set where 1 of 4 servers is lame, > we can estimate that they will have a 25% chance of sending a query to a > lame server and have to retry. If a user gets an NS-set where 2 of 4 > servers are lame, then they have a 50% chance of sending a query to a > lame server, and a 33% chance of their retry going to a lame server as > well. > > Combining a bit of analysis with actual traffic measurement could help > us to understand what the actual impact of lameness on Internet users > is(*). Thank you for these suggestions. They are very useful indeed, and we will consider making use of some of these ideas for future analyses. For the time being, however, we're focussing on the email alerts. Administrators of zones and name servers are beginning to receive email alerts about lame delegations. We hope that many people will act on these messages, and fix their servers. > I suppose the NCC would need to be careful about how it publishes > results, as LIRs or DNS operators might be sensitive about someone > publishing how much DNS traffic they get. I doubt it actually matters, > but people may still get upset. This is true, and it's why we do not make our detailed results available publicly. Regards, -- Anand Buddhdev DNS Services Manager, RIPE NCC