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

From: "Erik Aronesty" <[email-masked]>
Date: Mon, 26 Feb 2001 19:59:58 -0500

To be more clear:

A. Confusing usage

In order to create a CNAME for a domain, it is necessary to create a parent
node, and then add the CNAME within it.  However, you do not have to be
authoritative for the parent node.  This forces the DNS user to make odd
configuration choices to get CNAME's to work in the case where he is not
authoritative for the parent.

For example: in order to CNAME "foo.com" it is currently necessary to create
a "com" zone, and add a "microsoft" domain to it.  This works well - however
it is a potentially confusing configuration.

This same analogy holds for all levels of the DNS tree.

The reason why this is necessary is that SOA RR's are required for all
zones - but CNAME records cannot coexist with SOA RR's.

B. Misleading information

1) Currently, in the case of CNAME's the authority section, if present,
returns information about the alias - not the target.  2) When requesting an
SOA record for a name that has been aliased to another - the SOA record of
the target is returned.  3) The SOA record of the target contains
information that is misleading in any circumstances.

Clearly CNAMEs are, as currently implemented a source of confusion and
excessive technical support for DNS maintainers.

It appears there are three solutions:

    1- allow CNAMEs to coexist with SOA records
    2- create a new query type (IE: DNAME, as proposed) which has a pure,
recursive implementation
    3- make CNAME's obsolete

Also:

The majority of DNS software currently supports CNAME's alongside SOA
records - without any negative effects (because the majority of DNS software
is based on BIND 8.2.2 or prior versions - which supported this).  So, the
negative impact of allowing this would be minimal.

The positive impact would be that CNAME's could be used at the root of a
zone - which, for a long time, was a excellent DNS feature that has recently
been abandoned.

                - Erik

----- Original Message -----
From: "Erik Aronesty" <[email-masked]>
To: <[email-masked]>; "Paul A Vixie" <[email-masked]>
Sent: Monday, February 26, 2001 7:03 PM
Subject: Re: cnames are in conflict with soa's...

> > > However, NS RR's that are "required to be present" should only be used
> for
> > > authoritative server lists - not delegations - in the case of a CNAME
on
> a
> > > domain.
> >
> > There is no such thing as a "CNAME on a domain" (zone cut).  A given
name
> > is either an alias, or it's not an alias.  Zones have names.  Not
aliases.
>
> Sorry, on an alias.
>
> >
> > > Also, all CNAMRE responses have an "authority section" -
> >
> > Untrue.  And especially out-of-zone CNAME's (which is what your proposal
> is)
> > the only SOA you can put into the authority section is about the query
> name,
> > never the target name of the alias.
>
> Right... which is why the current technique of chaining SOA's in some
> contexte - but not in others is goofy.
>
> > > It should be formalized - that's all.
> >
> > It already is:  "Don't try that, DNS doesn't work that way."
>
> Actually, DNS does work that wa and has worked that way for many many
years.
> BIND 8.2.3 doesn't work that way.  All other DNS resolvers and libraries
> work just fine, and work that way.
>
>
> >
> >
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> >
>

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked]
Date: Tue, 27 Feb 2001 13:40:10 +1100

Eric, why do you want a CNAME at the top of zone?  Is it because
	you have a another party hosting your HTTP service?  There is DNS
	resource record specifically for supporting this sort of thing,
	it is called SRV which provides a generalised form of the MX
	record.  It has been around since 1996.

	Now you will find it much easier to update all the http clients
	in the world than it will be to update all the DNS servers in
	the world.  For one thing, people are used to updating HTTP
	clients.  Secondly it is a better solution.

	Of course if we go down your track you can't arange to get your
	mail delivered to a different box than where the mail is delivered
	for box hosting the HTTP traffic.

	People want to be able to say

	@		MX 0 mail.example.com.
	_http._tcp	SRV ... http.example1.net.
	_ftp._tcp	SRV ... ftp.example2.net.
	_kerberos._udp	SRV ... kdc.example.com.

	This is the solution space you should be aiming at.  Complain
	to Netscape, Microsoft etc. saying that you want SRV support
	in the browsers, ftp client etc.
	
