Subject: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa, e.164.com, etc.)

From: "Robert H. Walter" <[email-masked]>
Date: Tue, 30 Jan 2001 16:45:51 -0500

At 04:16 PM 1/22/2001 -0500, Richard Shockey wrote:
> I wish I could rewrite the DNS to allow for alternative resolution 
> models..but if some one could describe how this could be done I'd be 
> delighted to listen..

NetNumber faced this exact challenge when we deployed our
"commercial" ENUM service under the domain "e164.com" last year.
The vendors and customers we were contacting all liked the idea of
moving forward with ENUM by utilizing our commercial implementation
but they didn't want to be trapped into a single ENUM domain.  We
addressed this requirement by building an ENUM resolver that can be
configured to simultaneously query multiple ENUM domains.  Our
approach was to enable an application to query a corporate domain
like "e164.company.com", one or more commercial domains like "e164.com"
and a public domain like "e164.arpa".  Here are a few of the underlying
assumptions that lead us to implement a multi-domain ENUM resolver:

1.  The decision to query one or more ENUM domains is entirely under
    the control of the ENUM enabled application.  It is highly
    recommeded that the application only query "TRUSTED" ENUM domains.

2.  ENUM requires a special DNS resolver to correctly process the
    NAPTR records per RFC2915 and it is a simple matter to
    incorporate the ability to simultaneously query multiple ENUM
    domains.

3.  While supporting the domain "e164.arpa" as a viable competitive
    domain to "e164.com", the regulatory review process surrounding
    "e164.arpa" will take considerable time to sort out.

The NetNumber ENUM resolver is downloadable from the support center
of NetNumber's web site and is licensed under the GNU Lesser General
Public License.  It may be easily configured to query multiple ENUM
domains.  By default, both "e164.arpa" and "e164.com" are queried.
The returned result-set is simply the aggregation of NAPTR records
for all domains. The ability to sort the result-set based on the 
domain order is currently being considered.  This may prove useful
when dealing with corporate and commercial ENUM systems.  For more
detailed information see www.netnumber.com/support/downloads.jsp.

Bob

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

---

From: Michael Mealling <[email-masked]>
Date: Tue, 30 Jan 2001 17:26:01 -0500

>     "e164.arpa" will take considerable time to sort out.

This is VERY dangerous if not done very carefully. In the case
where a NAPTR record's flag field is blank you have started
doing the standard DDDS delegation steps. In this case you cannot
mix records from multiple nameservers since the entire algorithm
breaks. There are two solutions:

1) coordinate all of the nameservers so that the NAPTR delegations
don't step on one another

2) each ENUM 'root' corresponds to exactly to one ENUM delegation
path. You can combine the resulting _output_ but you _cannot_
combine the actual NAPTR records.

Please be very careful if you do this. 

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: "Robert H. Walter" <[email-masked]>
Date: Wed, 31 Jan 2001 10:16:05 -0500

> On Tue, Jan 30, 2001 at 05:26:15PM -0500, Michael Mealling wrote:

Thank you for the feedback... Indeed NetNumber has taken great care
with its use of NAPTR.  RFC2915 is reasonably flexible on how each
application must specialize the basic NAPTR algorithm, hence, the
multi-domain ENUM resolver is a degenerate case of the the basic
NAPTR algorithm and discards NAPTR records from the result-set if:

  1.  The flags field contains a value other than "u".
  2.  The protocol portion of the service field does not match
      the input service protocol filter.
  3.  The service field does not end with "+E2U".
  4.  The regex field is empty.
  5.  The RR is a duplicate from another ENUM domain.

The remaining records are all terminal and the processed output
is a set of URI's that are sorted on "order" then "preference".
It is important to note the that the underlying use of NAPTR is
completely encapsulated from the application and the output of
the ENUM resolver is zero or more sorted ENUM Records containing
a URI, order and preference.  When multiple ENUM Records have the
same "order" and "preference" the application must decide which
to use.  As previously mentioned, we are currently evaluating the
effect of additionally sorting the result-set on ENUM sub-domain.
For example, the corporate ENUM domain "e164.company.com" may be
be configured to take precedence over the commercial ENUM domain
"e164.com", etc.

Regards,

Bob

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Jan 2001 10:31:05 -0500

On Wed, Jan 31, 2001 at 10:16:05AM -0500, Robert H. Walter wrote:
> > This is VERY dangerous if not done very carefully.
> > 

This may be Netnumber's degenerate application but its not the ENUM
application defined in 2916. If you're going to use ENUM which defines
what happens when the flag is empty then simply munging all of the
records together that came back on the first request isn't allowed.

