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: Mark Andrews <[email-masked]>
Date: Wed, 11 May 2005 08:20:49 +1000

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

	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