Subject: Re: Bind 9 AXFR Modification vs AXFR Clarification

From: [email-masked]
Date: Fri, 21 Feb 2003 09:33:24 +1100

> > > > > The IXFR client must simply make the changes (again, by some
> > > > > implementation dependent, administrator maintained method) to the zon
> e by
> > > > > deleting RRs and adding RR's in each sequence. The original version o
> f th
> > > e
> > > > > zone might have been obtained by FTP (or quantum interference, or the
> > > > > psychic network) for all we know.
> > > >
> > > > 	Well the problem is that you have to get the *original* version
> ,
> > > > 	not a corrupted version.  AXFR implementations are not returnin
> g
> > > > 	the data originally entered.
> > >
> > > They sure have been.
> >
> > 	Not always.
> 
> You haven't shown any proof of that.  The "proof" you showed, was the
> result of a misconfiguration.

	No.  It is the result of operational reality.  Whenever you
	have a parent and child zones under different administrative
	controls it is impossible to change both zones simultaniously.
	It is also impossible using AXFR or any other mechanism
	which transfers *individual* zones to transfer them to a
	secondary and guarantee that they will arrive simultaniously.

	Having parent and child zone under different administrative control
	is the norm not the execption.

> > > If the zones are inconsistent through administrative mistake, then it
> > > won't matter what the IXFR does.
> >
> > 	Who said anything administrative mistakes?  The content is being
> > 	unilaterally changed by the servers.
> 
> It is reasonable and necessary to merge in glue. When you misconfigure the
> glue, strange things may happen. That is all that you have shown.  I'm
> sure that many software programs will exhibit even stranger behavior, and
> may even fail to operate as a result of misconfiguration.

	No.  It is neither reasonable nor necessary.  Any temporary
	inconsistancies will be corrected when all the zone transfers
	complete.  By changing the zones contents you create
	situations where these temporary inconsistancies won't be
	corrected.  When handing out non axfr/ixfr responses you
	use the best source of data you have.

	Nothing in RFC 1033 / 1034 / 1035 says that a server is permitted
	to alter the content of a zone.  The responability for maintaining
	consistancy between zones is a administrative function.
 
> > > Strange, that was my reaction, too. I'm just trying to be polite.  77%
> > > work just fine. We don't want to break 77% of the servers out there.
> >
> > 	You really think that it will break those servers?  LOL.
> 
> They will not be compliant, and thus will need to be changed. Thus, they
> would be broken by definition of not being compliant.

	So.  Just because they will not be compliant doesn't mean
	that that they need to be replaced immediately.  That
	non-compliance doesn't hurt most of them.  For those where
	it does have a negative impact it will mean that they should
	be able to request a fix from their vendor.

> Your failure to comprehend the consequences of the changes does not lessen
> the effect.  We now agree that these changes aren't necessary to support
> IXFR. You were part of the bad engineering that led to the unnecessary
> creation of these changes in Bind 9.  You were also part of the bad
> decision making that led to the distribution of these changes to Bind 9
> users prior to standardization, and quite possibly you were part of the
> bad decision making that resulted in publishing a book on the subject,
> prior to acceptance of your modifications to standards. In short, you have
> shown bad judgement.

	I never said that they we not necessary for IXFR.  I said that
	that your descripition of how to generate the differences was
	irrelevent to this discussion.

	It was bad engineering to merge the data sets together in the
	first place.  It was not required by RFC 1033/ 1034 / 1035.
	It had negative consequences.  It was good engineering to
	correct this.  It was also good engineering to report a
	common error to the community so that other vendors could
	fix their mistakes.
 
	Good engineers learn from their mistakes and try hard not
	to repeat them.  They also learn from the mistakes of others.
	That's why bridge designs are wind tunnel tested these days.

> Trying to "belittle" the effects with the "LOL", as opposed to offering
> anything substantive, simply suggests that you have no appreciation of the
> seriousness of the changes.  Perhaps you should take this more seriously.

	I'm quite aware of what the change requires.  I'm also aware
	that most of the nameserver are used in situations where
	the zone contents is already preserved because they are not
	serving zones with parent / child relationships.

	Anyone saying that all the nameservers need to be replaced
	immediately is spreading FUD.  LOL the the correct reponse
	to FUD.
 
	Using a server that perserves zone contents under all
	conditions doesn't break anything.

