Subject: * DNAME text in wcard

From: Edward Lewis <[email-masked]>
Date: Tue, 10 May 2005 09:39:30 -0400

Comments on this?

...

4.4 DNAME RRSet at a Wild Card Domain Name

     Ownership of a DNAME RRSet by a wild card domain name represents a
     threat to the coherency of the DNS and is to be avoided or outright
     rejected.  Such a DNAME RRSet represents non-deterministic synthesis
     of rules fed to different caches.  As caches are fed the different
     rules (in an unpredictable manner) the caches will cease to be coherent.

     For example, assume one cache, responding to a recursive request, obtains
     the record "a.b.example. DNAME foo.bar.tld." and another cache
     obtains "b.example. DNAME foo.bar.tld.", both generated from the record
     "*.example. DNAME foo.bar.tld." by an authoritative server.

     Queries for "sub.a.b.example. A" will be rewritten as "sub.foo.bar.tld. A"
     by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by
     the latter.  Coherency is lost, an operational nightmare ensues.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 10 May 2005 18:20:54 +0300 (EEST)

>      the latter.  Coherency is lost, an operational nightmare ensues.

At the risk of repeating myself: caching servers that actually follow
the algorithm in RFC2672 section 4.2, "Processing by Resolvers", will
_not_ perform the rewrites described in the last paragraph.

Caching servers that do perform such rewrites should be fixed, not
declared correct by saying that the rewrite "will" happen.
This probably should be clarified in the DNAME specification rather
than the wildcard one, but if you want to discuss it on the wildcard
side, the text should look more like this:

       When a wild card domain name owns a DNAME RRset, queries for
       type DNAME or type ANY at multiple names matching the 
       wild card will answered with multiple synthesized DNAME RRsets
       representing mutually conflicting DNAME rewrite rules,
       and these RRsets may be cached by caching servers.

       To preserve the coherency of the DNS, it is important that
       caching DNS servers do not themselves perform DNAME rewrites
       based on such cached DNAME RRsets.

       If the caches did DNAME rewrites based on the cached DNAMEs,
       queries for "sub.a.b.example. A" would be rewritten as "sub.foo.bar.tld. A"
       by the former caching server and rewritten as "sub.a.foo.bar.tld. A" by
       the latter.  Coherency would be lost, and an operational nightmare
       would ensue.

-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 May 2005 12:13:42 -0400

Now I am more confused than before.

>side, the text should look more like this:

I agree that the DNAME ought to be cleaned up elsewhere in general, 
but I do need to deal with the wild card issues with DNAME here.

BTW - thanks for sending text.

>    based on such cached DNAME RRsets.

What do you mean by "such cached DNAME RRsets?"  Are you referring to 
DNAME RRsets cached upon receipt having been synthesized by the 
sender?  How could the recursive server tell them apart?

I was under the assumption that RFC 2672 "directs" caches to do DNAME 
rewrites...

In 4.2/step 4.d, this lays the received DNAME in the cache.

       d. if the response shows a DNAME and that is not the answer
          itself, cache the DNAME.  If substitution of the DNAME's
          <target> for its <owner> in the SNAME would overflow the legal
          size for a <domain-name>, return an implementation-dependent
          error to the application; otherwise perform the substitution
          and go to step 1.

In 4.2/step 1, a later query sees:

    A resolver or a server providing recursive service must be modified
    to treat a DNAME as somewhat analogous to a CNAME.  The resolver
    algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
    as 4.e and insert a new 4.d.  The complete algorithm becomes:

    1. See if the answer is in local information, and if so return it to
       the client.

I would interpret this as saying that the DNAME rewrite happens here.

I don't see anywhere that a recursing server has the option to ignore 
the presence of DNAME RRsets.

>    the latter.  Coherency would be lost, and an operational nightmare

"If [they] ... did" - I 1) don't see that there's an option not to do 
so, and 2) if this is an option, is it an implementation weakness/bug 
to do so?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Alan Barrett <[email-masked]>
Date: Tue, 10 May 2005 18:20:23 +0200

