From Marten.Terpstra at ripe.net Wed Jan 11 09:41:16 1995 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 11 Jan 1995 09:41:16 +0100 Subject: Domain object template Message-ID: <9501110841.AA26575@ncc.ripe.net> 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 at 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 at ira.uka.de changed: dfk at 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 at ira.uka.de nic-hdl: MR78 changed: dfk at 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 at ira.uka.de changed: dfk at 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 at ira.uka.de nic-hdl: AN45 changed: dfk at 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 at 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 at 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 at 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 at 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 From GeertJan.deGroot at ripe.net Wed Jan 11 14:14:45 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 11 Jan 1995 14:14:45 +0100 Subject: Domain object template In-Reply-To: Your message of "Wed, 11 Jan 1995 09:41:16 MET." <9501110841.AA26575@ncc.ripe.net> Message-ID: <9501111314.AA28345@ncc.ripe.net> I have a couple of comments on this draft: On Wed, 11 Jan 1995 09:41:16 +0100 Marten Terpstra wrote: > 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} > 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 > example of both the NIC handle and normal name use: > > admin-c: Daniel Karrenberg > or (preferred) > admin-c: DK58 > > Status: mandatory, multiple lines allowed 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. > 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 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. Also, we might add 'the first nserver listed is the primary for the zone' > 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 > > Status: optional, multiple lines allowed Can someone please explain why it is useful to record this? Seems that this info might get outdated quickly as it isn't related to the domain _name_. Comments? Geert Jan From Dave.Morton at ecrc.de Wed Jan 11 14:23:56 1995 From: Dave.Morton at ecrc.de (Dave Morton) Date: Wed, 11 Jan 95 14:23:56 +0100 Subject: Domain object template Message-ID: <9501111323.AA07136@scorpio.ecrc.de> All very good points - I agree with Geert. Dave From Francis.Dupont at inria.fr Wed Jan 11 14:28:59 1995 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Wed, 11 Jan 1995 14:28:59 +0100 Subject: Domain object template In-Reply-To: Your message of Wed, 11 Jan 1995 14:14:45 +0100. <9501111314.AA28345@ncc.ripe.net> Message-ID: <199501111329.OAA09759@givry.inria.fr> In your previous mail you wrote: I have a couple of comments on this draft: > 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. > 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 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... Also, we might add 'the first nserver listed is the primary for the zone' => "primary first" is in the text. > dom-net: The dom-net attribute contains the list of IP net- Can someone please explain why it is useful to record this? Seems that this info might get outdated quickly as it isn't related to the domain _name_. => 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. Regards Francis.Dupont at inria.fr From Marten.Terpstra at ripe.net Wed Jan 11 14:47:53 1995 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 11 Jan 1995 14:47:53 +0100 Subject: Domain object template In-Reply-To: Your message of Wed, 11 Jan 1995 14:28:59 MET. <199501111329.OAA09759@givry.inria.fr> Message-ID: <9501111347.AA28697@ncc.ripe.net> * 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? * => 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..... -Marten From Andreas.Knocke at nic.de Wed Jan 11 20:02:43 1995 From: Andreas.Knocke at nic.de (Andreas.Knocke at nic.de) Date: Wed, 11 Jan 1995 20:02:43 +0100 (MET) Subject: Domain object template Message-ID: <9501111902.AA23513@andreas.nic.de> 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 at ira.uka.de 910208 changed: knocke at 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 at IRA.UKA.DE nic-hdl: WZ5-RIPE mnt-by: DENIC-P changed: dfk at cwi.nl 900411 changed: rv at Informatik.Uni-Dortmund.DE 930704 changed: knocke at 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 at ira.uka.de nic-hdl: KB49 mnt-by: DENIC-P changed: nipper at xlink.net 940406 changed: knocke at 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 at xlink.net nic-hdl: AN45 changed: nipper at xlink.net 940616 source: RIPE From Yves.Devillers at EUnet.fr Wed Jan 11 21:45:45 1995 From: Yves.Devillers at EUnet.fr (Yves Devillers) Date: Wed, 11 Jan 95 21:45:45 N Subject: Domain object template In-Reply-To: Your message of Wed, 11 Jan 95 14:28:59 N. <199501111329.OAA09759@givry.inria.fr> Message-ID: <199501112045.AA07270@chenas.inria.fr> In message <199501111329.OAA09759 at givry.inria.fr> francis.dupont at inria.fr wrote: > dom-net: The dom-net attribute contains the list of IP net- Can someone please explain why it is useful to record this? Seems that this info might get outdated quickly as it isn't related to the domain _name_. => 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. ==>I see a potential usage for this : In order to avoid spoiling network numbers we ask organisations, when asking for more numbers, what network have already been allocated to them. In case the answer is incomplete thunder from RIPE-NCC will occur. This might well be the place to keep this information. The fact that network allocation is done on a per-provider basis (who do not interact together) makes it impossible for you (you, as an ISP) when queried for some number to know weither is it "some" or "more" and weither RIPE criterai are enforced or grossly violated. Yves Devillers. ---------------------------------------------------------------- Yves Devillers e-mail: Yves.Devillers at EUnet.fr EUnet - France hot-line: tech at EUnet.fr 52 avenue de la Grande Armee infos: contact at EUnet.fr 75017 Paris Phone: +33 1 53 81 60 60 France Hot-line: +33 1 53 81 60 50 Fax: +33 1 45 74 52 79 From Francis.Dupont at inria.fr Mon Jan 16 15:57:42 1995 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Mon, 16 Jan 1995 15:57:42 +0100 Subject: do we need a meeting of the DNS TF ? Message-ID: <199501161457.PAA00500@givry.inria.fr> The subject is a good summary of the question... I can't see important problems which could make a meeting of the DNS TF necessary but perhaps I've forgotten something ? Thanks Francis.Dupont at inria.fr PS: new discussions about the domain object can be made at the DB TF meeting ? From Marten.Terpstra at ripe.net Mon Jan 16 18:11:08 1995 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 16 Jan 1995 18:11:08 +0100 Subject: do we need a meeting of the DNS TF ? In-Reply-To: Your message of Mon, 16 Jan 1995 15:57:42 MET. <199501161457.PAA00500@givry.inria.fr> Message-ID: <9501161711.AA28548@ncc.ripe.net> Francis Dupont writes * The subject is a good summary of the question... * I can't see important problems which could make * a meeting of the DNS TF necessary but perhaps * I've forgotten something ? * * Thanks * * Francis.Dupont at inria.fr * * PS: new discussions about the domain object can be * made at the DB TF meeting ? Question is whether we want to overhaul the domain object, or just approve the small changes discussed last week. If we just want the small changes, I am sure we can do it in the db-wg (Wilfried?). If we want other bigger changes, we'd probably need a dns-wg meeting. -Marten From Andreas.Knocke at nic.de Mon Jan 16 19:17:50 1995 From: Andreas.Knocke at nic.de (Andreas.Knocke at nic.de) Date: Mon, 16 Jan 1995 19:17:50 +0100 (MET) Subject: do we need a meeting of the DNS TF ? In-Reply-To: <9501161711.AA28548@ncc.ripe.net> from "Marten Terpstra" at Jan 16, 95 06:11:08 pm Message-ID: <9501161817.AA04421@andreas.nic.de> > Francis Dupont writes > * I can't see important problems which could make > * a meeting of the DNS TF necessary but perhaps > * I've forgotten something ? > * > * Thanks > * Francis.Dupont at inria.fr > > Question is whether we want to overhaul the domain object, or just > approve the small changes discussed last week. If we just want the > small changes, I am sure we can do it in the db-wg (Wilfried?). If we > want other bigger changes, we'd probably need a dns-wg meeting. We probably should still do it - if possible - within the db-wg. It's (just :-) another object and I think we should decide what's it use and what's the future of each of its attributes. I think it more relates to documented procedures and common usage of the RIPE DB than to DNS. It also has relevance with two action items in the db-wg (documentation, another new domain-object for in-addr delegations). But maybe I'm lacking the history of the dns-wg and db-wg than please excuse my ignorance. > -Marten Andreas (Knocke, DE-NIC) From woeber at cc.univie.ac.at Tue Jan 17 15:02:21 1995 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 17 Jan 1995 15:02:21 MET Subject: do we need a meeting of the DNS TF ? Message-ID: <0098A9A3.CB217F58.4@cc.univie.ac.at> Hallo Andreas! => Question is whether we want to overhaul the domain object, or just => approve the small changes discussed last week. If we just want the => small changes, I am sure we can do it in the db-wg (Wilfried?). If we => want other bigger changes, we'd probably need a dns-wg meeting. = =We probably should still do it - if possible - within the db-wg. =It's (just :-) another object and I think we should decide what's =it use and what's the future of each of its attributes. I think [ $ set /me /mode=piet.b # :-) ] I'm reluctant to drag this stuff (remaining in a state of being rare instead of well-done :-) into the DB-WG. Maybe I'm a bit too proud about the DB-folks, but I've got the impression recently that we managed to get various things and proposals discussed up to a useful point (by different means and methods) and then just put the finishing touch on top during the DB-WG meeting. Quite to the contrary, the DNS (-object stuff) is (and has been) tossed around for more than a year now, if I recall correctly. Listening to Piet's emontional announcement, I get the feeling that the DNS folks still have to make up their minds, one way or the other... If this indeed has happend, then a proposal for a changed object is welcome to be discussed withint the DB-WG. So, my proposal would be to actually convene a DNS group meeting (even with only this one agenda item) and to try to arrive at some kind of consensus or to completely dismiss this issue. Wilfried. PS: speaking as a plain USER and NOT speaking for the DB-WG, I'd rather have the DNS group dissolved than keeping it in the semi-paralysed state it is in these days :-( -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- From Havard.Eidnes at runit.sintef.no Tue Jan 17 22:13:01 1995 From: Havard.Eidnes at runit.sintef.no (Havard Eidnes) Date: Tue, 17 Jan 1995 22:13:01 +0100 Subject: Domain object template In-Reply-To: Your message of "Wed, 11 Jan 1995 14:28:59 +0100" References: <199501111329.OAA09759@givry.inria.fr> Message-ID: <9501172113.AA07654@ravn.runit.sintef.no> > > 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. This is actually a naming policy issue, and as such this decision may eventually rest with the administrator of each top-level domain. I do however agree that adhering to this practice is a very good idea indeed, and that we should strongly reocmmend it. > => 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. That the network template is broken is no excuse for not doing it right in this document... But I'm sure I misunderstood what you are saying. > > 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 > > Can we please drop the possibility of allowing IP numbers here? Yes! I'm all for it. It has one disadvantage, though, in that required glue information which has to be inserted in the zone file doing the delegation currently has no place in the domain object. Personally I do not view this as a great loss, it should however be noted. > 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. Indeed. > Also, we might add 'the first nserver listed is the primary for the zone' > > => "primary first" is in the text. Hmm, if I'm not totally mistaken, the concept of primaries and secondaries is a BINDism, and the concepts are likely to vanish some time in the not too distant future. Thus, I'm a little reluctant to mandate this usage. > > dom-net: The dom-net attribute contains the list of IP net- > > Can someone please explain why it is useful to record this? > Seems that this info might get outdated quickly as it isn't > related to the domain _name_. > > => 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. This attribute is essentially unmaintainable and quite difficult to check for as well (think about unannounced networks with no hosts registered in the "externally" viewable DNS tree). I think it should go into the dustbin. - Havard From Piet.Beertema at cwi.nl Wed Jan 18 10:18:58 1995 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 18 Jan 1995 10:18:58 +0100 Subject: do we need a meeting of the DNS TF ? In-Reply-To: "Your message of Tue, 17 Jan 1995 15:02:21 MET " <0098A9A3.CB217F58.4@cc.univie.ac.at> Message-ID: <9501180918.AA22435=piet@kraai.cwi.nl> [ $ set /me /mode=piet.b # :-) ] :-) I'm reluctant to drag this stuff (remaining in a state of being rare instead of well-done :-) into the DB-WG. Maybe I'm a bit too proud about the DB-folks, but I've got the impression recently that we managed to get various things and proposals discussed up to a useful point (by different means and methods) and then just put the finishing touch on top during the DB-WG meeting. Quite to the contrary, the DNS (-object stuff) is (and has been) tossed around for more than a year now, if I recall correctly. Listening to Piet's emontional announcement, I get the feeling that the DNS folks still have to make up their minds, one way or the other... In the DNS-WG on that RIPE meeting it was decided that the *sd and *ns attributes would change from mandatory into optional. But as far as I know it was the DB-WG that acted as showstopper becase they considered it their task to accept/reject changes and they didn't agree with these changes. Correct me if I'm wrong. If this indeed has happend, then a proposal for a changed object is welcome to be discussed within the DB-WG. Go ahead and talk, talk, talk. But it should be clear from my "emontional announcement" (which I consider quite to the point rather than emotional) that as far as I'm concerned it's far too late already for changes in the Domain object, the object effectively being dead because of it being unworkable and causing only headaches to domain registrars. Piet From Francis.Dupont at inria.fr Fri Jan 20 09:31:21 1995 From: Francis.Dupont at inria.fr (Francis Dupont) Date: Fri, 20 Jan 1995 09:31:21 +0100 Subject: DNS TF meeting Message-ID: <199501200831.JAA05643@givry.inria.fr> We'll have a DNS TF meeting. The main topic is still the domain object but I'd like to have a "bounded" discussion about it then I suggest to use strong arguments like "we have a tool using these set of attributes, this tool is available in ...". Don't remember that if you have no clear usage of the domain object then one can consider it only as a burden! Thanks Francis.Dupont at inria.fr From Piet.Beertema at cwi.nl Fri Jan 20 10:44:10 1995 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 Jan 1995 10:44:10 +0100 Subject: DNS TF meeting In-Reply-To: "Your message of Fri, 20 Jan 1995 09:31:21 +0100 " <199501200831.JAA05643@givry.inria.fr> Message-ID: <9501200944.AA04542=piet@kraai.cwi.nl> Don't remember that if you have no clear usage of the domain object then one can consider it only as a burden! The Domain object *is* a burden. Period. And so is the Person object. Piet From Jose.Legatheaux at puug.pt Fri Jan 20 11:19:41 1995 From: Jose.Legatheaux at puug.pt (Jose Legatheaux Martins) Date: Fri, 20 Jan 1995 11:19:41 +0100 (MET) Subject: DNS TF meeting In-Reply-To: <199501200831.JAA05643@givry.inria.fr> from "Francis Dupont" at Jan 20, 95 09:31:21 am Message-ID: <199501201019.AA19912@relay.puug.pt> > > We'll have a DNS TF meeting. The main topic is still the domain > object but I'd like to have a "bounded" discussion about it > then I suggest to use strong arguments like "we have a tool > using these set of attributes, this tool is available in ...". > Don't remember that if you have no clear usage of the domain > object then one can consider it only as a burden! > The Domain object *is* a burden. All the information that is really important already is in the DNS. That's why the domain object at european level is never updated. Drop this thing PLEEEAAASEEE. Jose' Legatheaux From Piet.Beertema at cwi.nl Fri Jan 20 11:36:00 1995 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 Jan 1995 11:36:00 +0100 Subject: DNS TF meeting In-Reply-To: "Your message of Fri, 20 Jan 1995 11:19:41 +0100 (MET) " <199501201019.AA19912@relay.puug.pt> Message-ID: <9501201036.AA04692=piet@kraai.cwi.nl> The Domain object *is* a burden. All the information that is really important already is in the DNS. That's why the domain object at european level is never updated. Drop this thing PLEEEAAASEEE. Thanks for your support, Jose. However, I want to be more precise: the Domain object *in the RIPE database* is a burden and should be dropped. A domain "entity" as such is not only useful, but by its very nature is something that is already well-maintained and therefore very up-to-date: by the top level domain registrar. Direct 'whois' access to that information is and stays useful, because not *everything* is in DNS; it can't even be without overloading [cache/memory] of nameservers and hosts all over the Internet. The current RIPE 'whois' access however is well-established, which is why I've suggested to drop all Domain objects except for a special one ("*td") for the top level domains, which would then contain an attribute ("*ws") pointing to the whois server for that top level domain. RIPE's whois server can than act as a "forwarder" for requests for . (much like DNS!), thus keeping the current whois service, but resulting in far more up-to-date and reliable information. Besided, the whois servers that located where the top level domain itself is administered can serve more purposes, like immediately notifying the maintainer of any inconsistencies between the administration and the top level zone file. Piet From Marten.Terpstra at ripe.net Fri Jan 20 11:52:54 1995 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 20 Jan 1995 11:52:54 +0100 Subject: DNS TF meeting In-Reply-To: Your message of Fri, 20 Jan 1995 11:36:00 MET. <9501201036.AA04692=piet@kraai.cwi.nl> Message-ID: <9501201052.AA02597@ncc.ripe.net> * over the Internet. The current RIPE 'whois' * access however is well-established, which is * why I've suggested to drop all Domain objects * except for a special one ("*td") for the top * level domains, which would then contain an * attribute ("*ws") pointing to the whois server * for that top level domain. RIPE's whois server * can than act as a "forwarder" for requests for * . (much like DNS!), * thus keeping the current whois service, but * resulting in far more up-to-date and reliable * information. Besided, the whois servers that Commenting here from a RIPE database implementers' point of view, this can be done. The database software will have to be taught how domains work similar to more/less specifics for IP addresses and how to forward queries. Again, as with most changes to the software this will take time. And general concensus of course..... It's the folks involved with the DNS objects that need to push this, not the NCC. -Marten From Piet.Beertema at cwi.nl Fri Jan 20 12:51:11 1995 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 Jan 1995 12:51:11 +0100 Subject: DNS TF meeting In-Reply-To: "Your message of Fri, 20 Jan 1995 11:52:54 +0100 " <9501201052.AA02597@ncc.ripe.net> Message-ID: <9501201151.AA04869=piet@kraai.cwi.nl> .... except for a special one ("*td") for the top level domains, which would then contain an attribute ("*ws") pointing to the whois server for that top level domain. RIPE's whois server can than act as a "forwarder" for requests for . (much like DNS!), thus keeping the current whois service, but resulting in far more up-to-date and reliable information. Commenting here from a RIPE database implementers' point of view, this can be done. Good. Actually I didn't expect otherwise. Again, as with most changes to the software this will take time. Hours? ;-) And general concensus of course..... It's the folks involved with the DNS objects that need to push this, not the NCC. True. Although I'd say it's in the interest of the NCC too to keep the whois service running, or the current service will simply die as far as information about domains is concerned. Piet From woeber at cc.univie.ac.at Fri Jan 20 13:45:19 1995 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 20 Jan 1995 13:45:19 MET Subject: DNS TF meeting Message-ID: <0098ABF4.87C43838.42@cc.univie.ac.at> Dear Piet! Direct 'whois' access to that information is and stays useful, because not *everything* is in DNS; it can't even be without overloading [cache/memory] of nameservers and hosts all over the Internet. The current RIPE 'whois' access however is well-established, which is why I've suggested to drop all Domain objects except for a special one ("*td") for the top level domains, which would then contain an attribute ("*ws") pointing to the whois server for that top level domain. RIPE's whois server can than act as a "forwarder" for requests for Unfortunately I didn't find the spare cycles to dive into the rwhois project info, but I think there could be some hidden synergy. Do you have any ideas on this aspect? Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- From Piet.Beertema at cwi.nl Fri Jan 20 14:27:08 1995 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 Jan 1995 14:27:08 +0100 Subject: DNS TF meeting In-Reply-To: "Your message of Fri, 20 Jan 1995 13:45:19 MET " <0098ABF4.87C43838.42@cc.univie.ac.at> Message-ID: <9501201327.AA05249=piet@kraai.cwi.nl> Unfortunately I didn't find the spare cycles to dive into the rwhois project info, but I think there could be some hidden synergy. Do you have any ideas on this aspect? Well, actually it's quite trivial: - What the RIPE NCC has to do is to implement a new "Topdomain" object, with absolutely minimal information in the database: *td: nl *de: Top level domain for the Netherlands *ws: .nl *mb: *so: RIPE where the presence of *td would signal to the whois server software that queries for both NL and .NL must be forwarded to the whois server specified in the *ws attribute. - A top level domain registry has 2 options then: 1) If it can't provide reliable whois service itself (yet): stick to the current situation, feeding the RIPE database with domain objects. Not ideal, since the Domain object in the RIPE database really should disappear, and I'm not the only one who thinks about it that way. 2) Provide its own whois service. This service would be accessible directly or indirectly via 'whois -h whois.ripe.net '. This whois service should preferably run on the same host that is the primary nameserver for the top level domain, although of course this is not mandatory. The NL whois server is almost finished. In fact it's just a shell script. And of course, once it's finished and works well, I'm willing to give it to other TLD registrars. The script will include notifying the registrar in case of discrepancies between the administration and the zone file, from both of which the script will take its information. Piet From Piet.Beertema at cwi.nl Fri Jan 20 20:37:15 1995 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 20 Jan 1995 20:37:15 +0100 Subject: Announcement to DB-WG Message-ID: <9501201937.AA06153=piet@kraai.cwi.nl> >From experience on/with previous RIPE meetings my conclusion was that the DB-WG didn't accept decisions made by the DNS-WG on the Domain object. Which is why I sent my "explosive" announcement to the DB-WG only (and to the NCC). But that means some people who are in de DNS-WG, but not in the DB-WG, have missed it. So just for completeness and FYI, I'm including the complete text of the message I sent to the DB-WG and the NCC. I think the text speaks for itself. Piet ----------------------------------------------------------------- To: ncc at ripe.net, db-wg at ripe.net Subject: Announcement Fcc: RIPE I've been following the recent umpteenth (...) discussion on the domain object in the RIPE database. I haven't commented on it though, since frankly I couldn't care less anymore. As NL domain registrar I have had - and am having - increasing problems with the *lot* of extra work caused by trying to keep the RIPE database up-to-date as far as .NL (primary) subdomains are concerned. For one thing, the - perceived or real, that has never become clear in all the discussions on the domain object - need to maintain information that is completely irrelevant for maintaining a domain administration is a hassle. But it's far more a nuisance that the RIPE database has "person" objects that in itself are an absolute kludge, in that they are invisibly related to in any other sense completely unrelated things like network objects and domain objects. The mere presence of these objects in the RIPE database gives the impression that RIPE is trying to keep sort of a worldwide phone directory, but then a "gambling" one: whether or not one will find a person in it is pure luck: you'll find it if the person happens (or happened!) to be related to a network or a domain object, otherwise not. A random generator would do about as well... The person object, because of its linking to different other objects, is also a nuisance in another respect: it calls for the need of "handles", where there is no such need whatsoever if the NL domain administration would be maintained completely seperate from the [setup of the] RIPE database. >From the above it should be clear that, as NL domain registrar, I'm sick and tired of all the extra work caused by the "feed" given to the RIPE database. I want to strongly emphasize here that there in NO OBLIGATION whatsoever for any [top level] domain registrar to "feed" the RIPE database and/or to keep the administration of the domain in accordance with or modeled after the RIPE database. What I'm saying below is therefore an OFFICIAL STATEMENT, and NOT a call for discussion. Included in it is an invitation to the RIPE NCC - as maintainers of the RIPE database and of the related software - and to the DB-WG, for a change in the setup of the database and software. I probably won't be far off if I'm saying that I think that I'm not the only [top level] domain registrar having problems like the ones described. I'm willing to illustrate and discuss on the forthcoming RIPE meeting the sort of problems that the current setup of the RIPE database is posing, even though I've done the same on previous RIPE meetings (albeit in the DNS-WG then). But it should be very clear that this will *not* lead to revoking the statement below and the actions announced in it. The time of endless discussions is really over. I have to "spit in the hands and get to work", without the work being hampered by external factors and matters of taste (which for a large part dominate the whole discussion on objects in the RIPE database). Piet ********************************************************************** * The NL naming authority is planning to change the setup of the * * NL domain administration, to make it possible to keep up with * * the ever increasing number of domain registrations, without an * * unnecessary amount of work posed by "external factors". * * Such an "external factor" is the regular feed of the RIPE whois * * database with complete .NL (primary) subdomain info, calling for * * the need of maintaining in said administration information that * * is not relevant for the purpose of said administration, but only * * for the "external factors". * * Because of the above mentioned change in setup, the information * * in the NL domain administration will no longer be compatible with * * the "domain objects" and "person objects" in the RIPE database. * * Feeding the RIPE database with said information will therefore * * stop. Thereafter anyone is free to enter .NL subdomain objects * * (in fact that's the case already, since there is no protection * * against entering such objects - only against changes), but it * * should be very clear that from the viewpoint of the NL domain * * registration such entries are NOT authoritative. * * * * The NL naming authority recognises the value of a whois service. * * Therefore the NL naming authority will make sure that a whois * * service for .NL (primary) subdomains will be provided, through * * a whois server [to be] set up by the NL naming authority. * * The NL naming authority at the same time recognises that the * * RIPE whois server is known worldwide and that people have come * * to rely on it. Therefore an invitation is enclosed below to the * * RIPE NCC - and to the DB-WG - for a change in the database and * * its software to make it possible that the "RIPE whois service" * * is maintained, with automatic referral of the NL domain info * * on requests for such info. * * * * As soon as the mentioned change of setup has been completed and * * the mentioned whois server made operational, all .NL subdomain * * objects will be removed from the RIPE database, leaving only a * * "minimised" entry for the NL top level domain itself, which will * * then look as follows: * * *dn: nl * * *de: Top level domain for the Netherlands * * *rm: Information about .NL (primary) subdomains can be * * *rm: obtained with "whois -h .nl .nl" * * * * As mentioned above, here is an invitation for a change in the * * RIPE database/software to automate the referral to NL domain * * info on queries directed to the RIPE whois server. Described in * * RIPE database format, after the change of the database/software, * * the "minimised" entry for the NL top level domain would be: * * *td: nl * * *de: Top level domain for the Netherlands * * *ws: .nl * * The "ts" attribute would signal this entry as a top level domain * * to the db/whois software, causing forwarding of the query to the * * listed whois server for both the top level domain itself and for * * any .nl query. This shouldn't sound unfamiliar: it's an * * almost complete analogon of DNS, with the exception that RIPE is * * not "delegating" any top level domain. * * This change/addition has been proposed to the RIPE NCC a couple * * of months ago already, but has met with no reaction whatsoever. * * This announcement is therefore also meant to evoke a reaction * * from the RIPE NCC on this issue/proposal. * * It is clear that the above construction introduces a completely * * new element in the RIPE database/software: an entry for a top * * level domain (NL) implicitly standing for subdomains (*.NL) of * * it. So it might not be trivial to implement it. Still we think * * the RIPE NCC people will be able to handle it. * ********************************************************************** For your information, I'm adding here what the NL domain administration will look like after the changes, in "RIPE database notation": *dn: *on: *cc: *ad: *) *ac: *ph: **) *em: *tc: *ph: **) *em: *st: ("MX-only" or "delegated") *dr: *dc: *) P.O. Box is *not* (since 1-1-95) accepted here. **) Fax number might be added, but the value of it seems next to zero, given that some 80% of all registered NL subdomains don't list a fax number of contact persons. That's all. An entry with all the really *necessary* information for the domain administration, without irrelevant bells and whistles. Things like nameservers are not included in an entry: that's information that belongs in and is entered in DNS, i.e. the NL zone file. If people feel the need to find that information, then there are plenty of tools (dig, nslookup, host) to find it in DNS. The *st field in the administration gives an indication of what can/should be expected there. If people are too lazy to query DNS, they're not interested in the information. Period. One note: some of the fields given above will not be presented on queries to the NL whois server; *cc is one of them, probably also *dr and *dc. Other fields may be added at any time, as need arises. It should be clear that the setup eliminates any need for a "handle". Sure enough, this change will also have the effect that there will be no more automatic "notification feedback" from the RIPE database in case the data of a person change. But that happens so rarely that I can live with that. Besides, changes pertaining to an NL (primary) subdomain *must* be sent to the NL registrar, not to RIPE.