Re: Fundamental problem with mandatory field zone-c
Ruediger Volk <rv@deins.informatik.uni-dortmund.de> writes * Andreas writes: * > There is no zone for aic.de, thus there is no zone contact. * and the data base entry for AIC.DE is gone also... * * > Opinions ? * possible ways out: * * (a) drop domain entries completely * (b) don't register MX-only domains (in RIPE db) * (c) make zone-c optional (with the convention that this is only allowed * for MX-only domains) * (d) insert the zone contact for MX-only - defaulting to zone-c of * the zone containing the MX * * I vote for (c) In the past (Blasco has mentioned this before) we said to include the zone-c of the parent zone, since he/she maintains the MX records. This is Ruediger's option (d). Looking at the number of syntax errors in the database currently for domains, and the population, I would even vote for (a) or (b), but this has been rejected by the dns-wg on several occassions (on very good grounds). The question was and is whether the domain objects give added information compared to what is in the DNS. With 4.9 and the TXT and RP RRs I am not quite sure if these grounds still hold ... Other opinions ? -Marten PS I have CCed the dns-wg as well ...
Marten Terpstra <Marten.Terpstra@ripe.net> writes:
In the past (Blasco has mentioned this before) we said to include the zone-c of the parent zone, since he/she maintains the MX records.
Sounds reasonable!
Looking at the number of syntax errors in the database currently for domains, and the population, I would even vote for (a) or (b), but this has been rejected by the dns-wg on several occassions (on very good grounds). The question was and is whether the domain objects give added information compared to what is in the DNS. With 4.9 and the TXT and RP RRs I am not quite sure if these grounds still hold ...
Can the DNS WG please put this on the agenda again and provide a paper with a comparison of what can be put in the DNS versus what is in the database. Once that's done the DNS and db working groups can make a recommendation which is written up and can be referenced. Daniel A personal HFl-.02's worth: One positive aspect about domain objects in the database is that it gives TLD registrars a well defined format to keep their administration, at least a minimal version. The database then provides a way to make that available by another means than the DNS. I am convinced that if *all* TLD registrars kept at least this level of administration it would improve many a TLD registry. Daniel
In the past (Blasco has mentioned this before) we said to include the zone-c of the parent zone, since he/she maintains the MX records. Sounds reasonable! Not at all: by the same token one could argue that the person maintaining a top level zone file should be registered as the zone-c for every primary subdomain, since (s)he maintains the NS records [in the top level zone file], just like in the case of MX-only domains (s)he maintains the MX records [in the top level zone file]. I've always just copied the admin-c into the zone-c in these cases, for the simple reason that there is no such thing as a zone for an MX-only domain and the admin contact can be held equally well responsible for the MX records, even though (s)he doesn't put/maintain them in the next higher zone file, as is the case with NS records. I would suggest to consider the presence of the *zc attribute mandatory only if *ns attributes are present in the domain entry. Piet
In the past (Blasco has mentioned this before) we said to include the zone-c of the parent zone, since he/she maintains the MX records. Sounds reasonable! Not at all: by the same token one could argue that the person maintaining a top level zone file should be registered as the zone-c for every primary subdomain, since (s)he maintains the NS records [in the top level zone file], just like in the case of MX-only domains (s)he maintains the MX records [in the top level zone file].
Well, this is an example of what I presently do with the few domains under "no" that are registered in the RIPE database (and which are of the "MX-only" variant): domain: fdata.no descr: Fellesdata A/S, Oslo admin-c: Geir Engebakken tech-c: Geir Engebakken zone-c: Uninett Hostmaster remarks: MX-only, maintained in "no" zone changed: Havard.Eidnes@runit.sintef.no 931124 source: RIPE
I've always just copied the admin-c into the zone-c in these cases, for the simple reason that there is no such thing as a zone for an MX-only domain and the admin contact can be held equally well responsible for the MX records, even though (s)he doesn't put/maintain them in the next higher zone file, as is the case with NS records.
Well, in case of DNS trouble (misconfiguration or similar lossage), the "zone-c" would in this case point in the wrong direction, no? Maybe the definition of "zone-c" should be refined to something like The zone contact for the zone where the authoritative data for the domain is registered. Note that in the case of a fully delegated domain, the NS records in the parent zone are actually not authoritative.
I would suggest to consider the presence of the *zc attribute mandatory only if *ns attributes are present in the domain entry.
Maybe worth discussing? (My initial reaction was "yes, this sounds great!", but after thinking about it for a while and reformulating the response to the previous paragraph, I'm not so sure anymore.) - Havard
participants (4)
-
Daniel Karrenberg -
Havard Eidnes -
Marten Terpstra -
Piet Beertema