- dns-wg - mailman.ripe.net

Can I have a look at your named cache please?
by Geert Jan de Groot 25 Mar '96

25 Mar '96

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

4 3

Re: Can I have a look at your named cache please?
by Havard.Eidnes＠runit.sintef.no 24 Mar '96

24 Mar '96

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

1 0

ripe23-dns draft minutes
by Antonio_Blasco Bonito 20 Mar '96

20 Mar '96

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. ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito(a)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 <auto-inaddr(a)ripe.net>. 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 <guyd(a)pipex.net>. DNS TLD - Questionnaire - 22 response for 24 top level domains - Full set of answers available on request email: guyd(a)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 =======================================================================

1 1

New mailing list: tld-admin@ripe.net
by Geert Jan de Groot 01 Feb '96

01 Feb '96

As requested at the last RIPE meeting, I have set up a new mailing list for TLD administrators: tld-admin(a)ripe.net. This is a closed mailing list; per request of the WG, only people who are maintaining a TLD are allowed to subscribe. As we need to verify requestor's affiliation, please send subscription requests to tld-admin-request(a)ripe.net including the name of the TLD you are administering. Please keep in mind that we need to verify things by hand and therefore some time may lapse processing requests. The maillist is archived, but again only privately so if you need a copy of the archive, please ask tld-admin-request(a)ripe.net. I'd like the TLD-admins to consider if they feel it is a good idea that the parties listed in RFC1591 (IANA, APNIC, InterNIC and RIPE NCC) are also allowed to subscribe or if the list should be restricted to TLD admins only. Let's party! Geert Jan

1 0

ZoneCheck sources are available
by Benoit Grange 28 Jan '96

28 Jan '96

As I promised at the last RIPE meeting in Amsterdam, the sources of the current version of Zone Check are available. Zone check is a tool that I created while I was working at the french Network Information Center. It checks that a domain matches some criterias and can be added successfully into the DNS. Zone Check has a WWW interface and is used with a forms capable WWW browser (any current browser can do this). Sources and more information are available at http://www.nic.fr/ZoneCheck/sources.html - Benoit Grange

1 0

DNS-WG agenda update
by Antonio_Blasco Bonito 26 Jan '96

26 Jan '96

RIPE 23 DNS Working Group Amsterdam Monday 29 January 1996 14:00 - 15:30 Chairman: Antonio-Blasco Bonito (substituting Leonid A.Yegoshin) Proposed draft agenda --------------------- 1) Administrative stuff - volunteering of the scribe - WG-agenda bashing 2) status of 'in-addr.arpa' automatic checking and delegation (RIPE-NCC) 3) status of the BIND software ( who? ) 3) report of experienced problems (anybody) - Problems experienced in the UK dns when a TLD was delegated as a subdomain of co.uk. (Guy Davies) 4) Report on European TLDs administrators questionnaire (Guy Davies) 5) Delegation of International Top Level Domains [iTLDs] (Randy Bush) suggested reading ftp://ftp.ripe.net/internet-drafts/draft-ymbk-itld-admin-00.txt 6) Discussion 7) AOB ---------- ---------- Antonio-Blasco Bonito E-Mail: bonito(a)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 ---------- ----------

1 0

RIPE23 DNS-WG proposed agenda
by Antonio_Blasco Bonito 26 Jan '96

26 Jan '96

Folks, I've been asked by the RIPE-NCC meeting organizers to substitute, once again, Leonid Yegoshin, who is not coming in Amsterdam, as the Working Group chairman. I've prepared the draft agenda below. Please propose adds/mods. RIPE 23 DNS Working Group Amsterdam 30 January 1996 Chairman: Antonio-Blasco Bonito (substituting Leonid A.Yegoshin) Proposed draft agenda --------------------- 1) Administrative stuff - volunteering of the scribe - WG-agenda bashing 2) status of 'in-addr.arpa' automatic checking and delegation (RIPE-NCC) 3) status of the BIND software ( who? ) 3) report of experienced problems (anybody) 4) Report on European TLDs administrators questionnaire (Guy Davies) 5) Delegation of International Top Level Domains [iTLDs] (Randy Bush) 6) Discussion 7) AOB ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)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 ---------- ----------

