Subject: DNAME [4.2]: DNAME Apex is not Redirected Itself

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 12 Oct 2006 12:03:04 +0200

Issue [4.2]:
   Since the x is not CNAME'd itself, queries for the DNAME apex RRs are
   answered with data at x not at y.  The reason for the original
   decision was that in this way (without DNAME apex affected) one can
   have a DNAME at the zone apex, next to the SOA, NS records, without
   problem.  And use this to point zones under your operational control
   to other zones.  Hosting two identical zones for example.  Another
   reason for excluding the DNAME apex from the DNAME is that one can
   then query for the DNAME through RFC 1034 [RFC1034] caches.

So, for x DNAME y; the x itself is not redirected which is nice below a
zone cut, but not if the DNAME resides above a zone cut.

Best regards,
   Wouter

--
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: Thu, 12 Oct 2006 17:57:57 +0200

> zone cut, but not if the DNAME resides above a zone cut.

this is a feature of DNAME that cannot be changed IMHO. The only change
to the text I'd suggest is s/DNAME apex/DNAME owner/g;

-Peter

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 12 Oct 2006 17:07:18 +0100

On 12 Oct 2006, at 11:03, Wouter Wijngaards wrote:

> Issue [4.2]:
>    Since the x is not CNAME'd itself,

	s/CNAME'd itself/itself redirected/

	Keeping CNAME out of the discussion, except where strictly necessary,
	may help avoid confusion

>    queries for the DNAME apex RRs are

	I'm not sure that "apex" is the term we need here.
	Does anyone else have the feeling that this use is an overload?

>    answered with data at x not at y.

>    The reason for the original

	Two reasons are mentioned here, and each seems a perfectly good
	reason to me.  However, since the purpose (IIRC) is to clarify,
	the "locus classicus" for each should be cited.  Otherwise the
	origin of each (as folklore, received wisdom, or even retrospective
	rationalization, any of which would be a satisfactory pedigree)
	should be identified.

> zone cut, but not if the DNAME resides above a zone cut.

	I'm not sure what the point is here.  A zone cut below the DNAME
	cannot arise in the zone in which the DNAME is situated.  A zone
	cut somewhere in the target namespace of the DNAME may be appropriate
	if it is for some reason convenient to distribute that namespace
	over more than one zone.

Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 13 Oct 2006 08:45:12 +0200

>     s/CNAME'd itself/itself redirected/
Thank you for your, and Peters' corrections.

>     Keeping CNAME out of the discussion, except where strictly necessary,
yes.

>     rationalization, any of which would be a satisfactory pedigree)

They are from discussion on the namedroppers list, around 18 june 2006.
Perhaps this counts as folklore ;)

>     if it is for some reason convenient to distribute that namespace

Yes you are correct. The text is meant to refer to a DNAME where the
target is a zone-cut. And the DNAME record resides on the parent side of
that zone-cut.

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Mon, 30 Oct 2006 09:44:53 -0500

>>      xxxxxx xx xx.  However, since the purpose (IIRC) is to clarify,

I would hope that documentation of the folklore existed prior to the 
DNAME RR RFC...;)  If there's no way to dig this up (IETF archives 
are generally useless when it comes to researching them), then 
reverse engineering the rationale is acceptable.

Either way, this document ought to support the assertions it makes - 
like why "X DNAME Y" does not redirect queries for X itself.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.