- dns-wg - mailman.ripe.net

Domain object template
by Marten Terpstra 11 Jan '95

11 Jan '95

Folks, Francis has made an update to the old domain object template. A draft version of his document is attached below. Please comment on this document, it should preferably be OK'ed at the coming RIPE meeting. This document is also available as: ftp://ftp.ripe.net/ripe/drafts/ripe-domain.{txt|ps} Cheers, -Marten RIPE Database Template for Domains Francis Dupont Document ID: ripe-049-bis Obsoletes: ripe-049 ABSTRACT This paper describes the format and syntax for the representation for Internet domains and associated contact persons in the RIPE database. 1. Introduction RIPE (Reseaux IP Europeens) coordinates TCP/IP networking for the research community in Europe. One of the activities of RIPE is to maintain a database of European IP networks, DNS domains and their contact persons along with various other kinds of network management infor- mation. This database content is public information for agreed Internet operational purposes. This supports NICs/NOCs all over Europe and beyond to perform their respective tasks. This document describes the format and syntax for Internet domain information and the closely related contact person information. Top, first and sensible level domains should be registered in the RIPE database. Each object in the database describes a single entity in the real world. This basic principle means that information about that entity should only be represented in the corresponding database object and not be repeated in other objects. Objects are described by attributes value pairs, one per line. Objects are separated by empty lines. An attribute that consists of multiple lines should have the attribute name repeated on consecutive lines. The information stored about domain UKA.DE consists of five objects, one domain object and four person objects and looks like this: ripe-049-bis.txt January, 1995 - 2 - domain: UKA.DE descr: Universitaet Karlsruhe descr: Informatik Rechnerabteilung IRA descr: Am Fasanengarten 5 descr: D-7500 Karlsruhe, FRG admin-c: Werner Zorn tech-c: Michael Rotert tech-c: Klaus Becker tech-c: Arnold Nipper nserver: iraun1.IRA.UKA.DE iramu1.IRA.UKA.DE nserver: unido.Informatik.Uni-Dortmund.DE sub-dom: ira dom-net: 129.13.0.0 192.54.104.0 changed: nipper(a)ira.uka.de 910208 source: RIPE person: Werner Zorn address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-7500 Karlsruhe phone: +49 721 608 3981 fax-no: +49 721 699 284 e-mail: zorn(a)ira.uka.de changed: dfk(a)cwi.nl 11-Apr-90 source: RIPE person: Michael Rotert address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-7500 Karlsruhe phone: +49 721 608 4221 fax-no: +49 721 699 284 e-mail: rotert(a)ira.uka.de nic-hdl: MR78 changed: dfk(a)cwi.nl 11-Apr-90 source: RIPE person: Klaus Becker address: Universitaet Karlsruhe address: Informatikrechnerabteilung address: Am Fasanengarten 5 address: D-7500 Karlsruhe phone: +49 721 608 3973 fax-no: +49 721 699 284 e-mail: becker(a)ira.uka.de changed: dfk(a)cwi.nl 11-Apr-90 source: RIPE person: Arnold Nipper address: Universitaet Karlsruhe address: Informatikrechnerabteilung ripe-049-bis.txt January, 1995 - 3 - address: Am Fasanengarten 5 address: D-7500 Karlsruhe phone: +49 721 608 4331 fax-no: +49 721 699 284 e-mail: nipper(a)ira.uka.de nic-hdl: AN45 changed: dfk(a)cwi.nl 11-Apr-90 source: RIPE 1.1. How to access the Database ? The database is public information for agreed Internet operational purposes. It can be accessed via a whois server on host whois.ripe.net (tcp port 43). The whole database is also available via anonymous ftp from ftp.ripe.net as file ripe.db in directory ripe/dbase. There is also a compressed version of the database available in that same directory, as well as a version of the database in which the different objects have been collected in different files. This "split" version of the database can be found in the subdirectory split. 1.2. How to submit information to the database ? Database updates should be sent via electronic mail to auto-dbm(a)ripe.net Be sure to supply a person object [1] for each contact per- son mentioned in the network objects. Of course you need not supply person objects if they are already present in the database and the information is still correct. Updates sent in should only contain the objects that need to be updated. The mail is automatically parsed by software that cannot intercept any messages that may be in the mail. If an update needs human intervention, or you have general questions on the procedures, please refer to ripe- dbm(a)ripe.net. Currently no special authorisation is needed to create, modify or delete objects that describe persons or domain name space. However extensive audit trails of all changes are being kept. 2. Format and syntax of the domain object In a short summary below, the attribute column indicates the name of the attribute inside the object, the second column indicates whether this attribute is optional or mandatory, and the third column indicates whether this attribute can ripe-049-bis.txt January, 1995 - 4 - appear more than once per object: attribute optional/mandatory multiple/single domain: mandatory single descr: mandatory multiple admin-c: mandatory multiple tech-c: mandatory multiple zone-c: optional multiple nserver: optional multiple sub-dom: optional multiple dom-net: optional multiple remarks: optional multiple notify: optional multiple mnt-by: optional multiple changed: mandatory multiple source: mandatory single Below each of these attributes and their format and syntax are described in more detail, and examples are given. domain: The domain attribute contains the fully qualified domain name without trailing ".". Note that DNS names are case insensitive. An example: domain: UKA.DE Status: mandatory, only one line allowed descr: The descr attribute consists of a short description of the organization and location where this domain is used. The description can have multiple lines. It need not contain the full postal address as this is required in the contact person objects (see further in this document). Free text is allowed. An example: descr: Universitaet Karlsruhe descr: Informatik Rechnerabteilung IRA Status: mandatory, multiple lines allowed admin-c: The admin-c attribute contains the name or the NIC handle of the administrative contact person. This is someone who will be contacted about administra- tive things such as domain registration etc. A NIC handle (if known) is preferred. Please do not use formal titles like 'Dr', 'Prof' or 'Sir'. Do not add full stops between names or initials. This value should be exactly the same as the attribute in the person object (see further below). More than one administrative contact person can be specified, by simply repeating the attribute. An ripe-049-bis.txt January, 1995 - 5 - example of both the NIC handle and normal name use: admin-c: Daniel Karrenberg or (preferred) admin-c: DK58 Status: mandatory, multiple lines allowed tech-c: The tech-c attribute contains the name or the NIC handle of the technical contact person. This is someone to be contacted for technical problems such as (mis)behavior of nameservers on the net etc. The format and syntax is the same as the admin-c attribute above. Status: mandatory, multiple lines allowed zone-c: The zone-c attribute contains the name of the zone contact for the domain. This is the person listed in the SOA record for the domain when the domain is a zone too (the same argument, not every domains are zones, applies to nserver attribute). The for- mat and syntax is the same as the admin-c attribute above. Status: optional, multiple lines allowed nserver: The nserver attribute contains the list of nameservers for of this domain, primary first. The format is fully qualified domain name without trailing "." OR IP Address(es) of the nameserver. Only one server should be described per line. An example: nserver: iraun1.IRA.UKA.DE Status: optional, multiple lines allowed sub-dom: The sub-dom attribute contains the list of sub- domains of the domain. The format is relative domain name to the domain (in order to keep the list compact). An example: sub-dom: ira Status: optional, multiple lines allowed dom-net: The dom-net attribute contains the list of IP net- works in this domain. The format is dotted quad including trailing 0s, extended formats defined in [1] for range of IP address space are allowed. An example: dom-net: 129.13.0.0 192.54.104.0 ripe-049-bis.txt January, 1995 - 6 - Status: optional, multiple lines allowed remarks: The remarks attribute contains any remarks about this domain that cannot be expressed in any of the other attributes. Although multiple lines are allowed, it should be only be used if it provides extra information to users of the database, and usage should be kept to a minimum. For format is like the description attribute free text. An exam- ple: remarks: MX record only Status: optional, multiple lines allowed notify: The notify attribute contains an email address to which notifications of changes to this object should be send. This can be useful if more than one person manage the same object. A more detailed description can be found in [2]. The format is one RFC822 electronic mail address per line. Although multiple lines are allowed, usage should be kept to a minimum. An example: notify: operations(a)ripe.net Status: optional, multiple lines allowed mnt-by: The maintainer attribute contains a registered maintainer name. This attribute is used for author- isation of database update requests. It is described in more detail in [2]. The format is a registered maintainer name. An example: mnt-by: RIPE-DBM Status: optional, multiple lines allowed changed: The changed field contains information on who last changed this object, and when this change was made. The format is an RFC 822 electronic mail address of the person who made the change, and the date of change in YYMMDD format. Multiple lines are allowed and shows the update history of an object. An exam- ple: changed: marten(a)ripe.net 940328 Status: mandatory, multiple lines allowed source: The source contains a source of information. For the RIPE database, the value should always be "RIPE". This field is used to combine and exchange information between various database sources around ripe-049-bis.txt January, 1995 - 7 - the world. Fixed value: source: RIPE Status: mandatory, only one line allowed, fixed value 3. References [1] Lord, A., Terpstra, M., "RIPE Database Template for Networks and Persons", ripe-119, October 1994. [2] Karrenberg, D., Terpstra, M., "Authorisation and Notif- ication of Changes in the RIPE Database", ripe-120, October 1994. ripe-049-bis.txt January, 1995

4 4

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