Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03.txt

Alfred Hoenes wrote:
> Before entering into the details of later Sections,
> I think we should establish a solid base.
> 
> So to start with there, my questions are:
> 
> Is the high-level description given in Section 2 ...
> a)  logically correct (from your point of view) ?
> b)  consistent with the terse text in RFC 1995 ?
> c)  consistent observed on-the-wire format, and hence with
>     implementations ?

There are some issues with section 2 also, such as defining the
condition of a client being up-to-date as sn_o = sn_n, when it should
be sn_o >= sn_n (in the RFC 1982 sense).  But apart from that, I think
it is sufficiently correct to be used as a basis for the present
discussion regarding the significance of message boundaries in
classifying responses.

> But if that's correct, we have the problem that the established
> response syntax unfortunately does not allow precise parsing
> without knowledge of where the end of the response is.

It has been a long time since I last implemented IXFR, but I think
the following procedure should work:

   If the response is over UDP, and the first RR in the response is a
   SOA whose serial is greater than the client serial, and the
   response contains no further RRs, then we have case (b) of the
   draft, "response too large for UDP".  This is the only place where
   we must determine whether or not an RR is followed by further RRs,
   and although that is not possible in the TCP case (without making
   message boundaries significant, or by resorting to timeouts or
   such), it is possible in the UDP case because UDP responses can
   only consist of a single message.

   Otherwise, examine the first RR in the response, which must be a
   SOA.  If its serial is less than or equal to the client serial, we
   have case (a), "up to date".

   Otherwise, examine the second RR in the response.  If it is not a
   SOA, we have case (d), "fallback to AXFR".

   Otherwise, we have a response beginning with two SOA RRs, which is
   case (c), with sub-cases as discussed in the draft.

Some of the sub-cases of (c) may need further discussion, but let's
first see if we can come to an agreement regarding the overall
algorithm for classifying responses into the four classes (a)
through (d) in the draft.
-- 
Andreas Gustafsson, gson@araneus.fi
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext