From bonito at nis.garr.it Wed Mar 20 10:41:12 1996 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Wed, 20 Mar 96 10:41:12 MET Subject: ripe23-dns draft minutes In-Reply-To: <199602201543.QAA05868@cuori.nis.garr.it>; from "Antonio_Blasco Bonito" at Feb 20, 96 4:43 pm Message-ID: <199603200941.KAA06046@cuori.nis.garr.it> Quoting from Antonio_Blasco Bonito's message: > > Hi folks, > > here are (thanks Carol!) the draft minutes of the last DNS working group. > You are encouraged in reading and reporting about any wrong or missing part. > Please do that before friday march 5th. I will then finalize the minutes. No answer received. Then this version is the final one. Blasco > > ---------- ---------- > Antonio-Blasco Bonito E-Mail: bonito at nis.garr.it > GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito > c/o CNUCE - Istituto del CNR Tel: +39 50 593246 > Via S. Maria, 36 Fax: +39 50 904052 > I-56126 PISA Telex: 500371 CNUCE I > Italy Url: http://www.nis.garr.it/nis/staff/bonito.html > ---------- ---------- > > ======================================================================= > DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT > > RIPE-23 dns-wg Meeting > > Monday, January 29, 1996 > 14.00 - 16:15 > > Chair: Antonio-Blasco Bonito > Scribe: Carol Orange > > Attended by 93 people (see below for the list) > > Agenda > ------ > > 1. Scribe > > 2. WG-agenda bashing > > 3. DNS Working Group chair needed > > 4. Status of 'in-addr.arpa' automatic checking and delegation > > 5. Status of the BIND software > > 6. Report of problems experienced > > 7. Report on European TLDs administrator's questionnaire > > 8. Delegation of International TLDs (Randy Bush) > > > ----------------------------------------------------------------- > > > 1. Scribe > > Carol Orange took notes. > > > 2. Agenda > > The agenda was agreed to without changes. > > > 3. DNS Working Group Chair > > Rob Blokzijl: > > + announced that the former DNS-WG chair (Leonid A. Yegoshin) had > to resign due to a change in both job and residence. > > + invited people to suggest candidates for the DNS working group > chair. > > Hopefully a new chair will be appointed during the next RIPE meeting. > > > 4. Status of 'in-addr.arpa' automatic checking and delegation > > David Kessens gave an update on the tool he created for > 'in-addr.arpa' automatic checking and delegation. His report > included the following information: > > To use the tool, one must: > + submit the appropriate RIPE database template > (inetnum or domain). > + send the template to . > The tool will: > + check the setup of the primary and secondary name servers. > + if no errors are detected, > forward request to human operator for final approval. > + report back to user. > The tool will *not*: > + check the relative location of servers. > + check whether the corresponding address space is allocated > or assigned. > + check whether /24's which fall under a /16 to be delegated, > have been delegated. > > The latest version has several software improvements including: > + a standardised output transaction format. > + tools for RIPE support staff to check what the tool does not > check (see above). > + a number of bug fixes. > > Currently under development: > + a tool to automatically update RIPE NCC zone files after > human approval. > > Plans to integrate the tool in RIPE database will mean: > + requests should be submitted to database with keyword. > + the RIPE database authentication mechanism will be used > to validate requests. > > The tool is available in: > + ftp://ftp.ripe.net/tools/inaddrcheck-960110.tar.gz > > Following David's report, the following discussion ensued. > > Documentation about reverse delegation procedures was requested. > David replied that the necessary information will be provided > in ripe-104++. > > Whether the automated mechanisms for inverse delegations > will work with IPv6 came up. There was some discussion as to > whether this is important given the slow progress of IPv6. However > it was also mentioned that as test beds are becoming operational, > these and other tools will be needed to support them. It is > expected that at most minor modifications to these mechanisms > will be required for use with IPv6. > > Randy Bush raised the issue of data integrity of DNS, and asked > whether steps are being taken to prevent corruption of the > inaddr.arpa name space delegated in Europe. After some discussion > on this topic, Randy said he has some tools available for > inspecting the integrity of DNS name space. Those interested > are welcome to contact him. > > This was followed by a discussion of how lame delegations come > into being and why they need to be cleaned up. It was pointed out > that the number of bad entries in the inaddr.arpa name space will > increase as renumbering goes in to effect. It was also mentioned > that currently the integrity of the European inaddr.arpa name > space data is quite good. > > > 5. Status of the BIND software > > Blasco Bonito announced that a the final version of Bind 4.9.3 has been > released. > > Geert Jan de Groot recommended using the "no recursion" option > available in version 4.9.3 to prevent data pollution, and to control > data sizes. This is useful if resources are limited. > > ** Action: Geert Jan offered to write up recommendations for managing > large databases. > > Finally, Randy Bush reported that a new version of TGV is available > for VMS users. Their new release contains, among much other stuff, > a modern version of BIND with all the recent improvements > (performance, security, etc). Folks should be strongly encouraged > to upgrade. By the way, TGV was recently bought by cisco. > > > 6. Report of problems experienced > > There have been some problems with the delegation of TLD names > under non TLD domains. For example, someone recently delegated > the name sgi.net.co.uk. The result is that sgi.com couldn't be > resolved anymore when using some old resolvers. As a large number > of similar names were generated, the DNS name space became > severely polluted, and it took two days to clear it up. > > According to Geert Jan, the problem is caused in part by old > bind software, which in accordance with RFC1535 should no longer > be used, but in practice is. > > Guy Davis says that in the UK, delegation of top level domain names > under TLD's (e.g. net.uk) will no longer be permitted. > > It was reported that this is already the case in other countries > (i.e. Germany, Italy, ...) and that DNS second level administrators > are also discouraged from allowing top level domain names to be used. > > There was some discussion as to whether the problem should be > solved by getting administrators to replace old resolver software > or by getting them to abstain from delegating TLD names. In the > end, there was consensus that the problem should be tackled as > a combined effort. > > It was mentioned again that the security issues are discussed in > RFC-1535 and that DNS administrators should be reminded to review > that document carefully. > > 7. Report on European TLDs administrator's questionnaire > > Guy Davis reported on a questionnaire he sent out to European TLD > administrators. The questionnaire was designed to determine the > policies used in DNS delegations by the TLD administrators. A > summary of the report he presented follows. Anyone interested in > the full set of information gathered can send a request to > . > > > DNS TLD - Questionnaire > > - 22 response for 24 top level domains > - Full set of answers available on request > > email: guyd at pipex.net > > EDITED HIGHLIGHTS > > 1. Who defines your policies? > Org Running TLD - 15 1/2 > The Government - 1 1/2 > ISPs by consensus - 4 > > 2. How do you establish your policies? > By Working Group - 2 > Told by Govt. - 1 1/2 > Decided by Org Running TLD - 7 1/2 > ISPs by Concencus - 10 > > 3. What Legal Status do your decisions/policies have? > None - 19 1/2 > As defined by Govt. - 1 1/2 > > 4a Public Subdomains? > Yes - 7 > No - 15 > > b Geographic Subdomains? > Yes - 6 > No - 16 > > c 2nd level categories (private & public) in parallel? > Yes - 6 > No - 16 > > d If you have public subdomains must everybodies request be accepted? > Yes - 7 > N/A - 15 > > e How would you split your TLD > See full listing - 6 > N/A - 16 > > 5a Sub. TLD? > Yes - 20 > No -2 > > b Sub. public TLD? > Yes - 7 > No - 15 > > 6a Who can obtain domains? > Anyone - 11 > Just Orgs - 11 > > 8 Must the requester be local? > Yes - 16 > No - 6 > > 9a More than one domain per Org. ? > Yes - 12 > No - 10 > > 17a Do you charge ? > Yes - 5 > No - 16 > > 19 Are you likely to change the system within 12 months? > Yes - 14 > No - 5 > Don't know - 3 > > 22 Do you use automation? > Yes - 11 > No - 11 > > After Guy's presentation of the above data, a discussion started > regarding the charging fees and schedules. Most TLD administrators > presently don't charge, but are thinking about doing so to cover > their costs. Among those who do charge, some have only a one time > fee, and some have a yearly administration fee. > > There does not appear to be competition among the national TLD > administrators. Moreover, running a TLD is primarily performed as > a nonprofit service to the Internet community. > > Blasco suggested a need for better coordination among TLD > administrators, so they can consult one another on technical and > policy matters. It was pointed out that this does not mean they > will all follow the same policy. > > The question was raised as to whether some private forum for > communication among TLD administrators should be created, so they > can exchange information easily. > > Whether or not 2nd level domain administrators might be included in > the "private" communication was considered. > > ** Action: Daniel offered that the RIPE NCC will set up a mailing list > for TLD administrators. > > A need was also expressed that the policies of TLD administrators > be made public. > > ** Action: The RIPE NCC will incorporate a page where TLD policies > can be published at its WWW site. > > It was suggested the questionnaire be repeated in 6 months so that > changes in policy can be monitored. > > 8. Delegation of International TLDs (Randy Bush) > > Randy Bush explained that there is a lot of talk in the US at the > moment about whether and why new TLD's should be created. > International TLD's are com, org & net. The main reason for > expanding these is to create healthy competition in the market. > Also, the US government (NSF here) wants to be out of the IP and > DNS delegation business. > > Randy also presented a set of guidelines that should be used in > determining whether a new TLD can be created. > > There was some discussion as to whether or not names should be > used for profit. Also, whether a white pages service (which is what > DNS provides) is sufficient, or whether we should start looking > into yellow page models for directory services. > > Back to the name space: it is perceived that the US wants to > control the name space. Who gave them the right to edu, mil, and > gov? Basically, it was stated that the US came up with those names, > so they have a right to them. Still the process remains unclear. > > Piet Beertema said the US should use the extension "us" just as other > countries use country extensions. > > Randy then summarised the proposal they are submitting to slowly > expand the number of TLD's. The number of TLD's would be increased > at a rate of about 3-5 per year. Basically, anyone suggesting a new > domain should argue that it will serve some purpose that none of the > currently existing TLD's do, and agree that it will be managed > responsibly following the guidelines agreed to in RFC1591 (as well > as some new ones: nondiscrimination policies, appeals procedures, > etc.). > > Piet B. pointed out that those changes only generate a false sense > of order in the chaos. The new policies only apply to new TLD's, not > to the old ones. No similar restrictions are applied to second > level domain administrators. > > Mike Norris pointed out that DNS administration is experienced as a > public service in Europe. > > Randy said that "com" on the other hand is turning into a high > profit monopoly, and the new suggestions are intended to curb its power. > > A discussion surrounding the trademark wars surrounding domain names > started up. Should the names be delegated on a "first come, first > served" or should DNS administrators be required to control > trademarks. > > Back to the issue as to whether new TLD's should be created: > > It was suggested that whereas the US TLD's fall under ".", they > should be placed under "us" (e.g. com.us, mil.us, edu.us, etc). > In other words, the problems surrounding "name for profit" monopolies > are US based, and should be solved there. To clarify, this Randy asked > the audience whether they should be removed from the root. There was > general consesus about that. > > That was about it for the DNS working group. > > > Attendees list > -------------- > Antonio-Blasco Bonito GARR-NIS > Rob Blokzijl RIPE > Jiri Orsag Eunet CZ > Jan HrJonka -U- > Kurt Kayser ECRC > Marc Pichon TRANSPAC > Bernard Tuy CNRS / UREC > Arnold Nipper NIG/Xlink > Elise Gerich Merit > Havard Eidnes NORDUnet/Uninett > Alfons Friedl SERVICOM > Dirk Pantring DENIC > Sabine Dolderer DENIC > Guy Davies Unipalm PIPEX > Lars-Johan Liman Ebone NOC > Geert Jan de Groot RIPE NCC > Hans Petter Holen SCHIBSTED NETT AS > Ivan Sedinic HPT - Croatian Post and Teleco > Stephan Biesbroeck BELNET > Christophe Huygens Katholieke Universiteit Leuven > Sean Doran Sprint > Els Willems RIPE NCC > Randy Bush > Michel Colin Brussels University/Service Te > Steve Druck TERENA > Ariel T. Sobelman TERENA > Hatice Kuey RIPE NCC > John Crain RIPE NCC > Johannes 5 Joemann Object Factory GmbH > Oliver Mandischer Object Factory GmbH > ??? RENATER > Paul Rolland Oleane > Ireneusz Neska NASK > Simon Cavendish EuroNet Internet > Erwin Blekkenhorst EuroNet Internet > Astrid Nijenhuis EuroNet Internet > ??? A. Vrivine SKYWORLD > Ivan Communod FTNSNL > Alina Dodescu Research Institute for Informa > Jan-Pieter Cornet NL.XS4ALL > Erik Bos nl.xs4all > Cor Bosman XS4ALL > Kimmo Kosonen Telecom Finland > Jarmo Oksanen Telecom Finland > Willi Huber SWITCH > Per Mattsson Unisource Business Networks > Hakan Hansson Unisource Business Networks > Harm Werkman Unisource Business Networks NL > Geza Turchanyi INFO-C > Nick Shield UKERNA/JANET > Kevin Hoadley ULCC/JANET > Asquith Bonaparte JANET NOSC > Bettina Kauth DFN-NOC > Steven Bakker DANTE > Daniele Bovio America OnLine > Vaclav Novak CESNET > Tomas Marsalek GTS CzechCom > Juergen Rauschenbach DFN > Anne Lord PIPEX International > Stef Van Dessel INnet > Magnus Danielson KTH > Nigel Titley BTnet > Giovanni Armanino GARR-NIS > Piet Beertema CWI/NL TLD registry > Francis Dupont INRIA > Wilfried Woeber VUCC / ACOnet > Tibor Weis SANET - Slovakia > Barbara Dooley CIX > Frank Slyne Telecom Eireann > Oliver Smith Demon Internet > Cliff Stanford Demon Internet Limited > Dusan Keprta EuroTel Bratislava Ltd. > Pavel Mikus EuroTel Bratislava Ltd. > Oliver Doll EUnet Deutschland GmbH > Janos Zsako BankNet > Pulak Rakshit Cable Online > Javed Mirza Cable Online > Holger Weinhardt EUnet Deutschland GmbH > Balazs Martos HUNGARNET > Janos Bajza HUNGARNET > Ton Windgassen= IBM Global Network Europe= > Carol Orange RIPE NCC > Daniel Karrenberg RIPE NCC > Bill Cessna IBM Global Network > Matt Fakray IBM Global Network > Helena Svensson Tele2 / SWIPnet > Armando Domingues FCCN/RCCN > Graca Carvalho FCCN/RCCN > Miguel Sanz RedIRIS > Ruediger Volk Deutsche Telekom > Hans Frese DESY > Elisabetta Ghermandi I.N.F.N. - CNAF > Rushdul Mannan Xara Networks Ltd > > DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT > ======================================================================= > -- ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito at nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 50 593246 Via S. Maria, 36 Fax: +39 50 904052 I-56126 PISA Telex: 500371 CNUCE I Italy Url: http://www.nis.garr.it/nis/staff/bonito.html ---------- ---------- From GeertJan.deGroot at ripe.net Sun Mar 24 15:44:43 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Sun, 24 Mar 1996 15:44:43 +0100 Subject: Can I have a look at your named cache please? Message-ID: <9603241444.AA26404@ncc.ripe.net> Hi, ns.ripe.net is stormed with IN A requests for @.root-servers.net. It looks like this isn't an isolated incident; I received similar reports from one of the other nameservers of root-servers.net. Given the intensity of the incident (we get 2 times as much requests on this than all other requests combined), I don't believe this is caused by a single bitflip somewhere. It would be real nice if the maintainers of some 'popular' caching nameservers would do a cache dump (kill -INT named), look if @.root-servers.net is listed somewhere, and send me the details if you find it in your cache. Thanks, Geert Jan From bilse at EU.net Sun Mar 24 16:24:31 1996 From: bilse at EU.net (Per Gregers Bilse) Date: Sun, 24 Mar 1996 16:24:31 +0100 Subject: Can I have a look at your named cache please? In-Reply-To: <9603241444.AA26404@ncc.ripe.net> Message-ID: <199603241524.AA20242@jotun.EU.net> On Mar 24, 15:44, Geert Jan de Groot wrote: > It would be real nice if the maintainers of some 'popular' > caching nameservers would do a cache dump (kill -INT named), > look if @.root-servers.net is listed somewhere, and send me the > details if you find it in your cache. I guess this is what you're looking for: com 463260 IN NS E.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 463260 IN NS I.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 463260 IN NS F.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 463260 IN NS G.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 463260 IN NS A.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 463260 IN NS H.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 463260 IN NS B.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 463260 IN NS C.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 463260 IN NS D.ROOT-SERVERS.net. ;Cr=addtnl [199.245.73.2] 203729 IN NS @.ROOT-SERVERS.net. ;Cr=addtnl [192.94.214.100] 337532 IN NS I.ROOT-SERVERS.LET. ;Cr=addtnl [198.71.19.35] 337532 IN NS F.ROOT-SERVERS.LET. ;Cr=addtnl [198.71.19.35] 337532 IN NS G.ROOT-SERVERS.LET. ;Cr=addtnl [198.71.19.35] 337532 IN NS A.ROOT-SERVERS.LET. ;Cr=addtnl [198.71.19.35] 337528 IN NS H.ROOT-SERVERS.LET. ;Cr=addtnl [198.71.19.35] 297856 IN NS F.I.ROOT-SERVERS.NET. ;Cr=addtnl [198.71.19.34] 83517 IN SOA A.ROOT-SERVERS.NET. HOSTMASTER.INTERNIC.NET. ( 1996032200 10800 900 604800 86400 ) ;Cr=addtnl [192.36.148.17] jotun.EU.net% dig @192.94.214.100 com. ns ; <<>> DiG 2.0 <<>> @192.94.214.100 com. ns ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr rd ra ; Ques: 1, Ans: 15, Auth: 0, Addit: 9 ;; QUESTIONS: ;; com, type = NS, class = IN ;; ANSWERS: com. 392808 NS F.ROOT-SERVERS.net. com. 392808 NS G.ROOT-SERVERS.net. com. 392808 NS A.ROOT-SERVERS.net. com. 392808 NS H.ROOT-SERVERS.net. com. 392808 NS B.ROOT-SERVERS.net. com. 392808 NS C.ROOT-SERVERS.net. com. 392808 NS D.ROOT-SERVERS.net. com. 182865 NS @.ROOT-SERVERS.net. com. 267814 NS F.I.ROOT-SERVERS.net. com. 303622 NS I.ROOT-SERVERS.LET. com. 303622 NS F.ROOT-SERVERS.LET. com. 303622 NS G.ROOT-SERVERS.LET. com. 303622 NS A.ROOT-SERVERS.LET. com. 392808 NS E.ROOT-SERVERS.net. com. 392808 NS I.ROOT-SERVERS.net. ;; ADDITIONAL RECORDS: F.ROOT-SERVERS.net. 156342 A 192.5.5.241 G.ROOT-SERVERS.net. 217670 A 192.112.36.4 A.ROOT-SERVERS.net. 38853 A 198.41.0.4 H.ROOT-SERVERS.net. 604534 A 128.63.2.53 B.ROOT-SERVERS.net. 441895 A 128.9.0.107 C.ROOT-SERVERS.net. 442792 A 192.33.4.12 D.ROOT-SERVERS.net. 348963 A 128.8.10.90 E.ROOT-SERVERS.net. 301944 A 192.203.230.10 I.ROOT-SERVERS.net. 442726 A 192.36.148.17 ;; Sent 1 pkts, answer found in time: 120 msec ;; FROM: jotun.EU.net to SERVER: 192.94.214.100 ;; WHEN: Sun Mar 24 16:13:07 1996 ;; MSG SIZE sent: 21 rcvd: 437 jotun.EU.net% host 192.94.214.100 Name: relay.tis.com Address: 192.94.214.100 jotun.EU.net% The amount of crap floating around in DNS space is actually quite disconcerting. Let's just pick one of the sources shown above: jotun.EU.net% host 199.245.73.2 Name: ns2.MainStreet.Net Address: 199.245.73.2 jotun.EU.net% dig @199.245.73.2 . ns ; <<>> DiG 2.0 <<>> @199.245.73.2 . ns ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr rd ra ; Ques: 1, Ans: 9, Auth: 0, Addit: 15 ;; QUESTIONS: ;; ., type = NS, class = IN ;; ANSWERS: . 517076 NS H.ROOT-SERVERS.NET. . 517076 NS B.ROOT-SERVERS.NET. . 517076 NS C.ROOT-SERVERS.NET. . 517076 NS D.ROOT-SERVERS.NET. . 517076 NS E.ROOT-SERVERS.NET. . 517076 NS I.ROOT-SERVERS.NET. . 517076 NS F.ROOT-SERVERS.NET. . 517076 NS G.ROOT-SERVERS.NET. . 517076 NS A.ROOT-SERVERS.NET. ;; ADDITIONAL RECORDS: H.ROOT-SERVERS.NET. 577657 A 128.63.2.53 B.ROOT-SERVERS.NET. 577657 A 128.9.0.107 B.ROOT-SERVERS.NET. 203240 A 128.9.0.0 C.ROOT-SERVERS.NET. 442285 A 192.33.4.12 D.ROOT-SERVERS.NET. 577657 A 128.8.10.90 D.ROOT-SERVERS.NET. 39628 A 192.5.5.241 D.ROOT-SERVERS.NET. 254525 A 128.8.10.88 E.ROOT-SERVERS.NET. 577657 A 192.203.230.10 E.ROOT-SERVERS.NET. 175214 A 224.203.230.10 E.ROOT-SERVERS.NET. 310335 A 192.201.230.10 E.ROOT-SERVERS.NET. 164163 A 192.203.228.10 I.ROOT-SERVERS.NET. 577657 A 192.36.148.17 F.ROOT-SERVERS.NET. 519502 A 192.5.5.241 G.ROOT-SERVERS.NET. 521347 A 192.112.36.4 A.ROOT-SERVERS.NET. 577657 A 198.41.0.4 ;; Sent 1 pkts, answer found in time: 224 msec ;; FROM: jotun.EU.net to SERVER: 199.245.73.2 ;; WHEN: Sun Mar 24 16:16:05 1996 ;; MSG SIZE sent: 17 rcvd: 408 jotun.EU.net% OK, what's that with D.ROOT-SERVERS.NET, three addresses? jotun.EU.net% host 192.5.5.241 Name: f.root-servers.net Address: 192.5.5.241 jotun.EU.net% host 128.8.10.90 Name: d.root-servers.net Address: 128.8.10.90 jotun.EU.net% host 128.8.10.88 128.8.10.88 does not exist (Authoritative answer) jotun.EU.net% trc 128.8.10.88 traceroute to 128.8.10.88 (128.8.10.88), 30 hops max, 40 byte packets 1 Amsterdam2.NL.EU.net (193.242.90.1) 2 ms 3 ms 2 ms 2 Amsterdam5.NL.EU.net (134.222.85.5) 3 ms 3 ms 2 ms 3 Vienna2.VA.US.EU.net (134.222.228.18) 86 ms 89 ms 91 ms 4 mae-east.digex.net (192.41.177.115) 98 ms 104 ms 97 ms 5 core1-hssi-2.us.dca.digex.net (206.205.246.1) 92 ms 88 ms 87 ms 6 umd-gate.digex.net (206.205.243.2) 106 ms 96 ms 113 ms 7 csc2gw-f0.umd.edu (128.8.1.225) 111 ms 90 ms 100 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * csc2gw-f0.umd.edu (128.8.1.225) 101 ms !H 15 * * csc2gw-f0.umd.edu (128.8.1.225) 91 ms !H Or E.ROOT-SERVERS.NET? jotun.EU.net% host 192.203.230.10 Name: E.ROOT-SERVERS.NET Address: 192.203.230.10 jotun.EU.net% host 192.201.230.10 192.201.230.10 does not exist (Authoritative answer) jotun.EU.net% trc 192.201.230.10 traceroute to 192.201.230.10 (192.201.230.10), 30 hops max, 40 byte packets 1 Amsterdam2.NL.EU.net (193.242.90.1) 4 ms 3 ms 2 ms 2 Amsterdam5.NL.EU.net (134.222.85.5) 3 ms 5 ms 3 ms 3 Amsterdam5.NL.EU.net (134.222.85.5) 6 ms !H * * 4 Amsterdam5.NL.EU.net (134.222.85.5) 6 ms !H * 12 ms !H jotun.EU.net% host 192.203.228.10 192.203.228.10 does not exist (Authoritative answer) jotun.EU.net% trc 192.203.228.10 traceroute to 192.203.228.10 (192.203.228.10), 30 hops max, 40 byte packets 1 Amsterdam2.NL.EU.net (193.242.90.1) 2 ms 2 ms 2 ms 2 Amsterdam5.NL.EU.net (134.222.85.5) 2 ms 3 ms 3 ms 3 Vienna2.VA.US.EU.net (134.222.228.18) 93 ms 85 ms 92 ms 4 mae-east-plusplus.washington.mci.net (192.41.177.181) 337 ms 134 ms 160 ms 5 borderx1-hssi2-0.Washington.mci.net (204.70.74.101) 127 ms 114 ms 98 ms 6 core-fddi-0.Washington.mci.net (204.70.2.1) 92 ms 127 ms 127 ms 7 core1-hssi-4.LosAngeles.mci.net (204.70.1.177) 244 ms 269 ms 310 ms 8 border3-fddi-0.LosAngeles.mci.net (204.70.170.19) 340 ms 281 ms 312 ms 9 telstra-internet.LosAngeles.mci.net (204.70.173.6) 498 ms 587 ms 544 ms 10 Fddi0-0.pad-core1.Sydney.telstra.net (139.130.249.226) 716 ms 441 ms 510 ms 11 Serial4-2.wel-core1.Perth.telstra.net (139.130.238.1) 526 ms 630 ms 599 ms 12 Fddi0-0.wel1.Perth.telstra.net (139.130.238.227) 680 ms 619 ms 699 ms 13 frontdoor.DIALix.COM (192.203.228.4) 728 ms frontdoor2.DIALix.COM (192.203.228.6) 682 ms frontdoor.DIALix.COM (192.203.228.4) 634 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * Not to mention 224.203.230.10 .... -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse at EU.net From Havard.Eidnes at runit.sintef.no Sun Mar 24 16:29:47 1996 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Sun, 24 Mar 1996 16:29:47 +0100 Subject: Can I have a look at your named cache please? In-Reply-To: Your message of "Sun, 24 Mar 1996 15:44:43 +0100" References: <9603241444.AA26404@ncc.ripe.net> Message-ID: <199603241529.QAA07429@vader.runit.sintef.no> Hi, the relevant things I find are on aun.uninett.no (nothing much interesting): $ORIGIN ROOT-SERVERS.net. ;@ 548 IN A NXDOMAIN ;-$ ;[193.0.0.193] A 38874 IN A 198.41.0.4 ;NT=112 Cr=auth [193.0.0.193] B 444608 IN A 128.9.0.107 ;NT=136 Cr=auth [193.0.0.193] C 445485 IN A 192.33.4.12 ;NT=1361 Cr=auth [193.0.0.193] D 451625 IN A 128.8.10.90 ;NT=245 Cr=auth [193.0.0.193] E 574845 IN A 192.203.230.10 ;NT=483 Cr=auth [193.0.0.193] F 156088 IN A 192.5.5.241 ;NT=245 Cr=auth [198.41.0.5] G 477455 IN A 192.112.36.4 ;NT=92 Cr=auth [193.0.0.193] H 437295 IN A 128.63.2.53 ;NT=225 Cr=auth [193.0.0.193] I 442643 IN A 192.36.148.17 ;NT=71 Cr=auth [193.0.0.193] However, on runix.runit.sintef.no I find: COM 461985 IN NS B.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 461985 IN NS C.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 461985 IN NS D.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 461985 IN NS E.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 461985 IN NS I.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 461985 IN NS F.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 461985 IN NS G.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 461985 IN NS A.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 461985 IN NS H.ROOT-SERVERS.NET. ;Cr=addtnl [198.6.197.1] 202438 IN NS @.ROOT-SERVERS.NET. ;Cr=addtnl [204.96.68.1] 77368 IN SOA A.ROOT-SERVERS.NET. HOSTMASTER.INTERNIC.NET. ( 1996032200 10800 900 604800 86400 ) ;Cr=addtnl [192.36.148.17] 296566 IN NS F.I.ROOT-SERVERS.net. ;Cr=addtnl [198.6.197.1] 336242 IN NS I.ROOT-SERVERS.LET. ;Cr=addtnl [198.6.197.1] 336242 IN NS F.ROOT-SERVERS.LET. ;Cr=addtnl [198.6.197.1] 336242 IN NS G.ROOT-SERVERS.LET. ;Cr=addtnl [198.6.197.1] 336242 IN NS A.ROOT-SERVERS.LET. ;Cr=addtnl [198.6.197.1] Not good at all. 204.96.68.1 is olympic.pacificrim.net. It appears to be running 4.9.3, and does not appear to be the source of the bad data. 198.6.197.1 is unregistered (it's located somewhere behind net99.net and cais.net). It also appears to be running a recent version of BIND and does also not appear to be the source of the bad data. This looks suspiciuosly like the ns.uu.net fun, and my bet is that it will be real difficult to track down the real source of this bogus information. - Havard From rv at zeus.NIC.DTAG.DE Sun Mar 24 17:34:27 1996 From: rv at zeus.NIC.DTAG.DE (Ruediger Volk) Date: Sun, 24 Mar 1996 17:34:27 +0100 Subject: Can I have a look at your named cache please? In-Reply-To: Your message of "Sun, 24 Mar 1996 15:44:43 +0100." <9603241444.AA26404@ncc.ripe.net> Message-ID: <22178.827685267@zeus.NIC.DTAG.DE> > ns.ripe.net is stormed with IN A requests for @.root-servers.net. > It looks like this isn't an isolated incident; I received > similar reports from one of the other nameservers of root-servers.net. > > Given the intensity of the incident (we get 2 times as much requests > on this than all other requests combined), I don't believe this is > caused by a single bitflip somewhere. > > It would be real nice if the maintainers of some 'popular' > caching nameservers would do a cache dump (kill -INT named), > look if @.root-servers.net is listed somewhere, and send me the > details if you find it in your cache. Our cache contains this: COM 203144 IN NS D.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 203144 IN NS E.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 203144 IN NS I.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 203144 IN NS F.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 203144 IN NS G.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 203144 IN NS A.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 203144 IN NS H.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 203144 IN NS B.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 101382 IN NS @.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 149719 IN NS F.I.ROOT-SERVERS.NET. ;Cr=addtnl [204.97.64.4] 170086 IN NS I.ROOT-SERVERS.LET. ;Cr=addtnl [204.97.64.4] 170086 IN NS F.ROOT-SERVERS.LET. ;Cr=addtnl [204.97.64.4] 170086 IN NS G.ROOT-SERVERS.LET. ;Cr=addtnl [204.97.64.4] 170086 IN NS A.ROOT-SERVERS.LET. ;Cr=addtnl [204.97.64.4] 203144 IN NS C.ROOT-SERVERS.NET. ;Cr=addtnl [206.96.248.2] 86158 IN SOA A.ROOT-SERVERS.NET. HOSTMASTER.INTERNIC.NET. ( 1996032200 10800 900 604800 86400 ) ;Cr=addtnl [192.203.230.10] BTW please don't miss the nasty NS references to [AFGI].ROOT-SERVERS.LET (LLLLLLLLet instead of NNNNNNNNNet) that we cached in addtition to F.I.ROOT-SERVERS.NET due to info from 204.97.64.4 (though it's present at 204.97.64.4 as well) Ruediger Volk ### this .signature is currently under construction ### Deutsche Telekom AG -- Internet Services NIC E-Mail: rv at NIC.DTAG.DE From mrr at eunet.no Mon Mar 25 09:20:17 1996 From: mrr at eunet.no (Morten Reistad) Date: Mon, 25 Mar 1996 09:20:17 +0100 Subject: Can I have a look at your named cache please? In-Reply-To: Your message of "Sun, 24 Mar 1996 15:44:43 +0100." <9603241444.AA26404@ncc.ripe.net> Message-ID: <199603250820.JAA14838@kirov.eunet.no> I couldn't see anything weird; but I left a copy of the dump as ftp://ftp.eunet.no/pub/named_dump.960225.gz This is a dump from relay.eunet.no, it keeps track of a lot of domains, and may not be active. It IS used as nameserver by a lot of customers, we get around 80 requests a second. ___ === / / / __ ___ _/_ === Morten Reistad === /--- / / / / /__/ / === Technical Manager === /___ /__/ / / /__ / === EUnet Norway AS === Connecting Europe since 1982 === phone +47 8100 0001 ext 206 From GeertJan.deGroot at ripe.net Sun Mar 31 04:16:15 1996 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Sun, 31 Mar 1996 04:16:15 +0200 Subject: DNS and UDP checksumming Message-ID: <9603310216.AA17458@ncc.ripe.net> Hi folks, Increasingly I get reports on bogus DNS records that are apperently caused by bitflips, possibly caused by bad lines and line protocols without error detection. The UDP protocol does not protect against this as the base spec does not require checksumming; a packet without checksum normally gets accepted and its poisenous contents processed by the DNS system. Of course, the best thing to do is to have everybody generate and verify checksums, but this is hard to change now because of the installed base. To the best of my knowledge, the only wide-spread platform that does not do UDP checksumming by default is 'solaris classic' aka SunOs. Even for this platform, enabling UDP checksumming is a simple command. The impact of this bogus information is obviously quite severe and once a bogus record is inserted, it does not die immediately but may stay in the caches for quite some time. RFC1122 (4.1.3.4) keeps the possibility open that apps ignore UDP packets that do not have checksums on them. On BSD-deratives this is hard to verify since the checksum of a packet is not easily obtained. However, it seems quite simple to modify a BSD-kernel to ignore all UDP packets without checksum; yielding the same result. I'm wondering if the RIPE community would concider this acceptable behaviour - it would mean that a host which doesn't do checksumming, will not be able to talk to one which enforces it. This obviously helps to get the message across, the same way as valid reverse lookup mapping for access to many FTP sites is an incentive for people to make their reverse lookup mapping work. What does the DNS working group think on this matter? Geert Jan From Francis.Dupont at inria.fr Sun Mar 31 14:49:54 1996 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Sun, 31 Mar 1996 14:49:54 +0200 Subject: DNS and UDP checksumming In-Reply-To: Your message of Sun, 31 Mar 1996 04:16:15 +0200. <9603310216.AA17458@ncc.ripe.net> Message-ID: <199603311249.OAA04223@givry.inria.fr> Benoit Grange when he was a member of NIC France has written a small test program which can easily detect DNS servers without proper UDP checksumming. With it we can complain when a new server is installed without checksumming... I believe we can't really banish all the sites without checksumming today then we must follow the standard path (educate them, point to them, ...). Regards Francis.Dupont at inria.fr PS: another stupid problem is too low TTLs.