> > > > > Essentially, you are putting more (unnecessary) constraints on
> > > > > implementations, and thus on the administrators, who are supposed to 
> be
> > > > > pretty free to define the zone boundaries.  Of course, the specifics 
> of a
> > > n
> > > > > implementation puts some constraints on the adminstrator, but the
> > > > > administrator can choose a different implementation more to her likin
> g.
> > > >
> > > > 	The constaint was already there and it is necessary for reliabl
> e
> > > > 	operation of the DNS.
> > >
> > > No, you ware not being honest about the contents of the Draft. See my las
> t
> > > message to Andreas.
> >
> > 	The abstract say:
> >
> > 				    This memo clarifies, updates, and
> >    adds missing detail to the original AXFR protocol specification in
> >    RFC1034.
> >
> > 	I fail to see how the contents can be deemed misleading when
> > 	it states up front what it does.  Woops we missed warning you
> > 	up front that it contains a warning.
> 
> I've no doubt that you fail to see it. We seem to be focusing a lot on
> your failures. I have to question whether someone who went to MIT could
> really fail so often. Perhaps it has changes since I was there. Or perhaps
> you aren't really taking this very seriously. Let me explain it:
> 
> 1) It doesn't say that it adds a completely new, incompatible zone
> transfer protocol.  New protocols should be made through a different
> process, which includes experimentation. I'm not against experimenting
> with a new protocol. Indeed, I think this idea has some merit. However, it
> can't be "end-run standardized" by a "clarification". There is a process.

	It isn't new.  All it is saying is that the contents tramitted
	out MUST be that transmitted in.  This occurs most of the time
	already.  Note BIND is not the only implementation that does
	this.  We have already had reports of 3 other implementations
	doing this.  Even the implementations that don't guarentee the
	contents do this most of the time.  It has no negative effects.

> 2) It doesn't say that it changes AXFR with respect to SIG

	It doesn't change anything wrt to SIG.  Go read RFC 2535 which
	also says that SIG records in the answer section are part of the
	zone contents and don't need special processing.
 
> 3) It doesn't say that it changes the status of other RFC's (RFC 2845, and
> possibly others.) without going through the appropriate standards process.

	It doen't change the status of RFC 2845.
 
> 4) It doesn't say that it changes the definition of zone data to be
> public. Zone data is absolutely not "public by definition". It could very
> well be useful to tag certain RRs as non-public, and exclude them from
> zone transfers to public servers. This "clarification" precludes that.
> This is really 2 changes.

	Nowhere in RFC 1033 / 1034 / 1035 does it say that zone transfers
	are restricted to secondaries.  Nowhere in RFC 1033 / 1034 / 1035
	does it say that you should restrict zone tranfers.
 
	There is a REFUSED rcode so the possibility of refusing a zone
	transfer is allowed for but the conditions underwhich this will
	be done are not specified.  This draft does not change this.

> 5) It doesn't say that it changes the security constraints on a zone
> transfer to be limited to deny or accept only.

	Effective it does.  If you transmit the zone then you MUST
	transmit its full contents unmodified (accept).  It also
	says that you are allowed to refuse zone transfers (deny).

> The list is longer, but that should be enough.
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Feb 2003 21:07:49 -0500 (EST)

> 	is the norm not the execption.

Actually, a parent always has some control over the child. It exercises
this control through the glue records.  When the glue records are in the
child zone, they need to be merged. If a zone transfer happens while they
are inconsistent, it is possible for some strange results to happen.
Ordinarilly, zone transfers don't happen when they are inconsistent, since
the inconsistency is usually short.

Any zone transfers made during the inconsistent window are corrected so
long as the child zone is updated with correct information after the
parent is updated.

Frequently the parent and child zone are under different administrative
control, and are frequently on different servers. In such a case, the
contents of the parent zone aren't merged with the child in the child's
server, and no evidence of the inconsistency is seen through zone
transfers. However, the inconsistency still exists and may still be
visible by resolvers and nameservers that lookup the glue records.

You have obtained no benefits by these constraints.

> 	use the best source of data you have.

It is necessary, since the parent has glue records in the child zone.
The parent therefore has (always) a part of the child zone. If that server
also loads the child zone (or perhaps generates part of it dynamically),
it quite reasonable to merge the records as though the zone includes
multiple files, which in theory, it does.

The child zone contents will only be correct when the administrators of
both zones agree on the contents of the glue records, and update their
parts of the child zone accordingly. It will not be correct until then,
regardless of how many zone transfers take place.

> 	consistancy between zones is a administrative function.

This is a loaded statement. The part of the server NOT involved in
responding to queries and zone transfers is part of the administrative
function. So, as part of that administrative function, it has to be able
to modify the RR and zones accordingly.  Your proposed changes exclude a
huge part of the potential for intelligence in name servers. And do so
with no benefits.

> 	be able to request a fix from their vendor.

You seem to make a case that in general, non-compliance doesn't hurt
anything. This is false, for both technical and commercial reasons.
Technically, it hurts interoperability, which has some many obvious harms
I won't go into them. Commercially, implementations make and advertise
compatibility and standards compliance claims. This retroactively makes
those claims false, which harms the business and reputation of those other
vendors.

77% will need a fix from the vendor, if we were to accept these changes.

The vendor that made false claims of compatibility and standards
compliance is Bind 9. It should suffer the commercial damage to its
business and reputation, as a result.

> 	irrelevent to this discussion.

Ok, you are half way there. They are irrelevant because IXFR is
irrelevant. These changes are not necessary to IXFR, as I explained that
IXFR can work with the current AXFR, or even without AXFR.

> 	common error to the community so that other vendors could

Actually, since the parent has the glue in the child zone, it has part of
the child zone as well as the master zone.  Merging them together is not
prohibited, and in the case where child and parent have the same
adminstrator, as might be the case where most of the child is simply
automatically generated by the nameserver, can make things much easier.

Your constraints preclude this unnecessarilly.

Since I can think of cases where it is useful to merge records together,
it is bad engineering to remove that flexibility and obtain no benefits in
return.

> 	serving zones with parent / child relationships.

Apparently, you aren't even aware that your changes will make all non-bind
9 servers non-compliant.  Had you been aware of that, it seems you would
have brought this proposal forward something like 3 years ago, before
releasing Bind 9, and before publishing a book on the subject.

> 	immediately is spreading FUD.  LOL the the correct reponse

Making 77% of the servers non-compliant is a fact of your proposed
changes.  It is another fact, as explained, that non-compliant servers
will need to be replaced.  Will they suddenly stop working? It depends on
whether other implementations want to implement a "backwards
compatibility" mode. If they don't implement this mode, then the answer is
yes, they will stop working as soon as these updates are deployed by other
vendors. Of course, this is a bad result.

> 	conditions doesn't break anything.

Your constraints break useful services, and offer no value in return.

> 	contents do this most of the time.  It has no negative effects.

No, Section 3.1 is a whole new derivative of AXFR. That is new.

> 	zone contents and don't need special processing.

Oh. Then section 3.3 can be deleted in entirety without objection.

> 	It doen't change the status of RFC 2845.

The IEFT index indicates that RFC 2845 is "Proposed Standard", with no
applicability statement that I could find.  This changes it to
"RECOMMENDED" requirement level.  I think an applicability statement is
premature until RFC 2845 is moved along, and then by the appropriate
standards body decision-making process. It is inappropriate to hide
something like this deep in an irrelevant "clarification".

> 	does it say that you should restrict zone tranfers.

I don't think you understood my statement. I'm talking about the
definition of zone data. Nowhere does 1034 etc say that zone data is
public.  It may well have been thought to be public, originally, but since
I can easily see a useful purpose in withholding some private RRs, there
isn't any reason to preclude that behavior.

Your constraints harm a useful purpose, and provide no benefits.

> 	be done are not specified.  This draft does not change this.

Your modifications put additional and unnecessary restrictions on a zone
transfer. Again, these restrictions have no useful purpose.

> 	says that you are allowed to refuse zone transfers (deny).

This was addressed in the previous comments.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 06:37:25 -0000

[email-masked] writes:
> Whenever you have a parent and child zones under different administrative

False.