> it is a potentially confusing configuration.

	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.

> returns information about the alias - not the target.

	You are getting back a negative answer here.  If you don't
	understand why you are getting the SOA record from the
	target zone then I suggest that you read RFC 2308.

> 2) When requesting an
> the target is returned. 

	You get undefined behaviour when you choose to ignore
	errors.

> 3) The SOA record of the target contains

	Again you have choosen to ignore error messages and get
	undefined behaviour.

> excessive technical support for DNS maintainers.

	There is no confusion.  RFC 1034/1035 clearly state that
	CNAMES cannot exist with other records.  It is precisely
	because it can cause the confusion you are seeing here that
	they are are not allowed to exist with any other record.

	You get the same sort of confusion when you deal with MX records
	and CNAME's.  The next thing you will be asking us for is to
	support CNAMES and  MX records at top of zone.

>     2- create a new query type (IE: DNAME, as proposed) which has a pure,

	4. Read the existing RFC's and error messages from your software
	and work within the constraints imposed.

> negative impact of allowing this would be minimal.

	BIND 8.2.2 does *not* support CNAME's along side SOA records.  It
	flags it as a error.  It prevents the zone being tranmitted in this
	error state.  The reason this was done was so that the server could
	continue to serve the rest of the zone WHILE YOU FIXED THE ERRROR.

> zone - which, for a long time, was a excellent DNS feature that has recently

	It's not been abandoned.  It's NEVER been allowed.

--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 26 Feb 2001 22:28:22 -0500

> zones - but CNAME records cannot coexist with SOA RR's.

If a name is intended to only be an alias to some other name, why on earth
would one even *try* to delegate it as a zone as well? The usage here only
becomes "confusing" if people try to do things which don't make any sense in
the first place.

