Subject: [Enum] RE: draft-ietf-enum-e164-dns-03.txt

From: James Yu <[email-masked]>
Date: Thu, 10 Aug 2000 09:51:46 -0500

Patrik, Mike,

I'll ask a few basic DNS questions which may help me in understanding the
enum process.

Let's assume that my desktop PC in my office needs to launch a enum/DNS
query.  It (the DNS client/resolver) follows the 6 steps described section 2
to formulate the DNS query.  Since I'm in an enterprise environment, there
is a local DNS server that does the caching and DNS resolutions.  So my PC
sends the query to that local DNS server which then tries to resolve the DNS
query.  

Question#1:  Does this local DNS server know anything about enum?   All
those digits in the DNS queries are just zones to it.  Is it correct?

Now, the local DNS server receives all the NAPTR RRs from for a particular
E.164 number related enum/DNS query.

Question#2: Does the local DNS server returns all those NAPTR RRs to the
client on my PC or does it continue the DNS resolution process including
applying the rewrite rules and launching the DNS query to fetch additional
RRs indicated in the NAPTR RRs?

I'll also need to read the I-Ds mentioned by Hong and Mike.

James

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Thursday, August 10, 2000 1:29 AM
> To: James Yu
> Cc: [email-masked]
> Subject: RE: draft-ietf-enum-e164-dns-03.txt
> 
> 
> At 16.30 -0500 00-08-09, James Yu wrote:
> >I'm still not clear about this.  The '+' is not part of the 
> enum DNS query
> >(only x.x.x.x.x.x.e164.arpa instead of 
> x.x.x.x.x.x.+.e164.arpa).   So for
> >the NAPTR algorithm to use the E.164 number, it has to 
> retrieve the E.164
> >number in the DNS query (e.g., get everything before 
> .e164.arpa, remove all
> >the dots and reverse the order of the digit to recover the 
> original E.164
> >number).  If '+' is needed, then '+' is added to the front 
> of the E.164
> >number.  I assume that the client is not asked to remember 
> the output of
> >step 2 in section 2. The rewrite rule will be applied to the 
> string in the
> >DNS query and that string does not have '+' in it.   That is 
> why I'm not
> >clear about the '+' discussed in your I-D.
> 
> No, the steps that have to be taken is _exactly_ what is 
> written in the spec:
> 
> (1) Take the E.164 number
> (2) Remove all characters part from leading '+' and digits
> (3) Remove the '+'
> (4) Reverse the order of digits
> (5) Add '.' between digits
> (6) Add ".e164.arpa." at the end
> (7) Look up NAPTR in DNS
> (8) If NAPTR is non-terminal apply rewrite rule to output of (2)
>      and query for new NAPTRs again which you apply output of (2) to
> 
> That is what you _have_ to do.
> 
> >Also, a client may send a DNS query to a local DNS server 
> for resolution.
> 
> Of course.
> 
> >Does the local DNS server continue the DNS resolution process when it
> >receives NAPTR records (may be it depends on the type of NAPTR RRs
> >returned)?
> 
> I don't understand. Do you ask whether the local resolving DNS server 
> is doing the NAPTR resolution? The answer to that question is "no". 
> The client have to do that as the client is the one which know what 
> the input to the NAPTR algorithm is for E2U. You can not when using 
> NAPTR take for granted that what the regexp is applied to can be 
> extracted from the domainname.
> 
> >I guess that if the NAPTR is for a SRV record, the local DNS
> >server will go to the NS specified by the "target" to 
> retrieve SRV RR(s).
> 
> I don't see how SRVs can be included in the ENUM mechanism...
> 
> >So the client performs the six steps described in section 2 
> but it is the
> >local DNS server that performs the DNS resolution.  The 
> local DNS server
> >then is required to add the '+' to the E.164 number using 
> the rewrite rule
> >if it needs to continue the DNS resolution process.  But 
> only the client
> >knows that the DNS process is related to enum.  The local 
> DNS server only
> >performs routine DNS process (including NAPTR) and may not 
> know that the DNS
> >query is about enum.  Is it correct?
> 
> The DNS part of this is only querying for DNS RRs, and does not do 
> anything else regarding NAPTR rewrites.
> 
>    paf
> 

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Aug 2000 16:59:04 +0200

At 09.51 -0500 00-08-10, James Yu wrote:
>Question#1:  Does this local DNS server know anything about enum?

No. Nothing at all. It only knows that you query for

   Owner: 1.2.3.4.5.5.6.7.8.e164.arpa. (or whatever)
   Type:  NAPTR
   Class: IN

Nothing else.

The data in the record is passed back to your computer.

>All

Yes.

>E.164 number related enum/DNS query.

Yes.

>RRs indicated in the NAPTR RRs?

Yes, it returns all of them.

    paf

---

From: Michael Mealling <[email-masked]>
Date: Thu, 10 Aug 2000 10:56:24 -0400

> I'll ask a few basic DNS questions which may help me in understanding the

No problem...

> those digits in the DNS queries are just zones to it.  Is it correct?

Correct. This is actually a strength since it allows DNS to act as it
always has. No additional software is needed in the server. You _can_
start optimizing stuff by making the server ENUM aware so that it
puts potentially useful information in the additional information 
field of the DNS packet. This optimization on the server side is a MAY 
not a MUST. 

> E.164 number related enum/DNS query.

Yep....

> RRs indicated in the NAPTR RRs?

Nope. The local DNS server is dumb with respect to ENUM and NAPTR. The
DNS server simply return the NAPTR records for the dname you request.
Its up to your client (PC) to actually do the rewrites and issue any
further DNS requests....

> I'll also need to read the I-Ds mentioned by Hong and Mike.

Read teh DDDS ones first and then the draft-ietf-urn-naptr-rr-04.txt
document. It'll make more sense that way...

-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: Patrik Fältström <[email-masked]>
Date: Thu, 10 Aug 2000 19:49:14 +0200

>document. It'll make more sense that way...

And when the DDDS documents are ready (all three of them) it will 
replace the existing RFC and draft-ietf-urn-naptr-rr-04.txt.

So the confusion today is on it's way to be resolved.

   paf