Subject: DNAME Issue 4.10 (open) CNAME TTL value

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 Feb 2007 20:19:44 -0500

Open Issue 4.10 TTL of Synthesized CNAME RRs

Original message:
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01340.html

Reply from Ed Lewis suggesting CNAME TTL = DNAME TTL
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01435.html

This issue is still open for discussion.  The current
version of the draft states the CNAME TTL is 0 but
MAY be set to the TTL of the original DNAME and that
resolvers could expect either TTL in a packet.

If there are strong opinions either way (or opinions in favor
of allowing both) please state the opinion.  

Scott & Wouter
DNAME clarify draft editors

--
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: Peter Koch <[email-masked]>
Date: Wed, 7 Feb 2007 18:04:42 +0100

> http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01435.html

not yet disagreeing, but consider this situation:

example.org.	DNAME example.net.

Query:	foo.example.org.  A
->	foo.example.org. $ttl  CNAME foo.example.net.
	[...]

Query:  deep.foo.example.org. A

Now, is the "recursive server" supposed to skip over the CNAME in its cache?

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Feb 2007 12:27:47 -0500

>Now, is the "recursive server" supposed to skip over the CNAME in its cache?

Well, "what a revolting development this is." [1]

I suppose that the cache would have this...

example.org.	 1873  DNAME example.net.
foo.example.org. 1873  CNAME foo.example.net.

So a "search" would see the DNAME first - assuming the cache works 
downward.  I think.  Well, I don't know as this is the cache, not the 
authority which begins by picking the zone and then labelling 
downward.  If the cache "longest" matched the name (deep.foo...) then 
it would "skip over" the DNAME and see the CNAME as the closest 
encloser.

Or does a cache search down from the apex of the cache?  I guess I 
don't know off hand.

[1] http://www.scriptmag.com/earticles/earticle.php?331
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"Two years ago you said we had 5-7 years, now you are saying 3-5.  What I
need from you is a consistent story..."

---

From: Peter Koch <[email-masked]>
Date: Wed, 7 Feb 2007 20:09:08 +0100

> foo.example.org. 1873  CNAME foo.example.net.

not sure it would/should cache both. If it doesn't understand DNAME, why
should it cache random garbage? This is unrelated to 3597, by the way.
If the response contains anything the querying resolver doesn't expect,
I'd assume it would at least ignore that part or even disregard the
response. But that touches a different issue.

If it understands DNAME, why cache the CNAME?

> it would "skip over" the DNAME and see the CNAME as the closest 

The owner of a CNAME RR proves that there's no name further down, doesn't it?
So, is "aggressive negative caching" prohibited here?  Well, the SOA RR
might be missing ...

What I'm trying to say is that back then there was a reason to set the TTL to
zero, most likely to avoid corner cases.  If these are obsolete today, a
relaxation of the TTL rule should clearly state that.

-Peter

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Feb 2007 10:31:04 +1100

> If it understands DNAME, why cache the CNAME?

	That was the expected behaviour.

	Versions of named which understand DNAME don't cache the CNAME.
	Versions of named which don't understand DNAME cache the CNAME.

> The owner of a CNAME RR proves that there's no name further down, doesn't it?

	No.  CNAMEs have never been restricted to leaf nodes.  The only
	place in the namespace where they can't be is at the apex of a
	zone.

> relaxation of the TTL rule should clearly state that.

	There was no technical reason for setting the CNAME to zero.
	The working group was just being conservative at the time.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]