Subject: question regarding wildcards and 2672

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Jun 2003 23:06:43 -0400

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?
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)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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/>

---

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

> How do people feel about barring DNAME records at wild cards?

	This would be my preferred option.
	
>                        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.

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

---

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: Edward Lewis <[email-masked]>
Date: Tue, 17 Jun 2003 09:46:35 -0400

>much time on updating a experimental RFC.

What's intended are paragraphs on what are apparently the three 
resource records (known to date) that have an impact on wild cards. 
The three are NS, CNAME, and DNAME.

(As a measure of the need to document something - a few of us have 
spent a couple of on-line hours in the past week discussing DNAME. 
When a topic takes so much time among folks that know DNS, you know 
it needs some deeper documenting.)

The DNAME paragraph in the wild card clarify document will be the 
shortest of the three - for one thing, DNAME is experimental.  I 
think it's important to place the text in the wild card draft as I 
don't think anyone is currently editing a follow-on to DNAME.  (2026 
makes no statement about the need to review experimental rfcs, unlike 
standards track rfcs.)

>give it up when shown the documents, because it works.

Perhaps there will be a catch all requirement like - any RR defined 
(from here on out) MUST describe how it is handled if it is owned by 
a wild card domain name.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Jim Reid <[email-masked]>
Date: Tue, 17 Jun 2003 07:00:10 -0700

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

If we accept wildcard DNAMEs are just too awful, it should be OK
for the document to say something like: "wildcard DNAMEs are
forbidden". Either as a general rule or in the specific case of
DNSSEC. 

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

True, but let's not provide another bottle for another genie. There's
not much use of DNAME yet so this particular stable door could get
closed before the horse has bolted. Apologies for the mixed metaphors.

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Jun 2003 07:04:06 -0700

>> Having said that, I do not think the wildcard clarify document
>> should spend much time on updating a experimental RFC.
> resource records (known to date) that have an impact on wild
> cards.  The three are NS, CNAME, and DNAME.

and, if there are any complications solely for the experimental DNAME
RR, then do not complicate.

randy

---

From: Bill Manning <[email-masked]>
Date: Tue, 17 Jun 2003 07:03:43 -0700 (PDT)

% What's intended are paragraphs on what are apparently the three 
% resource records (known to date) that have an impact on wild cards. 
% The three are NS, CNAME, and DNAME.

	what!  no SOA?

% Perhaps there will be a catch all requirement like - any RR defined 
% (from here on out) MUST describe how it is handled if it is owned by 
% a wild card domain name.

	amen.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: [email-masked]
Date: Wed, 18 Jun 2003 00:20:31 +1000

> much time on updating a experimental RFC.

Network Working Group                                        M. Crawford
Request for Comments: 2672                                      Fermilab
Category: Standards Track                                    August 1999

	Please cite the RFC that moves DNAME to experimental.  Note
	it is *not* RFC 3363.

	Plain DNAMEs provide a useful tool.  Wildcard DNAMEs on the other
	hand I have a hard time trying to envision a sensible use for them
	even with single label expansion.

> in RFC103[45], but in the case of CNAME the genie is out of the bottle.

	I agree that wildcard CNAMEs are out of the bottle and the
	algorithm should be updated to make it clear that they
	should be returned even when the QTYPE does not match and 
	be followed if appropriate.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Jun 2003 16:21:54 +0000

> >How do people feel about barring DNAME records at wild cards?

i think this is the right thing.

> ...
> As DNAME is a "zone terminator"

it's not, though.  see isc-tn-2002-1.txt (at www.isc.org/tn) for an example
of "DNAME and other data" all at the apex of a zone.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Jun 2003 11:52:19 -0400

>% The three are NS, CNAME, and DNAME.

No - the SOA is already restricted to the apex, so far as I know. 
So, unless you do something stooopid like have a zone that starts 
with a "*." name -

Umm, wait, perhaps there ought to be text covering that.

I ain't naming names.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Jun 2003 13:13:56 -0400

>	Please cite the RFC that moves DNAME to experimental.  Note

I missed that.  I thought DNAME was experimental.  So DNAME is 
another standards document that is falling through the cracks.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked]
Date: Wed, 18 Jun 2003 07:37:15 +1000

> another standards document that is falling through the cracks.

	I was well aware the draft-ietf-dnsext-ipv6-addresses was
	not making DNAME experimental.  I would have fought any
	attempts to make it experimental.  I think I even said at
	one point "just remove the section on DNAME" in it.

	Mark

---

From: Sam Weiler <[email-masked]>
Date: Tue, 17 Jun 2003 19:00:13 -0400 (EDT)

The IPSECKEY RR definition draft is nearing WG last call -- this would
be a good time to review the document.

The chairs would particularly like feedback on whether or not the
IPSECKEY record should inherit format definitions from the DNS
Security Algorithm registry -- if someone defines a (DNS)KEY RR format
for Sam's Public Key Algorithm, does it automagically show up as an
IPSECKEY format?

The text in draft-ietf-ipseckey-rr-04.txt is internally inconsistent,
but the intent with this version was that, yes, the formats are
inherited.

Please send all comments to the IPSECKEY list.
  General Discussion: [email-masked]
  To Subscribe: [email-masked]
  Archive: http://www.sandelman.ca/lists/html/ipseckey/

http://www.ietf.org/html.charters/ipseckey-charter.html
http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-04.txt

-- Sam

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 18 Jun 2003 12:53:54 +0300

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> for Sam's Public Key Algorithm, does it automagically show up as an

I am in favour of inheriting the definitions.  The same definitions
are currently being reused in HIP, and I am proposing that we use
those also in SEND.  (SEND currently specifies ASN.1 OIDs, but I
personally see little value in that.)

In particular, what comes to the following:

> 2.3 RDATA format - algorithm type
> 
....
>    The public key field contains the algorithm-specific portion of the
>    KEY RR RDATA, omitting the first four octets of the KEY RR RDATA.
>    This is the same portion of the KEY RR that must be specified by
>    documents that define a DNSSEC algorithm.  Those documents also
>    specify a message digest to be used for generation of SIG RRs; that
>    specification is not relevant to the IPSECKEY usage of the public key
>    format.

I think the intention of the text is excellent.  It aligns very
well with the current HIP usage of RFC2535 key formats.  However,
it might be good to explicitly mention that the first four octets
would contain the flags, protocol, and algorithm fields, which
are now left away.

A couple of comments:

   Should there be a reserved octed before the gateway field,
   thereby aligning the gateway field to 32-bit boundary?

   AAAA RDATA format is defined in Section 2.2 (not 3.2) of RFC1886.

--Pekka Nikander

---

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" ;)