November 1995 - dns-wg - mailman.ripe.net

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

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

18 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 10 Nov '95

10 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

Re: Second level domains for individuals
by e07＠nikhef.nl 10 Nov '95

10 Nov '95

> There is a hot debate in Hungary. Some peoples want me to > start registering second level domains for individuals. Arbitrary individuals ? The debate will become even hotter as soon as you start to implement such plan. Perhaps so hot as to cause a partial meltdown of the internet as we know it. Look at what happened to the *.com domain. Even most knowledgable and repectable people did not foresee that this would grow out-of-hand so soon as it does now. Registering individuals in one single domain constitutes essentially one enormous flat namespace. The DNS was designed to avoid just that, both for technical and administrative reasons. >From a technical view, I am not convinced that the DNS will be able to gracefully handle domains with, say, a million entries. Not an extraordinary number in the long run for a big country. But presumably the administrative burden will be overwhelming. Compare this with administration in real life, be it civil registration, telephone directories, you name it. All has been organized in a distributed matter of some sort, e.g. geographically. Apparently that's the way to survive. Think about arbitration of names. A first-come first-serve policy would be totally unrealistic. Strong naming conventions would have to be designed. This may be impossible to enforce. You really have to think beyond current experiments with a few hundred individuals, and anticipate what can happen when this becomes common practice. Having individuals registered in one single domain, *any* domain, does not look a good idea. In case that domain were a top-level domain, it looks like disaster. -- Eric Wassenaar

5 5

Re: Second level domains for individuals
by Niall O'Reilly 10 Nov '95

10 Nov '95

> From @IRLEARN.UCD.IE:Piet.Beertema@CWI.NL Fri Nov 10 12:48:14 1995 > > 1) Do not register individuals. This is only temporary > relief but it may last a few years. > That doesn't work either, the individuals just pretend > to be businesses. > They can't, when [evidence of] Chamber of Commerce > registration is required, as is the case for .NL. > And since CoC registration costs money and has a > couple of legal and tax implications, it serves > as a good showstopper in many cases. Sometimes I miss the Dutch business virtues: they make life so simple! When the local legal system recognizes that a private individual without registration may be a business, or even a number of businesses, it's not so easy. I guess the Australian system shares a common origin withe the Irish one. Niall O'Reilly

1 0

Re: Second level domains for individuals
by Geert Jan de Groot 10 Nov '95

10 Nov '95

Hi Gabor, 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. I know that at least for the NL TLD, it is required that one is registered in the Chambers of Commerce. (I hope piet^H^H^H^Hhostmaster does not mind this translation from the Dutch guidelines ;-) Geert Jan On Thu, 9 Nov 1995 17:45:21 +0100 Gabor Kiss wrote: > There is a hot debate in Hungary. Some peoples want me to > start registering second level domains for individuals. > > Personally I think this practice would have serious disadvantages: > - I would have to process incredible amount of registration requests. > - We would have to run the top level DNS on a really big machine. > - The RIPE-DB would contain 26000 domain objects instead of 16000. > > I wish to know how this problem is handled in different countries. > I guess there was several continent-wide discussion about this > question. Where can I find documents and archived matter?

2 1

DNS Questionnaire
by Daniele Vannozzi 09 Nov '95

09 Nov '95

