Subject: RE: combined User and Carrier ENUM (was RE: [Enum] Agenda items for IETF Paris)

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 18 Jul 2005 15:21:37 -0400

Jim,

What you describe is what I understood to be the case.  And if so, then
I don't see any more or less queries to what I suggested versus defining
an additional carrier domain.  It seems that both the user and carrier
have rights to submit records to be stored at the authoritative server
for domain x.x.x.x.X.X.N.A.P.N.1.e164.arpa (to use a North American
example).

Do I understand correctly that when you say "NAPTRs" below, that more
that one could be present?  

If so, what server is authoritative for that domain, and what stops them
from hosting two records?

What happens when a number is ported from one carrier to another, even
using Carrier ENUM?  It seems like the same exact problem exists that
having a Carrier domain was seeking to somehow avoid.

Mike

> -----Original Message-----
> From: Jim Reid [mailto:jim at rfc1035.com] 
> Sent: Tuesday, July 12, 2005 5:42 AM
> To: Michael Hammer (mhammer)
> Cc: Michael Haberler; enum at ietf.org
> Subject: Re: combined User and Carrier ENUM (was RE: [Enum] 
> Agenda items for IETF Paris)
> 
> > I suspect that there is some aspect to DNS operation that I haven't 
> > put my finger on that makes this difficult.  I'm still not 
> sure what 
> > exactly your one DNS lookup means since from what I 
> understand several 
> > domain servers need to be queried to get a final response.
> 
> Michael, you seem to be confused how DNS lookups work. I hope 
> this explanation helps.
> 
> An application makes a DNS lookup by sending a query to some 
> local name server. This is known as the stub resolver in DNS 
> jargon: it formats a packet, sends it and waits for a reply. 
> That's all.
> 
> The local name server -- full service resolver in DNS jargon 
> -- sends a response back. If it can't answer from its cache, 
> the local name server will make iterative queries to resolve 
> the stub resolver's query. 
> Conceptually, it does that by starting at the root and 
> working its way down the tree. In ENUM, this would be 
> querying the .arpa name servers, then the e164.arpa name 
> servers and so on. This full service resolver will not go off 
> and query other branches of the tree. That is no DNS 
> implementation has logic which says "if the name doesn't 
> exist under foo.bar, try resolving this in some other 
> incantation of foo.bar or in some other domain name 
> entirely". In other words, the full service resolver 
> terminates the iterative lookups when it gets an answer or 
> gives up because the remote name servers are non-responsible 
> or unresolvable. That answer can of course be "the name/query 
> type you looked up does not exist". Whatever result the full 
> service resolver gets is then returned to the stub resolver 
> that made the initial query.
> 
> Of course the application could have logic that says "if 
> there are no NAPTRs for this number in e164.arpa, try 
> querying for them in some other domain name". If it did, that 
> second lookup would go to the full service resolver and go 
> through the same iterative process as before.
> 

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum