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

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

Hi Suresh -


Just following up on this.  The updated draft (-08) attempts to address your DISCUSS.  You can see the diffs here:

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 can be found here:

http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-du=
al-stack-08.txt<http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt>

Once you confirm your points are addressed we will publish the -08 version.

Thanks,

Gonzalo


On Aug 19, 2016, at 4:30 PM, Dale R. Worley <[e-mail]<mailto:[e-mail]>> wrote:

"Suresh Krishnan" <[e-mail]<mailto:[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.

* 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<http://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