B.2 DNS procedures 3GPP clarifications on S-NAPTR

29.3033GPPDomain Name System ProceduresRelease 17Stage 3TS

IETF RFC 3958 [9] S-NAPTR procedures are unmodified with an exception of the following clarifications on the topological closeness and multi-protocol support:

1) For topological closeness the "topon" label matching of clause 4.3.2 of the present document takes precedence over NAPTR ordering but NAPTR ordering is still used when matching label lengths are equal. Therefore, a full list of "candidate" records is needed as sketched in Appendix A.2 of IETF RFC 3958 [9], which in turn requires "backtracking" as described by IETF RFC 3958 [9] clause 2.2.4. When collocation is to be considered applicable in a procedure it takes precedence in ordering over both "topon" and NAPTR ordering regardless of the value of the value of the "topon|topoff" label.

2) IETF RFC 3958 [9] has an ambiguity for S-NAPTR with multiple protocols in last paragraph of clause 2.2.5
"It MAY choose to run simultaneous DDDS resolutions for more than one protocol, in which case the requirements above apply for each protocol independently. That is, do not switch protocols mid- resolution."
The term " simultaneous DDDS resolutions" and "apply for each protocol independently" are not defined and can have different meanings. To resolve that ambiguity in S-NAPTR, the present document formally defines "Service description meeting the client requirement" from IETF RFC 3402 [14] clause 3.3 step 4 as a NAPTR record with one or more of the 3GPP desired service and protocol field pair(s) and such that all ancestor NAPTR records in the current path to this point also include the identified service and protocol in the DDDS procedure. The present document uses that as the definition of "simultaneous DDDS resolutions". See clause C.1 for more practical information on this point.

3) Strict ordering within S-NAPTR is obtained from the NAPTR order value as required in IETF RFC 3402 [14] and IETF RFC 3958 [8]. The value of (65535- NAPTR preference) shall be used as a statistical weight the same way the SRV weight is used on page 4 of IETF RFC 2782 [8] for SRV records.

Items 1) , 2) and 3) impact the ordering of DNS records in which they are returned by the S-NAPTR procedure. Items 1) and 2) also involve areas where the IETF RFC 3958 [9] only provides a sketch of the procedures needed and implicitly relies on IETF RFC 3402 [14] for details. To clarify these points as well as to guide implementations informative pseudo-code is provided in clauses C.1, C.2 and C.3. Item 3) allows an operators to load balance within one NAPTR record set without employing SRV records giving a simpler DNS provisioning and potentially reducing the number of DNS queries.