Subject: RE: cnames...

From: Erik Aronesty <[email-masked]>
Date: Sun, 25 Feb 2001 13:02:59 -0500

Sorry Kevin, you're right, future posts (including this one) will be 
directed to namedroppers.  I included the entire thread (below), so 
users there can catch up.

Your summary of the proposed/implied changes in DNS/BIND regarding 
CNAME's (below) are generally correct, although I think a detailed 
explanation of "why" is in order.

Anyway, here's a list of responses to your challenges (1,2,3 as numbered 
below):

	1) Yes, however, the resolver already has to do this if the QNAME is
a CNAME itself, and the others we had mentioned.

	2) Right, but the answer from the server is semantically correct.
In your example, an application doing this query would get the ONLY
nameservers that even know who "foo.com" is.  Attempting to query "bar.com's
nameservers" for information about "foo.com" would result in an error
anyway.  Which is why SOA/NS records are already exempt from chaining for
"certain situations" (IE: AXFR authoritative sections).

	3) If you absolutely needed to know about the NS record at the next 
level (for what reason - I have no idea), you would have to query for 
the CNAME itself, and then query for the NS record of the result - 
that's all.  It reduces the ability to "chain SOA's" - while 
dramatically improving the ability to chain "A/MX/LOC" records, etc - 
which is the point in CNAME's anyway.

There is a "philosophical/structural" argument here as well.  Why should 
you be able to place CNAME's in some places and not others - just 
because of their arbitrary location in a "text file".  IE: Why should I 
be able to place a CNAME in the ".com" zone for "foo" and not in the 
"foo.com" zone for "@" - since the two requests should be equivalent as 
far as a DNS is concerned.  DNS is, in theory, a clean hierarchical 
structure, the more "special exceptions" there are in such a structure - 
the weaker the structure.

Further, it can be argued that CNAMES's should be allowed with ALL other 
data and that the resolver should simply 1) see if it has a local 
record, if not, 2) go get the remote record.  This would eliminate all 
exception handling, and result in clearer behavior and a more flexible 
DNS.  It would eliminate the need for special processing for 
CNAME/SIG/KEY/SOA/NS, etc. and would reduce the verbiage in the protocol 
as well.

			- Erik

-----Original Message-----
From:	Kevin Darcy [SMTP:[email-masked]]
Sent:	Friday, February 23, 2001 9:38 PM
To:	[email-masked]
Subject:	Re: cnames...

Erik,
      I'm going to brutally summarize this discussion thread, since in 
my opinion it's off-topic to bind-users. (It belongs on namedroppers, as 
I have repeatedly pointed out).

Your basic proposal appears to be (correct me if I'm wrong):

     NS and SOA are "special" types because they are typically used only 
between nameservers, not something that a normal client would query. 
Given this, they should be exempted from CNAME chaining, and therefore 
can be exempted from the "CNAME and other data" rule as well, i.e. it 
should be legal for a CNAME to co-exist with SOA and/or NS records. This 
would put an end finally to the persistent confusion over the "CNAME and 
other data" rule as applied to names of registered domains.

I can foresee at least 3 general objections to this:

1) It complicates name resolution in the case where a query comes into a 
recursive nameserver, and all it has cached is a CNAME which matches 
QNAME, but nothing for the target of the alias. Currently, the decision 
of what to do next is simple: recurse to the authoritative nameservers 
for the *target*'s zone. Under your proposal, however, the nameserver 
needs to look at the query type first. If it's an NS or SOA query, then 
it should recurse to the nameservers for QNAME's zone, otherwise it 
recurses to the nameservers for the CNAME target's zone. Is the benefit 
to be gained here worth the cost of adding *yet*another*conditional* to 
the critical path of the DNS resolution algorithm?

2) It violates "the principle of least surprise". Take the following 
example: foo.com, a name which owns NS records, is an alias for bar.com, 
where bar.com owns *different* NS records and an A record. Doing a "dig 
foo.com a" yields the A record which is ultimately contained in the 
bar.com zone. Doing a "dig foo.com ns", however, yields the foo.com 
zone's NS records, since, under your proposal, the CNAME isn't chained 
for an NS query. An application or human which/who doesn't notice the 
indirection in the first query might be incorrectly led to believe that 
the A RRset and the NS RRset originated from the same zone -- a 
reasonable conclusion, since the QNAME was the same for both queries. 
Yet they are
from *different* zones, and thus the human or application could be 
easily led astray, possibly with disastrous results.

