- dns-wg - mailman.ripe.net

Re: Domain object template
by Andreas.Knocke＠nic.de 11 Jan '95

11 Jan '95

Hello, a couple of additions to the discussion: > * Can we please drop the possibility of allowing IP numbers here? > * If one of the secondaries of your domain changes IP number, then > * he has the nearly impossible task of finding all these outdated > * references. Bind only allows hostnames here; I think it is a good > * idea to restrict the database in the same way. > * > * => IP numbers were allowed in the previous template then we need > * a general agreement before dropping this possibility... > > Perhaps we should try and completely overhaul the domain object? Why > would we go for small changes when we may need major changes? I somehow agree with the positions Geert Jan and Marten gave, a complete overhaul is probably needed and especially the nserver, IP-address idea was much discussed the last time at the RIPE meeting in Amsterdam (May 1994) with the idea that there is a much more useful place to store it - BIND ! On the other hand there is maybe one useful point to IP-numbers here, for a domain abc.zz with a set of nameservers ns1.abc.zz and ns2.abc.zz which have lost connectivity - a very bad situation, I agree - it might be helpful to find there IP addresses here as well, so I would propose to use it only for nserver within the specified domain. domain: ABC.zz descr: ABC company .... nserver: ns1.abc.zz 194.205.120.3 nserver: ns2.abc.zz 194.205.120.6 nserver: ns.domain.my nserver: foo.bar.com ... Giving the primary first is probably a good idea, but what about 'hidden' primaries. It is I think a common situation for organisation behind a dial-up connection administering there own nameserver (as given in the SOA) with only a set of secondaries published as NS-RR's. This cannot be documented - if one wants to - this way, but maybe with a useful remark: > * => there is a loose binding between names and addresses. > * This attribute can be used if someone'd like to describe it. > * This attribute has been made optional then you use it only > * if you like. > > Hmm, personally I'd bin the attribute..... I think that most of the attributes made optional instead of obsolete could be seen as a compromise we can agree upon as a transitional step until the complete overhaul - if not achieveable at this meeting ? > > admin-c: The admin-c attribute contains the name or the NIC > > I suggest to make mandatory that the administrative contact > should reside on the site itself. Assume that people have outsourced > the 'technical stuff' of their network, then it is likely that the > technical contact is someone belonging to another company, and > it might be difficult to get in touch with the holder of the > domain itself because the address/phone number is different. > > => the admin contact for domains is different from the admin > contact for networks. It is explicitely an administrative > person who can answer to questions about name property, > legal problems, etc... In fact I understand your problem > but I believe the change should be done in the network > template. I totally agree with Geert Jan here, the admin-c should be from the organisation using domain and should be changed if he no longer represents this organisation. I didn't follow the discussion but heard some rumors about mtv.com but this way might be a good start. You have to have the organisation's address and at least one phone number somewhere. Another but important aspect I think would be to find a better (more up to date) example, if it should convince and educate new registries. The current one contains a number of factional errors (I'll append the correct entry at the bottom of this posting) and some discrepancy to it's own explanation for instance the format of the change dates not in format YYMMDD. Finally with the handles and names as key values for person objects 1.2 could be reformulated. Before entering or updating person objects the database should be checked for existing entries which were created as references of other objects (inetnum,...). Care should be taken to keep them up to date, without generating duplicate entries one with and one without a handle. I did it a number of times myself when I started using handles so please don't take it as an accusation to anybody. On the other hand the advent of ripe handles gives us the proper way to create different objects for one person where necessary - e.g. if he has his own domain at home and supports a number of networks or anything else at work. -------------------------------------------------------------------------- domain: uka.de descr: Universitaet Karlsruhe descr: Informatik Rechnerabteilung IRA descr: Am Fasanengarten 5, D-76128 Karlsruhe, Germany admin-c: WZ5-RIPE tech-c: KB49 tech-c: AN45 zone-c: KB49 nserver: iraun1.ira.uka.de nserver: iraux1.ira.uka.de nserver: ns.germany.eu.net nserver: ns.nic.de sub-dom: ira dom-net: 129.13.0.0 192.54.104.0 mnt-by: DE-DOM changed: nipper(a)ira.uka.de 910208 changed: knocke(a)nic.de 941121 source: RIPE person: Werner Zorn address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-76128 Karlsruhe address: Germany phone: +49 721 608 3981 fax-no: +49 721 699 284 e-mail: zorn(a)IRA.UKA.DE nic-hdl: WZ5-RIPE mnt-by: DENIC-P changed: dfk(a)cwi.nl 900411 changed: rv(a)Informatik.Uni-Dortmund.DE 930704 changed: knocke(a)nic.de 941121 source: RIPE person: Klaus Becker address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-76128 Karlsruhe address: Germany phone: +49 721 608 3973 fax-no: +49 721 699 284 e-mail: becker(a)ira.uka.de nic-hdl: KB49 mnt-by: DENIC-P changed: nipper(a)xlink.net 940406 changed: knocke(a)nic.de 941121 source: RIPE person: Arnold Nipper address: NTG Netzwerk und Telematic GmbH address: Geschaeftsbereich XLINK address: Vincenz-Priessnitz-Str. 3 address: D-76131 Karlsruhe address: Germany phone: +49 721 9652 0 fax-no: +49 721 9652 210 e-mail: nipper(a)xlink.net nic-hdl: AN45 changed: nipper(a)xlink.net 940616 source: RIPE

