[enum-wg] Help with enum docs

2011/4/1 Jim Reid <jim at rfc1035.com>:
> On 1 Apr 2011, at 13:32, Peter Andreev wrote:
>
>> So, from a DNS-provider's point of view a collision may occur in case
>> of "too greedy" NAPTR or while processing non-terminal NAPTR.
>> And resolving of such collision is mostly application-side, not DNS. I
>> mean search for NAPTR in another domains.
>> Are my conclusions right?
>
> Not quite. A DNS provider's job is to serve up resource records on a bunch
> of name servers that answer queries. They shouldn't care about what those
> records are. That's a concern for whoever manages the domain where those
> records are stored.
>
> There are many NAPTR collisions: any response that contains more than one
> NAPTR is a collision. What's in those NAPTRs doesn't matter. If there's more
> than one of them, you have a collision and this is something for the
> application to handle.
>
> Once upon a time ENUM people mumbled about a resolver: something that sat in
> between the DNS lookup code and the application and did all the NAPTR record
> processing: order/preference issues, NTNs, service selectors, etc. This
> badly named beast would be the thing that dealt with any collisions and made
> sure the application only got to see the NAPTRs it cared about.

Hmm, I thought ENUM resolver is just the same as ordinary DNS caching server.
What the main difference between them?

>
> I'm not sure what you mean by "search for NAPTR". DNS is a lookup mechanism.
> It does not do search. And it does not necessarily follow that collision
> resolution requires further NAPTR lookups.
>

-- 
--
AP