X-MHE-Checksum: 713bbdbbcea96ad7a6bd1c8b508de7cf To: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... In-Reply-To: Message from Mark.Andrews@nominum.com of "Tue, 27 Feb 2001 13:40:10 +1100." <200102270240.f1R2eAh67515@drugs.dv.isc.org> Date: Mon, 26 Feb 2001 19:49:55 -0800 From: Paul A Vixie X-Evolution: 00000347-0000 > If you want example.com to be an alias lobby the Internic to allow > CNAMES to be added to the COM zone. Other registries allow it, > however you have a to choose between that and a delegation. The cases aren't parallel. What nobody but me seems to realize about this proposal is that it makes CNAME's nonterminal. If erik.com had both a CNAME and an SOA (or in Mark's example, a CNAME and an NS in the delegating zone) then the meaning of www.erik.com becomes quite undefined. This whole thing is silly. > It's not been abandoned. It's NEVER been allowed. For the benefit of the gallery, here's what happened on bind-bugs@isc.org when Erik wanted 8.2.3 to propagate the same bad data that 8.2.2 had done. (This is just how it ended, and as you can see, I had by then lost my temper.) ------- Forwarded Messages To: Erik Aronesty cc: "'Mark.Andrews@nominum.com'" , Erik Aronesty , Michael Krebs , "bind-bugs@isc.org" Subject: Re: [BIND-BUGS #4054] root CNAME error in new version In-Reply-To: Message from Erik Aronesty of "Tue, 30 Jan 2001 23:06:30 EST." <01C08B11.48C97100@INSIDE> Date: Tue, 30 Jan 2001 20:26:17 -0800 From: Paul A Vixie i keep thinking this is a joke, and yet you keep acting as if you're serious. > If a CNAME exists at the root, it MUST NOT have any other records, > including an SOA and a NS. > > So, if BIND intends to follow the RFC fully, then it must allow a > CNAME to fully define the root of the zone. > > To repeat: > > OWNER IN CNAME CANONICAL-NAME > > ****The resolver goes to the canonical name for the SOA and the NS.**** > > To reiterate my email to Paul: > > > > > I would propose that if you want to really get CNAME's right, BIND > > > > should allow "*either*" a CNAME or an SOA/NS pair to define the > > > > root of a zone, and never both. everything you have said about CNAMEs refers to query behaviour. now pay some attention to the zone content and zone service behaviour. [RFC1034] | 4.2.1. Technical considerations | ... | - Data that defines the top node of the zone (can be thought of | as part of the authoritative data). | ... | Though logically part of the authoritative data, the RRs that describe | the top node of the zone are especially important to the zone's | management. These RRs are of two types: name server RRs that list, one | per RR, all of the servers for the zone, and a single SOA RR that | describes zone management parameters. this doesn't admit the possibility you wish it did. furthermore: | 4.3.4. Negative response caching (Optional) | ... | Note that in some circumstances, the answer section may contain multiple | owner names. In this case, the SOA mechanism should only be used for | the data which matches QNAME, which is the only authoritative data in | this section. QNAME would be an alias in the case you're attempting to describe, and the SOA would not be able to describe it (since there is no SOA there.) (CNAME synthesis works in the answer section but NOT in the authority section or the additional data section.) furthermore, AXFR is not a query and must not follow CNAME's. so the "zone" you wish you were creating would not be transferrable. furthermore, CNAME aliased SOA's could be higher up in the DNS hierarchy than the original alias, which could lead to loops if zone transfers were allowed. furthermore, in RFC1035 we see: | 5.2. Use of master files to define zones | | When a master file is used to load a zone, the operation should be | suppressed if any errors are encountered in the master file. ... | ... | Several other validity checks that should be performed in addition to | insuring that the file is syntactically correct: | ... | 2. Exactly one SOA RR should be present at the top of the zone. so, while loading a zone, it is not a requirement to look at any other zone in order to determine its syntactic correctness. in your imaginary world, a zone's correctness could only be determined by examining out-of-zone data. isc remains deeply apologetic that prior versions of BIND did not properly catch the configuration error that you appear to have built your business on. however, there are workarounds, and i suggest that rather than wasting more of your time and our time arguing about it, you get to work on implementing one. paul ------- Message 2 To: Erik Aronesty cc: "'Mark.Andrews@nominum.com'" , Erik Aronesty , Michael Krebs , "bind-bugs@isc.org" Subject: Re: [BIND-BUGS #4054] root CNAME error in new version In-Reply-To: Message from Erik Aronesty of "Wed, 31 Jan 2001 10:13:50 EST." <01C08B6E.8272A9F0@INSIDE> Date: Wed, 31 Jan 2001 08:44:05 -0800 From: Paul A Vixie > 1. The RFC1034 specification of a CNAME allows for a CNAME at the root of > a zone. No, it does not. > Your response, though it seems correct, does not address this at all. I'm done arguing with you about this. Please reread the RFC's and reread what I wrote to you previously. ------- End of Forwarded Messages