- dns-wg - mailman.ripe.net

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

02 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 29 Jan '96

29 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 27 Jan '96

27 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 26 Nov '95

26 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

Re: Second level domains for individuals
by Francis Dupont 19 Nov '95

19 Nov '95

In your previous mail you wrote: There is a hot debate in Hungary. Some peoples want me to start registering second level domains for individuals. => This question was hot debates in DNS working group too. We have no (not yet ?) good solution but we understand well the issues. This applies to other problems with a lot of small domains, individuals (aka private persons) are only the worst case: - individuals can be put in a second/third level domain - this domain must be split (because an huge flat domain is bad for tech and admin reasons) and *more* the management of its sub-domains must be given to ad hoc organization (this *is* the real problem!). - one way is to use a geographical hierarchy (as US domain). It gives a nice split without problems but it is hard to involve local/regional authorities into DNS management (it is an half success but in fact you need only to give the first level, ie regional). The main drawback is the name (and E-mail address) changes when an individual moves. - the second way is to use an arbitrary split, for instance an hash on the name. It gives good and *stable* split but it can't solve the management delegation problem. - the last way is to put individuals into domains related and managed by ISP (Internet Service Providers). This has a *terrible* drawback: individuals will be *bound* to their service providers. Then I can't recommend this! There is no new idea ? Francis.Dupont(a)inria.fr PS: just for an example of the need of a solution of this problem: in France some CATV operators propose (experimental) access to the Internet to individuals using PCs and CATV modems (pre IEEE 802.14).

1 0

Re: Second level domains for individuals
by Gabor Kiss 11 Nov '95

11 Nov '95

> First off, this is a hot debate in the RIPE DNS working group > (dns-rw(a)ripe.net) and I suggest followups to be sent there. This is a Hungarian language discussion. I'm afraid most of dns-rw subscribers doesn't speak Hungarian. However articles are archived here: URL: gopher://HUEARN.sztaki.hu:70/11/listak/lsvarch/HUDOM-L Regards Gabor

1 0

Re: Second level domains for individuals
by aw＠eunet.ch 10 Nov '95

10 Nov '95

Can you give me one good reason why we SHOULD register private individuals? Just one good reason. Then we'll see.......... Aleks Null Illigitimi Caborundom

2 1