On Tue, 10 May 2005, Andreas Gustafsson wrote:
> >      Queries for "sub.a.b.example. A" will be rewritten as
> >      "sub.foo.bar.tld. A" by the former caching server and rewritten
> >      as "sub.a.foo.bar.tld. A" by the latter.  Coherency is lost, an
> >      operational nightmare ensues.
> 

RFC2672 section 4.2 step 1 says "see if the answer is in local
information, and if so return it to the client".  Step 4d says "...
cache the DNAME ...".  I believe that the clear intent of these two rules
is to allow the cache to use a cached DNAME to perform CNAME synthesis
(and then to use the CNAME to to answer the query).

Any reading of this algorithm that prohibits treating a cached DNAME
as suitable "local information" for the purposes of step 1 would
also appear to prohibit treating a cached CNAME as suitable "local
information" for step 1.  Since we know that it is common practice to
use cached CNAMES in that way, such a prohibition would be absurd, and
was clearly not intended by the authors of RFC2672.

> declared correct by saying that the rewrite "will" happen.

No, if there is any scope for misinterpretation of the algorithm in
RFC2672 section 4.2, the algorithm should be clarified.  Use of DNAMES
for synthesis by caches was always intended to be part of the spec
as I understood it.

--apb (Alan Barrett)

---

From: Alan Barrett <[email-masked]>
Date: Tue, 10 May 2005 18:37:20 +0200

> Now I am more confused than before.

You described the failure case correctly before.  I agree with you
that the best solution would to prohibit (or at least strongly advise
against) wildcard DNAME records.

--apb (Alan Barrett)

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 10 May 2005 20:50:43 +0300 (EEST)

> sender?  How could the recursive server tell them apart?

I have a short answer and a long answer...  The short answer is that
if you follow the algorithm in RFC2672 section 4.2 literally, you will
not do rewrites based on _any_ cached DNAMEs.

The long answer is that in some cases you actually can tell whether
the DNAME could have been synthesized or not, and I don't want to
explicitly outlaw implementations taking advantage of that.
Specifically, a DNAME cached in step 4.d of the algorithm rather than
step 4.a can't be synthetic, and I suspect DNSSEC may allow you to
tell in other cases, too.  But to keep things simple, let's restrict
the discussion to the "short answer" case.

>           itself, cache the DNAME.

No - the caching happens in step 4.a.  The DNAME must be an answer to
the question, because that is the only case where wildcard synthesis
of DNAMEs happens in the authoritative server.

> I would interpret this as saying that the DNAME rewrite happens here.

I would not interpret it that way.  The cached DNAME is not "the
answer" - its name does not match the QNAME, and its type does not
match the QTYPE.  The answer simply is not in "local information"
in this case, and we continue to step 2.

> the presence of DNAME RRsets.

It's not a question of ignoring them - it's a question of not looking
for them.  In section 4.2, there is no mention of looking for a DNAME
at the "last node matched" as there is in section 4.1.

> so, and 2) if this is an option, is it an implementation weakness/bug 

I don't see that there is an option to _do_ the rewrite, and I would
say that an implementation that does the rewrite has a bug.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 May 2005 14:20:59 -0400

>I would not interpret it that way.  The cached DNAME is not "the

Ahh, the very symptom of a bad specification.  I.e., no "you're 
wrong" but instead an exchange of "would" and "would not" interpret.

>in this case, and we continue to step 2.

I don't want to travel down the path of fixing that RFC now,  I'll move on.

>at the "last node matched" as there is in section 4.1.

Granted.  I understand.  Unlike CNAMEs, which are at the sought name, 
DNAMEs would be sitting higher up in the domain tree.  There's no 
reason a lookup (note, not a search) would have anything but tunnel 
vision for the sought data.

My assumption has been that the intent of the DNAME RFC was to have 
recursing servers modify their "lookup" algorithm to include a 
"search" for the DNAME.  Based on this assumption, I found the idea 
of the DNAME abhorrent (hence the "who hates the DNAME" subject line).

