Subject: [Enum] RE: Standard DNS Delegation or CNAME/DNAME Redirection

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Thu, 2 Nov 2000 08:52:23 -0600

The key is your statement "Why re-issue, reform the query when standard DNS
delegation will suffice".  Where it is sufficient, it clearly preferable to
use NS records to delegate authority.  For the simple examples you have
provided, the NS records are clearly sufficient and return more quickly.

In a previous response, I have described a number of topologies where NS
records are not sufficient to represent existing numbering plan topologies.

Unless we decide otherwise, Dname / CNAME are useful and standard DNS
facilities.  As such they are part of the toolbox of an ENUM system
administrator, must be supported by clients, and whose negative interactions
with NAPTR must be well understood.

Greg V.

-----Original Message-----
From: Robert H. Walter [mailto:[email-masked]]
Sent: Tuesday, October 31, 2000 11:57 AM
To: [email-masked]
Cc: Vaudreuil, Greg M (Greg); Patrik Faltstrom; Randy Bush
Subject: Standard DNS Delegation or CNAME/DNAME Redirection

Greg, Ann,

Please clarify why you believe CNAME and DNAME resource records
are required to redirect the DNS query from the designated
authority to the service registrar?  Why re-issue, reform the
query when standard DNS delegation will suffice? Consider the
following scenarios that assume the designated authority for
1.e164.arpa has provisioned the fully specified E.164 domain
name 2.1.2.1.5.5.5.0.0.8.1.e164.arpa on behalf of the service
registrar ACME:

Scenario 1: Use NS and A glue records to delegate authority for
the fully specified E.164 domain name to the registered name
server.  This approach has the advantage of not requiring client
resolvers and/or foreign name servers to additionally query for
the A records associated with the defined name servers.  Using
glue records has the additional restriction that the delegated
name servers MUST be children of the 1.e164.arpa sub-domain,
but results in reduced resolution time because there are fewer
queries and network traversals required.  Notice the extended
domain names for acmes name servers.

  2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.1.e164.arpa.
                                   IN NS ns2.acme.1.e164.arpa.

  ns1.acme.1.e164.arpa.            IN A  192.249.249.1
  ns2.acme.1.e164.arpa.            IN A  192.249.249.2

Scenario 2: Use only NS records to delegate authority for the
fully specified E.164 domain name to the registered name server.
This approach has the disadvantage of requiring client resolvers
and/or foreign name servers to additionally query for the A
records associated with the defined name servers.  By not using
glue records, the delegated name servers are not required to be
children of the 1.e164.arpa sub-domain. The result is increased
resolution time due to additional queries and network traversals.

  2.1.2.1.5.5.5.0.0.8.1.e164.arpa. IN NS ns1.acme.com.
                                   IN NS ns2.acme.com.

In either scenario, the delegated name server must be minimally
provisioned with an e164.arpa zone that contains the associated
NAPTR records.  It may be more conventional that the delegated
name server be provisioned with the zone at the cut boundary
(1.e164.arpa), but this is not a requirement. Are you attempting
to avoid having the service registrar provision the e164.arpa
zone on their name server?

Bob

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Randy Bush <[email-masked]>
Date: Thu, 02 Nov 2000 07:19:14 -0800

> records are not sufficient to represent existing numbering plan

the example in your document does not sustain that point, and the point has
yet to be agreed in any circumstance.

> facilities.

with very large warning signs on them.

randy

---

From: "Robert H. Walter" <[email-masked]>
Date: Thu, 2 Nov 2000 11:21:28 -0500

> records are not sufficient to represent existing numbering plan
topologies.

Can you be more explicit about which topology?  I'm looking to support your
position on the use of CNAME/DNAME, but can't justify its application. What
issue are you attempting to solve by the use of CNAME/DNAME? Are you simply
attempting to avoid having a delegated name server provision an e164.arpa
zone by redirecting to an alternate name space, e.g. enum.company.com?

Bob

-----Original Message-----
From: Vaudreuil, Greg M (Greg) [mailto:[email-masked]]
Sent: Thursday, November 02, 2000 9:52 AM
To: Robert H. Walter; [email-masked]
Cc: Patrik Faltstrom; Randy Bush
Subject: RE: Standard DNS Delegation or CNAME/DNAME Redirection

Greg V.

-----Original Message-----
From: Robert H. Walter [mailto:[email-masked]]
Sent: Tuesday, October 31, 2000 11:57 AM
To: [email-masked]
Cc: Vaudreuil, Greg M (Greg); Patrik Faltstrom; Randy Bush
Subject: Standard DNS Delegation or CNAME/DNAME Redirection

Greg, Ann,

Bob

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 02 Nov 2000 13:56:02 -0500

I am in danger of having completely missed the point, but it
strikes me that:

	. the "traditional" view of ENUM has been for "top-down"
	  resolution, following a delegation path, and for that
	  the NS/NAPTR route is appropriate/adequate.

	. your examples seem to treat "bottom-up" resolution -- 
	  working resolution from a local context outwards to the
	  closest applicable scope.  In that case, you don't
	  want to/it would perhaps be difficult to engineer
	  top-down resolution that would find the appropriate
	  level for your resolution

These are two different problems, and probably bear 2 different
solutions -- but ones that need to be properly integrated or else
we will wind up with "islands" of enum telephony (where you can't
work your way out to "the" global registry).

Leslie.

-- 

-------------------------------------------------------------------
"Reality with a delicate splash of the imaginary... 
    ... or was that the other way around?"
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 02 Nov 2000 11:04:36 -0800

>with very large warning signs on them.

Which warning signs are those?

Rgds,
-drc