Subject: DNAME [4.1]: DNAME as a Delegation Tool

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 12 Oct 2006 11:59:09 +0200

Issue [4.1]
   DNAMEs can be used as indirections, the goal of these indirections is
   to mirror a part of the DNS domain tree in another part of the DNS
   domain tree.  This mirroring should be easy.  Alternative wording is
   that the goal is to have an alias name for a part of the domain tree.
   Running example is x DNAME y.  The extra point here is that the
   mirroring is done at exactly a delegation point.  There is a use for
   this case.

Can, should, must DNAME be used as a delegation tool? And how is this
possible according to protocol?

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: Niall O'Reilly <[email-masked]>
Date: Thu, 12 Oct 2006 16:43:24 +0100

On 12 Oct 2006, at 10:59, Wouter Wijngaards wrote:

> Issue [4.1]
>    DNAMEs can be used as indirections,

	s/can be/are/

	What else might they be used for, after all?

>    the goal of these indirections is
>    Running example is x DNAME y.

>    The extra point here is that the
>    mirroring is done at exactly a delegation point.

	I'm missing something here.  Why "exactly at a delegation point"?

	How should I read "is done" here -- as "must only be done",
	as "is most often done", as "may be done", as "is particularly
	effective when done", or what?

	From the point of view of the zone containing the DNAME record,
	there is definitely some kind of cut involved, as this zone can
	contain no descendants (not even glue!) of the owner of the DNAME.

	OTOH, the "target namespace" of a DNAME record may include

	 - all of a zone except the apex (an exapicated zone),
	 - part of a zone,
	   or
	 - the union of either of the above and possible child zones
	   or further [CD]NAME-redirected namespace.

	[ Yes, Aargh! ]

	So, I wonder just what

>    mirroring is done at exactly a delegation point

	should mean.

> There is a use for this case.
>

	I think it's worth keeping the term "delegation" to mean the
	relationship (or process of achieving that relationship) between
	the parties (or their nameservers) responsible for either side
	of a real, traditional zone cut.  Let's not dilute the terminology
	of so many existing, still-valid documents.

	I believe it will help to use some other term to describe the
	use of DNAME _instead_ of delegation. "Non-terminal redirection"
	is accurate, but perhaps a little obscure.  "Pseudo-delegation"
	helps make it clear that this is "something other than delegation",
	but may be too close to "delegation".

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: Peter Koch <[email-masked]>
Date: Thu, 12 Oct 2006 17:55:30 +0200

> possible according to protocol?

To avoid terminology pollution/erosion, I'd rather not re-define the term
'delegation' here. Delegation is tightly bound to making a zone cut and
separating out control over a well defined part of the name space to
a third (not necessarily) party. Delegations are something that (should)
happen transparently to the user.

So, as an approximation, 'registration tool' might be a better term.
Instead of a delegation, a registry (or anyone in a similar role) could
"alias" a subdomain (not zone!) into a different part of the name space.
I've seen this in the ENUM universe, but Niall may have more detail about this.

OTOH, this is a purely operational matter, so I'm not sure the DNAME
clarifications/update document has anything to say here except what appears
in issue 4.2, i.e., the owner is not covered by the DNAME.

-Peter

---

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

>>    mirroring is done at exactly a delegation point

The idea is that the use of DNAME as 'registration tool' (as Peter
coins) at a zone-cut for the target is envisioned, suffers from some
technical problems. To give out a new domain as an alias of another.
Like, trouble with NS, MX, PTR records to that new domain. Apex not
redirected. This item refers to the more overall picture, and it is an
issue because the 'registration tool' may not work as expected.

I do not know of issues surrounding the use of DNAME within a zone, or
the more complicated cases.

Best regards,
   Wouter

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 13 Oct 2006 10:48:04 +0100

> the more complicated cases.

	Interpreting "issues" as a euphemism for "problems", neither do I.

	For an example of the phenomenon, try

% dig 1.7.0.2.6.1.7.1.3.5.3.e164.arpa any

	Discussion of the content of the example, unless it helps elucidate
	relevant potential issues, is probably out of scope.

Best regards,

Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 13 Oct 2006 15:53:14 +0100

On 13 Oct 2006, at 07:35, Wouter Wijngaards wrote:
> redirected.

	I see what you mean.

	I wonder, would it be too gross an evasion to punt this set of
	problems to DNSOP?

	If one has a requirement for a domain clone (with however many
	alias instances), and the parent domain is administered as a
	delegation-only domain (policy of parent administration), and
	the clone apex is required not to be an empty non-terminal, then
	the consequence is that DNAME is not appropriate.  The
	disadvantage is that each instance in the clone has to be
	individually provisioned.

	But that's "operations", no?

	Enjoy the weekend, everyone!

	/Niall

---

From: Jim Reid <[email-masked]>
Date: Fri, 13 Oct 2006 16:37:47 +0100

> 	But that's "operations", no?

There may be some mileage in a draft that explains the gotchas  
arising from inappropriate or poorly considered use of DNAMEs. Or  
even wildcards. .-)

IMO DNAME was not invented to fix zone provisioning problems and  
should not be subverted for "solving" such problems.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Oct 2006 15:49:16 +0200

On Fri, Oct 13, 2006 at 03:53:14PM +0100,
 Niall O'Reilly <[email-masked]> wrote 
 a message of 31 lines which said:

>       The disadvantage is that each instance in the clone has to be

Or, if you want to put it in a protocol, RRP or "EPP mappings" are the
obvious candidates to do so. (I believe that some TLD already offer
the ability to manage such a "cluster" of domain names, providing they
have the same delegation info.)

I agree with Jim and Peter that it should not be in the DNS.

---

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

>I agree with Jim and Peter that it should not be in the DNS.

There are some things that are part of the DNS protocol and some 
things that are not (but impact it).  Provisioning, registration, 
etc., are not part of the DNS protocol, but delegation is.

When discussing an element of the protocol in the way this document 
does - i.e., defining the syntax and protocol semantics, it is best 
to leave any mention to the use of the element by applications to no 
more than illustrative examples or the statement of the problem the 
element is intended to address.

What I'm trying to say is that we ought not try to label the DNAME as 
a tool for any particular use.

The DNAME isn't a delegation tool.  The NS is.  (And the DS is - 
delegation of DNSSEC-brand security.)  The DNAME isn't for mirroring 
parts of the DNS name space - "mirroring" generally means maintaining 
an instantly complete copy of another object.

The DNAME is a non-terminal redirection element (in as much as a 
CNAME is a terminal redirection element).  A DNAME is an instruction 
to the look up process.  If anything, DNAME is a query redirection 
tool.  Think of DNAME as a passive, rubber-padded wall that ping-pong 
query balls hit and are sent elsewhere where they find what they are 
looking for.  Passive - as in not part of the "operation" of 
registration.

(I've always had a hankering to talk about padded walls and ping pong 
balls in the same sentence.  Life goal #8 checked off.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.