Subject: Re: Who hates the DNAME?

From: Niall O'Reilly <[email-masked]>
Date: Wed, 27 Apr 2005 08:40:46 +0100

On 27 Apr 2005, at 04:45, Mark Andrews wrote:

> Note there
> 	is a implict wildcard generated by the DNAME that *also* operates
> 	in caches.  To get consistant results from both authoritative
> 	servers and caches no subdomains of the DNAME owner are permitted.
>
> 	With wildcard DNAME you have *only* the explict wilcard being expaned
> 	by the authoritatives servers and *only* the implicit wildcard being
> 	expanded by the caches.  This results in different answers depending
> 	apon which server you query.

Succinct, clear, helpful, bravo!

Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

--
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: Edward Lewis <[email-masked]>
Date: Wed, 27 Apr 2005 07:52:29 -0400

>University College Dublin Computing Services

Maybe it's my American English or my desire for longer email 
messages, but, Mark, could you cook up an example?  Maybe a zone with 
just a DNAME and one other name below the apex and then a sequence of 
queries showing what you mean?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 27 Apr 2005 09:59:12 -0400

At 13:45 +1000 4/27/05, Mark Andrews wrote:
>
>	The reason for blocking "* DNAME" is that it results in different
>	results from authoritative servers compared with the results that
>	come from the cache.

So, unlike '* NS' this case ought to be outright "banned?"

By that I mean, '* NS' was once plausible, but DNSSEC has made 
exposed the rift in the fabric of DNS and created a protocol pinch 
point.  It seems that '* DNAME' has never been a wise idea and should 
have been explicitly prohibited when this went to proposed standard.

>	Plain (non-wildcard) DNAME.
>
>	"example.com DNAME foo.net" is like
>	"*.example.com CNAME <match of wildcard>.foo.net".  Note there

So, to try an example (I know I asked for one earlier):

If there is a "*.example DNAME cctld." here are two scenarios...

SCENARIO 1

Query                  Cache                    Authoritative

www.zone1.example.     ------------------------> responds with
                                                  www.zone1.example DNAME

                        www.zone1.example DNAME <----

www.sub.zone1.example. (cache miss) -----------> responds with
                                                  www.sub.zone1.example. DNAME

SCENARIO 2

Query                  Cache                    Authoritative

zone1.example.         ------------------------> responds with
                                                  zone1.example DNAME

                        zone1.example. DNAME <--------

www.zone1.example.     falls under DNAME above
                        "synthesizes" the CNAME
                        www.zone1.example. CNAME www.tld
zone1.example.     DNAME tld. <----------
www.zone1.example. CNAME www.tld.

www.sub.zone1.example.  (Not a cache miss this time)

It seems to me that DNAME processing in the cache is the culprit.

>	As for which servers support DNAME.  Every server that supports
>	DNSSECbis is required to support DNAME.

That's not a good gauge.  There is no enforcement of IETF standards...;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 27 Apr 2005 20:55:21 +0100

On 27 Apr 2005, at 12:52, Edward Lewis wrote:

> Maybe it's my American English or my desire for longer email messages, 
> but, Mark, could you cook up an example?  Maybe a zone with just a 
> DNAME and one other name below the apex and then a sequence of queries 
> showing what you mean?

I hope this isn't too short, and that I'm not "teaching my grandmother 
to suck eggs",
as we say in this part of the anglophone world.  8-)

A well-crafted example would be nice, and I'll take off my hat to 
whoever shows one.
See also the penultimate sentence below.

What I found truly wonderful about Mark's message was that he told me 
something
which, on reflection, I believe I must already have known, but had 
never recognized
in such simple terms.

What it comes down to is, not mixing the kinds of synthesis you use.

Simple terminal (non-NS, non-DNAME) wildcard specifies a synthesis 
which might be
called "default terminal substitution".  This is synthesis because the 
given QNAME
does not match the NAME of any existing RR; an RRset is brought into 
existence on
demand.

