Hello, list! I'm very new in enum and need some help in docs understanding. I can't understand following parts of rfc 3403: "Collision Avoidance: In the case where two Applications may use this Database (which is actually the case with the ENUM and URI Resolution Applications, Section 6.2), there is a chance of collision between rules where two NAPTR records appear in the same domain but they apply to more than one Application." And " * create a new zone within the domain in common that contains only NAPTR records that are appropriate for the application. E.g., all URI Resolution records would exist under urires.example.com and all ENUM records would be under enum.example.com. In the case where this is not possible due to lack of control over the upstream delegation the second method is used." Could someone provide me with examples of such collision and its resolution? Thanks in advance. -- -- AP
On 1 Apr 2011, at 11:10, Peter Andreev wrote:
Could someone provide me with examples of such collision and its resolution?
The answer is already in the text you quoted. There may be several NAPTR records for some domain name. RFC3403 calls this a collision. An application will do a lookup for that name, get a bunch of NAPTRs back and then have to make a decision about which ones are of interest. This can entail a bit of crunching on the DNS response: regexp rewriting, chasing non-terminal NAPTRs, order and preference handling, etc. This might be painful in some cases. In others, it's just an irritant. The DNS does not provide a way of saying "please only send me the mailto: NAPTRs for this name" or "send me all the D2U NAPTRs for this name, but no E2U (ENUM) ones". So if you want application-specific responses to NAPTR lookups, you need to organise the DNS data in that way and then give the applications a priori knowledge of how you've done that. eg Skype could be told to look for an E2U skype NAPTR for you at skype.peter.example.com instead of peter.example.com and you only put such a NAPTR at that node in the name space.
Jim, thank you for answer. 2011/4/1 Jim Reid <jim@rfc1035.com>:
On 1 Apr 2011, at 11:10, Peter Andreev wrote:
Could someone provide me with examples of such collision and its resolution?
The answer is already in the text you quoted.
There may be several NAPTR records for some domain name. RFC3403 calls this a collision. An application will do a lookup for that name, get a bunch of NAPTRs back and then have to make a decision about which ones are of interest. This can entail a bit of crunching on the DNS response: regexp rewriting, chasing non-terminal NAPTRs, order and preference handling, etc. This might be painful in some cases. In others, it's just an irritant.
The DNS does not provide a way of saying "please only send me the mailto: NAPTRs for this name" or "send me all the D2U NAPTRs for this name, but no E2U (ENUM) ones". So if you want application-specific responses to NAPTR lookups, you need to organise the DNS data in that way and then give the applications a priori knowledge of how you've done that. eg Skype could be told to look for an E2U skype NAPTR for you at skype.peter.example.com instead of peter.example.com and you only put such a NAPTR at that node in the name space.
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? -- -- AP
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. 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.
2011/4/1 Jim Reid <jim@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
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.
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
participants (2)
-
Jim Reid -
Peter Andreev