Subject: implications of RFC 2181 on cname chains

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Mar 2008 20:26:44 +0000

in a private discussion with jinmei, he showed me this text from RFC 2181:

>    Note that the answer section of an authoritative answer normally
>    contains only authoritative data.  However when the name sought is an
>    alias (see section 10.1.1) only the record describing that alias is
>    necessarily authoritative.  Clients should assume that other records
>    may have come from the server's cache.  Where authoritative answers
>    are required, the client should query again, using the canonical name
>    associated with the alias.

i've struggled with this concept, since i had always restricted this
treatment to "out of zone" cnames.  in other words when i receive...

	www.example.com. cname xxx.example.com.
	xxx.example.com. aaaa  dead::beef

...i had been treating both names as authoritative, since both are children of
the apex i was querying under.  i've realized that xxx.example.com might be an
NS RR for which the example.com authority servers happen to have an AAAA RR
cached (or might have it as glue in the example.com zone).  so, i have altered
my own caching server to ignore the second name in the above example, and to
re-fetch from the end of my cached cname chain, so that i have to build my
cached cname chain one query at a time, no matter what the authority server
says.

i recommend that authority servers stop sending back full cname chains.  i
don't think this implication was obvious during the production of RFC 2181.
only the name matching the qname can be seen as authoritative.  everything
else is just fluff.  cname chains are nec'y for RD=1 RA=1, otherwise useless.

--
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: Mark Andrews <[email-masked]>
Date: Tue, 04 Mar 2008 08:49:21 +1100

> else is just fluff.  cname chains are nec'y for RD=1 RA=1, otherwise useless.

	It's 1034 that you are chasing and with DNSSEC it doesn't matter
	as you should end up being able to cryptographically verify
	the entire CNAME chain regardless of its source.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Blacka <[email-masked]>
Date: Mon, 3 Mar 2008 19:05:21 -0500

> else is just fluff.  cname chains are nec'y for RD=1 RA=1, otherwise  

I was actually thinking about writing a draft about this, but figured  
that it was either too tall a hill to climb or not actually solving a  
real problem (or both).

I was thinking that authoritative servers should still be allowed to  
chase CNAMEs within zone, but your point suggests otherwise, which I  
find interesting.

My thinking was that, since modern resolvers should certainly the rest  
of the CNAME chain when it goes out of zone, then authoritative  
servers should not waste their time.    Your point is stronger.

--
David Blacka                          <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Mar 2008 04:21:29 +0000

> > ...
> > don't think this implication was obvious during the production of RFC
> > 2181.  only the name matching the qname can be seen as authoritative.
> > everything else is just fluff.  cname chains are nec'y for RD=1 RA=1,
> > otherwise useless.
> 
> I was actually thinking about writing a draft about this, but figured that
> it was either too tall a hill to climb or not actually solving a real
> problem (or both).

i've realized that the point in 1034 and 2181 is so subtle that a separate
i-d is required.  perhaps you would do me the honour of co-authoring it?

> I was thinking that authoritative servers should still be allowed to chase
> CNAMEs within zone, but your point suggests otherwise, which I find
> interesting.

i can't escape the feeling that in-zone cnames ought to be chainable in a
single response, nor the feeling that they really, in fact, cannot be.  in
any case any RD=0 initiator has to be prepared to detect and finish incomplete
cname chains, whether due to out-of-zone, or ttl-expired-middle-member, and
so this change adds no new logic, except the part where they have to ignore
all answer records whose owner != qname, even if it otherwise looks like a
complete in-zone chain.  the recommendation that servers stop sending this
swill is minor in comparison to what the initiator has to stop believing.

> My thinking was that, since modern resolvers should certainly ... the rest
> of the CNAME chain when it goes out of zone, then authoritative servers
> should not waste their time.  Your point is stronger.

but as you say, authoritative servers really shouldn't waste their time, but
if they do, then RD=0 initiators really shouldn't believe what they say.
(RD=1 initiators, so-called "stubs", are a different story, they should
believe what they hear from RA=1 responders, including cname chains.)

if this draft gets writ, then it would be a fine time to announce, once and
for all, that if RD=1, there is no need for an authority section, with or
without an RFC2308 SOA proof, and that the additional section should only
pertain to the answer section, not the (ought to be empty) authority section.

---

From: Phil Pennock <[email-masked]>
Date: Mon, 3 Mar 2008 21:07:44 -0800

On 2008-03-04 at 04:21 +0000, Paul Vixie wrote:
> single response, nor the feeling that they really, in fact, cannot be.

This seems reasonable to me, so please shoot holes in it:

If the responder orders the additional records so that authoritative
responses come before non-authoritative responses, then an EDNS0 option
AUTHADDITIONAL could provide an integer N in the range 0 to
number_of_additional_responses (inclusive) with the interpretation that
it is authoritative for the first N additional responses, not counting
the OPT pseudo-RR.

