Subject: RFC1995 implementor feedback

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 18 Nov 1999 10:57:56 -0800 (PST)

Based on discussions at the Washington DC DNSIND meeting, and having
recently implemented the IXFR protocol in BIND 9, I would like to
submit the following implementor feedback regarding RFC1995 to the
author and the DNSIND working group.

I have found the IXFR protocol to be workable, and I do not wish to
make any changes to the protocol itself.  I consider it far superior
to the DUXFR proposal.

However, in my opinion the protocol specification in RFC1995 is not
sufficiently detailed.  Many aspects of the protocol are not stated
directly but must be deduced, or must be known to the implementor a
priori (e.g., in the form of undocumented existing AXFR practice).
Therefore, I would like to add a substantial amount of clarifying text
to the RFC.  I would also like to make some minor editorial changes to
the existing text.

Proposed changes to RFC1995
===========================

In section 2, in the paragraph

   If an IXFR query with the same or newer version number than that of
   the server is received, it is replied to with a single SOA record of
   the server's current version, just as in AXFR.

the text ", just as in AXFR" should be removed as AXFR does not in 
reality behave the way the text says.

In section 4, in the paragraph

   RRs in the incremental transfer messages may be partial.  That is, if
   a single RR of multiple RRs of the same RR type changes, only the
   changed RR is transferred.

the initial "RRs" should be replaced with "RR sets"

Proposed additions to RFC1995
=============================

The following clarifying text should be added between sections 
7 and 8, renumbering subsequent sections as needed:

8. Clarifications

8.1. General notes about zone transfers

The IXFR protocol is based on AXFR, defined in RFC1034.  The AXFR
specification is very terse, and in practice it does not contain
sufficient information to construct interoperable implementations.
This section attempts to clarify the AXFR specification based on
existing practice.  Unless otherwise noted, all requirements stated in
this section apply equally to all zone transfers, both AXFR and IXFR.

8.1.1. Messages and answers

A zone transfer response is a stream of answer RRs transmitted in the
answer section(s) of one or more DNS response messages.

The language in RFC1034 does not make a clear distinction between
response messages and answer RRs - historically, DNS servers always
transmitted a single RR per message.  This is wasteful due to the
overhead of repeatedly sending DNS message headers and the loss of
domain name compression opportunities.  To improve efficiency, some
newer servers support a mode where multiple RRs are transmitted in a
single DNS response message.

A master MAY transmit multiple answer RRs per response message up to
the largest number that will fit within the 65535 byte limit on TCP
DNS message size.  For small transfers, this can cause the entire
transfer to be transmitted in a single response message, as in the
example drawings in section 7.

For compatibility with old slaves, masters that support multiple
answers per message SHOULD be configurable to revert to the historical
mode of one answer per message, and the configuration SHOULD be
settable on a slave-by-slave basis.

8.1.2 DNS message header contents

RFC1034 does not specify the contents of the DNS message header of
the zone transfer response messages.  The header SHOULD be set as
follows:

    ID      Copy from request
    QR      1
    OPCODE  QUERY
    AA      1 (except in error responses indicating nonauthority)
    TC      0
    RD      Copy from request
    RA      Set according to availability of recursion
    Z       000

The TC bit is 0 even if the message is an UDP IXFR response indicating
that the transfer is too large for UDP.

Since many existing servers do not adhere to these guidelines, slave
servers SHOULD ignore the values of all the above fields.

    RCODE   0 or error code

The slave MUST check the RCODE for error returns.  

8.1.3. Additional section and SIG processing

Zone transfer responses are not subject to any kind of additional
section processing or automatic inclusion of SIG records.  SIG RRs are
treated just like any other RR type.

8.1.4. The question section

RFC1034 does not say whether zone transfer response messages have a
question section or not.  The initial message of a zone transfer
response SHOULD have a question section identical to that in the
request.  Subsequent messages SHOULD NOT have a question section,
though the final message MAY.  The receiving server MUST NOT depend on
the existence or nonexistence of a question section in any part of the
response.