Set the clocks correctly, and schedule the change on all the servers for
a particular time, using (for example) the tinydns timestamp feature
described in http://cr.yp.to/djbdns/tinydns-data.html. When that time
rolls around, all the servers will change their data simultaneously, as
RFC 1034 requires.

Yes, this is difficult to achieve with BIND, AXFR, etc. But it's easy to
achieve with better software, better replication protocols, etc. You're
making a fool of yourself when you call it ``impossible.''

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: [email-masked]
Date: Fri, 21 Feb 2003 19:28:06 +1100

> rolls around, all the servers will change their data simultaneously, as

	So now you want to extend the protocol so that each record has
	an inception time and a expiration time.  We could create a
	new transfer protocol to do this and treat this data as meta
	data.

	However you would still have the problem of the meta data
	being inconsitant.  You would still need to ensure that it
	is transmitted in the right order or that servers didn't
	modify it while it was being transmitted or that you ban
	any server but the master server sending copies of the zone.

	The problems are inherent with having different source maintaining
	copies of the same data.
	
	Mark

---

From: Kandra Nygårds <[email-masked]>
Date: Fri, 21 Feb 2003 15:36:39 +0100

From: "D. J. Bernstein" <[email-masked]>

> rolls around, all the servers will change their data simultaneously, as

Excellent idea. Unfortunately, this doesn't address the problem with several
TLD registries requiring a correctly configured zone prior to making a
delegation. In many cases, there are automated checks that prevent you from
even requesting a change of delegation unless you have updated your zone.

Example:

Server A and B are authorative for zone C.
Zone C is a child of zone TLD.
The administrator for zone C wants to add Server D.
The registrar for TLD requires that Zone C is configured according to the
new data before approving a change.

Alternative A:

The administrator for zone C won't violate RFC1034 and is therefore unable
to change his zone data unless TLD is also updated at the same time, which
the TLD doesn't allow.

Alternative B:

The administrator for zone C changes the data in zone C, thereby temporarily
violating RFC1034.
The delegation robot for TLD verifies the data and accepts the delegation,
therefore ensuring that RFC1034 consistency is maintained.

I'm sure that most administrators would pick alternative B in this case. If
you're still maintaining that RFC1034 violations are unacceptable, you might
want to update the following pages:

http://cr.yp.to/djbdns/dot-fr.html
http://cr.yp.to/djbdns/dot-it.html
http://cr.yp.to/djbdns/dot-nl.html
http://cr.yp.to/djbdns/dot-no.html
http://cr.yp.to/djbdns/dot-ru.html
http://cr.yp.to/djbdns/dot-arpa.html

All of these registries require that administrators knowingly change the
data in their child zones before the parent zone is updated, in fact they
all use automated checks to ensure that the data is in fact correct. This
short-term intentional violation of RFC1034 is to ensure that parent and
child gluedata is consistent in the long run.

As I said, we don't live in a perfect world. If your software can't cope
with that, there's an implementation bug.

Best regards,
Kandra Nygards

---

From: Matt Crawford <[email-masked]>
Date: Fri, 21 Feb 2003 11:31:48 -0600

> rolls around, all the servers will change their data simultaneously, 

My friend Dr. Einstein would like a word with you about your casual
misuse of the word "simultaneously."

__________________________________________________________________
Matt Crawford             [email-masked]                Fermilab

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Feb 2003 14:06:41 -0500 (EST)

> rolls around, all the servers will change their data simultaneously, as

Clever.

> making a fool of yourself when you call it ``impossible.''

This could be done with a slight change to AXFR. Lets include it in the
MAXFR proposal (the axfr mods, taken out of the "clarification".

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 19:14:30 -0000

> with that, there's an implementation bug.

Where do you get the idea that my software (or most deployed versions of
BIND) has any trouble here?

Andrews is creating problems for himself by updating the parent serial
number too _early_. You're talking about parents that insist on making
the parent changes _late_. Early and late both violate RFC 1034, but
late doesn't cause problems.

---

From: Kandra Nygårds <[email-masked]>
Date: Fri, 21 Feb 2003 21:11:19 +0100

> BIND) has any trouble here?

You have been consistently claiming that your software enforces strict
RFC1034 compliance and therefore compromizes data integrity.

> late doesn't cause problems.

