From Francis.Dupont at inria.fr Mon Sep 5 23:54:06 1994 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Mon, 05 Sep 1994 23:54:06 +0200 Subject: RIPE DB domain object Message-ID: <199409052154.XAA28576@givry.inria.fr> The discussion about the RIPE DB domain object is still open... I remind you of the current proposal: (mininal) change status of zone contact, name server, sub-domain and reverse-server (the last one in IP network object) from mandatory to optional. (medium) change status of this attributes to obsolete. (maximal) delete domain object and reverse-server attribute. It is obvious that the managing of domain objects is a burden for local IRs but it is also useful if some tools use them. Then the real questions are: - do you know a real domain where zone contact is not one of the technical contacts ? - do you know a general tool using name server or sub-domain attributes ? (these informations are already available via the DNS then a strong argument in favor of these attributes would be a tool using them producing or checking the DNS. Another idea is a tool producing domain objects from the DNS automa{t,g}ically...). I'll try to present a summary of this discussion at the next RIPE meeting. Thanks Francis.Dupont at inria.fr PS: this is the last mail about this. It shows the pros and cons: identation summary: >> Daniele Vannozzi first arguments > Piet Beertema first arguments Daniele Vannozzi second arguments Piet Beertema second arguments To: Daniele Vannozzi Subject: Re: Removal nameserver an rev-srv tags Date: Tue, 24 May 1994 10:33:08 +0200 From: Piet Beertema >> Concerning the assumption of dns-wg about the useless of those tags and >> the absence of procedures based on them we would like to inform you that >> we are presently testing some automatic tools based exactly on those >> tags which we use before actually registering a new direct or inverse >> domain. >> Starting from the contained information, each server is queried on >> properly resolving the query. > >Do you mean, you first build the domain object, insert it into the >database and then get a list of nameservers out of it, in order to >do your querying ? >And only then you consider the domain configuration ok? > >If this is the case, why don't you get the NS list from the (soon to be) >primary nameserver, and if all is ok then you register the domain itself >and the domain object in the database? Or did I miss something? When we receive a domain form (domain registration template) we check the primary nameserver (we use the first "nameserver:" tag to locate it). How to find otherwise that server without a nameserver tag? If you receive a domain registration, it ought to list the nameserver hosts and their IP addressess, the simple reason being that you have to enter them into DNS. But that has absolutely nothing to do with [the domain object in] the RIPE database. If the primary nameserver is reachable and properly configured we continue checking secondary nameservers which should be listed in the domain form and as NS records in the primary nameserver. The above is a useful check because many times there are discrepancies in what is "declared" and what is actually configured. That's what I do too before entering nameservers for a domain into the NL zone file. But again, this has nothing to do with [the domain object in] the RIPE database. In addition, if in the domain form there is our nameserver listed as a secondary, we also check the refresh time, retry time, expiration period and default ttl. Same comment as above. Only after a successful check the domain object is added to database and the country master server is reloaded with the new information. Once again: this relates ONLY to DNS. If you think it's really necessary to clog the RIPE database with useless information (like nameservers; info that is present already in DNS), you have to come with good arguments. And please note that it is not forbidden for a [TLD] registrar to keep a *local* database with all sorts of additional info about a domain. Piet From panigl at cc.univie.ac.at Tue Sep 6 16:47:37 1994 From: panigl at cc.univie.ac.at (Christian Panigl /ACOnet/UniVie +43 1 4065822-383) Date: Tue, 06 Sep 1994 16:47:37 MET-DST Subject: RIPE DB domain object Message-ID: <0098412F.76CA7D38.5@cc.univie.ac.at> Hello Francis, >The discussion about the RIPE DB domain object is still open... > >I remind you of the current proposal: > (mininal) change status of zone contact, name server, sub-domain >and reverse-server (the last one in IP network object) from mandatory >to optional. > (medium) change status of this attributes to obsolete. > (maximal) delete domain object and reverse-server attribute. my comments to the medium and maximal versions: I clearly don't want to warm up a discussion which I didn't attend, however, the current situation in Austria is, that both serviceproviders and IRs (ACOnet and EUnet) have finally agreed that it is worth the effort to register second and third-level domains in the RIPE database, and this is done already for all 2nd-level and for all new 3rd-level applications, cleanup of 3rd-level up to end of 1994. Even if there are no tools actively using the domain-objects in the RIPE-DB, me as a human beeing and network-administrator is considering it as useful information !!! I definitely LIKE the RIPE-DB and it's simple tools (WHOIS, WAIS), it's a great help for my daily work, so please don't lock out valuable information, just because it's not used by poppy auto-config-tools !!! > - do you know a real domain where zone contact is not one of the >technical contacts ? Yes: e.g. univie.ac.at zone-c: Gerhard Winkler (is responsible for the nameservers) tech-c: Ewald Jenisch (is responsible for the router-network) > - do you know a general tool using name server or sub-domain attributes ? >(these informations are already available via the DNS then a strong >argument in favor of these attributes would be a tool using them >producing or checking the DNS. Another idea is a tool producing domain >objects from the DNS automa{t,g}ically...). I would prefer a tool producing DNS-entries from domain objects. When you are just including in the RIPE-DB the information already available in the DNS, it wouldn't make much sense. Again, even if there are no config-tools using the domain-object, human beeings ARE ! To enforce the administrative registration of a domain in the RIPE-DB you might consider a tool checking DNS, comparing it with the RIPE-DB and sending domain templates to the mail addr in the SOA if the domain is not registered or contains wrong nserver fields (of course this tool could do a DNS primary/secondary sanity check as well). >Once again: this relates ONLY to DNS. If you think it's really >necessary to clog the RIPE database with useless information >(like nameservers; info that is present already in DNS), you >have to come with good arguments. And please note that it is >not forbidden for a [TLD] registrar to keep a *local* database >with all sorts of additional info about a domain. If there definitely are no tools using the nserver information at all and the RIPE-DB has to safe a few kbyte disk space, for my sake drop the nsfields, but don't drop the whole domain-object ! Regards Christian --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet : -------------------------------------------- --- --- Universitaetsstrasse 7 : Internet: Christian.Panigl at CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) --- From e07 at nikhef.nl Sun Sep 18 03:32:06 1994 From: e07 at nikhef.nl (Eric Wassenaar) Date: Sun, 18 Sep 1994 03:32:06 +0200 Subject: nslookup enhancements for NSAP lookup In-Reply-To: Your message of "Wed, 14 Sep 1994 23:43:53 +0200 (CDT)" Message-ID: <9409180132.DA13951@nikhefh.nikhef.nl> "Peder Chr. Norgaard" writes: > I hereby forward a set of enhancements to the nslookup program > for easier lookup of NSAP addresses in DNS. For those of you who use the ``host'' utility: Similar nsap support has been incorporated in ``host'' as per version 940917. See below for a few examples. [Note that this is the contrib/host, not the tools/host, as distributed with BIND. Apart from being a DNS query tool, this utility does syntax and semantics analysis of the retrieved data on the fly. Several features have been added since the version currently present in BIND.] The latest version can be retrieved via anonymous ftp from ``ftp.nikhef.nl'' in directory ``/pub/network'' as ``host.tar.Z'' or ``host_940917.tar.Z''. (Apologies if you receive this message more than once.) -- Eric Wassenaar [] host -V Version 940917 # Fetch the nsap address of the specified host. [] host -t nsap cursive.nsap.nist.gov cursive.nsap.nist.gov NSAP 0x47.0005.8000.5A00.0000.0001.E133.FFFF.FF00.0171.00 # Do the reverse lookup. 0x prefix and dots are optional. # The reverse name is printed in forward notation by default. [] host -n 0x47.0005.8000.5A00.0000.0001.E133.FFFF.FF00.0171.00 47.0005.8000.5A00.0000.0001.E133.FFFF.FF00.0171.00 PTR cursive.nsap.nist.gov # In verbose mode we see what we are actually doing. [] host -v -n 0x47.0005.8000.5A00.0000.0001.E133.FFFF.FF00.0171.00 Query about 0.0.1.7.1.0.0.0.F.F.F.F.F.F.3.3.1.E.1.0.0.0.0.0.0.0.0.0.A.5.0.0.0.8.5.0.0.0.7.4.nsap.int. for record types PTR Trying 0.0.1.7.1.0.0.0.F.F.F.F.F.F.3.3.1.E.1.0.0.0.0.0.0.0.0.0.A.5.0.0.0.8.5.0.0.0.7.4.nsap.int ... Query done, 1 answer, status: no error The following answer is not authoritative: 47.0005.8000.5A00.0000.0001.E133.FFFF.FF00.0171.00 3561 IN PTR cursive.nsap.nist.gov Authoritative nameservers: 47.0005.8000.5a00 281735 IN NS wolf.ncsl.nist.gov Additional information: wolf.ncsl.nist.gov 66686 IN A 129.6.55.3 wolf.ncsl.nist.gov 66686 IN A 129.6.224.3 # Make a zone listing of a reverse mapping domain. [] host -t any -l -n 0x47.0005.8000.5A00 !!! 0.0.A.5.0.0.0.8.5.0.0.0.7.4.nsap.int has only one nameserver wolf.ncsl.nist.gov 47.0005.8000.5A00 SOA wolf.ncsl.nist.gov. root.wolf.ncsl.nist.gov. ( 1994081700 ;serial (version) 1800 ;refresh period 300 ;retry refresh time 604800 ;expiration period 3600 ;default ttl ) 47.0005.8000.5a00 NS wolf.ncsl.nist.gov. 47.0005.8000.5a00.0000.0001.0002.0000.0c01.1748.00 PTR sura-cgw.nsap.nist.gov. 47.0005.8000.5a00.0000.0001.0002.0000.9300.c4f0.00 PTR pgw48.nsap.nist.gov. 47.0005.8000.5a00.0000.0001.e137.ffff.ff00.0164.00 PTR infidel.nsap.nist.gov. 47.0005.8000.5a00.0000.0001.e133 NS wolf.ncsl.nist.gov. # The same, but force the output to be in full zone file format. [] host -t any -lZ -n 0x47.0005.8000.5A00 !!! 0.0.A.5.0.0.0.8.5.0.0.0.7.4.nsap.int has only one nameserver wolf.ncsl.nist.gov 0.0.A.5.0.0.0.8.5.0.0.0.7.4.nsap.int. 3600 IN SOA wolf.ncsl.nist.gov. root.wolf.ncsl.nist.gov. ( 1994081700 ;serial (version) 1800 ;refresh period 300 ;retry refresh time 604800 ;expiration period 3600 ;default ttl ) 0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. 3600 IN NS wolf.ncsl.nist.gov. 0.0.8.4.7.1.1.0.c.0.0.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. 3600 IN PTR sura-cgw.nsap.nist.gov. 0.0.0.f.4.c.0.0.3.9.0.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. 3600 IN PTR pgw48.nsap.nist.gov. 0.0.4.6.1.0.0.0.f.f.f.f.f.f.7.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. 3600 IN PTR infidel.nsap.nist.gov. 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. 3600 IN NS wolf.ncsl.nist.gov. # How to distinguish between dotted quads and nsaps. [] host -i 192.16.199.1 1.199.16.192.in-addr.arpa PTR nikhefh.nikhef.nl [] host -n 192.16.199.1 Invalid nsap address 192.16.199.1 [] host -i 192.16.199.80 80.199.16.192.in-addr.arpa PTR hef-router.nikhef.nl [] host -n 192.16.199.80 0.8.9.9.1.6.1.2.9.1.nsap.int does not exist (Authoritative answer)