Re: [dns-privacy] I-D Action: draft-ietf-dprive-xfr-over-tls-02.txt

[Tony Finch <[e-mail]>]

Sara Dickinson <[e-mail]> wrote:
>
> Hi Tony,
>
> Many thanks for the detailed review!

You're welcome! Your changes sound good, so I'll just answer a few
quesions...

> > Is there a reason for allowing concurrent AXFRs of the same zone?
> > Actually, thinking about this more generally, I can't see a way in RFC
> > 5936 for the server to impose backpressure to limit the number of
> > concurrent AXFRs. And there isn't an extended error code for concurrency
> > control or backpressure. If the server had a suitable response, that would
> > allow it to control xfer resources in general, as well as to choose
> > whether or not it wants to allow multiple AXFRs for the same zone at the
> > same time.
>
> I don’t believe RFC5936 says anything expliclty about concurrent
> transfer behaviour, and while there may not be a use case for it do you
> think we should actually prohibit it?
>
> Of course a server can error any AXFR if it chooses [RFC5936]:
>
> "To indicate an error in an AXFR response, the AXFR server sends a
>    single DNS message when the error condition is detected, with the
>    response code set to the appropriate value for the condition
>    encountered.  Such a message terminates the AXFR session;…”
>
> so it _could_ already answer SERVFAIL if it didn’t have the resources?,
> or REFUSED if a transfer is already underway and it doesn’t want to do
> another one? I’m not actually sure what existing implementations do in
> this case? (will double check)
>
> I suppose the advantage of adding an extended error code would be so
> that well behaved clients didn’t continue to request transfers that were
> going to be refused.

BIND at least has had quotas for controlling zone transfer concurrency for
aaages, so the answer to this question is out there. I was thinking out
loud a bit when I wrote that paragraph, mainly because I was surprised the
specs did not AFAICT describe a fairly well-known xfer feature.

> > Re pipelining, I can't see in RFC 5936 whether concurrent AXFRs are just
> > concurrent outstanding queries, with all the response messages for one
> > zone sent back-to-back, or whether response messages for different
> > concurrent AXFRs can be interleaved.
>
> No, you are right - that behaviour isn’t explicitly specified there but
> the discussion around using message IDs to match responses at the end of
> section 4.1.1. suggests/implies intermingling should work. Our draft
> doesn’t update RFC5936 at all (at the moment)… I hadn’t thought it
> necessary but perhaps we should actually make the normative statements
> around the updates to RFC1995 apply to RFC5936 as well for consistency?

I thought when reading the draft that it might be a bit clearer if there
were sections on stuff applying to xfers in general (connection
management, concurrency, etc.) and particular details for axfr and for
ixfr.

This spec probably does need to update RFC 5936 because 5936 doesn't say
anything about IXFR even though there are important details in how IXFR
and AXFR interact.

> Are you thinking of some text clarifying that servers can send AXoT
> responses for different zones intermingled with each other and with IXoT
> responses and clients have to handle them? I guess I thought that was
> implicit in the RFC7766 model but we could add some clarifying text.
> Again though, that would (I think) apply equally for AXFR and IXFR
> sharing a connection so perhaps it needs to appear earlier when they are
> discussed…. Do you have any error/problem cases in mind, or just
> clarifying what needs to be supported?

Yes, I was just unsure what degree of intermingling is supposed to be
allowed; I don't know enough about this part of the innards of existing
implementations to say what the right clarification is, though :-)

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
disperse power, foster diversity, and nurture creativity