[SR-Users] NAPTR priorities doesn't seem to work properly

Alex Hermann alex at speakup.nl
Thu Jun 9 20:26:02 CEST 2011


On Thursday 09 June 2011 12:44:11 Iñaki Baz Castillo wrote:
> 
> According to NAPTR:
> 
>   ~$ host -t naptr oversip.net
>   oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" ""
> _sips._tcp.oversip.net. oversip.net has NAPTR record 10 50 "S" "SIP+D2T"
> "" _sip._tcp.oversip.net. oversip.net has NAPTR record 20 50 "S" "SIP+D2U"
> "" _sip._udp.oversip.net. oversip.net has NAPTR record 40 50 "S" "SIP+D2S"
> "" _sip._sctp.oversip.net. oversip.net has NAPTR record 50 50 "S"
> "SIPS+D2S" "" _sips._sctp.oversip.net.
> 
> So it should try TLS over TCP first, if it fails try TCP and if it
> fails try UDP.
> 
> 
> However it just uses UDP, why??
> Even if I set a minor value to dns_tls_preference (so higher priority
> I expect) it still uses UDP.


The way I read rfc2915, there is no failover mechanism. The application pick 
the first target that it supports and uses that. There is no mention of trying 
other records afterwards. Matching/finding NAPTR records stops once the first 
match is completed. All other records are discarded. From  section 2:

   Order
      A 16-bit unsigned integer specifying the order in which the NAPTR
      records MUST be processed to ensure the correct ordering of
      rules.  Low numbers are processed before high numbers, and once a
      NAPTR is found whose rule "matches" the target, the client MUST
      NOT consider any NAPTRs with a higher value for order (except as
      noted below for the Flags field).

Note the last sentence.

-- 
Alex Hermann



More information about the sr-users mailing list