8.1.5. The authority section

The master server MUST transmit messages with an empty authority
section.  Slaves MUST ignore any authority section contents they
may receive from noncompliant masters. 

8.1.6. The additional section

The additional section MAY contain TSIGs and other additional RRs.
Unexpected RRs in the additional section MUST be ignored by the slave.

8.1.7. Glue

Zone transfers MAY contain glue RRs pertaining to NS records in the
zone.  The owner names of such glue RRs either are not subdomains of
the zone apex, or are below delegation points within the zone.  The
slave MUST recognize glue RRs as such; it MUST NOT treat them as
authoritative data.

8.2. AXFR protocol clarifications

8.2.1. Transmission order

RFC1034 states that "The first and last messages must contain the data
for the top authoritative node of the zone".  To accurately reflect
existing practice, this text should read "The first and last RR
transmitted must be the SOA record of the zone".  The top
authoritative node typically has not only an SOA record but also NS
records, and possibly others.  Transmitting these non-SOA records
twice makes no sense and no known implementation does that.

The initial and final SOA record MUST be identical, with the possible
exception of case and compression.  In particular, they MUST have the
same serial number.

The transmission order of all other RRs in the zone, including glue
records, is undefined.

8.3. IXFR protocol clarifications

8.3.1. Identifying an incremental response

To determine whether an IXFR response received over TCP is incremental
or not, it is necessary to receive the first two answer RRs in the
answer stream (which may or may not involve receiving two TCP DNS
messages).  The first RR is always an SOA.  If the second RR is an SOA
with a serial number different from the first SOA, the response is
incremental, in IXFR format.  If it is a non-SOA RR or a SOA RR with
the same serial number as the initial SOA RR, it is a nonincremental
response in AXFR format.  The last case can arise with a degenerate
zone containing only the SOA record.

This is the only way to identify an incremental response.  A slave
cannot reliably identify an incremental response based on the presence
or absence of a question section, the QTYPE field of a possible
question section, or the number of response RRs per message,

8.3.2 Finding the end of an IXFR response

When receiving an IXFR response over UDP, the end of the response is
indicated by the end of the UDP datagram. 

When receiving a response over TCP, the receiving server must
determine the end of the response by examining the IXFR or AXFR data
received.  It MUST NOT rely on the transmitting server closing the TCP
connection at the end of the transfer.

If the initial SOA has a serial number equal to or less than that of
the request, the response is an indication of up-to-date status and
ends immediately after the initial SOA.

Otherwise, the response is classified as non-incremental or
incremental.  A non-incremental response ends when a second copy of
the initial SOA RR has been received.  An incremental response ends
with a SOA that has the same serial number as the initial SOA and
occurs in a position where a new difference sequence would otherwise
begin (i.e., in place of the "deleted SOA").

8.3.3 Serial numbers

Each difference sequence transmitted MUST cause the SOA serial number
to increase.  Therefore, an IXFR server cannot defer serial number
updates unless it always condenses difference sequences in such a way
that each condensed sequence contains at least one serial number
update.

A set of difference sequences MUST NOT be condensed if the sum of the
serial number changes in the individual sequences is 2^31 or more.

If a server keeps history entries old enough that the serial number
increments performed since an entry was made total 2^31 or more,
such entries MUST NOT be used in answering IXFR queries.

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Nov 1999 14:45:35 +1100

Date:        Thu, 18 Nov 1999 10:57:56 -0800 (PST)
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | In section 4, in the paragraph
  | 
  |    RRs in the incremental transfer messages may be partial.  That is, if
  |    a single RR of multiple RRs of the same RR type changes, only the
  |    changed RR is transferred.
  | 
  | the initial "RRs" should be replaced with "RR sets"