Both "early" and "late" exist in the real world. Regardless of if it's an
administrative error or an intentional change, there's no excuse for any
software to allow timing issues to affect data integrity.

- Kandra

---

From: Len Budney <[email-masked]>
Date: Fri, 21 Feb 2003 15:52:18 -0500 (EST)

On Fri, 21 Feb 2003, [iso-8859-1] Kandra Nygårds wrote:
> 
> Both "early" and "late" exist in the real world. Regardless of if it's
> an administrative error or an intentional change, there's no excuse
> for any software to allow timing issues to affect data integrity.

Yes--early and late both exist. But errors are not symmetrical! If the
task is to "open the door and walk through", then opening the door "early"
doesn't hurt, but opening the door "late" really hurts a lot.

Dan has proposed allowing "late" but not "early". That's easy to do: just
do one thing before attempting to do the other. Your implied claim that
it's impossible to guarantee a time ordering is ridiculous.

--Len.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Feb 2003 21:32:57 -0000

> Regardless of if it's an administrative error or an intentional
> change, there's no excuse for any software to allow timing issues to
> affect data integrity.

Suppose the administrator changes the serial number and _then_ changes
the other data. This timing screwup destroys data integrity with BIND 9.
According to your mindless rhetoric, this is an inexcusable BIND 9 flaw.

Can we please drop the religious nonsense now?

In the real world, when the administrator screws up the timing, we blame
the administrator. Good software can prevent many problems---as tinydns
does with automatic serial numbers, for example---but all remaining
problems are the direct result of an administrator's misconfiguration.

Andrews says that the RFC 1034 rules are too hard for administrators to
follow. He wants to loosen them. I'm pointing out exactly which timing
rules are necessary to guarantee a successful update. You are claiming
that we don't need _any_ rules; that's ludicrous.

---

From: [email-masked]
Date: Sat, 22 Feb 2003 23:08:22 +1100

> that we don't need _any_ rules; that's ludicrous.

	Server A (tinydns) primary parent and child.
	Server B (bind 8) secondary parent and child off A
	Server C secondary parent off B

	Initial state NS RRset for child zone N on all servers

	Server A updates NS RRset to N'
	Server B transfers parent
	Server C transfers parent
	Server B transfers child
	
	Final state
	Server A N', Server B N', Server C N

	Your fix.  Delay the update of the parent.  Tinydns is
	incapable of doing this.

---

From: Kandra Nygårds <[email-masked]>
Date: Sat, 22 Feb 2003 16:12:16 +0100

> the other data. This timing screwup destroys data integrity with BIND 9.

BIND9 transfers the zone as presented by the master server at the time of
the transfer. BIND9 does not destroy or change any data received through
that transfer.

A change in the master zone without the corresponding change of serial is an
administrative error, true, and will result in inconsistent views in master
and slave servers. However, the draft in question is specific to the concept
of AXFR. In this scenario, an AXFR would never take place.

> Can we please drop the religious nonsense now?

I apologize. I strayed off topic.

> problems are the direct result of an administrator's misconfiguration.

I fully agree with you, with the exception that there is a defined problem
here. Under certain circumstances, some software might not preserve data
integrity. Your software might be one of them, as has been claimed by a
number of people.

I agree that good software can prevent many problems, in particular
administrative errors. However, those errors must be corrected at the source
or not at all. Attempting to correct administrative errors at a slave server
will cause data inconsistency in certain circumstances.

> that we don't need _any_ rules; that's ludicrous.

On the contrary, I'm trying to encourage a draft that specifies rules to
protect data integrity.

- Kandra

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Feb 2003 17:24:05 -0000

Andrews gives yet another example of a configuration that (1) violates
the semi-synchronization rule and (2) causes problems.

The solution, of course, is to follow the semi-synchronization rule:
update the parent serial number after the child servers have changed.

[email-masked] writes:
> Tinydns is incapable of doing this.

Where do you get these ridiculous ideas?

With tinydns, you can use manual serial numbers and update them exactly
as you would with BIND. You can also use automatic serial numbers and
update them by simply touching the data file. Both ways work.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Feb 2003 17:43:07 -0000

[ BIND 9 allowing a badly timed serial-number update to destroy data ]
> In this scenario, an AXFR would never take place.