1 0

Re: Domain object template
by Dave Morton 11 Jan '95

11 Jan '95

All very good points - I agree with Geert. Dave

1 0

Re: Bind (again)
by Mike Norris 21 Dec '94

21 Dec '94

On Wed, 21 Dec 1994 11:55:15 +0000 (WET) Denis Hickey said: >Mike, > Sorry to bother you with this, but I can only locate 4.9-2 at >gatekeeper,either in the pub/BSD/bind/4.9 directory or in pub/misc/vixie. >Do you know of another location. > Sorry about that, Denis. The RIPE archive has documentation for 4.9.3. I'll copy this to the DNS working group and ask the experts to say where BIND 4.9.3 can be found; thank you, RIPE folk. Cheers. Mike

3 3

RFC 1713: Tools for DNS debugging
by Francis Dupont 03 Nov '94

03 Nov '94

Arthur Romao's document has been published as a RFC/FYI. Francis.Dupont(a)inria.fr PS: here is the announce: A new Request for Comments is now available in online RFC libraries. FYI 27: RFC 1713: Title: Tools for DNS debugging Author: A. Romao Mailbox: artur(a)fct.unl.pt Pages: 13 Characters: 33,500 Updates/Obsoletes: none Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work. This document presents some tools available for domain administrators to detect and correct those anomalies. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

1 0

ROOT servers
by hostmaster＠xlink.net 07 Oct '94

07 Oct '94

Was there a change in the set of ROOT servers? c.nyser.net is still in named.root @ InterNIC, whereas the DNS returns NXDOMAIN. A new ROOT server (ns.isc.org) is listed there. Never heard of it before. Does anyone know the correct set of ROOT servers? Arnold -- Arnold Nipper / email: nipper(a)xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany

2 1

Provider-based DNS naming?
by marius＠isgate.is 03 Oct '94

03 Oct '94

This may not be the right forum for this request, but if not, I apologise but you might be able to point me in the right direction. What is the prevailing view on "provider based" DNS naming on Internet. I.e. is there something that can be done to disuade a provider - say provider.top from registering his customer companies as company1.provider.top company2.provider.top etc.. and thus attempting to lock these companies into their services (refusing to rewrite their mailing addresses as name(a)company.top and honoring MX'es for company.top pointing to provider.top). Do you know of a RIPE/ISOC documentation on this issue - or is this behaviour generally considered so obviously stupid that no one has thought of mentioning it? Thanks in advance Marius Olafsson SURIS/ISnet

3 3

Re: nslookup enhancements for NSAP lookup
by e07＠nikhef.nl 18 Sep '94

18 Sep '94

"Peder Chr. Norgaard" <pcn(a)tbit.dk> 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…. 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… ... 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…. 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…. 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…. 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)

1 0

RE: RIPE DB domain object
by Christian Panigl /ACOnet/UniVie +43 1 4065822-383 06 Sep '94

06 Sep '94

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(a)CC.UniVie.ac.at --- --- A-1010 Vienna / Austria : Tel: +43 1 4065822-383 (Fax: -170) ---

1 0

RIPE DB domain object
by Francis Dupont 05 Sep '94

05 Sep '94

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(a)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 <VANNOZZI(a)NIS.GARR.IT> Subject: Re: Removal nameserver an rev-srv tags Date: Tue, 24 May 1994 10:33:08 +0200 From: Piet Beertema <Piet.Beertema(a)cwi.nl> >> 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

1 0

BIND 4.9.3 documents
by Francis Dupont 22 Jun '94

22 Jun '94

Some documents from BIND 4.9.3 beta3 distrib are available by anonymous FTP on ftp.ripe.net in the tools/dns/bind-4.9.3-docs directory: - bog.ps.Z (BIND Operation Guide) - purdue-paper.ps.Z "Countering Abuse of Name-Based Authentication" Regards Francis.Dupont(a)inria.fr

1 0