From rv at deins.informatik.uni-dortmund.de Wed Mar 2 12:04:01 1994 From: rv at deins.informatik.uni-dortmund.de (Ruediger Volk) Date: Wed, 02 Mar 1994 12:04:01 +0100 Subject: current BIND status Message-ID: <23088.762606241@heinz.informatik.uni-dortmund.de> Dear colleagues, last week I helped trace back some DNS problems to (yet another) installation of a bad early test version of BIND 4.9.2 (installed on a major server). Unfortunately it seems that quite a lot of installations have picked up broken test versions that were never intended for public distribution or use; indeed archie indicates that that kind of bad software is carried by more archive servers than the public beta or the recent "final" version (931205). If you have published old versions of BIND 4.9.2 on your archive servers I would like to encourage you very much to purge these ASAP to prevent further spread of the broken software. Below I include a short note about the current state of the 4.9.2 release I wrote for a BIND source archive I maintain; I explictly checked this information with Paul Vixie. If interested you can grab the current distribution kit from DEC WRL (see below); you also can use one of the European copies e.g. ftp://deins.Informatik.Uni-Dortmund.DE/DNS/src/bind/4.9.2-940221.tar.Z (about 1.5 MByte). Cheers, Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB D-44221 Dortmund, Germany E-Mail: rv at Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386 ================================================================================ BIND 4.9.2 versions (Ruediger Volk -940302-) =================== Version 4.9.2-940221 of BIND is the best version so far; it will be declared the FINAL version of release 4.9.2; all previous versions of 4.9.2 were still test versions. (see also note from Paul Vixie below) In particular all previous versions of 4.9.2 include more bugs - and some are really bad. However a few problems with 4.9.2-940221 are still known, and a patch kit is in preparation. If you want a good and current BIND *now*, you are advised to use 4.9.2-940221 but switch OFF the options NCACHE and VALIDATE (these are the areas of known or suspected bugs that can be dangerous). Please GET RID of earlier versions of 4.9.2. (all versions prior to 931205 were ONLY intended for limited, controlled use within the group of testers and developers; 4.9.2-931205 WITH 4.9.2-931205.patch01 applied was the public beta test version, and is now succeeded by 4.9.2-940221.) P.S.: I minor bug in the 4.9.2-940221 distribution kit is related to the included formatted documentation: beware, while the PostScript formatted version of the BIND Operations Guide doc/bog/file.psf is current for 4.9.2, doc/bog/file.psf is the ASCII formatted version from the previous release (4.9). ================================================================================ From: paul at vix.com (Paul A Vixie) Subject: Re: Bind - 4.9.2 Date: 28 Feb 94 20:07:52 GMT Organization: Vixie Enterprises > Can anyone tell me when the 4.9.2 version of Bind is expected to >be realesed? i'm going to declare the 4.9.2 on gatekeeper.dec.com:~ftp/pub/misc/vixie (4.9.2-940221.tar.{gz,Z}) to be FINAL. we're working on the first patch now; it corrects the last bundle of small problems that couldn't be frozen into 4.9.2 due to release synchronization schedules. From Daniel.Karrenberg at ripe.net Fri Mar 11 16:45:55 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 11 Mar 1994 16:45:55 +0100 Subject: recommending use of IN-ADDR.ARPA Message-ID: <9403111545.AA11371@reif.ripe.net> Folks, what does the DNS WG think about recommending usage of in-addr.arpa for router networks in order to facilitate problem diagnostics? Daniel Date: Wed, 9 Mar 94 22:00:49 +0100 From: Philippe-Andre Prindeville Message-Id: <9403092100.AA20616 at davis.res.enst.fr> To: Marten.Terpstra at ripe.net Subject: Missing IN-ADDR.ARPA records Resent-To: hostmaster at ripe.net Resent-Date: Thu, 10 Mar 1994 10:14:18 +0100 Resent-From: Marten Terpstra Hi Marten, I was wondering if you could tell me something: for almost a year, I've been asking Renater regularly to install a name server for their IN-ADDR.ARPA zones for their routers. They've been (in the past) telling me that it was planned but they haven't gotten around to doing it. Well, the shoe has dropped. They've abandoned all pretenses of ever intending to install IN-ADDR.ARPA zones to the name servers. It simply will never happen. For users and network operators alike, this is a serious problem if we can't at least pin-point the locality of network outages. What political recourse does RIPE (or EBONE) have to bring Renater into line? Is there an "authority" I can complain to? Thanks, -Philip From Piet.Beertema at cwi.nl Fri Mar 11 16:57:19 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 11 Mar 1994 16:57:19 +0100 Subject: recommending use of IN-ADDR.ARPA In-Reply-To: "Your message of Fri, 11 Mar 1994 16:45:55 +0100 " <9403111545.AA11371@reif.ripe.net> Message-ID: <9403111557.AA02216=piet@kraai.cwi.nl> what does the DNS WG think about recommending usage of in-addr.arpa for router networks in order to facilitate problem diagnostics? Having IN-ADDR.ARPA nameservers should be considered mandatory for all networks with Internet connectivity. Philip gave a very good reason indeed for this: For users and network operators alike, this is a serious problem if we can't at least pin-point the locality of network outages. This goes for network operators and systems managers, even when the latter can/should contact their network operator(s): as a systems manager I want to be able to quickly pinpoint the spot of a network problem, so I can call on my experience as network manager to be able to make a guess on how long it may last. I must add though that I'm not at a complete loss when there is no IN-ADDR.ARPA resolving for a particular router: I can check the RIPE whois server to see whom the network belong too. Still it's a nuisance if there is no IN-ADDR.ARPA resolving. Piet From miguel.sanz at rediris.es Tue Mar 15 21:32:19 1994 From: miguel.sanz at rediris.es (Miguel A. Sanz) Date: Tue, 15 Mar 1994 21:32:19 UTC+0100 Subject: Registering 2 letter second level domain Message-ID: <2039*/G=miguel/S=sanz/O=rediris/PRMD=iris/ADMD=mensatex/C=es/@MHS> Hi! Does anyone know if there is any imperative (writen or oral) to avoid registering 2 letter second level domains? I know some top level domains refuse to do so based on possible conflicts (due to user misconfigurations) with current or future top level domains, but others allow it. We have a request to register one of these under "es" and I want some advice before saying "yes" or "no". Thanks, Miguel +---------------------------------------------------------------+ | Miguel A. Sanz Tel: + 34 1 5855152 | | RedIRIS/CSIC Fax: + 34 1 5855146 | | Serrano 142 Email: miguel.sanz at rediris.es | | 28006 Madrid | +---------------------------------------------------------------+ From nipper at xlink.net Tue Mar 15 23:58:47 1994 From: nipper at xlink.net (Arnold Nipper) Date: Tue, 15 Mar 1994 23:58:47 +0100 (MET) Subject: Registering 2 letter second level domain In-Reply-To: <2039*/G=miguel/S=sanz/O=rediris/PRMD=iris/ADMD=mensatex/C=es/@MHS> from "Miguel A. Sanz" at Mar 15, 94 09:32:19 pm Message-ID: <"xlink100.x.467:15.02.94.22.58.48"@xlink.net> Miguel A. Sanz wrote: > > > Hi! > > Does anyone know if there is any imperative (writen or oral) > to avoid registering 2 letter second level domains? > No, there isn't. There are lot of 2 letter second level domains under almost all TDL, e.g. es.net bt.com <2-letter-US-state-code>.us uc.edu co.uk ac.uk co.at ac.at .... In Germany we are just considering to install 2-letter-state-codes as second level domains to cope with the steady increase of domains. > I know some top level domains refuse to do so based on possible > conflicts (due to user misconfigurations) with current or > future top level domains, but others allow it. > > We have a request to register one of these under "es" and > I want some advice before saying "yes" or "no". > > Thanks, > > Miguel > > > +---------------------------------------------------------------+ > | Miguel A. Sanz Tel: + 34 1 5855152 | > | RedIRIS/CSIC Fax: + 34 1 5855146 | > | Serrano 142 Email: miguel.sanz at rediris.es | > | 28006 Madrid | > +---------------------------------------------------------------+ > > > Regards, Arnold -- Arnold Nipper / email: nipper at xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany From Daniel.Karrenberg at ripe.net Wed Mar 16 08:56:12 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 16 Mar 1994 08:56:12 +0100 Subject: Registering 2 letter second level domain In-Reply-To: Your message of Tue, 15 Mar 1994 23:58:47 MET. <"xlink100.x.467:15.02.94.22.58.48"@xlink.net> Message-ID: <9403160756.AA07911@fs1.ripe.net> > Arnold Nipper writes: > Miguel A. Sanz wrote: > > > > > > Hi! > > > > Does anyone know if there is any imperative (writen or oral) > > to avoid registering 2 letter second level domains? > > > > No, there isn't. There are lot of 2 letter second level domains under almos > t > all TDL, e.g. The problem with two letter domains in general is the ambiguity of abbreviated domain names. In principle you can always abbreviate domain names by omitting common higher levels. if you are inside a two letter domain which also exists as a toplevel domain this is ambiguous. Example: If you are inside ac.uk foobar.co can mean foobar.co.uk in the UK or foobar.co in Columbia Mostly this conflict is resolved in favour of the toplevel domain but the ambiguity exists. That's why it is advisable not to use two letter domains anywhere and also to avoid com edu mil etc. Since avoiding this is not hard it is advisable, in my opinion. Why not just use three letter state codes? A possible problem avoided at no cost. Daniel From Piet.Beertema at cwi.nl Wed Mar 16 11:49:34 1994 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 16 Mar 1994 11:49:34 +0100 Subject: Registering 2 letter second level domain In-Reply-To: "Your message of Tue, 15 Mar 1994 21:32:19 UTC+0100 " <2039*/G=miguel/S=sanz/O=rediris/PRMD=iris/ADMD=mensatex/C=es/@MHS> Message-ID: <9403161049.AA04254=piet@kraai.cwi.nl> Does anyone know if there is any imperative (writen or oral) to avoid registering 2 letter second level domains? I know some top level domains refuse to do so based on possible conflicts (due to user misconfigurations) with current or future top level domains, but others allow it. We have a request to register one of these under "es" and I want some advice before saying "yes" or "no". Forbidding to register 2-letter subdomains is pretty hard, but people should *strongly* be advised *not* to register 2-letter subdomains. Practice has shown that people overlook or don't know what RFC822 states in par. 6.2.2, and in their ignorance allow abbreviated addressing. I've seen *LOTS* of mails meant to stay within a CS department, being routed to [the former] Czecho-Slovakia, because there is no way to distinguish between an internal address user at foo.cs (where the FQDN is foo.cs.xxx) and an external address user at foo.cs in Czecho-Slovakia. In your case I'd say registering a domain es.es is almost a guarantee for troubles. Piet From robert at dknet.dk Fri Mar 25 20:21:17 1994 From: robert at dknet.dk (Robert Martin-Legene) Date: Fri, 25 Mar 94 20:21:17 MET Subject: Glues in DNS Message-ID: <199403251921.AA04908@dkuug.dk> I asked RIPE the following, and the directed me to here (and I book I am now waiting for). I'm hoping for a rather this-month-ish solution though. Consider the following from a fictive DNS. a. NS c.b.a. NS f.e. b.a. NS d.b.a. d.b.a A 1.2.3.4 Will it be necessary to put a glue in for c.b.a as it can be found, upon asking d.b.a? I think it is. Then it is also necessary to enter a glue for f.e, right? -- Robert Martin-Legene, = EUnet Denmark = DKnet, Fruebjergvej 3, DK-2100 Kobenhavn O, +45 39 17 99 00 From pk at TechFak.Uni-Bielefeld.DE Mon Mar 28 10:54:39 1994 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Mon, 28 Mar 1994 10:54:39 +0200 Subject: Glues in DNS In-Reply-To: Your message of "Fri, 25 Mar 1994 20:21:17 +0700." <199403251921.AA04908@dkuug.dk> Message-ID: <9403280854.AA22617@lupine.techfak.uni-bielefeld.de> > Consider the following from a fictive DNS. > > a. NS c.b.a. > NS f.e. > b.a. NS d.b.a. > d.b.a A 1.2.3.4 If these records are an excerpt of one DNS zone file, it must be the one carrying the DNS data for zone 'a', otherwise there were a mistake because you cannot first delegate zone 'a' and thereafter 'b.a' which is a subdomain of 'a'. So the first two NS-RRs are the authoritative information for zone 'a'. You do not need (and want) glue records here, inside the zone. Zone 'b.a' is delegated out of zone 'a' and server 'd.b.a' resides in zone 'b.a', so the glue record - as shown in your example - should be present. However, when delegating 'a' the glue RR for 'c.b.a' is necessary in the delegating zone. -Peter PS: Here's another one, from zone 'foo': bar.foo. NS a.rab.foo. NS b.rab.foo. rab.foo. NS c.bar.foo. NS d.bar.foo.