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/ _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
