Hi Brian, On Mon, 2021-01-25 at 10:28 -0800, Brian Dickson wrote: > > > > However, there's one part that bothers me. The 'intermingling' of multiple > > XFRs over a single connection (which is a SHOULD, not a MUST, so the > > document 'gets away with it', or conversely, implementations will get away > > with not implementing it) feels to me like a lot of additional code > > complexity for a gain that is not clear to me. XFRs are not latency > > sensitive to the point that TLS setup is an impediment. > > I'm not one of the authors, but re-reading the draft with "intermingling" in > focus, I think the issues are: > - The intermingling aspect originates in RFC5936 (over TCP)
Several people have pointed that out to me - I totally missed that since forever. 5936 specified the intermingling in a very loose way, though. > - They want parity between TCP and XoT (which is reasonable) The document goes further than parity, by adding 'optimize the use of TCP connections and SHOULD ... edns-tcp-keepalive ... to manage persistent connections'. It also adds 'The number of TCP connections between a secondary and primary SHOULD be minimized (also see Section 6.4).' While I think reducing the number of connections is always good, this should be part of a good tradeoff in code complexity, and the risks of head of line blocking. (Of course, head of line blocking becomes much worse when the number of TCP connections is limited and intermingling does not happen. I do get where the document is coming from here.) > - Interoperability is assumed and not negotiated Indeed. > > In other words, I do not think the goal 'minimize the number of TCP > > connections between a primary and secondary' warrants the complexity of > > intermingling XFRs. I'd much rather have a few more TCP connections, a few > > more TLS states, and a much simpler code base. > > > > We (PowerDNS) do not think we will implement the parts of the draft that > > call for such code complexity, and thus, we will serialise XFRs (serial > > connection reuse does make sense to me) and/or in fact open multiple TLS > > connections (like we do with TCP today). At least in our code base, TLS > > setup would never be the bottleneck for transfers anyway. > > The relevant sections appear to be the text at the top of section 6.2, and > all of 6.3.2. > > Servers MUST be able to handle multiple XFR requests. > Clients MUST be able to handle intermingled responses. > However, Servers MAY intermingle, rather than must, on the responses. > > I concur with the code base complexity concern, particularly on the client > side. My worries are mostly split between the client and server side. > > I think this might be possible to accommodate with guidance (i.e. suggested > text to the following effect): > "NB: If clients do not want to support intermingled responses, a compliant > client could serialize requests to avoid multiple outstanding XFR requests. > If only one XFR is outstanding, no intermingling will ever occur." Indeed, the document allows this but it would be good to call out. > Similarly, server-side guidance could be added: > "NB: if servers do not want to implement intermingled responses, they can > serialize the full XFR responses to individual XFR requests, and this would > be compliant. Similarly, reordering of XFR responses versus XFR requests is > allowed but not required (in order to be compliant)." Indeed, that more clearly reduces the scope to 'servers do not close TCP connections after sending out a single XFR' (which is the most basic requirement currently specified in the document). > > Do any other vendors actually plan to implement such thorough connection > > reuse, with primaries actually intermingling multiple XFR responses over a > > single TCP/TLS session, and with secondaries actually firing off several > > XFR requests on a single connection to receive the zone chunks in whichever > > order they may come? > > It is not clear if our (internal) implementations will do so, or how > (intermingling out-of-order serialized-but-not-interleaved, versus fully > interleaving of multiple XFR responses). > > One possibility is the use of TLS proxies, which could multiplex multiple XFR > over TCP streams, such as from multiple TCP clients to multiple TCP servers, > across "shared" TLS XFR sessions (site to site). But that is conjecture only > at this point. Yes, but definitely possible. Such a proxy would need to be aware of DNS TCP framing, of course. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
