2011/4/1 Jim Reid <jim@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