[Freeswitch-dev] mod_enum and ordering / prefference

[Lawrence Conroy]

Hi Jay, folks,
 Ahem -- the current ENUM spec is RFC6116. This obsoletes RFC3761, which in turn obsoleted RFC2716. I know this, 'cos I wrote it :). I strongly recommend you give 6116 a go, as we REALLY tried to make it useful and fix the bugs in the earlier specs.
As for the NAPTR spec, RFC2915 was obsoleted in RFC3403. That's within the set of specs RFC3401-RFC3405 (but I'd suggest care, as your head will bleed if you try to read them all, and they all cross-refer). For ENUM, RFC2915 is a false friend -- it looks OK, but is "historical only".

TL:DR; yup -- MUST be sorted on order/pref. Dealing with them "as they come" in the DNS response is a hangover from the original * client/hack -- it's wrong.

Longer: Strictly, should sort, then check the "best" one in the sorted list, see if that works, and then go on to the next if it doesn't (i.e., doesn't exists, is invalid, or your client app doesn't support the URI or it doesn't understand the enumservice tag within that NAPTR).

Note that the esteemed muppets in the SIP clique got the definition for the service field arse about face from the way it's used in ENUM, so beware of non-ENUM SIP NAPTRs (a la RFC3263) when developing a parser. They were told, and we still ended up with RFC3824 -- sigh.

Note that Non-terminal NAPTRs may mean that one chases "down" to another domain and looks there for NAPTRs, and Compound NAPTRs may mean that there are two choices in one record. Only place that uses either of them on the open Internet, as far as I'm aware, is domains within the .tel TLD. (What's used within Carriers' internal nets is another story, but you shouldn't see those, ever).

The specific bit in the ENUM spec that spells this out is in section 5.2 of RFC6116, which says:
"   ENUM clients MUST sort the records of a retrieved NAPTR RRSet into
   sequence using the ORDER and PREFERENCE fields of those records.  The
   ORDER is to be treated as the major sort term, with lowest numerical
   values being earlier in the sequence.  The PREFERENCE/PRIORITY field
   is to be treated as the minor sort term, with lowest numerical values
   being earlier in the sequence.
"

BTW, as regards what to do with NAPTs with identical ORDER/PREF fields, 5.2 also says:
"   ENUM clients SHOULD accept all NAPTRs with identical ORDER and
   identical PREFERENCE/PRIORITY field values, and process them in the
   sequence in which they appear in the DNS response.  (There is no
   benefit in further randomizing the order in which these are
   processed, as intervening DNS Servers might have done this already).
"
That's only a SHOULD, so knock yourself out with further randomisation if wanted -- it's not an error (but it is not really needed -- anyone publishing these must not care which is chosen).

all the best,
  Lawrence

On 13 Nov 2014, at 08:34, jay binks <jaybinks at gmail.com> wrote:
> so both http://tools.ietf.org/html/rfc2915 & http://tools.ietf.org/html/draft-daniel-naptr-00 
> say the the client MUST do the ordering.
> 
> Interesting to note is that http://tools.ietf.org/html/draft-daniel-naptr-00 talks about the client randomly selecting if order & pref are all the same.
> however the RFC does not explicitly mention this for NAPR.  ( which is a little unfortunate )
> 
> 
> 
> 
> 
> ---------- Forwarded message ----------
> From: jay binks <jaybinks at gmail.com>
> Date: 13 November 2014 17:40
> Subject: mod_enum and ordering / prefference
> To: freeswitch-dev at lists.freeswitch.org
> 
> 
> So im looking over mod_enum in relation to something Im trying to do ( will discuss later in the email ), and after looking through the code, it seems the mod_enum does not order the results at all, and it is assumed that ldns or the DNS server will order the results correctly.
> ldns_resolver_query is called, and parse_naptr is called for each result.
> parse_naptr parses the result row then calls add_result, which adds it to the array of enum_record.
> ( appears to always add it to the end )
> 
> Its not that this is failing for me, but this seems to be a little dangerous and I would have expected FS to interpret the order and preference values its self.
> 
> Can someone else take a look over this for me, and tell me if im wrong.  :)
> 
> In addition to this,   I was hoping to find a way to make FS randomly select a row if the order & preference are identical.   
> 
> Obviously this would need to be a config value because some people may NOT want this, but can anyone see any issues here ??   if the order / pref are identical your already going to run the risk of something jumbling the order around so you cant rely on the order of your zone file... having FS randomise this simple means that it will defiantly be random :)
> 
> just after some thoughts on this one...
> 
> 
> ( if you happen to decide to patch the above issue... then consider this also... otherwise ill attempt a patch for both depending on feedback )
> 
> -- 
> Sincerely
> 
> Jay
> 
> 
> 
> -- 
> Sincerely
> 
> Jay
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org