3) It arbitrarily reduces the overall usefulness of the aliasing 
mechanism. Why *shouldn't* I be able to point aliases at names which own 
SOA and/or NS records and have them chain properly when I do SOA and/or 
NS queries? Maybe I have domains many levels deep and I want "friendly" 
aliases to those domains at some higher level (which are more likely to 
be in my search path), so that I can say just "dig foo ns" instead of 
"dig foo.bar.blech.us.northamerica.earth.daimlerchrysler.com ns". CNAMEs 
are supposed to provide a *general* aliasing mechanism, but here you are 
carving out exceptions for record types you consider "special". Where 
does that line get drawn? Every record type is "special" in its own
way. Do we head down that slippery slope and eventually get rid of 
CNAMEs altogether (as DJB proposes)? I think that would be a great loss.

                                                                 - Kevin

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 25 Feb 2001 11:52:58 -0800

> other data" rule as applied to names of registered domains.

CNAME shouldn't be used with NS RRs at all, despite the other-data rule.

DNS uses NS RRs for two purposes: zone delegation, and authoritative
server lists (if it had been me, I would have used different RRs for these
purposes, but that is irrelevant). You have to be really really careful
about using NS with CNAMEs for zone delegation functions because the
alias' domain name could be in the target zone, thereby preventing the
CNAME recursion from suceeding. This fact goes beyond the simple case
(duh, add the local alias and an A RR) in that recursion for the target
zone would have to occur within the delegating server -- and the server
would have to be authoritative for the parent and target zones -- in order
for this to work with any level of reliability.

As long as NS is used for zone delegation, it cannot be used with CNAMEs
without very careful planning. The level of planning required is in fact
too high, with many more failure scenarios than success scenarios.

See also section 10.3 of RFC 2181 for a less emphatic rendetion.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Erik Aronesty" <[email-masked]>
Date: Mon, 26 Feb 2001 10:34:04 -0500

I agree.  The original conversation was in regard to SOA records, not NS
RR'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.

The original concept was that SOA record requests should not get "aliased"
during queries, since the resulting data is misleading.

Also, all CNAMRE responses have an "authority section" - and having a rule
which says that CNAME's cannot have SOA RR's present is a bit odd.

Therefore the restriction on CNAME's and other data should not apply to the
SOA record - since it's should not get aliased anyway.

There are already situations where the SOA record does not get aliased.

It should be formalized - that's all.

            - Erik

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 26 Feb 2001 09:25:07 -0800

> authoritative server lists - not delegations - in the case of a CNAME on a

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.

> 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.

> It should be formalized - that's all.

It already is:  "Don't try that, DNS doesn't work that way."

---

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

> is either an alias, or it's not an alias.  Zones have names.  Not aliases.

Sorry, on an alias.

> 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 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.

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 26 Feb 2001 16:40:56 -0800

> work just fine, and work that way.

sounds like a pissing match to me.  bind was wrong to do this in the past.
the rfc's are clear.  bind8.2.3 and bind9 get it right.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 26 Feb 2001 20:51:42 -0500

Erik Aronesty wrote:

> Sorry Kevin, you're right, future posts (including this one) will be directed to namedroppers.  I included the entire thread (below), so users there can catch up.
>
> Your summary of the proposed/implied changes in DNS/BIND regarding CNAME's (below) are generally correct, although I think a detailed explanation of "why" is in order.
>
> Anyway, here's a list of responses to your challenges (1,2,3 as numbered below):
>
>         1) Yes, however, the resolver already has to do this if the QNAME is a CNAME itself, and the others we had mentioned.

No, if the QNAME owns a CNAME, then, today, as I described, the resolver only needs to know to go to the authoritative nameservers for the CNAME's target's zone. Under your proposal, it needs to take the extra step of looking at the query type to see if it should go to *either* the CNAME's target's zone (normal case) *or* to QNAME's zone (for SOA or NS queries). This complicates and burdens the process.