I don't think that would improve anything.   The paragraph could be
rewritten to use "an RR set" in place of "multiple RRs of the same RR type"
(which is what an RRset is - though I don't think "RR set" was in common
use when 1995 was being written, so it is not surprising that it was not
used).

But ending with "multiple RR sets of the same RR type" would be a nonsense,
there can't be multiple RR sets of the same RR type.

  | 8.1.7. Glue
  | 
  | Zone transfers MAY contain glue RRs pertaining to NS records in the
  | zone.  The owner names of such glue RRs either are not subdomains of
  | the zone apex, or are below delegation points within the zone.  The
  | slave MUST recognize glue RRs as such; it MUST NOT treat them as
  | authoritative data.

The second sentence there would be better written as ...

	The owner names of such glue RRs are not within the zone being
	transferred.

If you're assuming that someone is implementing AXFR or IXFR, then you
had better assume that they know what a zone is (precisely), or a
definition for it needs to be given (or referred to).  Once you assume
that, be best thing to do afterwards is to make use of that definition,
not word around it.

  | 8.3.1. Identifying an incremental response
  | 
  | To determine whether an IXFR response received over TCP is incremental
  | or not, it is necessary to receive the first two answer RRs in the
  | answer stream [ ... ]

  | 8.3.2 Finding the end of an IXFR response

  [...]
  | When receiving a response over TCP,  [...]

  | If the initial SOA has a serial number equal to or less than that of
  | the request, the response is an indication of up-to-date status and
  | ends immediately after the initial SOA.

Those two are not consistent (as written, I know what the intent is).
Your 8.3.1 says that you cannot have an IXFR without at least 2 RRs in
the response.   But then this part of your 8.3.2 allows just a single RR
in an IXFR response.   The broken part is 8.3.1 I think, or perhaps it is
just a terminology oddity - an full AXFR must always contain at least 2 RRs,
so anything with only one RR cannot be a zone transfer - but it can be a
"you are already up to date" reply, which then is neither an IXFR or AXFR
response really...  (it is no transfer at all).

  | 8.3.3 Serial numbers
  | 
  | Each difference sequence transmitted MUST cause the SOA serial number
  | to increase.  Therefore, an IXFR server cannot defer serial number
  | updates unless it always condenses difference sequences in such a way
  | that each condensed sequence contains at least one serial number
  | update.

That part is fine.

But this ...

  | A set of difference sequences MUST NOT be condensed if the sum of the
  | serial number changes in the individual sequences is 2^31 or more.
  | 
  | If a server keeps history entries old enough that the serial number
  | increments performed since an entry was made total 2^31 or more,
  | such entries MUST NOT be used in answering IXFR queries.

stretches credibility a little.   Not because I believe that there
can never be a secondary server which has gone so long between zone
updates that the primary server has increased the serial number that
much, but because once that has happened, there will no longer be
(can no longer be) any kind of zone transfer (and certainly not an
incremental one).   Discussions of how to format a reply to such a
thing make no sense at all.

In this situation the secondary has a serial number which is greater
than that of the primary.   The primary sends back a single SOA record
indicating "this is the most recent I have, and it isn't newer than yours"
and that's the end of the reply.

kre

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 19 Nov 1999 09:43:21 -0800 (PST)

> there can't be multiple RR sets of the same RR type.

I never said that - my intent was to change only the first word of the
first sentence from "RRs" to "RR sets", since there clearly isn't such
a thing as a partial RR.  I don't think it is absolutely necessary to
change the second sentence, but I agree that if you do, replacing
"multiple RRs of the same RR type" with "an RR set" would be an
improvement.  To summarize:

    RR sets in the incremental transfer messages may be partial.  That is, 
    if a single RR of an RR set changes, only the changed RR is transferred.

> 	The owner names of such glue RRs are not within the zone being

I agree, your wording is much better.

> Those two are not consistent (as written, I know what the intent is).

Duly noted.  I will try to resolve this, but since it will probably
require extensive changes to 8.3.1 and/or 8.3.2 I will not try to do
it here.