If ENUM wants to allow this then you have the two alternatives
I listed earlier unless someone has an alternative that preserves
the delegation paths...

-MM

---

From: Richard Shockey <[email-masked]>
Date: Wed, 31 Jan 2001 09:33:55 -0500

At 05:26 PM 1/30/2001 -0500, Michael Mealling wrote:
> > configured to simultaneously query multiple ENUM domains.

That is all well and good but the vast majority  99.99 % of resolvers do 
not have that capability and never will.

> >     incorporate the ability to simultaneously query multiple ENUM

NO it is NOT.

It is not a special DNS resolver... the standard BIND 9 libraries can 
easily process NAPTR records.

> >     "e164.arpa" will take considerable time to sort out.

I reject the notion that e164.arpa is "competitive" ...it is designed to be 
trusted.

>combine the actual NAPTR records.

Thank you mike...

Richard Shockey, Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W., Suite 550, Washington DC. 20005
Voice: 202.533.2811,  Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Jan 2001 10:48:35 -0500

> easily process NAPTR records.

Actually, any DNS resolver that has the res_* API or some other way
of getting the answer data back in raw form can handle NAPTR records 
with no problems.  I think this API goes back to at least BIND 4.8 
which dates to the mid 1980s. DNS resolvers aren't supposed to care
if they get back an answer they can't parse. Its the servers that
are the issue and the latest Bind 8 and Bind 9 servers handle
NAPTR just fine (I know cause I'm testing it for URI resolution now).
And due to a security problem found recently, if you have a Bind 8 or
(heaven forbid) a Bind 4 server then you need to upgrade anyway.

-MM

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Jan 2001 10:55:52 -0500

> not have that capability and never will.

By resolver do you mean DNS resolver? The DNS resolver doesn't care
in this case. Its just being asked to retrieve a DNS record for 
some domain-name. If in the ENUM resolver you construct the domain-name
differently that's up to you. You just have to ensure that you follow
the ENUM (2916) rules until you get an output. If you have done that
in parallel for e164.com, e164.arpa and e164.boogaloo and gotten
three sets of output then you can do whatever you want. Its just that 
for each of those 'roots' you have to follow the rules until those 
rules tell you that you have finished....

-MM

---

From: "Robert H. Walter" <[email-masked]>
Date: Wed, 31 Jan 2001 15:33:16 -0500

> On Wed, Jan 31, 2001 at 10:31:25AM -0500, Michael Mealling wrote:
> 

With all due respect, I disagree that with your statement that the
ENUM resolver is not compliant with the ENUM application defined in
2916.  I can't find any text, example or specfication in either 2915
or 2916 that states or alludes that the flags field for the ENUM
application is anything other than "u".  In fact, all the specification
text and examples related to ENUM in both 2915 and 2916 only use
the "u" flag.

None the less, the ENUM resolver will most likely encounter a scenario
where the NAPTR records are provisioned in an ENUM domain with a blank
flag.  The remedy in this situation is simple... They are discarded.

Thank you for the heads up on processing sets of NAPTR RR's returned
from a given domain verses processing the munged NAPTR sets and then
combining the output.  I will be certain to account for this nuance.

Regards,

Bob

> -----Original Message-----
> From: Michael Mealling [mailto:[email-masked]]
> Sent: Wednesday, January 31, 2001 10:31 AM
> To: Robert H. Walter
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Enum] Querying Multiple ENUM Domains (e.g. e164.arpa,
> e.164.com, etc.)
> 
>

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Jan 2001 15:50:03 -0500

> text and examples related to ENUM in both 2915 and 2916 only use

You are correct. On second reading I noticed that the ENUM spec
never actually defines the contents of the flags field at all
but instead seems to inherit it from 2915.  'u' is used in several 
examples but nothing ever actually says what 'u' means.

> flag.  The remedy in this situation is simple... They are discarded.

2916 doesn't say this either. 2915 specifically says that in the
absense of a flag value that specifies terminality that the output of
the substitution is a new Key to be looked up. See the section
that defines the interaction between the Service field and the
Flags field:

      If a protocol is specified, but the
      flags field does not state that the NAPTR is terminal, the next
      lookup MUST be for a NAPTR.  The client MAY choose not to perform
      the next lookup if the protocol is unknown, but that behavior
      MUST NOT be relied upon.

> combining the output.  I will be certain to account for this nuance.

No problem. Remember, NAPTR and the DDDS aren't just TXT records
for stuffing URLs into....

-MM