From arthur at midir.ucd.ie Tue Aug 10 18:13:08 1993 From: arthur at midir.ucd.ie (arthur at midir.ucd.ie) Date: Tue, 10 Aug 93 17:13:08 +0100 Subject: localhost in zonefile? Message-ID: <9308101613.AA17577@midir.ucd.ie> Gentlebeings - Forgive the intrusion, but I have a DNS question that I think you should be able to provide a definitive answer on (something I can't get from other sources). The question is this: should I have an entry such as localhost A 127.0.0.1 in a zonefile? This seems to me somewhat silly, but I have seen examples in various places showing it. Also, I've been told that HP-UX v9 breaks if it isn't in. I'm not on the discussion list, so I'd appreciate answers to this address. Thanking you all in advance ... - Arthur Green University College Dublin Computing Services Tel: +353 1 706 2456 Fax: + 353 1 283 7077 E-mail: arthur at midir.ucd.ie From Dave.Morton at ecrc.de Wed Aug 11 13:11:35 1993 From: Dave.Morton at ecrc.de (Dave Morton) Date: Wed, 11 Aug 93 13:11:35 +0200 Subject: localhost in zonefile? Message-ID: <9308111111.AA09127@acrab25.ecrc> > >Gentlebeings - > Forgive the intrusion, but I have a DNS question that I think you should >be able to provide a definitive answer on (something I can't get from other >sources). The question is this: should I have an entry such as > >localhost A 127.0.0.1 > >in a zonefile? This seems to me somewhat silly, but I have seen examples in >various places showing it. Also, I've been told that HP-UX v9 breaks if it isn't >in. Hi Arthur, Don't know about HP_UX but it's generally recommeded to have this in so you don't get surpises, after all, it's your loopback (local) host and you are authorative for it, none else, including root servers. You'll also need a: IN PTR localhost. in there as well. an idea might also be to stick in a: loghost IN CNAME localhost. for the worst case as well. Cheers, Dave From pk at TechFak.Uni-Bielefeld.DE Wed Aug 11 13:38:29 1993 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 11 Aug 93 13:38:29 +0200 Subject: localhost in zonefile? In-Reply-To: Your message of "Wed, 11 Aug 93 13:11:35 +0200." <9308111111.AA09127@acrab25.ecrc> Message-ID: <9308111138.AA00804@lupine.techfak.uni-bielefeld.de> Hello, Dave Morton wrote: > Hi Arthur, > > Don't know about HP_UX but it's generally recommeded to have this in so you > don't get surpises, after all, it's your loopback (local) host and you are > authorative for it, none else, including root servers. You'll also need a: > > IN PTR localhost. > > in there as well. NO. First, this PTR record belongs into the zone 0.0.127.in-addr.arpa (or 127.in-addr.arpa, whichever you prefer) for the address 127.0.0.1 . Second, it is strongly recommended (see BIND operations guide) not to let it point to the fake top level domain 'localhost.' but to some localhost... . For the latter there should be an A-RR for the IP-address 127.0.0.1 . To answer the original question: Yes, you should have an entry localhost A 127.0.0.1 in your (forward) zone files. Note that the current origin will be appended to 'localhost' in the example, so you really will produce an entry like localhost.ucd.ie (if ucd.ie were this current origin) with this. Regards, Peter From Dave.Morton at ecrc.de Wed Aug 11 15:43:31 1993 From: Dave.Morton at ecrc.de (Dave Morton) Date: Wed, 11 Aug 93 15:43:31 +0200 Subject: localhost in zonefile? Message-ID: <9308111343.AA09230@acrab25.ecrc> >> Don't know about HP_UX but it's generally recommeded to have this in so you >> don't get surpises, after all, it's your loopback (local) host and you are >> authorative for it, none else, including root servers. You'll also need a: >> >> IN PTR localhost. >> >> in there as well. > >NO. >First, this PTR record belongs into the zone 0.0.127.in-addr.arpa >(or 127.in-addr.arpa, whichever you prefer) for the address 127.0.0.1 . >Second, it is strongly recommended (see BIND operations guide) not to >let it point to the fake top level domain 'localhost.' but to some >localhost... . For the latter there should be an A-RR for >the IP-address 127.0.0.1 . Peter, Ok, ok - start again else confusion reigns, mabye I was not explicit and I also forgot the 1 above - the joys of cut and paste. One should run primary for 0.0.127.in-addr.arpa, thus in the named.boot file : primary 0.0.127.in-addr.arpa named.local Also a good idea is to stick this in: ; The following are to prevent really stupid queries from going past this server. ; The zero and broadcast stuff primary 0.IN-ADDR.ARPA null primary 255.IN-ADDR.ARPA broadcast and then in named.local file an SOA and an NS record - in my case same as the origin thus the @: @ IN SOA ecrc.de. hostmaster.ecrc.de. ( 1.3 ;Serial 28800 ;Refresh 7200 ;Retry 604800 ;Expire 86400 ) ;Minimum IN NS ecrc.de. 1 IN PTR localhost. Alternatively stick in instead of the @ line: 0.0.127.in-addr.arpa IN SOA whatever.tld - etc.... The null and broadcast files are essentially the same - only an SOA and an NS record are needed. >To answer the original question: Yes, you should have an entry >localhost A 127.0.0.1 >in your (forward) zone files. Note that the current origin will be appended >to 'localhost' in the example, so you really will produce an entry like >localhost.ucd.ie (if ucd.ie were this current origin) with this. > >Regards, > Peter Ok - all true, and perhaps stick in these as well....... localhost. IN A 127.0.0.1 localhost IN A 127.0.0.1 loghost IN CNAME localhost. Well - it seems to work for me ? Dave From Marten.Terpstra at ripe.net Mon Aug 16 14:07:44 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 16 Aug 1993 14:07:44 +0200 Subject: RIPE database beta software Message-ID: <9308161207.AA10607@ncc.ripe.net> Dear all, We finally have some beta software running at the NCC for the database, and we would like you to test some things. We have created an empty test RIPE database on ncc.ripe.net running with the new whois daemon. You can send in updates to: testdb at ripe.net It will be processed and incorporated in a test database running on ncc.ripe.net (also a whois daemon running on that database). You should receive a ack mail back (to the Reply-To field, or From: is no Reply-To field present) and you should be able to find it in the whois server immediately. Acks should be send to you within minutes. You can also delete objects in that test database, by simply adding a delete: line to an object. So, person: Marten Terpstra address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: marten at ripe.net nic-hdl: MT2 changed: marten at ripe.net 930503 source: RIPE delete: just try and delete this thing should delete this object in the database, if all fields are the same as in the database. The ordering of fields does not matter, just as long as attributes with the same name are in the same order, ie in the object above you cannot change the place of two "address:" fields. Also the place of the delete field does not matter, it can be anywhere in the object. Updating should be very quick, ack mails should be send to you within minutes. Please try some stuff and see what happens. Comments on the format of the ack mail are also appreciated. Currently verbose ack is default ie you get at least a one line ack per object you send in, and the full object if there were errors or warnings. If you send in objects with a source other than RIPE it should complain that this is an unknown source and should refuse the update. -Marten PS All requests are already properly logged so be careful with those deletes ;-) PPS The syntax checker for this test database is VERY strict, simply because there is no manual intervention from the NCC any longer. It may well be that existing objects in the real database are no longer accepted ;-) From Marten.Terpstra at ripe.net Mon Aug 16 14:20:57 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 16 Aug 1993 14:20:57 +0200 Subject: About the RIPE database software Message-ID: <9308161220.AA10703@ncc.ripe.net> Oops, Sorry people, the last message about the database software was supposed to have gone to the db-wg in stead of the dns-wg. Not that you cannot try the stuff if you do not want to, but still ... -Marten From Francis.Dupont at inria.fr Wed Aug 18 13:48:13 1993 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Wed, 18 Aug 1993 13:48:13 +0200 Subject: DNS WG at the 16th RIPE meeting Message-ID: <199308181148.AA27397@givry.inria.fr> I am collecting the ideas for the DNS WG agenda... Here are some elements: - a second root name server in Europe - IPng support (input needed from IPng (TUBA/SIP/PIP/TPIX) groups) - last BIND software (version 4.9.2 is still beta) Francis.Dupont at inria.fr From Daniel.Karrenberg at ripe.net Wed Aug 18 17:27:31 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 18 Aug 1993 17:27:31 +0200 Subject: DNS WG at the 16th RIPE meeting In-Reply-To: Your message of Wed, 18 Aug 1993 13:48:13 MET. <199308181148.AA27397@givry.inria.fr> Message-ID: <9308181527.AA18579@ncc.ripe.net> Short discussion on Piet's Internet draft? From rv at deins.informatik.uni-dortmund.de Tue Aug 24 15:28:55 1993 From: rv at deins.informatik.uni-dortmund.de (Ruediger Volk) Date: Tue, 24 Aug 1993 15:28:55 +0200 Subject: bogus info for root NS (broadcast addr!) Message-ID: <422.746198935@heinz.informatik.uni-dortmund.de> Dear colleagues, rather nasty bogus info for NS.NIC.DDN.MIL is spreading, and your host already got it: ; <<>> DiG 2.0 <<>> @nic.funet.fi NS.NIC.DDN.MIL. any ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 2, Addit: 2 ;; QUESTIONS: ;; NS.NIC.DDN.MIL, type = ANY, class = IN ;; ANSWERS: NS.NIC.DDN.MIL. 517916 A 192.112.36.4 NS.NIC.DDN.MIL. 131377 A 192.112.36.255 ;; AUTHORITY RECORDS: NIC.DDN.MIL. 205986 NS NIC.DDN.MIL. NIC.DDN.MIL. 205986 NS DIIS-DEV.DDN.MIL. ;; ADDITIONAL RECORDS: NIC.DDN.MIL. 205986 A 192.112.36.5 DIIS-DEV.DDN.MIL. 205986 A 192.112.38.89 ;; Sent 1 pkts, answer found in time: 1120 msec ;; FROM: heinz to SERVER: nic.funet.fi 128.214.6.100 ;; WHEN: Tue Aug 24 14:57:50 1993 ;; MSG SIZE sent: 32 rcvd: 144 (for servers of the other To; addressees please see trace at the bottom) We don't have yet an idea about the source for this; I would not be too surprised if some misconfigured server in Germany is the source - but as it already spread to Finland, probably warning should be distributed more widely. Any hints about possible sources for the bad A record would be appreciated. (so far I have only seen TTLs of upto 160000, and most in teh range of 130000) Best regards, Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB DE-NIC D-44221 Dortmund, Germany E-Mail: rv at Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386 ; <<>> DiG 2.0 <<>> @dfnnoc.GMD.DE NS.NIC.DDN.MIL. ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 8, Addit: 13 ;; QUESTIONS: ;; NS.NIC.DDN.MIL, type = A, class = IN ;; ANSWERS: NS.NIC.DDN.MIL. 494406 A 192.112.36.4 NS.NIC.DDN.MIL. 129880 A 192.112.36.255 ;; AUTHORITY RECORDS: . 494406 NS NS.INTERNIC.NET. . 494406 NS AOS.ARL.ARMY.MIL. . 494406 NS KAVA.NISC.SRI.COM. . 494406 NS C.NYSER.NET. . 494406 NS TERP.UMD.EDU. . 494406 NS NS.NASA.GOV. . 494406 NS NIC.NORDU.NET. . 494406 NS NS.NIC.DDN.MIL. ;; ADDITIONAL RECORDS: NS.INTERNIC.NET. 500936 A 198.41.0.4 AOS.ARL.ARMY.MIL. 517638 A 128.63.4.82 AOS.ARL.ARMY.MIL. 517638 A 192.5.25.82 AOS.ARL.ARMY.MIL. 32753 A 26.3.0.29 KAVA.NISC.SRI.COM. 500936 A 192.33.33.24 KAVA.NISC.SRI.COM. 86839 A 223.184.64.35 C.NYSER.NET. 500936 A 192.33.4.12 TERP.UMD.EDU. 500936 A 128.8.10.90 NS.NASA.GOV. 500936 A 128.102.16.10 NS.NASA.GOV. 500936 A 192.52.195.10 NIC.NORDU.NET. 500936 A 192.36.148.17 NS.NIC.DDN.MIL. 494406 A 192.112.36.4 NS.NIC.DDN.MIL. 129880 A 192.112.36.255 ;; Sent 1 pkts, answer found in time: 779 msec ;; FROM: heinz to SERVER: dfnnoc.GMD.DE 192.88.108.8 ;; WHEN: Tue Aug 24 15:22:53 1993 ;; MSG SIZE sent: 32 rcvd: 475 ; <<>> DiG 2.0 <<>> @deneb.dfn.de NS.NIC.DDN.MIL. ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 2, Addit: 2 ;; QUESTIONS: ;; NS.NIC.DDN.MIL, type = A, class = IN ;; ANSWERS: NS.NIC.DDN.MIL. 445700 A 192.112.36.4 NS.NIC.DDN.MIL. 129700 A 192.112.36.255 ;; AUTHORITY RECORDS: NIC.DDN.MIL. 166305 NS NIC.DDN.MIL. NIC.DDN.MIL. 166305 NS DIIS-DEV.DDN.MIL. ;; ADDITIONAL RECORDS: NIC.DDN.MIL. 166305 A 192.112.36.5 DIIS-DEV.DDN.MIL. 166305 A 192.112.38.89 ;; Sent 1 pkts, answer found in time: 579 msec ;; FROM: heinz to SERVER: deneb.dfn.de 192.76.176.9 ;; WHEN: Tue Aug 24 15:25:43 1993 ;; MSG SIZE sent: 32 rcvd: 144 From mea at nic.funet.fi Tue Aug 24 22:06:49 1993 From: mea at nic.funet.fi (Matti Aarnio) Date: Tue, 24 Aug 1993 23:06:49 +0300 Subject: bogus info for root NS (broadcast addr!) In-Reply-To: <422.746198935@heinz.informatik.uni-dortmund.de> from "Ruediger Volk" at Aug 24, 93 04:28:55 pm Message-ID: <93Aug24.230656eet_dst.91269-7@nic.funet.fi> > Dear colleagues, > > rather nasty bogus info for NS.NIC.DDN.MIL is spreading, and your host already > got it: Hello Ruediger, Try: dig -x 137.129.1.1 and then check your cache... Even though you seem to accept commonly happening faults in German DNS configurations, this one is in France... It took circa 30-40 minutes to get that fault to happen the first time after I restarted the dns server. Once I found that, French site, it is repeatable reliably :-( -- 5 minutes later, it seems I can't repeat that at all.. No, again... Now with "named -d 255", which gives somewhat more data.. There we are. Yes, we definitely get the contamination from 137.129.150.2 ( xdata.cnrm.meteo.fr, DNS manager: company at ctidev.cnrm.meteo.fr ) /Matti Aarnio Postmaster From nipper at xlink.net Wed Aug 25 09:15:37 1993 From: nipper at xlink.net (Arnold Nipper) Date: Wed, 25 Aug 93 9:15:37 MET DST Subject: bogus info for root NS (broadcast addr!) Message-ID: <"iraun1.ira.878:25.07.93.07.16.03"@ira.uka.de> >> Dear colleagues, >> >> rather nasty bogus info for NS.NIC.DDN.MIL is spreading, and your host already Please be aware that there is bogus info for KAVA.NISC.SRI.COM. as well. Please look for address 223.184.64.35 which is given for KAVA.NISC.SRI.COM in addition to 192.33.33.24. >> got it: > >Hello Ruediger, > > Try: dig -x 137.129.1.1 >and then check your cache... > >Even though you seem to accept commonly happening faults in German DNS >configurations, this one is in France... > >It took circa 30-40 minutes to get that fault to happen the first time >after I restarted the dns server. Once I found that, French site, it >is repeatable reliably :-( -- 5 minutes later, it seems I can't repeat >that at all.. No, again... Now with "named -d 255", which gives somewhat >more data.. There we are. > > Yes, we definitely get the contamination from 137.129.150.2 >( xdata.cnrm.meteo.fr, DNS manager: company at ctidev.cnrm.meteo.fr ) > I'm not quite sure whether this one is the origin of the bogus data. I just queried this host and it still has bogus data for NS.NIC.DDN.MIL and KAVA.NISC.SRI.COM. > > /Matti Aarnio Postmaster Arnold Nipper nipper at xlink.net XLINK Hostmaster