[enum-wg] Re: more enum resolver confusion

2011/4/1 Jim Reid <jim at rfc1035.com>:
> On 1 Apr 2011, at 15:08, Peter Andreev wrote:
>
>>> 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 hoped that had been clearly explained in the paragraph above. Obviously
> not. Oh well... The (hypothetical?) ENUM resolver would be some code that
> spoke to a stub resolver that made DNS lookups and had an API to whatever
> applications wanted to avoid doing NAPTR record processing for themselves.
>
> It was/is exceptionally stupid to call this middleware thing a resolver.
> Because it isn't one. That unfortunate choice of terminology creates
> needless confusion with DNS resolution. Sigh.
>
> This so-called "resolver" is actually a NAPTR record processor/filter that
> sits *above* some DNS API but *below* the application. This bit of
> middleware does not get involved in DNS resolution, apart from maybe making
> more NAPTR lookups if it has to go chasing a chain of NTNs. It does not
> disrupt or interfere with the usual DNS model of stub resolvers talking to
> resolving (cacheing) name servers talking to authoritative name servers.
>
Now I see my mistake.
Jim, thank you for patience and explanation.


-- 
--
AP