However, my assumption still holds - that it is the intent of the 
DNAME in a cache to "cut off" further queries to the authoritative 
server for the same zone.

Does anyone familiar with the debate back then have an answer to the 
question of "what was the intent?"  I wasn't involved in the work 
then, I was still stuck on DNSSEC-only issues.

>say that an implementation that does the rewrite has a bug.

Hmmmm.  Any other opinions on this?  (I mean other implementers who disagree?)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 May 2005 08:20:49 +1000

> then, I was still stuck on DNSSEC-only issues.

	The intent was to make/let caches synthesis the result.  It is
	also clear from the text as this restriction would not be
	needed otherwise.

      If a DNAME RR is present at a node N, there may be other data at N
      (except a CNAME or another DNAME), but there MUST be no data at
      any descendant of N.  This restriction applies only to records of
      the same class as the DNAME record.

   This rule assures predictable results when a DNAME record is cached
   by a server which is not authoritative for the record's zone.  It
   MUST be enforced when authoritative zone data is loaded.  Together
   with the rules for DNS zone authority [DNSCLR] it implies that DNAME
   and NS records can only coexist at the top of a zone which has only
   one node.

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 May 2005 20:09:24 -0400

>    and NS records can only coexist at the top of a zone which has only

But that does not rule out '* DNAME'.  I thought it did for a while, 
that was before Niall's haunting message came back at me for one more 
'boo.'  You see, "*.<anything>" won't ever generate a descendant of 
itself, just certain descendents of <anything>.

But wait, I suppose there is one contorted way in which "this rule" 
does outlaw '* DNAME' and that is because, ahem, let me try some 
algebra...

Let the wild card domain name be "*.A"  Let there be some label, B, 
that is not an immediate descendent of A.  Collarary 1 - there exists 
a label C that does not exist that is a descendent of the B (which 
also does not exist).  Since '*.A DNAME' can synthesize both 'C.B.A. 
DNAME' and 'B.A. DNAME' in violation of "this rule" then "*.A DNAME" 
cannot be allowed unless there are is no way to find two labels below 
A.  (Latter added because a domain name has a fixed upper bound on 
length.)

Eh?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 May 2005 10:30:54 +1000

> A.  (Latter added because a domain name has a fixed upper bound on 

	Why are we argueing about whether "* DNAME" is already prohibited
	or not?  The existing text is obviously not clear enough if it is
	there and we need text to make it explictly clear that "* DNAME"
	is to be rejected at load/update time.  There are also other things
	that need to be addressed when the DS review comes up. (e.g. does
	a DNAME occult data when added via UPDATE in a similar way as NS
	occults data when added via UPDATE. BIND 9 does this but it is
	definitely not clear if this is correct or not though it does fit
	the spirit of the UPDATE spec.  Can the chairs at this question
	to the issue tracker so that it doesn't get lost please.)

	Now you asked a question about intent.  Do you agree that the
	above text makes the intent clear or not.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 May 2005 22:32:39 -0400

>	above text makes the intent clear or not.

Remember that my effort is to edit a wildcard clarifications 
document.  One of the unclear points is what does it mean for a 
wildcard to be a DNAME record.

The need to clarify this empirically demonstrated in the lengthy 
discussions on why '* DNAME' is a bad idea.  Perhaps one or a few 
people have seen this clearly, but apparently the knowledge is not 
widespread.

As to your last sentence, my answer is, well, truthfully, "huh, 
what?"  What are you asking? ;)  I'm not sure what you mean at all, 
in addition to the "or not" part of the sentence.

(The impact of DNAME on UPDATE isn't of concern for the wildcard 
clarify document.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: [email-masked] (Andreas Gustafson)
Date: Wed, 11 May 2005 11:33:52 +0300 (EEST)

Alan Barrett writes:
> information" for step 1.

Good point.  Looks like the use of cached CNAMEs _and_ DNAMEs is
equally underspecified.
-- 
Andreas Gustafsson, [email-masked]