February 2003 - dns-wg - mailman.ripe.net

RIPE NCC network affected by the DDoS attack
by Andrei Robachevsky 27 Feb '03

27 Feb '03

Dear Colleagues, Starting from 14:00 UTC today, 27 February, RIPE NCC network suffered a large DDoS attack. It was a distributed ICMP echo attack. The attack caused various congestion related problems for the RIPE NCC's network, to the extent that our BGP peering sessions were affected, and non-ICMP traffic was being randomly dropped. The attack was successfully mitigated with cooperation of our peer networks at AMS-IX. Network condition returned back to normal at 16:30 UTC. As a result some of our services, including www.ripe.net (web), whois.ripe.net (RIPE Database), ns.ripe.net (DNS) and ftp.ripe.net (FTP) were not accessible during this timeframe. Now all services are back to normal. Regards, Andrei Robachevsky CTO, RIPE NCC

1 0

Re: clueing in TLD registries for delegations to non-BIND servers
by Jim Reid 24 Feb '03

24 Feb '03

>>>>> "Stefan" == Stefan Paletta <stefanp(a)cabal1.com> writes: Stefan> All, good to see nsd make progress (played with it a litte Stefan> while ago, but tinydns continues to serve me best). Oh dear. It seems that the behaviour of tinydns is preventing you from registering domains in some TLDs. That wouldn't appear to be "serving you best", at least not to me anyway. Stefan> Some TLD registries, however, make unreasonable demands Stefan> regarding the behaviour of servers to which they delegate Stefan> zones. Most notably the .fr and .it registries, which Stefan> apparently demand that servers return a Stefan> (non-authoritative!, in the case of .it) referral to the Stefan> root servers when they are lame. These demands are highly Stefan> questionable -to say the least- and are hard and sometimes Stefan> impossible to follow for users of at least tinydns and Stefan> nsd. While I am not speaking on behalf of these registries -- they can do that themselves -- I believe they're acting out of enlightened self-interest. Many people think a registration entitles them to hours of free consultancy from the registry on how to set up and configure their name servers. [I have been in several registries and overheard the helpdesk staff answer floods of these calls.] Expecting a customer to have name servers that answer authoritatively and/or know about the root servers goes a long way to reducing the number of these misdirected requests for help. "Don't come to us until your name servers are working" is not an unreasonable stance IMO. Stefan> I was wondering if RIPE or a group from the RIPE community Stefan> might appeal to those registries and try to make them stop Stefan> acting stupid. First or all, you do not do your cause any good by spreading insults. This is not constructive or helpful. Secondly, you should be aware that it's not for RIPE or the DNS WG to dictate policy to a ccTLD registry -- that's a national matter -- or tell anyone how to run their name servers. How an organisation chooses to operate its infrastructure is up to them. The WG can produce recommendations or a best common practice (eg RIPE-192) but that's it. People are free to accept or reject or ignore that advice as they see fit. If you wish to prepare such a recommendation, go ahead. The matter can be discussed on this list and I'll be happy to arrange discussion time for the subject at future sessions of the WG. As WG chair, I would welcome a wider analysis of the registration policies of the TLD registries in the RIPE region (and beyond?) and try to see if some common guidelines can be established. This could be a worthwhile subject for a WG recommendation. The topic has exercised you, so I think you'd be an ideal candidate to get that work under way. :-) And if I can be provocative, why don't you ask the author of djbdns to make the software do the Right Thing and at least *respond* whenever it gets a query for something it's not authoritative for?

5 6

My video from RIPE 44...
by Brad Knowles 20 Feb '03

20 Feb '03

Folks, For anyone who is interested, I've got a few files moved up to <http://www.shub-internet.org/brad/pictures/RIPE44>. I'll be moving the rest up fairly soon. If I need to reclaim space and get back down below my quota, I may have to take them down again, but hopefully everyone who wants them will have copied them off by then. I'd welcome any feedback you may have. Thanks! -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

1 0

