On 7/24/14, 6:58 AM, Viktor Dukhovni wrote:
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.
Definitions of "major" vary. In the HTTP world, something like SRV is
actively shunned because of the latency it introduces.
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.
This is true. Thus text like this might be better:
Developers of application clients that depend on DANE-SRV often would
like to prepare as quickly as possible for making a connection to the
intended service, thus reducing the wait time for end users. To make
this possible, a DNS library might perform the SRV queries and
address queries in parallel (because it is wrong to make TLSA queries
if the address records are not secure, performing them in parallel
with the SRV queries and address queries is not appropriate).
(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).
Yes, that usage makes my head hurt. However, that usage does not comply
with RFC 2782 (which says that the Target MUST NOT be an alias), which
is why we don't talk about it in the dane-srv specification.
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.
Pointing implementors (in a non-normative way) to the possible benefits
of lookup concurrency does not seem actively harmful to me.
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.
Right. As I said, I'd prefer to avoid this contentious topic in the
dane-srv specification.
Peter
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