> thing make no sense at all.

What you say makes sense with respect to the first quoted paragraph.
I'll remove it.

However, the second quoted paragraph attempts to deal with a different
issue, one that can arise even when all slaves stay closely in sync
with their masters.

Here's an example.  Suppose the primary master M goes through the
following sequence of serial numbers:

  1000000000
  2000000000
  3000000000 (a)
  4000000000
  1000000000
  2000000000
  3000000000 (b)
  4000000000 (c)

This history contains several entries with identical sequence numbers.
When M receives an IXFR request with serial 3000000000, it may send
the differences from (b) to (c) or it may send an AXFR-style response,
but it MUST NOT send the differences from (a) to (c).  Perhaps this is
so obvious it does not need to be stated, but the next example may 
be a bit less obvious:

A slave server S gets its zone data by IXFR from master M, and version
(b) happens to get condensed away.  Thus, S has the following history:

  1000000000
  2000000000
  3000000000 (a)
  4000000000
  1000000000
  2000000000
  4000000000 (c)

When S receives an IXFR request with serial 3000000000, it MUST send
an AXFR-style response.  It MUST NOT respond with the differences from
(a) to (c) even though the serial number 3000000000 appears exactly
once in the history.

I once heard a DNS implementor propose a history data structure that
would have failed to handle this last case correctly, hence my desire
to state an explicit requirement.
-- 
Andreas Gustafsson, [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Sat, 20 Nov 1999 12:50:04 +1100

Date:        Fri, 19 Nov 1999 09:43:21 -0800 (PST)
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | I never said that - my intent was to change only the first word of the
  | first sentence from "RRs" to "RR sets", 

Oh sorry - I missed that one.  Yes, that does make sense.

  | Perhaps this is
  | so obvious it does not need to be stated, but the next example may 
  | be a bit less obvious:

Hmm - yes, perhaps I just always assumed that no-one could be so insane
to even consider that as a possibility.

So, yes, OK, I guess that other paragraph could stay, though I think I
would avoid references to 2^31, and just use "less" "greater", etc.

When I think about all of this in general, I suspect there are some
pathalogical cases with a secondary server fetching from multiple other
servers (which is necessary for yoru 2nd example) with wildly
differing serial numbers (S fetching from a primary server P which is
incrementing the serial number very rapildy, then fail to contact that
and fall back to fetching from a secondary Q which has not been keeping up
and has a much older serial number than either P, or S.   Then Q might
just see the request as an attempt to update from the previous time
that S's serial number was active.

However I'm not about to worry about that, there is nothing particular
about IXFR here (old style AXFR transfers have a similar failure mode
possible).

kre

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 21 Nov 99 0:29:22 JST

Andreas;

> Proposed changes to RFC1995

OK. Seems to be my mistake that the intension was "just as SOA query
before TCP AXFR".

> the initial "RRs" should be replaced with "RR sets"

OK.

   RR sets in the incremental transfer messages may be partial.

> Proposed additions to RFC1995

They (save 8.3.1) are clarifications on RFC103[45], not RFC1995,
that they should better constitute a separate document, I think.

Or, are there any implementor who need IXFR, but not corresponding AXFR,
clarification?

> question section, or the number of response RRs per message,

Logically unnecessaly but not a bad clarification.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 20 Nov 99 23:32:29 JST

Kre;

> about IXFR here (old style AXFR transfers have a similar failure mode

Yup. I carefully avoided to overspecify IXFR that implementors
who can implement AXFR with RFC103[45] can implement IXFR.

Clarifications of AXFR should be solved in RFC103[45] clarification
documents.

Shouldn't it be specified as the clarification document that serial
number should not wrap around (or not half wrap around) until
all of the previous versions expiration periods pass?

							Masataka Ohta

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 22 Nov 1999 10:51:35 -0800 (PST)

> They (save 8.3.1) are clarifications on RFC103[45], not RFC1995,

8.1 and 8.2 are clarifications on RFC103[45].  All of 8.3 (not just
8.3.1) pertains to RFC1995.

> that they should better constitute a separate document, I think.

It does not make much of a difference to me whether the AXFR
clarifications are included in a successor to RFC1995 or published as
a separate document.  Both approaches have been used in the past when
clarifying other aspects of RFC103[45].  If you don't want to include
them in 1995bis, I can certainly publish them as a separate AXFR
clarification I-D.
-- 
Andreas Gustafsson, [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 23 Nov 99 9:37:53 JST

Andreas;

> 8.3.1) pertains to RFC1995.

Suppose someone implement AXFR.

Then, which part of 8.3, do you think, is necessary for the person
to add IXFR to the implementation?

First two paragraphs of 8.3.2 is applicable to AXFR.

The next paragraph conflicts with the requirement of second paragraph.

8.3.3 describes an IXFR aspect of operational problem of too quick serial
number updates. But, there are similar problem with AXFR as Kre pointed
it out, and too quick update should be banned. But, it is an topic of
BCP not standard track RFC.

						Masataka Ohta

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 23 Nov 1999 09:57:19 -0800 (PST)

> to add IXFR to the implementation?

No part of 8.3 may be strictly necessary, since some people have
demonstrably succeeded in producing interoperable implementations
without it.  However, others have failed, and I think all of 8.3 is
useful in the sense that it will help increase the probability that
future implementations interoperate.

> First two paragraphs of 8.3.2 is applicable to AXFR.

To recap, here are those first two paragraphs:

The intent of these two paragraphs is to highlight the fact that the
slave needs to use *different* methods to find the end of an IXFR
response depending on whether the response is a UDP or a TCP one.
This issue never arises in AXFR because it operates only over TCP.

I don't see the conflict, please explain.  Did you perhaps interpret
"the response ... ends" as saying that the TCP connection is closed?
That is not what I meant - I meant that the slave must not wait for
more response messages in this case, because there will not be any.

> BCP not standard track RFC.

I agree that the operational issues surrounding rapid serial number
wraparound belong elsewhere, but this is not what most of 8.3.3. is
about.  8.3.3 consists of three paragraphs, each about a different
issue:

I added the above paragraph because one implementation I tested
actually sent IXFR difference where the "old SOA" and "new SOA" serial
number were the same due to serial number update deferral, and this
caused it not to interoperate with another implementation that
expected them to be different.

As Robert Elz pointed out, this paragraph applies only in a scenario
where the operational requirements on serial number updates have been
violated.  I already agreed to remove it.

I already explained the reason for this requirement in my recent reply
to Robert Elz.
-- 
Andreas Gustafsson, [email-masked]

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 23 Nov 1999 19:13:54 -0500

I have comments on Andreas' proposed additions to RFC1995.

[...] 
> servers SHOULD ignore the values of all the above fields.

I think this is a bit too loose.  If processing a UDP IXFR response, these
fields need all be valid, as in any UDP Query response.  For a TCP IXFR or
AXFR response, I think there should be at least a correct ID in the first
message header.

> The slave MUST check the RCODE for error returns.

I think we should make it clear that the RCODE is significant only in the
initial response message, and not in subsequent response messages which are
part of a TCP IXFR/AXFR.  At least, that's the way I believe its typically
implemented.

> the existence or nonexistence of a question section in any part of the

I think it may be necessary to indicate that if a question section is
included, it should match the initial query.  I've seen implementations
returning a question section with type=AXFR in response to query of
type=IXFR.

> that each condensed sequence contains at least one serial number

I understand from Andreas' later mail that this second sentence is aimed at
preventing a specific behavior he saw in an implementation.  However, I
didn't interpret "defer serial number updates" in exactly that way, so it
made no sense to me.  My implementation of UPDATE defers serial number
updates in that mulitple UPDATE packets will be combined in one serial
update, so I was concerned about this statement.  Of course, it sends the
result of all these updates as one IXFR change-set.  Maybe the above
paragraph could say:

  Each difference sequence transmitted MUST cause the SOA serial number
  to increase.  An IXFR server which defers serial number updates across
  multiple zone changes must conbine these changes into one difference
  sequence.

I think that says the same thing, but just differently.

-- 
========================================================================
Josh Littlefield                                     Cisco Systems, Inc.
[email-masked]                                         250 Apollo Drive
tel: 978-244-8378  fax: 978-244-8378          Chelmsford, MA  01824-3627

---

From: [email-masked]
Date: Wed, 24 Nov 1999 16:09:00 +1100

> AXFR response, I think there should be at least a correct ID in the first

	The ID should match for all responses.  With that it is possible
	to multiplex multiple AXFR, IXFR and general query responses down
	the one TCP connection.  Demultiplexing in ID.

	If we are going to make clarifications we don't need to be wishy
	washy about things like ID and RCODE.  The ID for all messages
	in a IXFR / AXFR stream MUST be the same and MUST match the
	corresponding query.

	Similarly RCODE MUST be consistant across messages in the stream.
	Note it is impossible to get a stream of answers where the rcode
	should not be NOERROR.

	Mark

--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Nov 99 14:24:35 JST

Andreas;

> No part of 8.3 may be strictly necessary, since some people have

That's not a point.

> future implementations interoperate.

Rephrasing my question:

	how many of those failed have successfully implemented AXFR?

> This issue never arises in AXFR because it operates only over TCP.

You are a little confused.

Over TCP, multiple queries, including but not limited to XFR, may be sent.
That is, the end of TCP AXFR must be detected syntactically and other
non-XFR queries may follow end of which may be detected by a *different*
method.

It's a complication that XFR use multiple messages.

> more response messages in this case, because there will not be any.

Oops, my confusion that I thought you said "greater than".

> expected them to be different.

Huh? "Serial number update deferral"? How can it be possible?

IXFR clients are not the primary.

"Serial number update deferral" is a strange feature of DDNS which
operate only on the primary.

RFC 2136 says:

	Visible (to DNS clients) SOA SERIALs need
	to differ if the zone differs. 

The primary is allowed to deffer incrementing SOA only if the deferral
is not visible from outside.

Clients always receive differences with SOA serial incremented.

If any clarificaiton are ever necessary, it should be on DDNS and my
suggestion is to remove the deferral feature.

OK.

> I already explained the reason for this requirement in my recent reply

For the server to try to send such a zone, the client's current serial
must be 2^31 or more smaller than the server, which makes the server
and the client consider that the client have newer copy than the
server's that there will be no transfer.

Note also that the client's copy of the zone had already expired, if
the operational requirement had satisfied.

							Masataka Ohta

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 24 Nov 1999 12:29:12 -0500

>them in 1995bis, I can certainly publish them as a separate AXFR

Andreas, 
you are now tasked with writing the long over due formal specification 
for AXFR. I expect a draft soon. 

Masataka
I think we are getting close can you submit RFC1995bis draft based on
current input and what ever feedback you have got so far. 
 
I would like to advance both of these documents before March !

	Olafur (speaking as a WG co-chair).

--------
Olafur Gudmundsson - NAI Labs 			(443)-259-2389 
The Security Research Division of Network Associates, Inc.
[email-masked]  [email-masked]  Private: [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 27 Nov 1999 19:35:05 -0800 (PST)

> 	how many of those failed have successfully implemented AXFR?

As far as I know, they all have interoperating AXFR implementations.

> non-XFR queries may follow end of which may be detected by a *different*

I know this.  I may have been a little confused, but not over the TCP
case but the UDP one.  Here is what RFC1995 says about UDP:

   If an IXFR query
   is via UDP, the IXFR server may attempt to reply using UDP if the
   entire response can be contained in a single DNS packet. 

I was interpreting the words "single DNS packet" as "single UDP packet
containing DNS protocol data", not as "single DNS message".  That is,
if a master were to construct a multiple-DNS-message response and this
"entire response" happened to fit in a UDP packet, it would be allowed
to transmit it over UDP.

Under this interpretation, the receiver can only determine the end of
the UDP response using out-of-band UDP datagram size information from
the protocol stack, because a message with a single SOA RR at the
beginning of the datagram may either be the complete indication that
the response did not fit, or it may followed by other messages.

I now see that you probably intended a different interpretation,
as if RFC1995 had said

   If an IXFR query
   is via UDP, the IXFR server may attempt to reply using UDP if the
   entire response can be encoded as a single DNS response message
   and that message fits in a single UDP datagram.

Under this interpretation, the end of the response can be found
syntactically as the end of the (single) response message.  If this is
what you meant, please change the text in RFC1995 to make it clear
that an UDP response may only contain a single response message.

> operate only on the primary.

I *am* talking about the primary.

> 	to differ if the zone differs.

Not to defend this particular implementation, but in this case, the
serial numbers *did* differ whenever the zone did.  The serial number
was incremented before responding any query, and also before
responding to any IXFR.  The question is whether it needs to be
incremented *multiple* times when an IXFR contains multiple difference
sequences.  I say yes, but neither RFC says so clearly enough (IMO).

> must be 2^31 or more smaller than the server,

No.  At the risk of repeating myself, here is the example from my
reply to kre again, in a bit more detail:

Suppose the primary master M goes through the following sequence of
serial numbers:

  1000000000
  2000000000
  3000000000 (a)
  4000000000
  1000000000
  2000000000
  3000000000 (b)
  4000000000

A slave server S1 gets its zone data by IXFR from master M, and
version 3000000000 (b) happens to get condensed away.  Thus, S1 has
the following history:

  1000000000
  2000000000
  3000000000 (a)
  4000000000
  1000000000
  2000000000
  4000000000 (c)

A second slave server S2 has been doing transfers directly from M and
is nearly up to date, at version 3000000000 (b).  It is now
temporarily unable to contact M directly and contacts S1 instead,
asking for an IXFR with serial number 3000000000.  S1 MUST respond
with a full zone transfer, not with an incremental transfer starting
at 3000000000 (a).

In this scenario, the serial of S2 is *not* 2^31 or more smaller than
that of the master.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Mon, 29 Nov 1999 00:10:43 +1100

> Mark Andrews said:
> Unfortunately, BIND 4 sends the correct ID only in the first and last
> AXFR response message.  All the other IDs are zero.  At least this is
> the case in BIND 4.9.7.  

Still no reason not to specify that all messages in a answer MUST contain
the same ID.  

Just note that BIND 4 got it wrong.

> We can certainly make it a MUST for the master to transmit the exact
> values specified, but the slave still needs to accept deviant IDs and
> flags for interoperability with BIND 4.

Agreed.

Mark

---

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 27 Nov 1999 17:41:11 -0800 (PST)

Josh Littlefield <[email-masked]> said:
> ...
> ...
> fields need all be valid, as in any UDP Query response.

Good point.  I'll change the text such that the looseness applies to TCP only.

> For a TCP IXFR or

We could say that the slave SHOULD check the ID of the first message.
In any case, it SHOULD NOT check the ID of subsequent ones if it wants
to interoperate with BIND 4.

> part of a TCP IXFR/AXFR.  At least, that's the way I believe its typically

Hmm, does this mean that it is always transmitted as zero (in which
case checking it does no harm), or are there actually implementations
out there that transmit a nonzero RCODE in the middle of a successful
AXFR?

> returning a question section with type=AXFR in response to query of

OK, I'll add some text to that effect.

> I think that says the same thing, but just differently.

Yes.  I think your way of saying it is preferable.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 27 Nov 1999 17:53:54 -0800 (PST)