DNS Questionnaire ================= 1. Who defines your policies? They are defined by a open committee called ITA-PE which coordinates e-mail activities in Italy. The committee includes individuals from most of the italian Service Providers and Academic Institutions. 2. How do you establish your naming policies? The agreements are reached finding consensus (avoiding votes) after discussion either on a mailing list, ita-pe(a)nis.garr.it, or during quaterly meetings. 3. What legal status, if any, do your decisions/policies have? None for the time being, but we are expecting formal recognition from Italian PTT Ministry and UNINFO (ISO Italian branch). 4a. Would you register sub.tld (e.g. co.uk, ac.uk etc)? No. b. Do you have geographic subdomains in the tld (e.g. state.tld, county.tld)? Yes, hierarchical administrative geographycal domains c. Do you have different categories of 2nd level domains (e.g."public" ones like "co.at" and "private" ones like "alcatel.at") in parallel? Yes, administrative geographycal 2nd and 3rd level domains are public. d. If you have "public" 2nd level domains, what are the rules for running such a domain (e.g. everybody's registration has to be accepted for free if it fits into this category)? Public domains are delegated to an organization wishing to provide a free name service in its region. Delegation could be withdrawn if the delegated organization does not properly administer the geographical domain. e. If so, how do you split your tld? Hierarchical administrative geographical domains as follows: 2nd level - Regions registered with both full name and 3-letter shortname. (e.g. Lombardia and LOM, Toscana and TOS, etc) - Provincies with both fullname and 2-letter shortname. (e.g. Napoli and NA, Milano and MI, etc) 3rd level - Cities with fullname only, under their province. (e.g. Capri.NA.it, etc). Note that cities giving their name to the province do not register also as 3rd level. 5a. Would you register domain.tld (e.g. microsoft.uk)? Yes, if compliant with the registration rules. b. Would you register domain.sub.tld (e.g. microsoft.co.uk)? No. Only if sub.tld is already registered, then we accept to register (for information purposes only) its subdomains. 6a. Do you allow individuals to register names or just organisations? Just organizations. b. If you differentiate between individuals and organisations, what are your criteria? An organization should have legal status as such. 7a. Do you require proof of identity? Yes. b. If so, how do you prove the identity of a requestor? We ask the requestor to sign his acceptance of the rules on company head paper and we trust a number of known ISPs who actually submit the request on behalf of the requestor. 8. Do you register domains only for organisations/individuals located in your country or do you allow anyone to register in your tld? Only organizations with legal status in Italy. 9a. Do you allow a single organisation to register more than one domain? No, with some exceptions (e.g. legally registered newspapers and magazines belonging to the same publisher, some telematics services, etc) b. If so, do you limit the number of domains registered by a single organisation? n/a 10a.To whom would you allocate well known names like digital.tld/ digital.sub.tld? We ask, but without enforcement, that the domain name should be as much similar as possible to the legal name of the requesting organization. If not we first recall the rule "one name per organization" and briefly try to convince the requestor not to use a well known name to avoid conflicts in the future. b.What criteria do you use when deciding whether or not to allow a name? Names are allowed except when they are in the set of the reserved names or shorter then 3 characteres (at 2nd level) or of 2 characters (under any other "public" domain). 11a.How do you arbitrate between two or more claims to the same name? We inform both parties of the claim asking if one of them could renounce. If none renounces we give the name to the first requestor and mark it as challenged. We leave to them resolve their conflict as they wish. We query at regular intervals for both parties to resolve the challenge, in any form they wish, to solve the situation: bilateral agreement, arbitration commettee, civil law judgment, ... We also inform both parties when very similar names may cause ambiguity. b.Who is responsible for the arbitration? Any Italian legal entity. 12a.Do you allow the registration of geographical names (cities, countries, rivers, etc)? Yes but regions, provinces and cities are special cases (see 4.b,c,d,e). b.If so, would you register one for an individual organisation? Yes, but we briefly try to discourage the requestor. 13a.Do you have any names which may not be registered (e.g. names in bad taste, names of protocols, etc)? Names shorter than 3 characters (2nd level domains) or 2 characters (other levels). Names of protocols/services (tcp, finger, ftp, telnet, etc) and ambiguos names (email, www, ecc). 14a.Do you run secondary nameservice for subdomains of the tld? Yes, only for 2nd level subdomains (e.g. cnr.it, fiat.it, ecc) and 2nd and 3rd level administrative geographical domains. b.If so, is this optional/mandatory and do you charge for the service? Optional, no charge. Mandatory for public geographical domains. 15a.Do you check for a running nameserver at the time of request? Yes, for at least a couple of them b.Do you check for a running nameserver at regular intervals after the name has been delegated? Yes, because we check for the reachability of each postmaster@<domain>.it. 16. Do you allow the reservation of names (i.e. no running service)? No 17a.Do you charge for reservation/registration of names? No, at the moment. Policy to be modified b.If so, is it a one off fee, an annual subscription or both? n/a c.How much is the fee? n/a 18a.Do you remove unused domain names? Yes. b.If so, how do you define an unused domain? A domain that is cancelled by the admin-c or that is no longer serviced by any Service Provider. A domain which results inactive for more than 6 consecutive months. 19. Do you think that the current system you operate will be changed over the next 12 months? Yes, completion and update of existing rules and policies are expected soon. 20. Do you accept requests for domains from providers only, from anyone or from a different group only? >From Providers only. 21. What resources are allocated to the administration of the domain? 3 FTE, 2 servers, 3 workstations. 22. Do you have any automation of the registration/delegation process? Yes, partial (e-mail robot). Daniele Vannozzi Phone: +39 50 593280 GARR-NIS Phone NIS: +39 50 593360 c/o CNUCE - Istituto del CNR Fax: +39 50 904052 Via Santa Maria 36 Telex: 500371 - CNUCE 56100 Pisa - Italy E-mail: vannozzi(a)nis.garr.it

1 0