Re: [sipcore] Suresh Krishnan's Discuss on draft-ietf-sipcore-dns-dual-stack-07: (with DISCUSS)

["Olle E. Johansson" <[e-mail]>]

> On 19 Aug 2016, at 22:30, Dale R. Worley <[e-mail]> wrote:
> 
> "Suresh Krishnan" <[e-mail]> writes:
>> * Section 3.1
>> 
>> It is not clear to me what exactly the normative addendum is requiring
>> the client to do as regards to the DNS query while implementing "The
>> dual-stack client SHOULD look up all address records". Does this mean
>> that the client should do a AAAA (28) query followed by (or in parallel
>> or preceded ) for a A (1) query? I think it would be good to clarify the
>> types and ordering/concurrency of the queries.
> 
> Given that the responses to DNS queries do not depend on the order in
> which they are done, it seems to me that the only necessity is to
> specify that the client must do both A and AAAA queries.
> 
> In regard to the specific record types, one of our goals was that the
> wording should be robust to the possibility of additional address
> families being created.  Thus we used the wording
> 
>      The dual-stack client SHOULD look up all address records [...] for
>      all address family(ies) that it supports [...] for the domain name
>      and add the resulting addresses to the list of IP addresses to be
>      contacted.
> 
> Assuming that the client supports exactly IPv4 and IPv6, the queries to
> obtain address records for those families are A and AAAA.  I don't see
> that the text can be interpreted in a different way.
Note that RFC 2782 (DNS SRV records) use a similar approach:

"Note that where this document refers to "address records", it means A
   RR's, AAAA RR's, or their most modern equivalent.”

/O
> 
>> * Section 4
>> 
>> I am a bit puzzled by the merging of the address lists from two separate
>> DNS queries in relation to RFC6724. This is how I see the destination
>> address selection in RFC6724. The application ends up calling some kind
>> of name resolution API (something like getaddrinfo()) with a
>> hostname/FQDN (say sip-1.example.com) and this results in a set of
>> addresses being returned. The destination address selection algorithm
>> specified in Section 6 of RFC6724 then orders these addresses and picks
>> one. I am not seeing how the second FQDN and its associated set of
>> addresses become involved in the RFC6724 process. Is this something that
>> you are adding on top of RFC6724? Please clarify.
> 
> One way of looking at it is that the full process of resolving the
> server's address is the process for SRV records (RFC 2782) on top of the
> destination address selection process (RFC 6724).  You've identified
> that correctly.
> 
> The full process is fairly complicated, and the full documentation
> involves the interaction of RFC 3263, RFC 2782, and RFC 6724.  But
> restricting our attention to the case in question:
> 
> - The SRV records for domain name in the destination SIP URL are looked
>  up.  (RFC 3263)
> 
> - Depending on the priority and weight fields (and the randomization
>  implied by them!), the "target" domain names of the SRV records are
>  listed in a particular order.  (RFC 2782)
> 
> The case in question is when there are more than one SRV records for the
> destination domain name, and hence more than one target domain name.
> 
> - Each of those target domain names is expanded into a group of IPv4 and
>  IPv6 addresses by looking up the A and AAAA records for the name.  Each
>  group is sorted by the destination selection algorithm.  (This can be
>  accomplished by calling getaddrinfo() on the target domain name.)
>  (RFC 6724)
> 
> - The sorted groups of addresses for the target domain names are
>  concatenated in the order of the target domain names.
> 
> The crucial point here is that the destination selection reordering is
> only within the groups that result from the target domain names of the
> SRVs -- The whole algorithm is a two-field sort with the "major" sort
> being done by the SRV algorithm and the "minor" sort being done by
> destination selection.
> 
> The original RFC 3263 specification describes the first two steps, but
> presumes that the third step does not explicitly sort the addresses that
> are obtained for the target domain name.  As a general rule, people who
> have digested the rules of RFC 3263 agree that the "naturally correct"
> way to incorporate destination selection (now that it exists for IPv6)
> is to expand the third step to include that sortation -- and,
> critically, that destination selection cannot reorder two addresses
> between groups that derive from different target domain names.
> 
> The purpose of section 4 is to make that understanding normative.
> 
> Now, comparing what I have written here with the text in section 4, I
> see that section 4 does not make explicit the ordered list of target
> domain names from the SRV records.  And I can see that if the reader is
> not thoroughly familiar with RFC 3263, that makes the overall process
> significantly less clear, because it doesn't make step 2 above explicit.
> 
> I've updated the draft -08 to show the list of target domain names.
> You can see the difference in
> https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt
> and the entire current draft in
> http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.{txt,html}
> 
> Dale