- dns-wg - mailman.ripe.net

Thanks for RIPE 59
by Jim Reid 19 Oct '09

19 Oct '09

Colleagues, I have to say thanks to the people who gave presentations at the DNS WG in Lisbon and who participated in the discussions. The WG sessions in Lisbon were particularly lively. This wouldn't have been possible without the contributions. So thanks are due to them. Thank you.

1 0

Re: [dns-wg] a historical perspective on DNS lameness
by B C 15 Oct '09

15 Oct '09

On Wed, Oct 14, 2009 at 5:05 PM, Edward Lewis <Ed.Lewis(a)neustar.biz> wrote: > At 15:55 +0100 10/13/09, B C wrote: > > I'm not sure I really understand your point here, >> > > I forget if I answered this, it's been very busy at home since I returned - > the context of my post was a follow up to Shane's presentation on RIPE-400 > at the last RIPE DNS WG meeting. > > Aha, I wasn't at the meeting and couldn't catch the webcast, I'll take a look at the replay. Thanks for the clarification Ed. Brett

1 0

Re: [dns-wg] a historical perspective on DNS lameness
by B C 13 Oct '09

13 Oct '09

Ed, On Thu, Oct 8, 2009 at 6:23 PM, Edward Lewis <Ed.Lewis(a)neustar.biz> wrote: > 1. RFC 1912 has this definition: > > A lame delegations exists when a nameserver is > delegated responsibility for providing nameservice for a zone (via NS > records) but is not performing nameservice for that zone (usually > because it is not set up as a primary or secondary for the zone). > > I would agree with the definition, I'm not sure whether I would 100% agree with the 'usually because' I think it can be for a number of reasons and I don't think anybody has looked into this in an detail. Misconfiguration or communication issues could equally be to blame as 'no configuration' > Note - a remote party can only detect the situation if the server in > question responds to a query, that is, if: > > the server has no IP address, > the IP address is unreachable, > the query drops on the way there, > the response drops, > the server simply won't answer, > or etc., > the remote party does not have the evidence to conclude lameness. > > A common confusion made is that misconfigured delegations are lame, but > that is not the case. The distinction will be important later on. > > 2. There is no specified protocol response to indicate that a server is not > set up to answer the question, nothing in the RFC's, You can say this is > the root cause of the failure - an old, old version of BIND decided to > return a referral "upwards" (as to the root or maybe the TLD) to be kind of > helpful. This kind act turned out to be the problem when... > > 3. An implementation of an iterative resolver was released that "believed" > the upwards referral and would follow it. (The implementation was widely > distributed, legend said it was a MS release in about 2000. But I can't > confirm that.) What this meant is that a lot of resolvers would query the > root, then a TLD, then a SLD and then be referred back to the root and keep > on cycling. That was the operational impact that lead to... > > 4. ARIN policy 2002-1 which told ARIN staff to go off an stamp out lame > servers. (This is where I came into the picture.) The purpose was to stop > this cycle of activity, but by the time the policy got in place the software > was patched pretty much out of existence and the operational pain lessened. > Thats quite interesting I had no idea that was the reason behind the ARIN policy I thought it was for a similar reason to the RIPE one which basically was a desire to ensure the reverse tree was as clean and functional as possible. > > 5. At RIPE 45 I presented ( > http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-testing-…) > which has some interesting bullets and slides that are still pertinent today > on the process of dealing with lameness. When I presented this, ARIN had a > high lame rate and RIPE a low one, due largely to early registration mishaps > and the difference in the timing of ARIN and RIPE "cutting" a delegation for > a new assignment. > > 6. At some time RIPE adopted a lame inspection policy. I don't have a > personal recollection of this. http://www.ripe.net/ripe/docs/ripe-400.htmlis the policy definition, I had left ARIN by then and wasn't as aware of > what was going on then in the RIPE region. > > Indeed I was the author of said document (following input from the RIPE community of course) I do seem to remember discussing this with you at the time the policy was going through the WG, but I think it was more related to what methodology you had used to detect the lameness rather than the reason for doing it. > So - what perspective I am trying to say here is - "lame" per se refers to > name servers that led software into a loop which is why they were a problem > for ARIN. This is why today you probably won't measure the impact of > "misconfigured" delegations (which is what RIPE-400 calls lame) by > inspecting traffic. The question of the value of RIPE-400 then turns into > being one of database cleanliness. > > I'm not sure I really understand your point here, If an LIR has entered some data into the DB which it believes to be correct but it (or its friends) have misconfigured (or not configured) the servers then I would regard the DB to be clean and that the server's need fixing. Either way I would regard notification of the problem to the LIR to be a good thing. Brett >

2 1

a historical perspective on DNS lameness
by Edward Lewis 08 Oct '09

08 Oct '09

1. RFC 1912 has this definition: A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone). Note - a remote party can only detect the situation if the server in question responds to a query, that is, if: the server has no IP address, the IP address is unreachable, the query drops on the way there, the response drops, the server simply won't answer, or etc., the remote party does not have the evidence to conclude lameness. A common confusion made is that misconfigured delegations are lame, but that is not the case. The distinction will be important later on. 2. There is no specified protocol response to indicate that a server is not set up to answer the question, nothing in the RFC's, You can say this is the root cause of the failure - an old, old version of BIND decided to return a referral "upwards" (as to the root or maybe the TLD) to be kind of helpful. This kind act turned out to be the problem when... 3. An implementation of an iterative resolver was released that "believed" the upwards referral and would follow it. (The implementation was widely distributed, legend said it was a MS release in about 2000. But I can't confirm that.) What this meant is that a lot of resolvers would query the root, then a TLD, then a SLD and then be referred back to the root and keep on cycling. That was the operational impact that lead to... 4. ARIN policy 2002-1 which told ARIN staff to go off an stamp out lame servers. (This is where I came into the picture.) The purpose was to stop this cycle of activity, but by the time the policy got in place the software was patched pretty much out of existence and the operational pain lessened. 5. At RIPE 45 I presented (http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-testing-…) which has some interesting bullets and slides that are still pertinent today on the process of dealing with lameness. When I presented this, ARIN had a high lame rate and RIPE a low one, due largely to early registration mishaps and the difference in the timing of ARIN and RIPE "cutting" a delegation for a new assignment. 6. At some time RIPE adopted a lame inspection policy. I don't have a personal recollection of this. http://www.ripe.net/ripe/docs/ripe-400.html is the policy definition, I had left ARIN by then and wasn't as aware of what was going on then in the RIPE region. So - what perspective I am trying to say here is - "lame" per se refers to name servers that led software into a loop which is why they were a problem for ARIN. This is why today you probably won't measure the impact of "misconfigured" delegations (which is what RIPE-400 calls lame) by inspecting traffic. The question of the value of RIPE-400 then turns into being one of database cleanliness. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.

1 0

Agenda for RIPE 59
by Jim Reid 21 Sep '09

21 Sep '09

Colleagues, here's the agenda for the Lisbon meeting. There might be some small adjustments to the running order between now and RIPE59. Though there shouldn't be any major changes. If there are updates, they'll be posted here and on the meeting web pages. Hope to see you all in Lisbon next month. # # $Id: dnswg-agenda59,v 1.6 2009/09/18 11:54:26 jim Exp $ # Morning Session A. Administrivia & Agenda Bashing (2 mins) B. Matters arising from RIPE58 Minutes (3 mins) C. Review of Action Items (10 mins) D. IETF Report (10 mins) Carsten Strotmann, Men and Mice E. IANA Update (10 mins) Leo Vegoda, ICANN Progress report on root signing and the ITAR. F. DNSwitness: recent developments (15 mins) Stephane Bortzmeyer, AFNIC DNSwitness is a set of (free software) programs to gather statistics from the DNS. The active component of DNSwitness has now more data to display, showing an increase in IPv6 use in .FR. The new passive component allows us to get information from the packets we receive. G. Provisioning DNSSEC - What Would Operators Do? (15 mins) Ed Lewis, Neustar Recent lapses in the operation of Trust Anchor Repositories illustrate that the need to develop some operationally sound means to exchange DNSSEC Keys amongst operators of DNS servers, both from the operator of a zone upwards (e.g., a TLD) and if needed to ISP-run caches. This talk will discuss the operational considerations and open the floor for suggestions for requirements. H. Followup to EOF Presentations (20 mins) Discussion about the ITAR and root signing, DNSSEC in .pt Afternoon Session I. NCC Update (10 mins) Anand Buddhev, RIPE NCC J. Lame Delegation Analysis for the RIPE region (25 mins) Shane Kerr, ISC Falling Trees (or If a DNS Server is Lame but Nobody Queries It, Should I Get an E-mail?) Queries to the RIPE NCC server for reverse DNS were recorded and compared against which name servers are lame. Based on this, we can see which queries are affected by lameness, and how badly. K. ICANN/OARC Root Zone Augmentation Impact Analysis (15 mins) Duane Wessels, OARC ICANN commissioned DNS-OARC to study upcoming changes to the DNS root zone. In particular we examined signing the zone with DNSSEC, increasing the number of TLDs, and adding more IPv6 glue records. OARC studied how these changes affect zone size, response latency, start and reload times, AXFR and IXFR bandwidth requirements, and potential increases in queries over TCP. L. Root Zone Scaling Survey Findings (15 mins) Lyman Chapin, Interisle M. Open discussion on root scaling (20 mins) N. AOB

1 0

Agenda Items for RIPE 59?
by Peter Koch 26 Aug '09

26 Aug '09

Dear RIPE DNS WG, for Lisbon <http://www.ripe.net/ripe/meetings/ripe-59/meeting-plan.html> we have been assigned two slots around lunch on Thursday, 2009-10-08. Please send suggestions for agenda items to Jaap, Jim and me under the chairs' alias <dns-wg-chair(a)ripe.net>. Regards, Peter PS: The RIPE58 minutes have been timely delivered by the NCC and are under review.

1 0

New local K-root node in Tanzania
by Anand Buddhdev 20 Aug '09

20 Aug '09

Dear Colleagues, The RIPE NCC is pleased to announce that we have deployed a new K-root local node at the Tanzania Internet Exchange (TIX) in Dar es Salaam. This node is sponsored by AfriNIC and the Tanzania Internet Service Providers Association (TISPA), with transit provided by Simbanet and Africa Online. The RIPE NCC is participating in AfriNIC's Root Server Anycast Copy Program, which assists well established IXPs in the African region to deploy anycast instances of root name servers. The K-root local node in Dar es Salaam is the first such deployment. For more information about this K-root node, and K-root in general, please visit the K-root website: http://k.root-servers.org/ For more information about AfriNIC's Root Server Anycast Copy Program, please visit: http://www.afrinic.net/projects/project_anycast.htm Regards, Anand Buddhdev DNS Services Manager RIPE NCC

2 1

DNSSEC for 1.3.e164.arpa
by Antoin Verschuren 06 Jul '09

06 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, As some of you may have noticed We have signed in our zone 1.3.e164.arpa last week. We are preparing for implementation of DNSSEC in that zone. In the coming months, we will test our administrative procedures. We will do some emergency key rollovers to make sure they work in our production systems the same as they did in our testing environment. Once we are satisfied about the results, we will publish our trust anchor on our website and to our parent RIPE NCC. In the mean time, we don't advise the key in our zone to be treated as a trust anchor in production systems. You are free to experiment with it though. Changes to our policy will be published on our website: http://www.enum.nl/en/dnssec/dnssec-status-for-13e164arpa.html An SSL secured version of that site will be available soon. We will also announce to the RIPE dns and enum wg mailing lists when we consider our trust anchors to be ready for production use. We hope this contribution will help the adoption of DNSSEC to secure the DNS. Regards, Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ - -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFKUcJSXOb5yambhgkRArcXAKCB5QTb4/6z3jJONlQJifGcZhJTpQCgkE3c b8IMVyjdyM4bX1zoKOnEJFg= =Tm1m - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSlHDCzqHrM883AgnAQgTcwf/Sp7GhL+sT8yS4wWDp5SdIULLKyNb36nV 3Lfl6EZ36zk15SpdUPzh3D7BBYHmoIYwdQ5PtpcwZ2I//+2cE+Hl7D0Biixytc7x 4vcrW3qKq/bkkkMo7R2bSJ8QYTIcqPyx5LIP69Ob9wzSIjwdGRZs2pJGMIOP0jSE r4LgGcXW42SuGkOz4cEhWX0Inom9+DdZh8GbSswV99M46NJO5ZnUeIVADnwNuF8W 1jnWbHy1W6EN8rEVjRKJwqhVzYsCaIZEZZQkMaqu4r4oDBXb9QX+hCzLOGMKgC7x Os8MKXPDppLTIaiqTuiPm69WM6yIcKWaDjej3FSxn6z9QcQbj0WFzg== =bEKp -----END PGP SIGNATURE-----

1 0

RIPE NCC and ICANN Commit to Ongoing DNS Root Name Service Coordination
by Paul Rendek 22 Jun '09

22 Jun '09

[Apologies for duplicates] Dear Colleagues, Dr. Paul Twomey, CEO of ICANN, has posted an open letter to Axel Pawlik, Managing Director of the RIPE NCC, noting ICANN's appreciation of the role RIPE NCC plays as operator of k.root-servers.net, or simply K-root, one of the 13 Internet root name servers. The letter was sent in response to letters sent by the RIPE NCC, Autonomica, operator of I-root, and WIDE Project, operator of M-root, to ICANN in May 2009. The letter notes that both ICANN and the RIPE NCC acknowledge "that a single, unique DNS root is paramount to the stable operations of the Internet and to ensure global interoperability", and that "close ICANN coordination with the root-server operators provides a foundation for a secure, stable and resilient DNS." ICANN and the RIPE NCC have jointly committed to "coordinating their respective activities regarding the DNS root name service with each other and third parties". This includes "exchanging and maintaining the necessary operational and administrative contact information, notifying each other without undue delay of any (pending) operational changes or any (pending) changes in their respective activities". You can view the full text of the letter from ICANN to the RIPE NCC at: http://ripe.net/news/icann-kroot-reply.pdf The text of the May 2009 letter from the RIPE NCC to ICANN can be found here: http://ripe.net/news/root-server-statement-to-icann.html More information about RIPE NCC's operation of K-root is available at: http://k.root-servers.org/ Regards, Paul Rendek Head of External Relations and Communications RIPE NCC

1 0

Change of K-Root Instance in Frankfurt to a Global Node
by Wolfgang Nagele 19 Jun '09

19 Jun '09

Dear Colleagues, The RIPE NCC (AS25152) upgraded the k.root-servers.net instance in Frankfurt, Germany to a global node on 18 June 2009. This means that we are now announcing the prefix without the BGP no- export attribute. If you have been operating a peering session with us at DE-CIX, you will now see the prefix 193.0.14.0/23 instead of 193.0.14.0/24. Please adjust your filters if necessary. Anybody interested in peering with us can either use the DE-CIX route servers or contact <k-peerings(a)ripe.net> to set up a separate peering session. We also invite anybody who is willing to provide us with transit for this instance to contact us at <k-peerings(a)ripe.net>. Regards, Wolfgang Nagele DNS System Engineer, RIPE NCC

3 2