k.root-servers.net Changing DNS Software at on 19.2.2003
by Daniel Diaz 19 Feb '03

19 Feb '03

Dear all, We are glad to announce that k.root-servers.net has successfully started to run NSD with the change over being completed at 9:25 a.m. UTC. Best regards. -- Daniel.Diaz & Bruce Campbell Operations RIPE NCC

1 0

Announcement RIPE NCC DNSSec Training Courses
by RIPE NCC Training 17 Feb '03

17 Feb '03

Dear Colleagues, [apologies for duplicate postings] As a new service to its members the RIPE NCC offers the DNSSec Training Course. The main objective of the DNSSec Training Course is to provide LIRs with sufficient background to be able to deploy DNSSec in their own organisation as soon as the protocol is standardised. This course also explains the specific procedures set up by the RIPE NCC to to secure the in-addr.arpa zone. The Domain Name System (DNS) is one of the main parts of the Internet infrastructure. At the moment DNS lacks a mechanism to establish the authenticity and integrity of the data it provides. DNSSec is a set of extensions to provide this end-to-end authenticity and integrity. It is currently being developed within the IETF dnsnext Working Group. The protocol is about to be finalised and the code implementing the protocol is available in alpha releases. The DNSSec course consists of two parts: an "Introduction to DNSSec" and a real life demonstration. The "Introduction to DNSSEC" will cover: - DNS security threats - DNSSec security mechanisms - DNSSec server protection - DNSSec data protection - Delegation issues - Key management issues - Current developments Examples are based on the BIND name server. Please note that DNSSec is an advanced course. It will: - NOT teach the basics of DNS. - NOT describe how to receive Internet resources from the RIPE NCC not describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network & system operators, engineers, etc. This course is not intended for administrative or management staff (e.g. Hostmasters). It is assumed that all attendees are familiar with common DNS terminology, have a practical knowledge in operating DNS servers and are interested in learning the concepts and mechanisms that DNSSec offers. The DNSSec course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the DNSSec Training Course can be found at: http://www.ripe.net/training/dnssec/ REGISTRATION: You can register for a course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> In order to register for a DNSSec Training Course you must be an employee of an LIR and either : - be an LIR contact - be confirmed by an LIR contact. LIR contacts are those employees of an LIR who are registered with the RIPE NCC as authoritative contact persons. It is expected that most of those interested in the DNSSec Training Course will not be an authorative contact persons for their LIR, and therefore will be refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team COURSE DATES AND VENUES ======================== Date: Thursday 27 March 2003 Time: 0900 - 1700 Location: Amsterdam,The Netherlands AND: Date: Saturday 17 May 2003 Time: 0900 - 1700 Location: Barcelona, Spain AND: Date: Tuesday 3 June 2003 Time: 0900 - 1700 Location: Stockholm, Sweden REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

Re: clueing in TLD registries for delegations to non-BIND servers
by Jim Reid 14 Feb '03

14 Feb '03

>>>>> "Stefan" == Stefan Paletta <stefanp(a)cabal1.com> writes: Stefan> That was just a cynical response to Jim's fallacious Stefan> assumption about my motivation and of course not to be Stefan> taken seriously. If someone took it for that, I am sorry. The only assumption I made was that you might do some work on registry policies, present it at the WG and maybe produce a RIPE document. I hope that was not fallacious. You've apologised for the earlier comments, so this matter is now closed. Let's move on to what this list is for: technical discussions about the DNS and the activities of the WG.

1 0

k.root-servers.net Changing DNS Software at on 19.2.2003
by Daniel Karrenberg 14 Feb '03

14 Feb '03

