On 24 Jul 2014, at 14:58, Viktor Dukhovni <[email protected]> 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. > > 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. Or rewritten to make it olle-compatible ;-) > >> 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. +1 The reference to Happy Eyeballs, which is all about connection attempts, mislead me I guess. I think we may add "the handling of network connection attempts is not defined in this document". > >> 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. Then we need to clarify this again. Thanks for your response, Viktor! /O _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