Simple CNAME specifies "specific terminal substitution".  In this case, 
what
happens is not synthesis; the given QNAME matches an existing RR, and 
the
specified substitution is performed.  No tricks.

Simple DNAME specifies "non-terminal substitution".  This is synthesis 
because,
just like the simple wildcard case, the given QNAME does not match the 
NAME of
any existing RR.

What Mark helped me realize is that these two kinds of synthesis are 
sufficiently
different that there is probably no circumstance in which mixing them 
would be
appropriate.

A well-crafted example contradicting this view would be a significant 
contribution
to the discussion.

Non-terminal wildcard and wildcard NS are topics on which I don't feel 
prepared to
comment.

/Niall

---

From: David Blacka <[email-masked]>
Date: Wed, 27 Apr 2005 16:18:35 -0400

> 	DNSSECbis is required to support DNAME.

What do you mean by server?  What do you mean by "support DNAME"?

-- 
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: [email-masked]
Date: Wed, 27 Apr 2005 20:33:05 +0000

> David Blacka wrote:

	and for that matter, Mark, you talk aobut a cache that
	performs tricks :)   i'd be really interested in the distinction
	betwn a cache (which i think of a data structures in storage)
	and a server (authoritative is the only kind i know)

	what some folks call a caching server is really an iterative mode
	resolver  that has access to a cache... right?

--bill

---

From: Rob Austein <[email-masked]>
Date: Wed, 27 Apr 2005 17:12:22 -0400

> 	resolver  that has access to a cache... right?

It's a recursive name server, which includes an iterative reolver,
which includes a cache.

As far as DNSSECbis requiring support for DNAME, search for "DNAME" in
RFC4035, but the one that's relevant here has to do with validation of
synthesized CNAMEs:

4.8.  Synthesized CNAMEs

   A validating security-aware resolver MUST treat the signature of a
   valid signed DNAME RR as also covering unsigned CNAME RRs that could
   have been synthesized from the DNAME RR, as described in [RFC2672],
   at least to the extent of not rejecting a response message solely
   because it contains such CNAME RRs.  The resolver MAY retain such
   CNAME RRs in its cache or in the answers it hands back, but is not
   required to do so.

That is: the DNSSECbis validation algorithm requires the validator to
understand DNAME, because DNAME is another kind of synthesis rule.
Just as with wildcards, the only real options we had here were:

a) signing synthesized RRsets on the fly, or

b) signing the synthesis rule, which requires the validator to
   understand the synthesis rule.

RFC2672 said to do both (a) and (b) at once.  For DNSSECbis, the WG
decided to punt (a) and just do (b).

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Apr 2005 09:51:05 +1000

> queries showing what you mean?

	*.example.net DNAME foo.bar

	Perform the following query sequence.
	a) sub.example.net/ANY
	b) www.sub.example.net/A

	Auth server:
	a) sub.example.net DNAME foo.bar
	b) NODATA

	Cache:
	a) sub.example.net DNAME foo.bar
	b) sub.example.net DNAME foo.bar +
	   www.sub.example.net CNAME www.foo.bar

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

---

From: [email-masked]
Date: Thu, 28 Apr 2005 00:14:58 +0000

> decided to punt (a) and just do (b).

	that still leaves me withthe question of -where- synthesis
	is supposed to occur.  ... the resolver?   the validator?
	some shared datastructures where intermediate data si stored
	ffor future use by either the resolver or the validator?
	it could be that synthesis can occur in several distinct areas
	but the expectation is that the results of the synthesis operation
	is expected to be stored in a cache... and one of the problems Ed and Mark
	were trying to tease out is that what is eventually stored in
	a cache may not be consistant with what an auth server might
	have synthesized - or for that matter what might be found in some other cache.
	regardless of who ir what did the synthesis to put it there.  

	(oh for better connectivity... :)