As announced previously k.root-servers.net will start running nsd 1.0.2-rel. The changeover will start at 0900UTC on Wednesday 19.2.2003. Between 0900 and 0930 all instances of K will be sequentially cut over. This way there will be no service interruption. During the cut-over period K will answer either using bind8 or nsd. After 0930 K will answer only using nsd. K will support identification of software and instance via id.server and version.server in class CHAOS as per draft-ietf-dnsop-serverid. This change is designed to increase the diversity of software in the root name server system, the lack of which is widely considered to be a potential vulnerability. The nsd software has been designed from scratch specifically as an authoritative name server. It has no design commonalities with bind, the currently prevalent DNS implementation. In addition to that nsd provides a significant increase in the performance reserve of k.root-servers.net. Please report any anomalies with k.root-servers.net service to <ops(a)ripe.net> as usual. nsd can be found at http://www.nlnetlabs.nl/nsd/index.html.

2 2

New Document Available: RIPE-268
by RIPE NCC Document Announcement Service 13 Feb '03

13 Feb '03

New RIPE Documents Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-268 Title: Distributing K-Root Service by Anycast Routing of 193.0.14.129 Author: Daniel Karrenburg Date: 13 February 2003 Format: PS=26610 TXT=12804 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document proposes to distribute the DNS service provided by k.root-servers.net across multiple locations in the Internet topology. It discusses the motivation for and the principles of implementation. A first inventory of detailed issues is provided in an appendix. Accessing the RIPE document store --------------------------------- You can access the RIPE document in HTML format via our website at the following URL:. http://www.ripe.net/ripe/docs/ripe-268.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new document on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-268.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-268.txt plain text version

1 0

clueing in TLD registries for delegations to non-BIND servers
by Stefan Paletta 10 Feb '03

10 Feb '03

All, good to see nsd make progress (played with it a litte while ago, but tinydns continues to serve me best). I understand that nsd (as most non-BIND servers) returns SERVFAIL for questions for which it it does have neither authoritative nor non- authoritative data (i.e. it is lame) and that this behaviour is RFC- conformant and certainly best-practice for authoritative-only servers. Some TLD registries, however, make unreasonable demands regarding the behaviour of servers to which they delegate zones. Most notably the .fr and .it registries, which apparently demand that servers return a (non-authoritative!, in the case of .it) referral to the root servers when they are lame. These demands are highly questionable -to say the least- and are hard and sometimes impossible to follow for users of at least tinydns and nsd. I was wondering if RIPE or a group from the RIPE community might appeal to those registries and try to make them stop acting stupid. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC}

7 17

Re: clueing in TLD registries for delegations to non-BIND servers
by Olaf Kolkman 08 Feb '03

08 Feb '03

* > It should be configured to hand out a referral. * * if you do not include a hints file in nsd's database, it will return * SERVFAIL. * * > > bind9 will reply with REFUSED if the hints file is missing and it is * > > configured to be authoritative only. * > * > Are you sure? For which version of BIND 9? My understanding is * > that they had a pre-compiled list of the root servers built into the * > source code, and that this would be used to generate the initial * > "hints" zone, thus allowing you to avoid having this file. Indeed, I * > wouldn't be surprised at all if the built-in data over-rode the file, * > but maybe that's going too far. * * if you set up bind9 with a authoritative-only view it will return REFUSED. * in a "normal" configuration, it will use pre-compiled root-hints. * Also see Appendix B in the REQUIREMENTS doc in the distribution. This argues why a SERVFAIL is returened if there is no hints file present. " B.1. Returning the root delegation when no answer can be found From RFC1034/1035 it is not obvious if returning a root delegation is a (non-)requirement for authoritative servers. We have decided not to implement a root-hints since an authoritative server should in normal circumstances only receive queries for which the server is authoritative. Also see RFC 1123 section 6.1.2.5. Whenever an answer cannot been provided we return a SERVFAIL. It has been argued that this is a policy decision and thus a REFUSE should be returned. However, in the spirit of RFC1034/1035 a server should return cached data, if that cache cannot be reached a SERVFAIL is an appropriate response. Also see the discussion on the 'namedroppers list' Starting April 2002 with subject "name server without root cache " (ftp://ops.ietf.org/pub/lists/) ' --Olaf

1 0