From stefanp at cabal1.com Thu Feb 6 18:42:45 2003 From: stefanp at cabal1.com (Stefan Paletta) Date: Thu, 6 Feb 2003 18:42:45 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers Message-ID: <20030206174246.23560.qmail@lolita.WRonline.de> 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} From Jim.Reid at nominum.com Fri Feb 7 13:50:47 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Fri, 07 Feb 2003 04:50:47 -0800 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: Message from Stefan Paletta of "Thu, 06 Feb 2003 18:42:45 +0100." <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: <5484.1044622247@shell.nominum.com> >>>>> "Stefan" == Stefan Paletta 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? From paf at cisco.com Fri Feb 7 14:42:31 2003 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Fri, 7 Feb 2003 14:42:31 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: <0196FEA0-3AA2-11D7-BB1A-0003934B2128@cisco.com> On torsdag, feb 6, 2003, at 18:42 Europe/Stockholm, Stefan Paletta wrote: > 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. Do you have a pointer to this rule of theirs? In many cases an NS is lame simply because no DNS server is listening on the IP address which is associated with the NS in question. I.e. that someone has moved the server without talking to the parent zone administrator. paf From bortzmeyer at nic.fr Fri Feb 7 13:29:08 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 7 Feb 2003 13:29:08 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030206174246.23560.qmail@lolita.WRonline.de> References: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: <20030207122908.GB5308@nic.fr> On Thu, Feb 06, 2003 at 06:42:45PM +0100, Stefan Paletta wrote a message of 25 lines which said: > 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. I am not involved in the daily operations of the '.fr' registry but, AFAIK, the ZoneCheck tool (check it out yourself ) requires a referral only if your server claims to be recursive. Therefore, nsd, which is never recursive, or BIND9 with two views (one with recursion for local clients and one without for serving authoritative data to the outside) are OK. BIND8 is more problematic since the recursive flag is apparently global. > 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. A new (completely new: rewritten from scratch) version of ZoneCheck is currently beta. Unlike ZoneCheck 1, the actual tests are configured in a separate configuration file so you can remove some tests without hacking the code. This will make policy adjustements much easier. Input from the community is welcome. From brad.knowles at skynet.be Fri Feb 7 14:25:24 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 7 Feb 2003 14:25:24 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030206174246.23560.qmail@lolita.WRonline.de> References: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: At 6:42 PM +0100 2003/02/06, Stefan Paletta wrote: > 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. Best practice? No, I would disagree most vehemently on that. If nsd is doing this, then I believe it needs to be fixed. Handing out a referral to the root zone is no more work than handing out SERVFAIL. > Some TLD registries, however, make unreasonable demands regarding the > behaviour of servers to which they delegate zones. Unreasonable? No, I consider this to be best practice. > 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. Hard for users of tinydns? Just what is required? Here's what the djbdns FAQ at has to say: Tinydns does not answer at all when someone lamely delegates to it? Yes. You can add this line to your data file to simulate BIND behaviour: &::a.root-servers.net While I believe this to be b0rken behaviour, and I definitely ding djbdns for doing this by default, this is not what I would consider to be particularly onerous if you have jumped through all the other necessary hoops, incredibly poor documentation, and bizarre data file formats in order to get djbdns running. Now, for users of nsd, yes this is a serious problem. They are not given any choice. But then, nsd is not useful as a general-purpose authoritative nameserver -- it is designed as a root/TLD nameserver, and anyone who mis-uses or abuses it to try to serve as a general-purpose authoritative nameserver basically gets what they deserve. > 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. I would appeal to the authors of nsd to fix this and to have nsd generate referrals by default. -- Brad Knowles, "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(+++) From bruce.campbell at ripe.net Fri Feb 7 15:33:50 2003 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Fri, 7 Feb 2003 15:33:50 +0100 (CET) Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030207122908.GB5308@nic.fr> Message-ID: On Fri, 7 Feb 2003, Stephane Bortzmeyer wrote: > On Thu, Feb 06, 2003 at 06:42:45PM +0100, > Stefan Paletta wrote > a message of 25 lines which said: > > > 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. You may wish to refer to the dnsop archives, and the 'Should a nameserver know about itself?' thread, starting at: http://www.cafax.se/dnsop/maillist/2001-05/msg00009.html ( I am not expressing an opinion of the RIPE NCC, just work I did at my previous employer ) > I am not involved in the daily operations of the '.fr' registry but, > AFAIK, the ZoneCheck tool (check it out yourself > ) requires a referral only if your > server claims to be recursive. Is this 'recursive for the zone being delegated' (somewhat bad) or 'recursive' in general ? Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security From brad.knowles at skynet.be Fri Feb 7 16:33:51 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 7 Feb 2003 16:33:51 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: Message-ID: At 3:33 PM +0100 2003/02/07, Bruce Campbell wrote: > You may wish to refer to the dnsop archives, and the 'Should a nameserver > know about itself?' thread, starting at: > > http://www.cafax.se/dnsop/maillist/2001-05/msg00009.html > > ( I am not expressing an opinion of the RIPE NCC, just work I did at my > previous employer ) I read through this entire thread. It doesn't seem to have anything to do with whether or not an authoritative-only server should respond with a referral to the root zone when asked a question that it is not authoritative for. So far, the best argument I've seen for returning anything else, is for returning a SERVFAIL, in . However, I am not yet convinced. IMO, if I ask a server a question and it gives me a root referral, then I know that name is not served by that machine. If it gives me a SERVFAIL instead, then I am left wondering just how b0rken it is, and whether or not it should be ignored for all future queries of any type or question. -- Brad Knowles, "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(+++) From jakob at crt.se Fri Feb 7 16:58:53 2003 From: jakob at crt.se (Jakob Schlyter) Date: Fri, 7 Feb 2003 16:58:53 +0100 (MET) Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: On Fri, 7 Feb 2003, Brad Knowles wrote: > At 6:42 PM +0100 2003/02/06, Stefan Paletta wrote: > > > 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. > > Best practice? No, I would disagree most vehemently on that. If > nsd is doing this, then I believe it needs to be fixed. Handing out > a referral to the root zone is no more work than handing out SERVFAIL. nsd could be configured to either hand out a referral or send SERVFAIL. bind9 will reply with REFUSED if the hints file is missing and it is configured to be authoritative only. jakob From brad.knowles at skynet.be Fri Feb 7 18:48:28 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 7 Feb 2003 18:48:28 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: At 4:58 PM +0100 2003/02/07, Jakob Schlyter wrote: > nsd could be configured to either hand out a referral or send SERVFAIL. It should be configured to hand out a referral. > 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. -- Brad Knowles, "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(+++) From jakob at crt.se Fri Feb 7 19:47:58 2003 From: jakob at crt.se (Jakob Schlyter) Date: Fri, 7 Feb 2003 19:47:58 +0100 (CET) Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: On Fri, 7 Feb 2003, Brad Knowles wrote: > At 4:58 PM +0100 2003/02/07, Jakob Schlyter wrote: > > > nsd could be configured to either hand out a referral or send SERVFAIL. > > 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. jakob From brad.knowles at skynet.be Sat Feb 8 03:01:07 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat, 8 Feb 2003 03:01:07 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: At 7:47 PM +0100 2003/02/07, Jakob Schlyter wrote: > if you do not include a hints file in nsd's database, it will return > SERVFAIL. Are you saying that it will hand out a referral if this information is configured into the database? If so, then I would be much less unhappy with the way it is working. Maybe this code isn't on by default, but it's much better than not being there at all. > 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. Right, but REFUSED != SERVFAIL. -- Brad Knowles, "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(+++) From brad.knowles at skynet.be Sat Feb 8 03:15:51 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Sat, 8 Feb 2003 03:15:51 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: At 3:01 AM +0100 2003/02/08, Brad Knowles wrote: >> 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. > > Right, but REFUSED != SERVFAIL. Moreover, this isn't the default behaviour of BIND 9. You have to go out of your way to make this configuration choice. I'm okay with people choosing to configure their servers this way, but this isn't something that should be done by default. -- Brad Knowles, "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(+++) From olaf at ripe.net Sat Feb 8 10:41:03 2003 From: olaf at ripe.net (Olaf Kolkman) Date: Sat, 08 Feb 2003 10:41:03 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: Message from Jakob Schlyter of "Fri, 07 Feb 2003 19:47:58 +0100." Message-ID: <200302080941.h189f3Aq019221@birch.ripe.net> * > 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 From bruce.campbell at ripe.net Sat Feb 8 23:33:53 2003 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Sat, 8 Feb 2003 23:33:53 +0100 (CET) Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: Message-ID: On Sat, 8 Feb 2003, Brad Knowles wrote: > At 7:47 PM +0100 2003/02/07, Jakob Schlyter wrote: > > > if you do not include a hints file in nsd's database, it will return > > SERVFAIL. Actually (having burnt my fingers on this one), you really do not want to configure any zones into nsd (including '.') unless you are authoritative for those zones. Since nsd is (by design) an authoritative-only nameserver, any zones configured will be answered authoritatively. > Are you saying that it will hand out a referral if this > information is configured into the database? nsd will return authoritative NXDOMAIN with authority of '.' on unknown queries if '.' is configured. This is probably not what is wanted in most cases. Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security From brad.knowles at skynet.be Sun Feb 9 02:12:28 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun, 9 Feb 2003 02:12:28 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: Message-ID: At 11:33 PM +0100 2003/02/08, Bruce Campbell wrote: >> > if you do not include a hints file in nsd's database, it will return >> > SERVFAIL. > > Actually (having burnt my fingers on this one), you really do not want to > configure any zones into nsd (including '.') unless you are authoritative > for those zones. Since nsd is (by design) an authoritative-only > nameserver, any zones configured will be answered authoritatively. In which case, it is impossible to configure nsd to "do the right thing", even if this feature wasn't turned on by default. If you don't configure the root zone, then you get SERVFAIL instead. If you do, then you get bogus information. We need a third way, one that gives us the right answer. -- Brad Knowles, "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(+++) From daniel.karrenberg at ripe.net Sun Feb 9 22:27:57 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Sun, 9 Feb 2003 22:27:57 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: Message-ID: <20030209212757.GB1716@reifchen-wave.karrenberg.net> On 08.02 23:33, Bruce Campbell wrote: > On Sat, 8 Feb 2003, Brad Knowles wrote: > > > At 7:47 PM +0100 2003/02/07, Jakob Schlyter wrote: > > > > > if you do not include a hints file in nsd's database, it will return > > > SERVFAIL. > > Actually (having burnt my fingers on this one), you really do not want to > configure any zones into nsd (including '.') unless you are authoritative > for those zones. Since nsd is (by design) an authoritative-only > nameserver, any zones configured will be answered authoritatively. > > > Are you saying that it will hand out a referral if this > > information is configured into the database? > > nsd will return authoritative NXDOMAIN with authority of '.' on unknown > queries if '.' is configured. This is probably not what is wanted in most > cases. If you load a root zone into a name server and tell it to be authoritative for it (default in nsd) it serves that zone authoritatively. Anything else would be strange, wouldn't it? So if a TLD is not in that zone the only correct answer is an autoritative NXDOMAIN. (If you take a hints file, add a SOA record, and then tell NSD it is a root zone, the outcome is the same. How can the poor program know it is really a hints file with a SOA added and not a zone file? ;-() The next release of nsd (actually zonec) will require a special flag to allow compiling the '.' zone. Just another feeble attempt to prevent bullets in feet caused by the preconceptions that all name servers need a hints file to work. I hope it will be more successful than all the other "Do you really want to do this [y/n]?" questions. Imho non-recursing name servers should not answer anything they are not authoritative for. Such queries should not go to them and being extra helpful without knowing authoritative information is never good. This is why I always ask more than one person for directions especially if the first person I asked is very nice and helpful. It is better to admit one does not know. (RFC 1123 section 6.1.2.5 codifies this) Daniel From stefanp at cabal1.com Sun Feb 9 21:38:11 2003 From: stefanp at cabal1.com (Stefan Paletta) Date: Sun, 9 Feb 2003 21:38:11 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: <20030206174246.23560.qmail@lolita.WRonline.de> Message-ID: <20030209203811.GA9581@lolita.wronline.de> [please do not explicitly send copies of followups to me] Brad Knowles wrote/schrieb/scripsit: > Best practice? No, I would disagree most vehemently on that. If > nsd is doing this, then I believe it needs to be fixed. Handing out > a referral to the root zone is no more work than handing out SERVFAIL. The ability to hand out referrals has an administrative overhead and is thus more prone to errors. The recent misconfiguration of NS.EU.NET is a good example for that. Most importantly, responding with a SERVFAIL is RFC compliant. > Now, for users of nsd, yes this is a serious problem. They are > not given any choice. But then, nsd is not useful as a > general-purpose authoritative nameserver -- it is designed as a > root/TLD nameserver, and anyone who mis-uses or abuses it to try to > serve as a general-purpose authoritative nameserver basically gets > what they deserve. Are you suggesting that different demands for conformance should be applied to root/TLD nameservers vs. others? There is btw. nothing in the announcements of and documentation for NSD to suggest that it might not be designed or fit for use as a general-purpose authoritative nameserver. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC} From stefanp at cabal1.com Sun Feb 9 22:56:27 2003 From: stefanp at cabal1.com (Stefan Paletta) Date: Sun, 9 Feb 2003 22:56:27 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: Message-ID: <20030209215627.GA18366@lolita.wronline.de> [please do not explicitly send copies of followups to me] Brad Knowles wrote/schrieb/scripsit: > In which case, it is impossible to configure nsd to "do the right > thing", even if this feature wasn't turned on by default. If you > don't configure the root zone, then you get SERVFAIL instead. If you > do, then you get bogus information. We need a third way, one that > gives us the right answer. There is no One True Lame Delegation Answer. Servers have always re- sponded differently when a delegation was lame. For example, suppose I had configured the cabal1.net nameservers like: $ORIGIN cabal1.net. ; SOA yadda yadaa foobar NS k k A 193.0.14.129 ; address of k.root-servers.net Then, when a client had learned that k.cabal1.net at address 193.0.14.129 was supposed to know about foobar.cabal1.net, this nameserver, when asked for the address of foobar.cabal1.net, would respond with an authoritative referral to the net servers. The client would notice that this was a lame delegation and then throw away the information received, because it would be vulnerable to poisoning otherwise. Similarly, BIND servers usually have a root.cache file, even when they are not acting as recursive resolvers. As a consequence, under certain circumstances, all they could do when asked for information they did not have was to return their knowledge of the root servers. They would do this non-authoritatively because the root.cache information is not their authoritative knowledge. No matter if this is even an authorita- tive answer (i.e. the server had a local root zone configured) or not, the client will notice that the delegation is lame and then throw away the (possibly bogus) information. So, there is absolutely nothing magic about returning a referral to the roots. Many possible -- and correct -- responses to a lame delegation exist and one of them is to simply return SERVFAIL for lack of better knowledge. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC} From brad.knowles at skynet.be Mon Feb 10 12:46:31 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Mon, 10 Feb 2003 12:46:31 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030209215627.GA18366@lolita.wronline.de> References: <20030209215627.GA18366@lolita.wronline.de> Message-ID: At 10:56 PM +0100 2003/02/09, Stefan Paletta wrote: > [please do not explicitly send copies of followups to me] Roger. > There is no One True Lame Delegation Answer. Servers have always re- > sponded differently when a delegation was lame. Just because you got a query for a zone that you do not host does not mean that there is a lame delegation. It could very well be an issue of a mis-configured resolver or a mis-configured client nameserver, and have nothing to do with published delegation information. > Then, when a client had learned that k.cabal1.net at address 193.0.14.129 > was supposed to know about foobar.cabal1.net, this nameserver, when asked > for the address of foobar.cabal1.net, would respond with an authoritative > referral to the net servers. The client would notice that this was a lame > delegation and then throw away the information received, because it would > be vulnerable to poisoning otherwise. Correct. > Similarly, BIND servers usually have a root.cache file, even when they > are not acting as recursive resolvers. BIND 8 requires a root.cache file, BIND 9 does not. BIND 9 has an equivalent of a root.cache file built directly into the source code, and will use this built-in equivalent in the absence of a root.cache file. > As a consequence, under certain > circumstances, all they could do when asked for information they did > not have was to return their knowledge of the root servers. Correct. > They would > do this non-authoritatively because the root.cache information is not > their authoritative knowledge. Correct. > No matter if this is even an authorita- > tive answer (i.e. the server had a local root zone configured) or not, > the client will notice that the delegation is lame and then throw away > the (possibly bogus) information. Again, the query may not have been the result of a lame delegation. > So, there is absolutely nothing magic about returning a referral to the > roots. Many possible -- and correct -- responses to a lame delegation > exist and one of them is to simply return SERVFAIL for lack of better > knowledge. I disagree. I am willing to be convinced. However, I think this needs wider and more in-depth discussion over a longer period of time. When we get to a standards-track RFC that explicitly states this fact, and I can go back and review all of the public discussions on this topic, and I can sit down with people who were involved in the appropriate private discussions, I would be more likely to agree to this statement. But not yet. -- Brad Knowles, "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(+++) From brad.knowles at skynet.be Mon Feb 10 12:40:54 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Mon, 10 Feb 2003 12:40:54 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030209203811.GA9581@lolita.wronline.de> References: <20030206174246.23560.qmail@lolita.WRonline.de> <20030209203811.GA9581@lolita.wronline.de> Message-ID: At 9:38 PM +0100 2003/02/09, Stefan Paletta wrote: > [please do not explicitly send copies of followups to me] Roger. > The ability to hand out referrals has an administrative overhead and > is thus more prone to errors. The recent misconfiguration of NS.EU.NET > is a good example for that. It does require more network traffic, yes. But the specific IP addresses should not be paid attention to by anyone -- all they should record is that they got a response that basically said "Sorry, I don't have this information -- if you like, you may try asking this question of these machines". > Most importantly, responding with a SERVFAIL is RFC compliant. I am not yet convinced of this. Yes, I've read the namedroppers traffic. But so far as I know, this issue has never been put into a ID, BCP, or standards-track RFC. Therefore, a very small community of people have discussed this issue in very isolated circumstances, and IMO this has not received sufficient review to be considered "RFC compliant". > Are you suggesting that different demands for conformance should be > applied to root/TLD nameservers vs. others? Depends on what you're testing against. > There is btw. nothing in the announcements of and documentation for > NSD to suggest that it might not be designed or fit for use as a > general-purpose authoritative nameserver. Understood. However, obviously people are now mis-using it in this fashion (perhaps even at my behest, as a result of my presentation at LISA 2002), otherwise the original report would never have been generated. Therefore, I believe that making this point explicit is a very good idea. -- Brad Knowles, "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(+++) From stefanp at cabal1.com Tue Feb 11 17:40:11 2003 From: stefanp at cabal1.com (Stefan Paletta) Date: Tue, 11 Feb 2003 17:40:11 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <5484.1044622247@shell.nominum.com> References: <20030206174246.23560.qmail@lolita.WRonline.de> <5484.1044622247@shell.nominum.com> Message-ID: <20030211164011.GA7796@lolita.wronline.de> [please do not explicitly send copies of followups to me] Jim Reid wrote/schrieb/scripsit: > >>>>> "Stefan" == Stefan Paletta 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. Bait not taken; rest assured, my choice of nameserver software has never hindered any registration (at least not yet) and I will never hesitate a second to cheat around useless requirements if necessary. I believe that diversity of software is actually a strong requirement for the stability of the Internet (but then I'm not geeting paid by a company that makes and sells nameserver software---SCNR!) and I welcome the effort RIPE has made to contribute to that. A simple, reliable and fast nameserver that groks BIND zonefiles is a good thing to have. What concerns me, though, is a possible limitation of use- fulness of NSD and I would expect RIPE to actually care about that, too (I am aware that this list is not authoritative wrt. this). Anyway, just let me know if that is not the case and I will shut up. (Though I might then -- at another place -- raise the question why RIPE is purposely wasting my money making nameserver software that is not usable for domains in some TLDs.) > 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. > "Don't come to us until your name > servers are working" is not an unreasonable stance IMO. It is entirely reasonable. Altough I firmly believe Darwinism is much better in selecting those who know DNS and those who don't, actively giving people clues about how to do it right is probably more within the spirit of the Internet. The problem here is just that the definition of 'working' is too often less than helpful. As I have already explained briefly -- and I think we will see more thoroughly later -- some checks are nonsensical in a technical way, actively hindering e.g. deployment of standards conformant software, and most of them fail to provide a continued use because they are nonrevisable, unenforcable and singular, i.e. people can screw up in wonderful ways once a zone has been delegated anyway. > 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. I was not asking for anyone to dictate policy at all. It is just that registries have a habit of not listening to their customers (esp. not those who apparently cannot get their nameserver to work 'correctly'). That is where a RIPE document at least gives people something in their hands to take to a registry and (hopefully) make them listen. > 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. :-) Well first of all I am not familiar with the guidelines of such an undertaking (you probably guessed that ;-) ), but nonetheless, I am willing to collect, analyze and then evaluate such policies, given the necessary input from the community. As for a recommendation on reg. policies I have to say that probably my ideas about that, while being -- as far as I know -- well thought out, might simply be too radical to be suitable for inclusion in a document approved by this WG. For example quite a few registries have the requirement for at least two independent nameservers and that those have addresses not within the same /24. This can be replaced by one completely different re- quirement that, in contrast, is revisable, enforcable and actually useful. By all means, if someone wants to hear I will be happy to write this up and have it discussed and, for that matter, proven wrong. > 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? Bait not taken again; there is, however, some truth in your statement. I agree that djbdns servers must respond in any case, and I found it not too hard to configure my servers to do the Right Thing and fall back to SERVFAIL. The method of adding a referral to the roots is also documented. Again, others may operate their servers the way they choose. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC} From webmaster at ripe.net Thu Feb 13 16:22:13 2003 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Thu, 13 Feb 2003 16:22:13 +0100 Subject: New Document Available: RIPE-268 Message-ID: <200302131522.h1DFMDAq012796@birch.ripe.net> 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 From brad.knowles at skynet.be Fri Feb 14 01:36:56 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 14 Feb 2003 01:36:56 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030211164011.GA7796@lolita.wronline.de> References: <20030206174246.23560.qmail@lolita.WRonline.de> <5484.1044622247@shell.nominum.com> <20030211164011.GA7796@lolita.wronline.de> Message-ID: At 5:40 PM +0100 2003/02/11, Stefan Paletta wrote: > Bait not taken; rest assured, my choice of nameserver software has > never hindered any registration (at least not yet) and I will never > hesitate a second to cheat around useless requirements if necessary. If you choose to "cheat around requirements" that you consider to be useless, do not be surprised if you find yourself summarily disconnected and treated as a true net.pariah. > I believe that diversity of software is actually a strong requirement > for the stability of the Internet (but then I'm not geeting paid by a > company that makes and sells nameserver software---SCNR!) and I > welcome the effort RIPE has made to contribute to that. As far as this statement goes, I think everyone on this list will agree -- regardless of who their employer may or may not be. Before you casually dismiss us, you should at least check to see if we actually support whatever it is that you abhor so much. Throwing mud at people you do not know sufficiently well to determine whether or not they agree or disagree with your statements is not a particularly effective manner of convincing people that you're right. > A simple, > reliable and fast nameserver that groks BIND zonefiles is a good thing > to have. What concerns me, though, is a possible limitation of use- > fulness of NSD and I would expect RIPE to actually care about that, > too (I am aware that this list is not authoritative wrt. this). One of the fundamental design criteria for nsd was to eliminate all possible operations that were not strictly required for the proper functioning of a TLD nameserver. However, this does limit the functionality of nsd with regard to regular authoritative functioning. > Anyway, just let me know if that is not the case and I will shut up. > (Though I might then -- at another place -- raise the question why > RIPE is purposely wasting my money making nameserver software that is > not usable for domains in some TLDs.) This is a design choice made by the authors. I don't think there's any chance of getting them to change their minds about eliminating all functions not strictly necessary for a TLD nameserver. > It is entirely reasonable. Altough I firmly believe Darwinism is much > better in selecting those who know DNS and those who don't, actively > giving people clues about how to do it right is probably more within > the spirit of the Internet. Regretfully, there are many people who can cause much damage to the DNS and the Internet as a whole, without actually being eliminated themselves. This is kind of the same problem as you have with drunk drivers -- they usually cause far more damage to others than to themselves. > i.e. people > can screw up in wonderful ways once a zone has been delegated anyway. Sure, that's always possible. Indeed, this sort of problem is possible in most human endeavours. However, it's also possible for people like Rob Thomas or someone else to put into place procedures that will periodically check for a variety of DNS configuration problems, and then we can publicly name and shame them. There's little more we can do, but there is at least the chance that this might do some good. > I was not asking for anyone to dictate policy at all. It is just that > registries have a habit of not listening to their customers (esp. not > those who apparently cannot get their nameserver to work 'correctly'). > That is where a RIPE document at least gives people something in their > hands to take to a registry and (hopefully) make them listen. Things like this are also useful to take to program authors who insist on implementing b0rken behaviour in their software, just because they think it's right. > For example quite a few registries have the requirement for at least > two independent nameservers and that those have addresses not within > the same /24. This can be replaced by one completely different re- > quirement that, in contrast, is revisable, enforcable and actually > useful. By all means, if someone wants to hear I will be happy to > write this up and have it discussed and, for that matter, proven wrong. I would be curious to know what your proposed alternative is. -- Brad Knowles, "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(+++) From daniel.karrenberg at ripe.net Fri Feb 14 08:50:12 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 14 Feb 2003 08:50:12 +0100 Subject: k.root-servers.net Changing DNS Software at on 19.2.2003 Message-ID: <20030214075012.GA1405@reifchen-wave.karrenberg.net> 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 as usual. nsd can be found at http://www.nlnetlabs.nl/nsd/index.html. From daniel.karrenberg at ripe.net Fri Feb 14 09:52:00 2003 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 14 Feb 2003 09:52:00 +0100 Subject: [rssac] k.root-servers.net Changing DNS Software at on 19.2.2003 In-Reply-To: <5.1.0.14.2.20030214190903.01c79df8@kahuna.telstra.net> References: <20030214075012.GA1405@reifchen-wave.karrenberg.net> <5.1.0.14.2.20030214190903.01c79df8@kahuna.telstra.net> Message-ID: <20030214085200.GA1360@reifchen-wave.karrenberg.net> On 14.02 19:10, Geoff Huston wrote: > Does this proposed change for K as a root server also imply a change for > K as a .arpa server? Yes. Increased diversity for the .arpa zone at no extra cost. ;-) From stefanp at cabal1.com Fri Feb 14 07:30:36 2003 From: stefanp at cabal1.com (Stefan Paletta) Date: Fri, 14 Feb 2003 07:30:36 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: References: <20030206174246.23560.qmail@lolita.WRonline.de> <5484.1044622247@shell.nominum.com> <20030211164011.GA7796@lolita.wronline.de> Message-ID: <20030214063035.GA29345@lolita.wronline.de> Brad Knowles wrote/schrieb/scripsit: > At 5:40 PM +0100 2003/02/11, Stefan Paletta wrote: > > I believe that diversity of software is actually a strong requirement > > for the stability of the Internet (but then I'm not geeting paid by a > > company that makes and sells nameserver software---SCNR!) and I > > welcome the effort RIPE has made to contribute to that. > > As far as this statement goes, I think everyone on this list will > agree -- regardless of who their employer may or may not be. Before > you casually dismiss us, you should at least check to see if we > actually support whatever it is that you abhor so much. > > Throwing mud at people you do not know sufficiently well to > determine whether or not they agree or disagree with your statements > is not a particularly effective manner of convincing people that > you're right. That was just a cynical response to Jim's fallacious assumption about my motivation and of course not to be taken seriously. If someone took it for that, I am sorry. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC} From gih at telstra.net Fri Feb 14 09:10:44 2003 From: gih at telstra.net (Geoff Huston) Date: Fri, 14 Feb 2003 19:10:44 +1100 Subject: [rssac] k.root-servers.net Changing DNS Software at on 19.2.2003 In-Reply-To: <20030214075012.GA1405@reifchen-wave.karrenberg.net> Message-ID: <5.1.0.14.2.20030214190903.01c79df8@kahuna.telstra.net> Daniel, Most of the root servers are also servers for the .arpa zone Does this proposed change for K as a root server also imply a change for K as a .arpa server? thanks, Geoff At 08:50 AM 2/14/2003 +0100, Daniel Karrenberg wrote: >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 > as usual. > >nsd can be found at http://www.nlnetlabs.nl/nsd/index.html. From Jim.Reid at nominum.com Fri Feb 14 13:18:14 2003 From: Jim.Reid at nominum.com (Jim Reid) Date: Fri, 14 Feb 2003 04:18:14 -0800 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: Message from Stefan Paletta of "Fri, 14 Feb 2003 07:30:36 +0100." <20030214063035.GA29345@lolita.wronline.de> Message-ID: <55753.1045225094@shell.nominum.com> >>>>> "Stefan" == Stefan Paletta 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. From training at ripe.net Mon Feb 17 15:45:27 2003 From: training at ripe.net (RIPE NCC Training) Date: Mon, 17 Feb 2003 15:45:27 +0100 Subject: Announcement RIPE NCC DNSSec Training Courses Message-ID: <200302171445.h1HEjRAq018003@birch.ripe.net> 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 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 . 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.) # 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 From ddiaz at ripe.net Wed Feb 19 11:09:35 2003 From: ddiaz at ripe.net (Daniel Diaz) Date: Wed, 19 Feb 2003 11:09:35 +0100 Subject: k.root-servers.net Changing DNS Software at on 19.2.2003 Message-ID: <200302191009.h1JA9ZAr005535@birch.ripe.net> 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 From brad.knowles at skynet.be Thu Feb 20 09:54:26 2003 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu, 20 Feb 2003 09:54:26 +0100 Subject: My video from RIPE 44... Message-ID: Folks, For anyone who is interested, I've got a few files moved up to . 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, "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(+++) From bortzmeyer at nic.fr Thu Feb 20 10:52:46 2003 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 20 Feb 2003 10:52:46 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030211164011.GA7796@lolita.wronline.de> References: <20030206174246.23560.qmail@lolita.WRonline.de> <5484.1044622247@shell.nominum.com> <20030211164011.GA7796@lolita.wronline.de> Message-ID: <20030220095246.GA16683@nic.fr> On Tue, Feb 11, 2003 at 05:40:11PM +0100, Stefan Paletta wrote a message of 109 lines which said: > I will never hesitate a second to cheat around useless requirements > if necessary IANAL but I believe that the after-the-fact discovery of cheating is a sufficient reason to delete a domain in '.fr'... > The problem here is just that the definition of 'working' is too > often less than helpful. As I have already explained briefly -- and I > think we will see more thoroughly later -- some checks are nonsensical > in a technical way, As I said, AFNIC is working on a new version of ZoneCheck, rewritten from scratch, free software and, more important, completely modular: tests can be added easily and a configuration file allows to suppress a test without source code modification. Advices on the current set of tests is welcome. Input from the community is also welcome: if you have ideas of nice tests, please write AFNIC or myself (I'll forward). > people can screw up in wonderful ways once a zone has been > delegated anyway. Right. Unlike the '.de' and '.br' registries, AFNIC does not check once the delegation is made. But it will be done in '.eu' with the ZoneCheck tool. > registries have a habit of not listening to their customers (esp. not > those who apparently cannot get their nameserver to work > 'correctly'). We received two weeks ago a complaint from a potential customer (a big software company, people who should be technically savvy) saying that we had no business testing the connectivity on port 53 with TCP and that we disturbed their firewall. They added that TCP was only for zone transfers. The idiot^H^H^H^H^Hcustomer requested my supervisor's name and address when I told him he knew nothing about DNS :-) > For example quite a few registries have the requirement for at least > two independent nameservers and that those have addresses not within > the same /24. Funny, you do not mention of the biggest bugs of the present ZoneCheck: it is still classful and complains if your two nameservers are in the same former class A... > quirement that, in contrast, is revisable, enforcable and actually > useful. By all means, if someone wants to hear I will be happy to > write this up and have it discussed and, for that matter, proven wrong. Please do because I do not have many good ideas on how to test this. Do you plan to use BGP announces? From stefanp at cabal1.com Sun Feb 23 23:15:50 2003 From: stefanp at cabal1.com (Stefan Paletta) Date: Sun, 23 Feb 2003 23:15:50 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: <20030220095246.GA16683@nic.fr> References: <20030206174246.23560.qmail@lolita.WRonline.de> <5484.1044622247@shell.nominum.com> <20030211164011.GA7796@lolita.wronline.de> <20030220095246.GA16683@nic.fr> Message-ID: <20030223221550.GE20103@lolita.wronline.de> Stephane Bortzmeyer wrote/schrieb/scripsit: > On Tue, Feb 11, 2003 at 05:40:11PM +0100, > Stefan Paletta wrote > a message of 109 lines which said: > > > I will never hesitate a second to cheat around useless requirements > > if necessary > > IANAL but I believe that the after-the-fact discovery of cheating is a > sufficient reason to delete a domain in '.fr'... Because I changed the software my name server runs? (That is a hypothetical me.) Maybe 'cheating' was not the right word - 'using tools more creatively than the rule-makers thought of'. Anyway.. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC} From pk at TechFak.Uni-Bielefeld.DE Mon Feb 24 10:06:12 2003 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Mon, 24 Feb 2003 10:06:12 +0100 Subject: clueing in TLD registries for delegations to non-BIND servers In-Reply-To: Your message of "Sun, 23 Feb 2003 23:15:50 +0100." <20030223221550.GE20103@lolita.wronline.de> Message-ID: <200302240906.h1O96CF06236@grimsvotn.TechFak.Uni-Bielefeld.DE> Stefan Paletta wrote: > Maybe 'cheating' was not the right word - 'using tools more creatively > than the rule-makers thought of'. this is really not a race "those stupid rule makers" vs "oh-so-creative zone administrators". First, the "creativity" of the latter very often is detrimental to DNS operational quality and second, registries have to cope with a high volume of changes every day while having to ensure technical quality without the ability of in-depth case studies. So, while those rules probably won't be fair to every single case, they will - if applied reasonably - ensure a high quality system for the average zone. I guess the discussion of what are "reasonable" pre- and post-delegation checks is well inside the scope of this working group and I'd be looking forward to see (and contribute to) some activity in this direction. Still, the RIPE DNS WG is neither the network policy nor a supervisory body for registry operations, i.e. there will be a "grey area" of tests which a registry may want to apply which are neither "necessary" nor "nonsense". We should discuss the technical merits and the pros and cons of such tests. -Peter From andrei at ripe.net Thu Feb 27 18:18:25 2003 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 27 Feb 2003 18:18:25 +0100 Subject: RIPE NCC network affected by the DDoS attack Message-ID: <3E5E4861.4030203@ripe.net> 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