On Thu, Jul 24, 2014 at 10:19:08AM +0200, Olle E. Johansson wrote:
> Section 3:
>
> I really like this here, but would like it to be expanded a bit to help
> implementors. The DNS SRV RFC is not easy to understand and in the IP
> world RFC 3263 has confused a lot of people. DNS SRV says that all
> candidates for a given priority should be attempted before one moves to
> the next priority. It doesn't say anything about order, which this document
> does when you say "SHOULD be performed in parallel".
Note, the text at the top of Section 3:
To expedite connection to the intended service, where possible the
queries described in the following sections SHOULD be performed in
parallel (this is similar to the "happy eyeballs" approach for IPv4
and IPv6 connections described in [RFC6555]).
is encouraging parallel *DNS lookup*, not parallel connection
attempts. And in fact parallel connection attempts would be wrong
unless all the weights are equal, and, as a blanket policy, questionable
even then.
> If one given priority have two hosts with two IPv4 and three IPv6 each -
> should all of them be tried in parallell?
The answer is NO, because the document does not suggest connection
concurrency, and because even that is I thing a mistake. When the
weights are unequal, the client is supposed to employ some sort of
RNG to choose candidate servers with a probability based on the
weights. If the client is correctly employing weighted selection,
parallel address lookup is generally inappropriate, in most cases
the first (randomly) chosen server will in fact be available and
lookups for other server addresses are I believe wasteful.
Thus parallel lookups are only useful when the first server does
not respond and further lookups are required to find more servers,
and could arguably have been performed in parallel with the first
lookup. However, after incurring a connection timeout with the
first server, additional DNS lookup latency for the second server
is not a major increment in the latency.
Also one needs TLSA lookups which should only follow the address
lookups because the TLSA lookup should not be made when the address
records are not secure. (Also when CNAMEs are supported on the
RHS of SRV records, the TLSA base domain is not known until the
original address record is CNAME expanded).
Bottom line I think the "parallel" language should be withdrawn.
> This is a big issue and may be too big an issue for this document to cover,
> especially with normative language.
This document definitely cannot specify anything about connection
concurrency. I would like to suggest strongly it also should *not*
specify lookup concurrency.
> According to the SIP domain cert RFC the CN should be disregarded
> and NOT used if there are any SANs. I don't know the
> reasoning behind this. Anyone? Should we do that here too or just forget it?
This is IIRC either from 5280, 6125 or both. DNS names in the
subject CN are deprecated, SANs are preferred, and trump the CN
when both (at least one SAN of type DNS and a CN in the subject
DN) are present.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
