From arthur at midir.ucd.ie Thu Nov 11 16:14:48 1993 From: arthur at midir.ucd.ie (Arthur Green) Date: Thu, 11 Nov 93 15:14:48 GMT Subject: Query: What to do if you use an A record but can't handle mail Message-ID: <9311111514.AA05731@midir.ucd.ie> Gentlemen - Apologies for intruding in this manner, but I have a query for which the usual sources don't seem to have an answer. What is the collective wisdom on providing A records (for Internet access) but stopping mail access? There are a large number of machines here in University College Dublin which require Internet access but can't run a SMTP server (they're PC and the like). I want to ensure that anyone trying to send mail to them gets a prompt refusal -- what I plan to do to is provide a DNS entry like this: toaster.ucd.ie. IN A 137.43.2.29 toaster.ucd.ie. IN MX undeliverable.ucd.ie. The host undeliverable.ucd.ie doesn't exist, which should as far as I know return a prompt "can't deliver mail" message. So, is this how other people do it? Is this the right way? Is there a better way? Any and all suggestions will be gratefully received. - Arthur Green University College Dublin Computing Services Tel: +353 1 706 2456 Fax: +353 1 283 7077 E-mail: arthur at midir.ucd.ie From bonito at nis.garr.it Thu Nov 11 18:02:39 1993 From: bonito at nis.garr.it (Antonio_Blasco Bonito) Date: Thu, 11 Nov 93 18:02:39 MET Subject: Query: What to do if you use an A record but can't handle mail In-Reply-To: <9311111514.AA05731@midir.ucd.ie>; from "Arthur Green" at Nov 11, 93 3:14 pm Message-ID: <9311111702.AA26134@jolly.nis.garr.it> > > Gentlemen - > Apologies for intruding in this manner, but I have a query for which > the usual sources don't seem to have an answer. > > What is the collective wisdom on providing A records (for Internet access) but > stopping mail access? There are a large number of machines here in University > College Dublin which require Internet access but can't run a SMTP server > (they're PC and the like). I want to ensure that anyone trying to send mail to > them gets a prompt refusal -- what I plan to do to is provide a DNS entry > like this: > > toaster.ucd.ie. IN A 137.43.2.29 > toaster.ucd.ie. IN MX undeliverable.ucd.ie. > > The host undeliverable.ucd.ie doesn't exist, which should as far as I know > return a prompt "can't deliver mail" message. So, is this how other people do > it? Is this the right way? Is there a better way? Any and all suggestions will > be gratefully received. > > > - Arthur Green > University College Dublin Computing Services > Tel: +353 1 706 2456 Fax: +353 1 283 7077 E-mail: arthur at midir.ucd.ie > If the PC has no smtp server listening on TCP port 25 and you have no MX record for it mailers trying to deliver mail will get "Connection refused by ..." which should be enough I guess. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito at nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ---------- From Marten.Terpstra at ripe.net Fri Nov 26 12:17:11 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 26 Nov 1993 12:17:11 +0100 Subject: Fundamental problem with mandatory field zone-c In-Reply-To: Your message of Fri, 26 Nov 1993 12:07:18 MET. <20510.754312038@seins.Informatik.Uni-Dortmund.DE> Message-ID: <9311261117.AA08770@ncc.ripe.net> Ruediger Volk 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 ... From Daniel.Karrenberg at ripe.net Fri Nov 26 14:10:20 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 26 Nov 1993 14:10:20 +0100 Subject: Fundamental problem with mandatory field zone-c In-Reply-To: Your message of Fri, 26 Nov 1993 12:17:11 MET. <9311261117.AA08770@ncc.ripe.net> Message-ID: <9311261310.AA09193@ncc.ripe.net> > Marten Terpstra 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 From Piet.Beertema at cwi.nl Fri Nov 26 14:46:27 1993 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Fri, 26 Nov 1993 14:46:27 +0100 Subject: Fundamental problem with mandatory field zone-c In-Reply-To: Your message of Fri, 26 Nov 1993 14:10:20 +0100 . <9311261310.AA09193@ncc.ripe.net> Message-ID: <9311261346.AA20736=piet@kraai.cwi.nl> 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 From Havard.Eidnes at runit.sintef.no Fri Nov 26 22:29:46 1993 From: Havard.Eidnes at runit.sintef.no (Havard Eidnes) Date: Fri, 26 Nov 1993 22:29:46 +0100 Subject: Fundamental problem with mandatory field zone-c In-Reply-To: Your message of "Fri, 26 Nov 1993 14:46:27 +0100." <9311261346.AA20736=piet@kraai.cwi.nl> Message-ID: <199311262129.WAA02153@spurv.runit.sintef.no> > 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 at 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