4 4

New version of the reverse delegation checking tool
by RIPE NCC IN-ADDR. ARPA Role Account 30 Nov '95

30 Nov '95

Dear all, This is the newest version of the reverse delegation tool that we use at the RIPE NCC for checking your reverse delegation requests. A lot has been changed. The program is now split into functional components and a common output format has been defined to be able to let it work together with your own tool that can update your zone files. Still missing is a back-end that actually updates your zone files. Furthermore, it can not check if nameservers are at the same ethernet. The most recent version will always be available at our ftp server: ftp://ftp.ripe.net/tools/inaddrtool-DATE.tar.gz Of course comments and bug reports are welcome and can be send to: <inaddr(a)ripe.net> Kind regards, David Kessens RIPE NCC -------- README for the inaddrtool Date: 951130 Author: David Kessens, RIPE NCC NOTE: PLEASE USE THE NORMAL PROCEDURE AS DESCRIBED IN RIPE-105 IF YOU WANT TO DO A REVERSE DELEGATION REQUEST FOR A REVERSE DOMAIN MANAGED BY THE RIPE NCC, BUT SEND YOUR REQUEST TO <AUTO-INADDR(a)RIPE.NET> INSTEAD OF <HOSTMASTER(a)RIPE.NET> Reverse delegation checking tool -------------------------------- As of today the RIPE NCC offers an automated method for the submission of reverse zone delegations in 193.in-addr.arpa and 194.in-addr.arpa. The reverse delegation requests and the zone files on all nameservers will be checked automatically. The diagnostics generated by these checks will be returned to you automatically too. This will make you aware of any problems very quickly, so that you can correct them and re-submit your request. The most recent version of the tool is publicly available at: ftp://ftp.ripe.net/tools/inaddrtool-DATE.tar.gz The tool itself needs perl4/5 and uses some other external programs for gathering the information it needs for checking your zone files: ftp://ftp.ripe.net/tools/ping.tar.Z ftp://ftp.ripe.net/tools/dns/host.tar.Z ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta3.shar.gz (perl4 only) Installing the software: - uncompress/unzip and untar the tool and the external programs - if needed, edit the variables in the source code (inaddrtool.config): $TESTMODE=1 for testing, 0 for normal use $CHECKCONNECTIVITY=1 will check the connectivity to the nameserver with ping & prtraceroute when the tool has problems gathering the zone info from a certain server. $HELPFILE="/ncc/ftp/ripe/docs/ripe-105.txt"; The help file $TMPDIR="Directory for storing temporary files"; $UPDLOGDIR="Directory for logging the incoming requests"; $ACKLOGDIR="Directory for logging the outgoing acknowledgements"; $FWLOGDIR="Directory for logging the outgoing approved requests"; $MSGQUEUEDIR="Directory for temporarily storing the requests"; $NSNAME="The name of your nameserver"; $NAMESERVERCHECK=; see for details the source code and discussion below about the NSNAME keyword $MAILCMD=; see for details the source code $NICECMD="Your nice program" or "" if you don't want to use this feature; $HUMANMAIL="The E-mail address of the human processing the approved requests and answering questions. When $TESTMODE=1, all mail will be send to this address"; $AUTOMAIL="The E-mail address of the mail box that will auto process incoming requests"; and finally you might want to change the limits we use for the timiing parameters defined at the end of the config file. Values that start with $too.* are the values that define the upper/lower limits of the timers. Values that start with $low|high define the limits wherein no warnings will be generated. - Put something like: "|/home/user/bin/inaddrtool 2>/dev/null" in the .forward file of user $AUTOMAIL Note: there is *NO* queuing mechanism yet, so beware of overloading your machine with a large number of requests. The input: The tool expects to read an E-mail message from standard input. It can be used from a .forward files as well as a stand-alone program. The E-mail message should contain a valid RIPE database object as described in the ripe-105 (ftp://ftp.ripe.net/ripe/docs/ripe-105) procedure. When the automated procedure does not detect any errors, the request is forwarded to the $HUMANMAIL role account person for some additional manual checks and the processing of the delegation itself. An acknowledgement of this fact is also sent to the people mentioned in the From:/Reply-To: and Cc: field in the E-mail message. The tool will return an error report if errors are found. If $TESTMODE=1 all mail will be send to $HUMANMAIL. You can use some keywords in the 'Subject:' line of your E-mail to control the checking process. The use of the LONGACK keyword is very recommended. HELP - will send you a (patched) ripe-105 document CHANGE - is needed if you want to change an existing reverse delegation LONGACK - will give you the most verbose output as possible TEST - do the checks, but sent only a report back to the user even if no errors are found You also might want to use the special keyword NSNAME that's documented in the source code itself (for experts only). This variable can be used to change the rules that we use for when our own $NSNAME is required/optional/not allowed as a secondary/primary nameserver. RIPE document ripe-105 requires you to send in a RIPE database 'inetnum' object with a 'rev-srv' attribute for each nameserver for single/multiple C's reverse delegation requests and for whole blocks 'domain' objects with 'nserver' attributes for each nameserver. I am neither a DNS expert or native English writer ;-) so all your comments are welcome! Please send them together with complaints, bug reports or special requests to <inaddr(a)ripe.net>.