Clients that don't understand the extension treat all additional
responses identically (and hopefully non-authoritative).

Clients that _might_ understand the extension will have issued an EDNS0
query suggesting that it will correctly ignore unknown extended options.
(Worst case, a new extended flag requesting an authadditional response).

Clients that do understand the extension gain the ability to reduce the
number of round-trips to safely chase CNAME chains, providing a
performance benefit to enabling EDNS0 where the server supports this.

Clients that understand the extension talking to a server which doesn't
support the extension won't get the new option response so won't see the
immediate benefit, but no harm done.

No additional octets required for query packets.

Adds six octets to response packets where this is used.  Since it's an
EDNS0 response, there should typically be a larger buffer to play with
in the first place.  Assumption is that 16 bits will be sufficient to
count the number of additional records for which the server is
authoritative.

The deployment path looks clean, the benefits look obvious, the cost is
minimal (given the additional packet-size available with EDNS0) and it
helps push EDNS0 to on-by-default in clients.

Two birds, one stone?

Now someone will point out what I'm missing and I'll be duly
embarrassed.

-Phil

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 04 Mar 2008 09:32:07 +0100

Paul Vixie wrote:
|>> ...
|>> i recommend that authority servers stop sending back full cname
chains.  i
|>> don't think this implication was obvious during the production of RFC
|>> 2181.  only the name matching the qname can be seen as authoritative.
|>> everything else is just fluff.  cname chains are nec'y for RD=1 RA=1,
|>> otherwise useless.
| i've realized that the point in 1034 and 2181 is so subtle that a separate
| i-d is required.  perhaps you would do me the honour of co-authoring it?
|> I was thinking that authoritative servers should still be allowed to
chase
|> CNAMEs within zone, but your point suggests otherwise, which I find
|> interesting.

Hi,

I think that (as it says in RFC2181) the remainder of the CNAME chain is
still useful, but simply receives a lower trust rank order. RFC2181 does
not say that the remainder of the CNAME chains has to be discarded.

You receive a reply with AA bit set from the authority server, and thus
classify the RRsets in the answer section as
~   + The authoritative data included in the answer section of an
~       authoritative reply.
But the data after the CNAME has to be classified as
~   + Data from the answer section of a non-authoritative answer, and
~       non-authoritative data from the answer section of authoritative
~       answers,
Which is a lower trust rank.

This means that the queryer has to lower its belief in the remainder of
the CNAME chain. And a-query-per-CNAME is not required (unless the
queryer wants to have all of the CNAME chain with the same trust rank).

If you decide to produce text about this, please consider this point to
soften the hard-line 'one query per CNAME'-solution.

Best regards,
~   Wouter

---

From: "Roy Arends" <[email-masked]>
Date: Tue, 4 Mar 2008 10:23:45 +0100

[email-masked] wrote on 03/03/2008 09:26:44 PM:

> Paul Vixie <[email-masked]> 
> Sent by: [email-masked]
> 
> 03/03/08 09:26 PM
> 
> To
> 
> [email-masked]
> 
> cc
> 
> Subject
> 
> implications of RFC 2181 on cname chains
> 
> cached (or might have it as glue in the example.com zone). 

Or the server might be authoritative for both the zone example.com and the 
zone xxx.example.com. I have argued many times that the concept of zone is 
lost to the resolver, hence the resolver can not distinguish between 'in 
zone' and 'out of zone'.

Roy

---

From: [email-masked]
Date: Tue, 4 Mar 2008 10:45:33 +0000

> lost to the resolver, hence the resolver can not distinguish between 'in 

	thats certainly true for a resolver - i'd argue that a validator
	has to understand the concept of zone... 

--bill

---

From: John Dickinson <[email-masked]>
Date: Tue, 4 Mar 2008 11:51:05 +0000

> 	has to understand the concept of zone...

Why? A validator is just something that knows how to do something with  
the records it got from a resolver. The only other info it has that  
the resolver didn't know is the trust anchor.

John
---
John Dickinson

---

From: [email-masked]
Date: Tue, 4 Mar 2008 12:17:29 +0000

> the resolver didn't know is the trust anchor.

	perhaps we are speaking past each other.  a validatior walks
	the trust chain - starting from the data in the response from
	the query - until it reaches a keyset that matches one of its
	locally configured TAs.

	query - returns an RRset (and we are done, modulo the question
		of where did all the data in the RRset come from)
		no real need to know/care about delegation heirarchy.
		at least from the resolver end.
	validation - a series of query/responses to build a trust chain
		back to one of my local TAs.  Very much needs to know how
		to walk the delegation hierarchy line.

	or did you mean something else?

--bill

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2008 01:12:19 +1100

> the resolver didn't know is the trust anchor.

	It knows the trust anchor for a ZONE.  You chain trust
	across ZONE boundaries with signed DS and DNSKEY records.
	You go insecure at ZONE boundaries by presenting the correctly
	signed NSEC records.