Fundamental problem with mandatory field zone-c
domain: AIC.DE descr: AIC Software GmbH descr: Muenchen admin-c: Gottfried Bartmuss tech-c: Gottfried Bartmuss source: RIPE *ERROR*: mandatory field "zone-c" missing *ERROR*: mandatory field "changed" missing ; <<>> DiG 2.0 <<>> @deins.informatik.uni-dortmund.de aic.de. any ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 1 ;; QUESTIONS: ;; aic.de, type = ANY, class = IN ;; ANSWERS: aic.de. 86400 MX 190 mail.Germany.EU.net. ;; ADDITIONAL RECORDS: mail.Germany.EU.net. 86400 A 192.76.144.65 ;; Sent 1 pkts, answer found in time: 18 msec ;; FROM: foobar to SERVER: deins.informatik.uni-dortmund.de 192.35.64.34 ;; WHEN: Fri Nov 26 11:42:36 1993 ;; MSG SIZE sent: 24 rcvd: 75 There is no zone for aic.de, thus there is no zone contact. Opinions ? Andreas Schachtner afs@Germany.EU.net === ____ === EUnet Deutschland GmbH === / / / ___ ___ _/_ === Emil-Figge-Str. 80 === /---- / / / / /___/ / === D-44227 Dortmund === /____ /___/ / / /___ / === ===== ===== Tel. +49 231 972 00 ===== Connecting Europe since 1982 ===== Fax +49 231 972 1111
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) Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB DE-NIC D-44221 Dortmund, Germany E-Mail: rv@Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386
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
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...
You did that yourself: From: Ruediger Volk <rv@deins.informatik.uni-dortmund.de> To: auto-dbm@ripe.net Cc: ripe-dbm@deins.Informatik.Uni-Dortmund.DE Subject: get rid of outdated German domain entries Date: Thu, 25 Nov 1993 11:36:35 +0100 Message-Id: <17273.754223795@seins.Informatik.Uni-Dortmund.DE> ... *dn: AIC.DE *de: AIC Software GmbH *de: Muenchen *ac: Gottfried Bartmuss *tc: Gottfried Bartmuss *so: RIPE delete: rv@Informatik.Uni-Dortmund.DE old junk - hope to get better current st uff ...
participants (6)
-
Andreas Schachtner
-
Daniel Karrenberg
-
Havard Eidnes
-
Marten Terpstra
-
Piet Beertema
-
Ruediger Volk