1 0

WWW nscount
by Paolo Bevilacqua 25 Nov '95

25 Nov '95

Hello, This WWW interface to a little DNS tool can be useful to know about 'load' for nameservers under a given domain. Greetings, /pab

1 0

RIPE22 dns-wg minutes - Final version
by Antonio_Blasco Bonito 20 Nov '95

20 Nov '95

Folks, since no more comments were received I here enclose the final version of the minutes. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)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 ---------- ---------- -----------------------cut here--------------------- RIPE 22 DNS Working Group minutes Amsterdam 12 October 1995 Chairman: Antonio Blasco Bonito (ABB) Scribe: Benoit Grange (BG) Participants ------------ Antonio-Blasco Bonito GARR-NIS Guy Davies Unipalm PIPEX Sabine Dolderer RZ Uni-Karlsruhe, DENIC Oliver Doll EUnet Deutschland GmbH Armand Dominque FCCN/RCCN Francis Dupont INRIA Krzysztof Dzwigala NASK Benoit Grange INRIA / NIC France David Hujer SPT TELECOM, A.S. Avgust Jauk ARNES Klaus Landefeld Nacamar Data Comm. Bohumila Mullerova CESNET Ireneusz Neska NASK Peder Chr. Norgaard Telebit Communications A/S Christian Panigl UniVie/ACOnet Marc Pichon TRANSPAC Franck Pradal France Telecom Eva Ptackova SPT TELECOM, A.S. Pulak Rakshit Cable Online Ltd Nick Reid RIPE NCC Valeria Rossi CILEA Oliver Smith Demon Internet Ltd Milan Sterba HP Czech republic Thierry Scortatore FRANCE TELECOM Bernard Tuy CNRS / UREC Pierre Verbaeten KU Leuven Eric Wassenaar NIKHEF Ton Windgassen EU.IBM Preliminaries ------------- Rob Blokzijl presented the apologies from the working group chairman, Leonid Yegoshin (LY), who had a visa problem and asked ABB to chair the group. The agenda was reorganized and agreed. 1) Reports about DNS Failures -------------------------- [This item should have been covered by LY, but because he was not there some of us reported current problems] BG talked about the known problem with uncesessary glues that appear in zone transfers. This happens on most old implementations (BIND prior to 4.9) as shipped my most of the vendors. DNS Operation suffer from old implementation that have known bugs and proble ms. The usual suggestion is to install a recent version of BIND, which happens to be a beta version. It was noted that, altough that effectively eliminates the problem, many DNS administrators are not willing to use a beta version. The working group agreed on sending a letter to the ISC to ask to put BIND 4.9.3 in final so that doubts about it are solved. [ACTION on ABB] Many expressed concern about how delegation changes are done at the Internic. Today Internic accepts any change to current delegation (normal and reverse) and also to glue records. This leads to situation where some bad data is introduced, either as an error, or as some malicious action. Eg: 'ns.ripe.net' (193.0.0.193) is primary for 'ripe.net' and a lot of important zones. John Doe wants to create a 'johndoe.com' zone and submits a request to Internic mentionning both 'banana.johndoe.com' (198.1.2.3) as primary and 'ns.ripe.net' with a WRONG address 193.0.0.93 because of a typo. Internic creates the 'johndoe.com' zone and CHANGES the glue record for 'ns.ripe.net'. All delegations to 'ns.ripe.net' are affected because Internic accepted unnecessary glue record from John Doe and blindly accepted to change an existing name server IP address. The working group recommends that Internic does not accept unneccessary glue records and double checks any change to existing glue records. [ACTION on Geert Jan de Groot] Some people do not watch their name servers: it happens that some name servers are left unattended and fail without anyone noticing. This has an impact on the performance and reliability of the overall name service. People should watch their name servers and their zones on their primary and secondaries. At least the 'host' command can be used in the following way: host -C -A -L 1 <zonename> to do this at regular intervals. During the plenary session someone remembered the existance of RFC1713 A. Romao, "Tools for DNS debugging", which is usually referred to as the guide for DNS administrators and suggested to ask the author to include such recommendation. [ACTION on ABB] 2) 'in-addr.arpa' automatic checking and delegation (D. Kessens) ------------------------------------------------------------- David briefly talked about the tool he wrote which is being used at RIPE- NCC. This tools checks if the reverse zone is correctly configured as per RIPE requirements. Usage: Send an e-mail message to 'auto-inaddr(a)ripe.net' containing the 'inet-num' object with 'rev-svr:' attributes listing the desired name servers (1 name server per line). Send an empty message to get help. The final editing of the zone file is still done manually and the operators also checks the author of the update. After a short discussion the group agreed that some authentication mechanism be added in order to avoid malicious changes to current delegation, specially when the reverse delegation process will be completly automated. [ACTION on RIPE-NCC] This tool could also be used to check for normal delegations, but only after some rewriting because some of the checks are specific to reverse delegation or RIPE requirements. Sources are on ftp://ftp.ripe.net/tools/inaddrtool-VERSION Another tool to check delegation exist under http://www.nic.fr/ZoneCheck Sources of this tool will be freely available by the end of the year. [ACTION on BG] 3) Future developments of the name servers --------------------------------------- It was reported that: Paul Vixie got RU-BIND and will somehow merge the two programs. IBM has donated code to do dynamic updates, and an other source is available as well. 4) About the recent changes of the root name servers ------------------------------------------------- All root name servers have been renamed as '<letter>.root-servers.net'. If you want to know the "old name" of a name server, query for the TXT record associated with the name. A new primary for the root zone will be created and managed directly from IANA, and the primary for the '.com', etc. zones will remain managed by Internic. 5) Charging for domain names, etc. ------------------------------- TLD administrators are increasingly contacted by multinational company which wants to create a bunch of domains in different countries. Different countries have different policies and procedures. The requestor often challenge the TLD aministrator with questions about differences in naming and registration policies. A European TLD forum might be useful to have a better understanding of the matter. The first move should be to collect how TLD management is done over Europe. As a starting point the working group decided to set up a questionnaire. The main reason to collect such information is to help the TLD administrators in their task by knowing the guidelines followed by other countries. If they wish TLD administrators have then the possibility to keep themselves aligned to the mean behaviour (best current practice?), to reduce disputes about registration requests. During the meeting Guy Davies (GD) started collecting a lot of proposed questions. He will organise the questionnaire and submit it to the list for review and later send it to the European TLD admins. [Action on GD] DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT

2 2