Subject: Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-xfr-over-tls

From: Peter van Dijk <[email-masked]>
Date: Thu, 04 Feb 2021 12:49:14 +0100

Hello Sara,

On Fri, 2021-01-29 at 17:34 +0000, Sara Dickinson wrote:
> To pick apart what exact changes would be needed to the document to support these 2 relaxations explicitly for XFRs, it would include:
> 
> CONNECTION RE-USE:
> * Adding a reason to section 6.3.1 for not re-using an existing connection something like: “as noted in RFC7766, separate connections for different zones might be preferred for operational reasons. In this case the number of concurrent connections for zone transfers SHOULD be limited to the total number of zones transferred between the client and server.”
> * If there is consensus the above is the right way to go, then since the main goal of limiting the connections is to reduce load on the server, I would also suggest adding some text to say “servers MAY limit the number of concurrent connections accepted from a given secondary”. One concern is that there is no easy way for the server to signal a preferred behaviour (for example if it has a very large number of zones and a very large number of secondaries it might really want to minimise connections), so I think this is the best that can be done? 
> 
> 
> PIPELINING:
> * Updates to sections 6, 6.1 and 6.2 and 6.3.2 to add an exception for XFRs wrt pipelining. For section 6, this would be something like:
> 
> “RFC7766 states that 'DNS clients SHOULD pipeline their queries’ on TCP connections, however it did not distinguish between XFRs and other queries for this behaviour. XFRs are not as latency sensitive as other queries, and can be significantly more complex for clients to handle both because of the large amount of state that must be kept and because there may be multiple messages in the responses. For these reasons this requirement is relaxed for XFR requests: clients sending XFRs MAY choose not to pipeline queries. Clients that do not pipeline XFR queries, therefore, have no additional requirements to handle out-of-order or intermingled responses as they will never receive them. "
> 
> Would that address your concerns? It would also be good to hear from other folks if they agree with this balance.

This works for us. Thank you very much!
 
Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/