Subject: Re: wcard-clarify's change

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 3 Oct 2003 11:42:56 +0200

Namedroppers,

We have to get to a consensus on this one at some point. I want to try
and keep momentum going.

Let us define X="something that matches the *"

Then I think we have consensus on the fact that there is a problem in
the fact that for QNAME=X QTYPE=A we will get different answers from a
cache depending on the fact if the cache was asked QNAME=X,QTYPE=CNAME
before.  This is an ambiguity and it needs clarification.

I think that the TTL=0 solution will not lead to consensus so we are
currently left with two possibilities:

- Either clarify the algorithm so that QNAME=X,QNAME!=CNAME will
  produce a CNAME response in the authoritative server.

- Or outlawing "* CNAME".

Am I missing other solutions?

Process:

-  If there is anybody who CANNOT live with one of the two solutions than 
   speak up and motivate.

-  If there is a strong preference for one of the solutions than also speak up
   and motivate.

-  If you can live with the default (below), or you really do not care
   which solution is picked, it would be nice to know so we know people
   actually read this thread.

I hope that based on these two questions we can cook up the consensus
solution. Please keep in mind you do not have to like that solution but you
should be able to live with it.

If there is no input before Oct 18 I will take "Outlawing * CNAME" as
being the consensus outcome of this issue. The motivation for me
choosing that particular solution as default is that it is simplest;
you do not have to deal with all kinds of loop protections etc.

-- Olaf
   DNSEXT Co-Chair.

   Is there an English equivalent to the proverb "een olifant in een
   porcelein kast"?

--
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: Robert Elz <[email-masked]>
Date: Fri, 03 Oct 2003 17:17:48 +0700

I can live with either, no problem outlawing CNAME in a '*' record.

kre

---

From: Randy Bush <[email-masked]>
Date: Fri, 3 Oct 2003 08:16:29 -0700

> I can live with either, no problem outlawing CNAME in a '*' record.

as paul said, that is a change, not a clarification, and hence
outside the range of this document.

randy

---

From: Robert Elz <[email-masked]>
Date: Sat, 04 Oct 2003 00:44:34 +0700

Date:        Fri, 3 Oct 2003 08:16:29 -0700
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | > I can live with either, no problem outlawing CNAME in a '*' record.
  | 
  | as paul said, that is a change, not a clarification, and hence
  | outside the range of this document.

Randy, something has to be done.  The option that can be argued that
is not a change is to explicitly permit CNAME in wildcards, and actually
make it work correctly.   That would be OK too.   But just doing nothing
is unacceptable.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 04 Oct 2003 01:17:18 +0700

I just said ...

  | That would be OK too.   But just doing nothing is unacceptable.

I should have also added that we should make the best of the two
choices (if there is a "best" - or for Randy "better") on technical
grounds, not based on some absurd self imposed rule about what this
document is supposed to be permitted to do or not do.

kre

---

From: Sam Weiler <[email-masked]>
Date: Fri, 3 Oct 2003 16:55:37 -0400 (EDT)

>    Is there an English equivalent to the proverb "een olifant in een

"An elephant in a china shop?"  "A bull in a china shop" is more
common 'round these parts.

http://www.adbusters.org/oldwebsite/Uncommercials/bullspot.html

-- Sam

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 4 Oct 2003 07:29:32 +0859 ()

Olaf;

> -  If there is anybody who CANNOT live with one of the two solutions than 

I can't live with a solution that

	QNAME=X, QNAME!=CNAME produces an error

	QNAME=*, QNAME!=CNAME does not produce an error

even though the latter is the behaviour specified at 3a of 4.3.2.

So, just accept the fact that 3c of 4.3.2 contradicts with other
descriptions in rfc1034 and it should be clarified that wildcard
CNAME is OK.

							Masataka Ohta

---

From: Rob Austein <[email-masked]>
Date: Fri, 03 Oct 2003 21:23:23 -0400

> you do not have to deal with all kinds of loop protections etc.

I think that this is the right thing to do.

---

From: Randy Bush <[email-masked]>
Date: Sat, 4 Oct 2003 08:23:42 -0700

> Randy, something has to be done.

about what exactly?

> The option that can be argued that is not a change is to
> explicitly permit CNAME in wildcards

i think that is pretty clear, as paul also pointed out

> and actually make it work correctly.

what's "correctly?"  they are returned for a direct query.
you want more?  i suspect folk don't.

randy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 6 Oct 2003 10:41:46 +0200

> Am I missing other solutions?

I think there is a 3rd solution, although I personally do not like it,
I want to mention it.

 Leaving the existing situation but facing that a security aware
 resolver will need to have the intelligence to do the CNAME query and  
 resolve the ambiguity.

Explanation:

Assume the security aware resolver queries for QNAME=X (X being a name
that matches the wildcard that has a CNAME) and QTYPE=A.

The authoritative server will return something like

RCODE=NOERROR
 ; answer empty

 ; authority
  X    NSEC   CNAME SIG NSEC
  X    SIG    (labelcount indicating wildcard)

So the resolver gets an answer with the NSEC RR proving there is a
CNAME and the SIG proving that the match was against a wildcard. The
security aware resolver would have to know to do a query for QNAME=X,
QTYPE=CNAME to get the proper CNAME.

A non-secure resolver wouldn't know what situation its in.

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC