Here are proposals about the RIPE DB domain object definition Francis.Dupont@inria.fr Some mandatory entries should become optional (i.e. can be missing): - zone-c (zone contact(s)) when the domain is not a zone (technically: it has no SOA RR), for instance MX only domains have no zone contacts. - nserver (name servers) is in the same case - sub-dom (sub domain(s)) when there is no sub domains Some important entries should be redefined: - nserver (name servers): the new syntax should be: (*) name [ (address)+ ] with a star for unpublished (secondary) name servers, fully qualified domain name of the name server and the list of the IP addresses of the name server. We have to write a detailed description of this, for instance what are the mandatory fields, what are unpublished ns, ... - sub-dom (sub domains): this entry should be either not present or not empty. Domain names should be fully qualified (change). New entries like the "notify" entry must be added (it is in the scope of of RIPE DB WG but we have to produce an up to date document about domain object)
Some mandatory entries should become optional (i.e. can be missing): - zone-c (zone contact(s)) when the domain is not a zone (technically: it has no SOA RR), for instance MX only domains have no zone contacts. At last... Good! Some important entries should be redefined: - nserver (name servers): the new syntax should be: (*) name [ (address)+ ] with a star for unpublished (secondary) name servers, What's the use of that??? Do you really see a domain registrar chasing each and every subdomain in search for unpublished nameservers? The term "unpublished" is already a clear indication that it shouldn't be listed.... fully qualified domain name of the name server and the list of the IP addresses of the name server. Either one should do, so it should be name|address Piet
Some important entries should be redefined: - nserver (name servers): the new syntax should be: (*) name [ (address)+ ] with a star for unpublished (secondary) name servers, Why restrict this to secondary servers ? While it might really become a problem to hold this list up-to-date, it is more important to have information about a probably hidden (or "unpublished") primary server in the database.
fully qualified domain name of the name server and the list of the IP addresses of the name server. To avoid any duplication of information inside the db, this should probably be done with DNS glue logic in mind: Specify the IP address(es) iff the server resides inside the described domain. Having just the addresses does not seem very readable to me, so the server name should be mandatory. Further it might improve readability if we allow just one item per *nserver: field. Any changes here imply changes to the *rev-srv: field in the network object.
- sub-dom (sub domains): this entry should be either not present or not empty. Domain names should be fully qualified (change).
How can I then interpret the list of "domains" shown by the sub-dom fields ? Does it have to be a complete list of subdomains, if not empty ? How is completeness determined in this case ? To become concrete: If I have a DNS object (2nd level domain in this case), e.g. for Uni-Bielefeld.DE, which "subdomains" are to be listed in the sub-dom field ? We have two delegated zones (==subdomains), some not-leaf subdomains (department domains administered within the Uni-Bielefeld.DE zone) and their subdomains (in fact, these are mostly the hosts) and even some leaf domains (mostly hostnames, but also departmental "mail catchers") directly under Uni-Bielefeld.DE . Hostnames are surely not all candidates for the sub-dom (?), whereas the delegated subzones are. What about the rest ? I suggest to list a domain in the sub-dom field iff there is another domain object describing this domain. -Peter
Having just the addresses does not seem very readable to me, so the server name should be mandatory. Pray tell, why should "foo.bar" be more `readable' 1.2.3.4??? I would even go further: nameserver information in the domain object is utterly useless and only clogging the database; the nameserver information belongs in the nameserver, not in the database: then it's only duplication of information that's not serving any real purpose. So drop the n-server entries! Piet
Pray tell, why should "foo.bar" be more `readable' 1.2.3.4??? With a human reader in mind I preferred domain names over IP addresses. This is also a nearer to DNS (I know, I know), you do specify hosts there as servers, not (sets of) IP# .
I would even go further: nameserver information in the domain object is utterly useless and only clogging the database; the ~~~~~~~ We have not yet heard about the idea of publishing unpublished secondaries this way and as I pointed out already it is useful to be able to announce "hidden" primaries. It is also useful to be able to find out the primary server (it is the first in the list), even if it is not "hidden". With proper DNS setup this information should be coded into the SOA RR, but experience shows that this is done wrong often. (OK, I wonder how and why the correct information shall find its way into the DB.)
nameserver information belongs in the nameserver, not in the database: then it's only duplication of information that's not serving any real purpose. So drop the n-server entries!
This should hold for more fields - the dom-net is available in the DNS by RFC1101 style coding, zone-c is coded into the SOA and admin-c and tech-c can then be announced via RP records. Anything left for the domain object ? -Peter
participants (3)
-
Francis Dupont -
Peter Koch -
Piet Beertema