On Wed, 25 Nov 2015 09:23:50 +1100, Mark Andrews wrote: > > >In message <17673.1448400...@dash.isi.edu>, John Heidemann writes: >> On Mon, 23 Nov 2015 20:25:29 +0000, "Wessels, Duane" wrote: >> > >> >> On Nov 23, 2015, at 11:58 AM, Mukund Sivaraman <m...@isc.org> wrote: >> >> >> >> Hi Jinmei >> >> >> >> On Mon, Nov 23, 2015 at 10:31:23AM -0800, $B?@L@C#:H(B wrote: >> >>> At Mon, 23 Nov 2015 21:37:48 +0530, >> >>> Mukund Sivaraman <m...@isc.org> wrote: >> >>> >> >>>> While looking at a bug last week in an implementation of 5966bis and >> >>>> AXFR, I found that there's no explicit mention of AXFR and out-of-order >> >>>> replies. AXFR replies [RFC 5936] can arrive in several messages over >> >>>> TCP. While 5966bis speaks only about re-ordering replies and not >> >>>> individiual messages (and so, is not incorrect), I feel that explicitly >> >>>> describing ordering in the AXFR case would avoid confusion. >> >>>> >> >>>> It seems that AXFR messages would have to be sent in order to avoid >> >>>> confusion at the client about when a transfer correctly completed >> >>>> vs. when it timed out. While they can be multiplexed with other DNS >> >>>> messages, the individual messages of a single transfer must not be sent >> >>>> out of order. >> >>> >> >>> I'm not sure if I understand the concern...do you mean, for example, >> >>> if an AXFR consists of the following 3 messages: >> >>> >> >>> Message1: beginning SOA and some RRs >> >>> Message2: some intermediate RRs >> >>> Message3: some more intermediate RRs >> >>> Message4: some more RRs and ending SOA >> >>> >> >>> the client side of AXFR receives them in the order of, e.g., Message2, >> >>> Message3, Message4, and then Message1? That is, Message1 is not >> >>> necessarily sent/received first and/or Message4 is not necessarily >> >>> sent/received last? >> >> >> >> Yes. Without them being in order, it doesn't seem the client can >> >> determine upon timeout if all messages corresponding to the transfer >> >> have been received, or if the transfer is incomplete. >> >> >> >> Example: >> >> >> >> (1) Message1, Message4, Message2, Message3 received. >> >> Timeout complete and TCP still connected. >> >> >> >> (2) Message1, Message4, Message2 received. [Message3] not received when >> >> timeout complete and TCP still connected. >> >> >> >> How can client know that in (2), the whole transfer was not received? >> > >> > >> >TCP preserves the order of delivery, so if the messages are received in >> >the order above, it is an AXFR/IXFR protocol violation by the server. The >> >server must send Message4 last. >> >> Perhaps some of the confusion here has to do with overloading the term >> "message". >> >> There are DNS query and response messages and TCP segments. >> >> A DNS message is a query and response (as per RFC1034 and >> draft-hoffman-dns-terminology-02). > >A query is a DNS message. A response is one or more DNS messages. > >> For AXFRs, the DNS message maybe large enough that it is split into >> multiple TCP segments (each a separate packet). > >For AXFR/IXFR over TCP if the response is large enough or the server >has been configured to send one record per message it will be split >into multiple messages each proceeded by its length. That sequence >of messages is split into multiple TCP segments. That sequence of >messages and lengths may be interleaved with other responses to >other requests over the same TCP connection with each <length,message> >pair treated as a atomic unit on the TCP connection. > >A TCP segment boundaries and message boundaries are not required >to be aligned. The contents of two messages may appear in one >segment. > >The sequence of DNS messages that make up a AXFR / IXFR response >are orders as per the requirements of AXFR and IXFR. > >> The statement: "an AXFR consists of the following 3 messages: Message1: >> beginning SOA and some RRs, Message2: some intermediate RRs, Message3: >> some more intermediate RRs..." I think conflates these concepts (it >> uses the term "message" incorrectly). The AXFR reply does NOT consist >> of 3 DNS messages, it is ONE DNS message that is split into 3 or more >> TCP segments. > >No. It consists of a sequence (one or more) messages.
Of course you're correct---with large zones the reply would easily exceed the 16-bit DNS message length. Sorry, it was I who misunderstood the original post. Apologies to Mukund and Duane. (You know, clearly what this thing needs is some additional form of message fragementation and reassembly :-) -John Heidemann _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
