RIPE DB domain object

[Francis Dupont <]

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

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@localhost
Subject: Re: Removal nameserver an rev-srv tags 
Date: Tue, 24 May 1994 10:33:08 +0200
From: Piet Beertema <Piet.Beertema@localhost

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