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@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@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@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