BIND 9 does an AXFR, but does it too early, because the administrator
updated the parent serial number too early. BIND 9 never realizes that
it has to do another AXFR.

This is also what's going wrong in Andrews's tinydns/BIND 8 scenarios.
Andrews updates the parent serial number too early, so the parent slave
doesn't realize that it have to transfer the parent zone. The necessary
final AXFR never takes place.

> Attempting to correct administrative errors at a slave server

No. It will simply copy inconsistencies created by the administrator.

If the administrator changes serial numbers properly, the only effect
of these inconsistencies is that, _during_ the update, clients might
receive old data, and clients might receive new data.

If the administrator screws up the timing of changing serial numbers,
the old data can persist _beyond_ the update. You claimed that this was
``inexcusable'' but have now admitted that it's true for BIND 9 too. The
solution is for the administrator to change serial numbers properly.

---

From: [email-masked]
Date: Sun, 23 Feb 2003 10:36:40 +1100

>   [ BIND 9 allowing a badly timed serial-number update to destroy data ]

	Dan, is your intention to intentionally mislead the list?
	The example was for BIND 8.  Saying it was for BIND 9 was
	a lie.

        
        Final state

> it has to do another AXFR.

	Well it was BIND 8 doing the AXFR.
 
> final AXFR never takes place.

	There is not such thing are a "necessary final AXFR".
 
> No. It will simply copy inconsistencies created by the administrator.

	What?
 
> solution is for the administrator to change serial numbers properly.

	Well I didn't claim this.

	If the nameserver screws up the copy of the zone the old
	data can persist _beyond_ the update.

	The simple solution to this is to stop the nameservers
	screwing with the copy the zone.

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2003 00:19:14 -0000

[email-masked] writes:
> The example was for BIND 8.  Saying it was for BIND 9 was a lie.

You are, as usual, completely wrong. I gave a crystal-clear example of
BIND 9 allowing a badly timed serial-number update to destroy data. I
was responding to the ridiculous claim that ``there's no excuse for any
software to allow timing issues to affect data integrity.''

> Tinydns is incapable
  [ of changing serial numbers upon demand ]

Wrong again. You're making a fool of yourself.

---

From: Kandra Nygårds <[email-masked]>
Date: Sun, 23 Feb 2003 10:59:35 +0100

> solution is for the administrator to change serial numbers properly.

Whoa, back up a moment.

First, I'd like to apologize for not making my argument crystal clear. For
some reason, a few people seem to be under several misconceptions regarding
my intentions.

Let's step back and define a few base parameters:

I'm claiming that some software - now existing or future - might experience
problems due to implementation errors.
These problems may be caused by minor administrative errors, or may be
caused by normal everyday routine operations.

These problems are caused by the following:

Server A updates parent and/or child zones.
Server B reaches its refresh threshold for parent zone, checks for an
updated SOA serial and transfers the zone via AXFR
Server C reaches its refresh threshold for parent zone, checks for an
updated SOA serial and transfers the zone via AXFR
Server B reaches its refresh threshold for child zone, checks for an updated
SOA serial and transfers the zone via AXFR

In the above scenario, all updates are performed according to established
routines:
* Any update of the data in a zone is accompanied by the required update of
the SOA serial.
* The AXFRs are all initiated by a SOA serial query indicating an updated
zone.
* The frequency and timing of the queries are controlled by the SOA refresh
value.

This scenario is for a perfectly ordinary routine operation for real-world
configurations - I've personally witnessed configurations where several
masters (see Server B) receive their data from a hidden master (Server A)
and in turn allow slaves (Server C) to update from them.

Now, the problems mentioned above can of course also be caused by
administrative errors, but that's beside the point. What I'm trying to point
out here is the need to maintain zone integrity for the purposes of AXFR in
order to ensure that the zones stay consistent between the servers during
normal updates.

- Kandra

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Feb 2003 00:28:24 -0000

> Any update of the data in a zone is accompanied by the required
> update of the SOA serial.

That sentence is, obviously, not a complete statement of a glue-update
procedure.

See my 21 Feb 2003 06:27:51 -0000 message for a complete list of the
things you have to do. Do you have some questions about that procedure?