>         2) Right, but the answer from the server is semantically correct.

Semantically correct, but confusing.

> In your example, an application doing this query would get the ONLY nameservers that even know who "foo.com" is.  Attempting to query "bar.com's nameservers" for information about "foo.com" would result in an error anyway.

No, I think you misunderstood. When the user or application issues "dig foo.com a" (or the equivalent), and a "foo.com cname bar.com" record is known by the recursive server, then it queries the bar.com nameservers for a "bar.com" A record. In contrast, under your proposal, a "dig foo.com ns" or "dig foo.com soa" would be answered directly from the foo.com zone, since NS and SOA aren't chained. This results in apparently-inconsistent behavior which could be very confusing and lead to nasty, hard-to-diagnose bugs.

> Which is why SOA/NS records are already exempt from chaining for "certain situations" (IE: AXFR authoritative sections).

Um, surely you mean IXFR rather than AXFR. As far as I know, Authority Section contents aren't specified for either AXFR queries or responses...

I think you are misunderstanding the purpose of the SOA in the Authority Section of an IXFR request. The SOA owner name specifies a zone of interest, and the only other item of interest in the SOA RR is the serial number. This SOA RR is expected to come from a slave's authoritative (but possibly out-of-date) copy of the zone. There is no possibility that the owner name of this SOA RR could also own an alias, because of the very "CNAME and other data" rule which we are discussing. So there is no aliasing "exemption" necessary, and you have demonstrated no inconsistency here in the application of the "CNAME and other data" rule.

Or, alternatively, feel free to quote this "exemption" from RFC 1995. Maybe I missed it.

>         3) If you absolutely needed to know about the NS record at the next level (for what reason - I have no idea), you would have to query for the CNAME itself, and then query for the NS record of the result - that's all.  It reduces the ability to "chain SOA's" - while dramatically improving the ability to chain "A/MX/LOC" records, etc - which is the point in CNAME's anyway.

The point here is that your proposal disables chaining for 2 whole record types -- SOA and NS -- while the "CNAME and other data" rule only prohibits certain data relationships, under very specific circumstances, which are quite well understood and quite easy to work around. My opinion is that your proposal results in a net reduction in the usefulness of CNAMEs.

> There is a "philosophical/structural" argument here as well.  Why should you be able to place CNAME's in some places and not others - just because of their arbitrary location in a "text file".  IE: Why should I be able to place a CNAME in the ".com" zone for "foo" and not in the "foo.com" zone for "@" - since the two requests should be equivalent as far as a DNS is concerned.  DNS is, in theory, a clean hierarchical structure, the more "special exceptions" there are in such a structure - the weaker the structure.

It has nothing to do with location of entries in a text file -- there is no requirement that DNS master zones even be loaded from a text file. The rule is strictly based on relationships between data elements -- if a name owns a CNAME, it can't own records of other types (except for the DNSSEC types which we've already discussed). How zones are loaded, and in what order the records are processed in the loading process, is irrelevant to the "CNAME and other data" rule.

Now you seem to think that making chaining exceptions for some record types somehow makes the hierarchical structure "cleaner" and consequently stronger. But I see it exactly the opposite way. An alias is a name which stands for another name, and has no independent existence of its own. So if name X is an alias to name Y, which may or may not happen to be a zone, it should not have any other records of its own. That's the cleanest way to consider X -- as just another name for Y, not an entity or container in its own right. Anything else is "dirtier", and therefore, by your reasoning, "weaker".

To attempt an analogy, imagine I told everyone that they could call me "Fred", and this usage became somewhat prevalent. Does that suddenly mean that I can open up a separate bank account under the name "Fred"? Does it mean I could file separate 1040 tax returns under my name and the name "Fred", splitting up the income so as to pay less overall income tax? If I were given a speeding ticket, could I just show up in court and say "Fred did it, go fine him instead"? No, of course not. "Fred" is just another name for me. "Fred" has no independent existence; he/it can't own property, hold assets, earn income, pay taxes, be criminally liable, etc. for anything beyond what Kevin Darcy can. "Fred" is just a
name for me, not something with its own existence.

