Subject: Re: wcard-clarify's change

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

Date:        Fri, 03 Oct 2003 18:12:11 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i think that clarifying rfc1034 is the right goal, and that in this case,
  | that means clarifying that wildcard CNAME's will result in noerror/nodata
  | responses, which is (a) useless and (b) counterintuitive and (c) probably
  | not what the zone editor wants and so therefore (d) it's not recommended.

Paul, you keep skipping the point, which is that "wildcard CNAME's will
result in noerror/nodata responses" is simply not true.   And I don't mean
just because a (set of) very popular implementations doesn't do that.

I mean that whether you get the empty response (assuming the server is
implemented the way you believe is the correct way) depends upon where
you ask the question, and what previous questions that server has been
asked.

That is what is unacceptable - the DNS needs to supply predictable
answers, whatever they are.

kre

--
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: Sat, 04 Oct 2003 14:04:41 +0700

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

  | I can't live with a solution that
  | 	QNAME=X, QNAME!=CNAME produces an error
  | 	QNAME=*, QNAME!=CNAME does not produce an error

Otha-san - could you possibly repeat that with a little more detail,
or perhaps precision ...   Why would anyone care if the QNAME  was "CNAME"
for example?   (Is there something wrong with having a host called
cname.example.com ?)

kre

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 4 Oct 2003 21:24:11 +0859 ()

kre;

> for example?

Oops, I meant (assuming X does not explicitly exist)

  | 	QNAME=X, QTYPE!=CNAME produces an error

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

because latter behaviour is specified at 3a of 4.3.2, which means
code is error prone, regardless of whether it is an implementaion
one or a pseudo one of 3c.

So, just don't believe in pseudo code and follow explanations in
other parts of rfc1034 to allow wildcarded CNAME, which is the
clarification.

							Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Sat, 04 Oct 2003 20:12:32 +0700

Date:        Sat, 4 Oct 2003 21:24:11 +0859 ()
    From:        Masataka Ohta <[email-masked]>
    Message-ID:  <[email-masked]>

  | because latter behaviour is specified at 3a of 4.3.2, which means
  | code is error prone, regardless of whether it is an implementaion
  | one or a pseudo one of 3c.

Right - now I think just about everyone agrees that 1034's spec of
wildcard handling (where the wildcard has a CNAME record) is simply
broken.

The question is what to do about it.

This ...

  | So, just don't believe in pseudo code and follow explanations in
  | other parts of rfc1034 to allow wildcarded CNAME, which is the
  | clarification.

is certainly one option.   The other is to simply outlaw wildcarded CNAME.

Defining it to work sensibly (as you're suggesting) has the advantage that
it adds flexibility, and means one less special case (though implementations
at least need to make sure to handle

	* IN CNAME nosuchname

in some rational way).

Outlawing it is easy to accomplish, works everywhere already (if there
is no wildcard CNAME record, what the implementation might do if it
had one is irrelevant - so if wildcard CNAME is illegal, anyone who has
one in their zone simply needs to remove it). and most probably does
no great harm (uses for wildcard CNAME that make sense are few and far
between...)

Do you have a reason for preferring to define it (make it work properly)?

kre

---

From: Robert Elz <[email-masked]>
Date: Sun, 05 Oct 2003 17:12:57 +0700

Date:        Sat, 04 Oct 2003 15:40:22 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | presenting wildcard cnames that way (declaring them broken vs. fixing them)
  | presumes facts not yet generally accepted.

No, you still keep missing the point.  Or at least, on the list you do.

  | consider this text from rfc1034:
  | 
  | 	If a CNAME RR is present at a node, no other data should be
  | 	present; this ensures that the data for a canonical name and its
  | 	aliases cannot be different.  This rule also insures that a
  | 	cached CNAME can be used without checking with an authoritative
  | 	server for other RR types.

Yes.  All that is fine.

  | this argues that a wildcard cname would be legal if there were no other
  | descendents of the same parent.

Of course.  I am not attempting to claim that 1034 makes wildcard CNAME
illegal.

  | what's strange is that pvm said "at a
  | node" rather than "whose owner matches the qname".

I'm not sure what is strange about that.

  | but the last sentence
  | is compelling evidence that the pseudocode is not in error,

I have no idea how you arrive at that conclusion.   What the last sentence
says is that a CNAME must be the only RR, as otherwise, a cache with a
CNAME record, when asked for an A for that name, wouldn't know whether it
should just chase the CNAME, and return the A for the canonical name, or
whether it was required to query the auth server, and find out if there was
also an A record (in addition to one at the canonical name, if any).

That's all quite clear - but I don't see how it provides any evidence at
all about whether CNAMES at wildcards were intended to be noticed when the
name is not explicitly in the zone, but the wildcard CNAME is.

  | that the behaviour you're calling "broken" was intentional,

Note, the behaviour I am calling "broken" has nothing to do with the
algorithm in 3.4 particularly at all.   If it caused no other problems,
I'd be happy to leave things in the (totally useless) state where a
lookup of type CNAME would find the wildcard record, and a lookup of
type A would not - which is what you claim the algorithm requires.

The broken behaviour is that that does not produce a consistent result when
a cache is queried, rather than the auth server directly.

The answer depends upon earlier queries.   If you're claiming that's
a design feature, I'd like to see some evidence for it.   Nowhere else
in the DNS is it possible to make a query for type=X and have that query
affect the result of a later query for the same qname of type=Y (or not
if everything is correctly configured, and operating).

  | and that wildcard
  | cnames really just don't do what people intuitively feel they ought to.

I don't care what they do, or don't do.  I consider them useless in any
case.   What bothers me is that you're seriously suggesting that the DNS
should be explicitly made non-deterministic, but you won't actually say
so directly.

[email-masked] said:
  | what's "correctly?"  they are returned for a direct query. you want more?

I want consistent predictable answers.   Is that too much to ask?

In this case, I don't care what the answers are, but I want to know
what answers resolvers will obtain for queries I know they will make,
whenever I make any DNS configuration that is not invalid.

kre

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 6 Oct 2003 09:30:56 +0859 ()

kre;

> wildcard handling (where the wildcard has a CNAME record) is simply

I think it is merely that some description is missing, which, in
general, makes specifcation ambiguous.

A complication is that missing decription in psuedo code makes the
code not ambiguous but broken.

But, it merely means that we shouldn't blindly believe psuedo code,

In this case, the code is not consistent with the rest of the
specification nor other part of the code itself.

> The question is what to do about it.

Add some description.

> Do you have a reason for preferring to define it (make it work properly)?

In this case, it is already defined. See above.

Another reason not to outlaw wildcarded CNAME is that some might
already be using it in some zone.

							Masataka Ohta

---

From: [email-masked]
Date: Tue, 07 Oct 2003 09:23:36 +1000

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

	This is ridiculous.

	Failure to follow wildcard CNAME records in RFC 1034 section
	4.3.2 is clearly a oversite.  There is no technical reason
	not to follow them for QTYPE!=CNAME.  Following them clearly
	works based on years of experience and is consistant with
	the use of CNAME elsewhere in the DNS.

	It has to be a oversite as no engineer (we are engineers arn't
	we) would deliberately design a system which make the answers
	from the cache dependent apon the query order.

	I have argued for a long time to get 3c expanded to include
	following CNAMEs.  I will continue to argue for that result.

> A non-secure resolver wouldn't know what situation its in.
>
> -- Olaf
> 
> ---------------------------------| Olaf M. Kolkman
> ---------------------------------| RIPE NCC
> 
> 
> --
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]