Now, I appreciate that, given the way DNS is *implemented*, certain desirable
kinds of aliasing -- e.g. make foo.com an alias for bar.com -- are precluded by
the policies of certain TLD registrars. One cannot just go to NSI (say) and
successfully get foo.com aliased to bar.com, at least as far as I know
(I haven't personaly tried this). I don't believe they are set up to handle
such a request. But is this bureaucratic obstacle a justification for making a
*protocol* change? Perhaps you should be expending your effort trying to
persuade ICANN or various TLD registrars to offer an "alias
registration" service, instead of lobbying for a protocol change of dubious
technical merit (?) Seems to me like the registrars would jump at the chance to
make money off adding CNAMEs to TLDs, especially since this means that many of
the names which currently require 2 or more delegation records, and possibly
also glue records, could be accommodated with a single CNAME record, thus
reducing the size of the zone(s) and the load on the TLD servers (thus reducing
overhead costs)...

> SOA record for a name that has been aliased to another - the SOA record of

BUT NOT IN THE AUTHORITY SECTION! You are mixing apples and oranges here. If
someone asks for an SOA record, why should it be surprising in the least that
they get an SOA record in the *Answer* Section of the response? But this has
nothing to do with what's in the Authority Section.

> information that is misleading in any circumstances.

Huh? What's "misleading" about getting the SOA record one asked for, albeit
through one or more levels of aliasing? Is it any less "misleading" to do an A
record query and get the answer through one or more levels of aliasing? If you
think aliases are _inherently_ "misleading", don't use them.

> excessive technical support for DNS maintainers.

I think you have failed to demonstrate that. Sure, there's a lot of confusion.
But that can explained by the dilution of average DNS administrator skill
levels in recent years, no doubt due to the "dot com explosion", "new economy",
whatever-you-want-to-call-it. Good help is hard to find. If people don't really
grasp the essence of CNAMEs being *aliases* without any independent existence,
just like a different name for your dog, then yes, they may get confused by the
"CNAME and other data" rule. But this is generally temporary: once they grasp
that essence, the "CNAME and other data" rule makes perfect sense; the owner
name of a CNAME isn't a *different* thing, it's just another name for the
*same* thing, and therefore shouldn't be expected to own other records.

>     1- allow CNAMEs to coexist with SOA records

I'll note that this wouldn't, _ipso_facto_, get you what you want. A CNAME with
the same name as a zone would still conflict with the zone's NS records, even
if it could co-exist with the SOA record.

>     2- create a new query type (IE: DNAME, as proposed) which has a pure,

I'm not sure what you mean by "pure, recursive implementation".

In any case, as I understand DNAME, it wouldn't do what you want. It
effectively aliases *suffixes*, not whole names. So, while one could
effectively alias www.foo.com, ftp.foo.com, and mail.foo.com to www.bar.com,
ftp.bar.com, mail.bar.com, respectively, with a single DNAME, one could not,
however, effectively alias foo.com to bar.com using a DNAME. This
characteristic, along with the "no descendants" rule, prevents DNAME from
incurring the evils warned against in RFC 1034, which gave rise to the
"CNAME and other data" prohibition.

>     3- make CNAME's obsolete

I don't think any reasonable person advocates this.

> negative impact of allowing this would be minimal.

BIND failed to follow the RFC's, and unreliable/inefficient behavior was the
result. As Paul (Vixie) has pointed out, ISC/Nominum has now seen the error of
their ways and fixed the non-conforming behavior.

Now, don't get me wrong. I'm not saying that *blindly* following rules is a
good thing. I've had my differences with, for example, BIND's adherence to the
rules (such as they are perceived to exist) with respect to the underscore
character. But there are strong technical justifications for the "CNAME and
other data" rule. This is a rule that should have been enforced all along, and
I applaud BIND's conformance.

> zone - which, for a long time, was a excellent DNS feature that has recently

It's a "feature" that comes at the cost of reliability and efficiency. The
original DNS RFC's didn't think that the benefits of the "feature" were worth
the costs, and that's why they instituted the "CNAME and other data" rule. And
nothing has really transpired in the meantime, in my opinion, to give rise to a
repeal of that rule. Not even the abovementioned skill-level dilution: I'm not
in favor of dumbing down protocols just because administrators are less
cluefull than they used to be...

-Kevin

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 26 Feb 2001 19:49:55 -0800

> 	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 [email-masked]
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 <[email-masked]>
cc: "[email-masked]'" <[email-masked]>,
    Erik Aronesty <[email-masked]>,
    Michael Krebs <[email-masked]>,
    "[email-masked]" <[email-masked]>
Subject: Re: [BIND-BUGS #4054] root CNAME error in new version 
In-Reply-To: Message from Erik Aronesty <[email-masked]> 
   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 <[email-masked]>

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 <[email-masked]>
cc: "[email-masked]'" <[email-masked]>,
    Erik Aronesty <[email-masked]>,
    Michael Krebs <[email-masked]>,
    "[email-masked]" <[email-masked]>
Subject: Re: [BIND-BUGS #4054] root CNAME error in new version 
In-Reply-To: Message from Erik Aronesty <[email-masked]> 
   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 <[email-masked]>

> 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

---

From: "Erik Aronesty" <[email-masked]>
Date: Tue, 27 Feb 2001 11:12:39 -0500

1. Because it makes absolutely no sense to have CNAME's excluded from a
particluar node in the tree - since the DNS algorithm is generic and works
(check to see if there's a CNAME, if there is, go back to step 1 using the
target) regardless of where a CNAME is.

2. Most DNS servers in the world already support this feature though BIND
8.2.2, only BIND 8.2.3 stopped supporting it -and subsequently a percentage
of zones in the world stopped working.

3. So now these people are hard-coding in IP addresses to service providers
like everyone.net, yahoo and akamai - resuling in a support nighmare that is
getting worse by the hour.

4. There's a hack to get CNAME's to work for any node within the DNS system.
You can make a zone "com" and put a "foo.com IN CNAME ..." record in it.
However, requiring people to be authoritative for "com" in order to get
their old CNAME's to work is completely wacky - and I had to patch BIND to
prevent users from doing it on my servers.

Anyway, the system allowed CNAME's at any level in the tree for 15 years or
so.  Suddenly it doesn't and there's bound to be some issues.  I outlined a
few - that's all.

            - Erik

---

From: Doug Barton <[email-masked]>
Date: Tue, 27 Feb 2001 09:49:53 -0800

> excessive technical support for DNS maintainers.

	Mostly because they are used improperly and excessively as solutions for
problems they were never intended to address. Kevin's point about dns
administrator clue dilution is well taken here. 
 
>     2- create a new query type (IE: DNAME, as proposed) which has a pure,

	You are ignoring the fourth option, which is to continue following the
RFC's and use CNAME's as they were intended. 
 
> negative impact of allowing this would be minimal.

	The only truly safe way to handle this situation is to follow the RFC's.
Before an implementation change could be considered it should be vetted
through the traditional RFC engineering process which includes
compatability testing. Forcing an implementation change that contradicts
the RFC's because you think it will work is simply not how it is done. 
 
> zone - which, for a long time, was a excellent DNS feature that has recently

	Other than the fact that this option would make it easier for certain
silly edge case configurations you've yet to show any benefits from your
proposal. On the other hand, you are either ignoring, or ignorant of the
many reasons this is a bad idea. 

Doug
-- 
    "Pain heals. Chicks dig scars. Glory . . . lasts forever."
        -- Keanu Reeves as Shane Falco in "The Replacements"

	Do YOU Yahoo!?

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 27 Feb 2001 14:29:10 -0500 (EST)

> target) regardless of where a CNAME is.

Yes it does, but you are not listening, read what Mark said. 
CNAME says this name has been renamed and the only information you can
store with CNAME is KEY, SIG and NXT (see RFC2535) why. 

> of zones in the world stopped working.

This is the cost of not following the rules, just like speeding and
running read lights, we all do it, but that does not make it legal. 

> getting worse by the hour.

Follow the rules and life will get better. 

> prevent users from doing it on my servers.

If that works for you, use it, but stop trying to change the rules without
writing an Internet Draft documenting the change and have the working
group comment on it. 

> so.  Suddenly it doesn't and there's bound to be some issues.  I outlined a

I do not see any groundswell support for your insistance that non
compliant software not be fixed. 
Remember: the DNS protocol is defined by RFC's not by implementations.

	Olafur

---

From: "Erik Aronesty" <[email-masked]>
Date: Wed, 28 Feb 2001 14:37:58 -0500

Doug,

Clearly, the resolver algorithm already supports this feature - if it plans
on following the RFC's.  This is a completely backward-compatible feature.
Eliciting dialogue on this forum *is* a part of the process.  RFC's are not
used as "requests for comments" anymore.

Should a DNS server issue an error if a CNAME is at the "zone top"?

DNS is a "tree" of information.  CNAME's can be at any node on this tree.
If the text file they are in has SOA record for the same domain, then
there's a problem.  However the text file is required to have an SOA record
if it's a "zone top".

This is an indirect restriction on CNAME's at the zone top and should have
been clarified in the RFC.

RFC's should not create "implied rules".  They should be careful to list all
of the rules - so that things like this don't happen.

At the very least, the RFC should be amended to state that CNAMEs are
restricted from being served from any node that is a "parent" in the tree.
This would be acceptable - but would expose the obvious problem.  But, that
way none of this would have happened.

                - Erik

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 28 Feb 2001 20:05:38 -0500

> DNS is a "tree" of information.  CNAME's can be at any node on this tree.

Subject to the "CNAME and other data" rule, of course.

> there's a problem.  However the text file is required to have an SOA record

No, this has nothing to do with "text files" _per_se_. Although the RFC's
specify "master file format", I'm not aware of any requirement that text files
be used to load DNS zones. It is more proper, I think, to state that a zone
must have at least 1 SOA RR and 1 NS RR. This is true *regardless* of whether a
text file is used to load the zone.

> been clarified in the RFC.

I suppose we can differ on whether the restriction is "indirect" or not, but it
seems to me to follow, by simple logical implication, from

1. CNAME records can't co-exist with records of other types having the same
owner name, and

2. The name of a zone must own at least 1 NS and 1 SOA record

that

3. a CNAME can't have the same owner name as that of a zone.

But then, what do I know from syllogisms? I only have a degree in Philosophy...

> way none of this would have happened.

Feel free to submit a clarifying Internet Draft.

- Kevin