(Yes, I know the analogy might seem to break down a little bit in the case of corporations, which *are* in many respects considered independent entities, but hopefully you appreciate that a corporation is more analogous to a separate name, or to a zone, than just somebody's alias).

> Further, it can be argued that CNAMES's should be allowed with ALL other data and that the resolver should simply 1) see if it has a local record, if not, 2) go get the remote record.

Well, no, as RFC 1034 already alludes, if all a nameserver has cached is the CNAME RR, then if the "CNAME and other data" rule is abrogated completely, it now has to look in *two* places: 1) QNAME's zone, and 2) the CNAME's target's zone. Suddenly, you double the nameserver's workload in these situations. For no appreciable benefit.

> This would eliminate all exception handling, and result in clearer behavior and a more flexible DNS.

To what "exception handling" are you referring?

> It would eliminate the need for special processing for CNAME/SIG/KEY/SOA/NS, etc. and would reduce the verbiage in the protocol as well.

Actually, the processing of CNAMEs during normal nameserver operation is *simpler* because of the "CNAME and other data" rule. The rule is enforced at zone load time, which takes most of the special processing out of the critical path -- once a zone is loaded, the nameserver can assume that any CNAMEs in the zone own no other records. The special processing required by your lead proposal, however, would have to be done in the heart of the query-processing/recursion/name-resolution code, and thus could be rather expensive.

                                                                                                            - Kevin

>       I'm going to brutally summarize this discussion thread, since in my opinion it's off-topic to bind-users. (It belongs on namedroppers, as I have repeatedly pointed out).
>
>      NS and SOA are "special" types because they are typically used only between nameservers, not something that a normal client would query. Given this, they should be exempted from CNAME chaining, and therefore can be exempted from the "CNAME and other data" rule as well, i.e. it should be legal for a CNAME to co-exist with SOA and/or NS records. This would put an end finally to the persistent confusion over the "CNAME and other data" rule as applied to names of registered domains.
>
> 1) It complicates name resolution in the case where a query comes into a recursive nameserver, and all it has cached is a CNAME which matches QNAME, but nothing for the target of the alias. Currently, the decision of what to do next is simple: recurse to the authoritative nameservers for the *target*'s zone. Under your proposal, however, the nameserver needs to look at the query type first. If it's an NS or SOA query, then it should recurse to the nameservers for QNAME's zone, otherwise it recurses to the nameservers for the CNAME target's zone. Is the benefit to be gained here worth the cost of adding *yet*another*conditional* to the critical path of the DNS resolution algorithm?
>
> 2) It violates "the principle of least surprise". Take the following example: foo.com, a name which owns NS records, is an alias for bar.com, where bar.com owns *different* NS records and an A record. Doing a "dig foo.com a" yields the A record which is ultimately contained in the bar.com zone. Doing a "dig foo.com ns", however, yields the foo.com zone's NS records, since, under your proposal, the CNAME isn't chained for an NS query. An application or human which/who doesn't notice the indirection in the first query might be incorrectly led to believe that the A RRset and the NS RRset originated from the same zone -- a reasonable conclusion, since the QNAME was the same for both queries. Yet they are
> from *different* zones, and thus the human or application could be easily led astray, possibly with disastrous results.
>
> 3) It arbitrarily reduces the overall usefulness of the aliasing mechanism. Why *shouldn't* I be able to point aliases at names which own SOA and/or NS records and have them chain properly when I do SOA and/or NS queries? Maybe I have domains many levels deep and I want "friendly" aliases to those domains at some higher level (which are more likely to be in my search path), so that I can say just "dig foo ns" instead of "dig foo.bar.blech.us.northamerica.earth.daimlerchrysler.com ns". CNAMEs are supposed to provide a *general* aliasing mechanism, but here you are carving out exceptions for record types you consider "special". Where does that line get drawn? Every record type is "special" in its own
> way. Do we head down that slippery slope and eventually get rid of CNAMEs altogether (as DJB proposes)? I think that would be a great loss.
>
>                                                                  - Kevin