Subject: Re: question regarding wildcards and 2672

From: [email-masked]
Date: Tue, 17 Jun 2003 16:52:15 +1000

> With a light bulb supplied by Mark Andrews, in the never ending 
> effort to clarify wild cards...
> 
> In RFC 2672, section 4.1:
> 
> #     c. If at some label, a match is impossible (i.e., the
> #        corresponding label does not exist), look to see whether the
> #        last label matched has a DNAME record.
> #
> #        If a DNAME record exists at that point, ... SHOULD synthesize a
> #        CNAME record ...  Go back to step 1.
> #
>           ...
> #
> #        If the "*" label does exist, match RRs at that node against
> #        QTYPE.  If any match, copy them into the answer section, but
> #        set the owner of the RR to be QNAME, and not the node with the
> #        "*" label.  Go to step 6.
> 
> There's a problem with this.
> 
> Let's say an authoritative server has '*.example. DNAME example.org.' 
> in a zone.
> 
> ACT I:
> 
> Cache issues a query for '1.2.example. DNAME IN' and gets the 
> synthesized answer.  Cache is then asked for '0.1.2.example. A IN'
> 
> ACT II:
> 
> Cache issues a query for '2.example. DNAME IN' and gets the 
> synthesized answer.  Cache is then asked for '0.1.2.example. A IN' 
> (same query as in ACT I).
> 
> In ACT I, the response will include:
> 
>               0.1.2.example. CNAME 0.example.org.
> 
> In ACT II, the response to the SAME query will include:
> 
>               0.1.2.example. CNAME 0.1.example.org.
> 
> Note that the first query changes what the second query gets.  (And 
> unlike the ANY situation, the two answers are incoherent.)
> 
> One reason for the problem is that a wild card is allowed to own a 
> DNAME record.
> Another reason for the problem is that there is no restriction on how 
> many labels a wild card domain matches.
> 
> How do people feel about barring DNAME records at wild cards?

	This would be my preferred option.
	
> How do people feel about limiting the DNAME to matching just one label?
> (I.e., In ACT I, the reply to '1.2.example. DNAME IN' would be:
>                        2.example.   DNAME example.org.
>                        1.2.example. CNAME 1.example.org)

	Note the presence of a DNAME would cause all other type to
	also match just one label otherwise you get inconsistant
	answers.

> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                            +1-703-227-9854
> ARIN Research Engineer
> 
> ...as graceful as a blindfolded bull in a china shop...
> 
> --
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 17 Jun 2003 09:13:11 -0400

At 23:06 2003-06-16, Edward Lewis wrote:
>With a light bulb supplied by Mark Andrews, in the never ending effort to 
>clarify wild cards...

<snip>

>One reason for the problem is that a wild card is allowed to own a DNAME 
>record.
>Another reason for the problem is that there is no restriction on how many 
>labels a wild card domain matches.
>

As DNAME is a "zone terminator" it just feels wrong that wildcard DNAME
can be expanded more than one label, and in my mind should not be allowed.
Having said that, I do not think the wildcard clarify document should spend
much time on updating a experimental RFC.

Having said that I think wildcard [CD]NAME is bogus and was not indented
in RFC103[45], but in the case of CNAME the genie is out of the bottle.

I think the "right thing to do" for the wildcard clarify document,
is to put in a strongly worded warning that wildcard DNAME leads to
unintended and strange results. Thus is it strongly discouraged.
Of course I realize this will leave us in the same position as with
with multiple CNAME RRs in a set, someone will find use and refuse to
give it up when shown the documents, because it works.

         Olafur

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 20 Jun 2003 17:43:24 -0700 (PDT)

On Monday, Edward Lewis wrote:
> synthesized answer.  

Elaborating to check that I'm understanding you correctly, the
synthesized answer you refer to above would be "1.2.example. DNAME
example.org.", and the type of synthesis performed by the
authoritative server in this case is wildcard expansion, not DNAME
redirection.

When the cache follows the algorithm of RFC2672 section 4.2, it ends
up caching this DNAME 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).

> Cache is then asked for '0.1.2.example. A IN'

This is where we get into murky waters.  When the cache 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 "0.1.2.example. A"
     query to the authoritative server which responds with
     a noerror/nodata response because there is no A record at
     "*.example.", and there is no inconsistency between Act I and II.

  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 contain the cached
     "1.2.example. DNAME example.org." and a synthetic CNAME
     "0.1.2.example. CNAME 0.example.org.".  This is the outcome you
     described, which will lead to the inconsistency between
     Acts I and II.

  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.

     This will give the same consistent result for your example queries
     as interpretation 1), but has the advantage of avoiding 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.
The two implementations I am familiar with do 2) and 3), respectively.

Note that this lack of clarity of the algorithm is not limited to the
wildcard case - it is equally unclear how a DNAME cached as a result
of a direct query or a normal DNAME rewrite not involving wildcards is
taken into account by the resolver.

> unlike the ANY situation, the two answers are incoherent.)

Based on the above, it is far from clear that a correct implementation
of DNAME will produce the inconsistency.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Jun 2003 13:24:24 -0400

>The two implementations I am familiar with do 2) and 3), respectively.

I like this, it is akin to the way negative answers are understood to 
work in a cache.  A cache doesn't infer a negative answer from 
previously seen data, a cache shouldn't infer a DNAME from previously 
seen data.

In this case, it seems that it won't matter if the wild card matches 
one or more labels in synthesizing the DNAME.  From that I think that 
trying to restrict the wild card to matching just one label (for 
DNAME or NS) isn't the right path to clarification.

Perhaps a wild card owning a DNAME is innocuous after all.

(Keeping in mind that a non-DNAME-aware cache won't use it in forming 
an answer anyway.)

>taken into account by the resolver.

I'm not going to tackle the rest of DNAME, that's clearly not my 
intent.  (But someone one day will.)  My only concern is what happens 
at the wild card.  Caches don't do wild card synthesis, so I'm less 
concerned about that topic.  They don't have enough information to do 
that, even when they know, thanks to the SIG record, that the answer 
was the result of a synthesis - label count.

PS - In deference to a request by a chair who is now on vacation, 
I'll include dictionary references at times. ;)

innocuous  = producing no injury : HARMLESS
"in deference to" DNAME "in consideration of" ;)