--bill

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 29 Apr 2005 13:25:44 +0300 (EEST)

> 	   www.sub.example.net CNAME www.foo.bar

Not all caching servers will actually give the response shown on the
last two lines of the example above, and it's far from clear that this
response is the correct one based on the DNAME specification.

Let's look at what the caching server will do in terms of the

>	a) sub.example.net/ANY

Here, the caching server will cache the record "sub.example.net
DNAME foo.bar".  The caching occurs in step 4a of the algorithm
(not step 4d - this DNAME is simply the answer to the question,
not a DNAME being redirected through to find the answer).

>	b) www.sub.example.net/A

This is where we get into murky waters.  When the caching server
resolves this query, at what step of the resolver algorithm does the
DNAME we just cached come into play, if any?

As far as I can see, the text of RFC2672 section 4.2 doesn't say.
Clearly in step 1 the answer is not in local information, so we
proceed to step 2, "find the best servers to ask", but what happens in
that step is unclear.  I see the following possible interpretations:

  1) "Finding the best servers to ask" means looking for the closest
     parent node with cached NS records, just as it did when DNAME was
     not yet invented.

     In this case, the cache ends up sending the "www.sub.example.net/A"
     query to the authoritative server which responds with a
     NODATA response because there is no A record at "*.example.net.".
     The client will get a NODATA response, not the DNAME + CNAME response
     Mark showed.

  2) "Finding the best servers to ask" means looking for the closest
     parent node with cached NS records or a parent node with a cached
     DNAME record.  If a cached DNAME is found, the SNAME is
     rewritten, a DNAME and optional synthetic CNAME are added to the
     response, and the search for the best servers is restarted at the
     SNAME, in a way similar to what authoritative servers do in
     section 4.1 step 3c.

     In this case, the response will be the DNAME + CNAME response
     Mark showed.

  3) "Finding the best servers to ask" means looking for the closest
     parent node with cached NS records or a parent node with a DNAME
     record that was cached in step 4d of the algorithm (due to being
     involved in a rewrite), disregarding any DNAME record that was
     cached in step 4a (due to being the answer to a query).
     If the former kind of DNAME is found, we rewrite as in 2) above.

     In this case, the client will get a NODATA response, as in 1).  
     The advantage of this interpretation over 1) is that it will avoid
     making queries to the authoritative servers in some situations where
     a server doing 1) would make them.

Of these interpretations, 1) seems closest to the letter of RFC2672,
but I don't know any implementation using it.  BIND 9 does 2), and
Nominum CNS does 3).

I would argue that the inconsistency between the responses from the
authoritative and caching server in Mark's example indicates a
problem with the BIND 9 implementation, not a problem with the DNAME
specification.  A server implementing the specification literally (as
in case 1 above) will not exhibit the inconsistency.

Also, this issue doesn't actually have anything to do with wildcards.
If you replace the "*" in Mark's example with "sub", you will get
exactly the same results.  This of course means that outlawing
wildcard DNAMEs would not eliminate the inconsistency.

If this message seems familiar, it's because I sent an almost
identical one in 2003 when the wildcard DNAME discussion last came up.
I have just changed the domain names to refer to Mark's current
example rather than the one that was used in the 2003 discussion and
made some minor edits.
--
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 29 Apr 2005 13:51:13 +0300 (EEST)

A small correction to my previous message...  I said:
> exactly the same results.

Actually, you won't.  Mea culpa.  Although the question of how cached
DNAMEs affect the resolution algorithm applies equally to DNAMEs that
resulted from wildcard expansion and ones that don't, the specific
inconsistency Mark showed only happens in the wildcard case.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Sat, 30 Apr 2005 11:59:24 +0000

thank you andreas.  it is clear that the beahviour of the caching
engine is underspecified here and needs work.  I think that option
one is the correct behaviour - but since caches are woefully
underspecifed, we get into nasty interoperability problems.

--bill