Re: cnames are in conflict with soa's...

[Paul A Vixie <vixie@mfnx.net>]

> 	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 <erik@primedata.org>
cc: "'Mark.Andrews@nominum.com'" <Mark.Andrews@nominum.com>,
    Erik Aronesty <support@zoneedit.com>,
    Michael Krebs <mkrebs@zoneedit.com>,
    "bind-bugs@isc.org" <bind-bugs@isc.org>
Subject: Re: [BIND-BUGS #4054] root CNAME error in new version 
In-Reply-To: Message from Erik Aronesty <erik@primedata.org> 
   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 <vixie@redpaul.mfnx.net>

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 <erik@primedata.org>
cc: "'Mark.Andrews@nominum.com'" <Mark.Andrews@nominum.com>,
    Erik Aronesty <support@zoneedit.com>,
    Michael Krebs <mkrebs@zoneedit.com>,
    "bind-bugs@isc.org" <bind-bugs@isc.org>
Subject: Re: [BIND-BUGS #4054] root CNAME error in new version 
In-Reply-To: Message from Erik Aronesty <erik@primedata.org> 
   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 <vixie@redpaul.mfnx.net>

> 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



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.