Re: rsync vs. axfr-clarify (was: in support of axfr-clarify)

[Danny Mayer <mayer@gis.net>]

At 05:29 AM 12/9/02, Bruce Campbell wrote:
> On Mon, 9 Dec 2002, Danny Mayer wrote:
>
> > Let us say we have two servers A and B that are authorative for a zone.
> > The contents of the zone reside in a file named Z on server A and in a file
> > named Z' on server B.
> >
> > An admin adds records to file Z on server A and reloads the server. rsync
> > notices the change to the file and transfers the delta to server B and 
> merges
> > the changes into file Z'. If I understand correctly rsync, the contents of
> > file Z'
> > is now identical to that of Z. Server B is now reloaded and can respond to
> > queries on the new records.
>
> Yes.
>
> > Isn't this exactly what axfr-clarify is trying to accomplish, i.e. the 
> records
>
> Nearly.
>
> > in the zone should be transferred unchanged from server A to server B
> > irrespective of other information that the server may have regarding some
> > of the records? Why should AXFR be different in this respect from rsync?
>
> The main difference between AXFR and rsync-over-ssh is that the latter
> produces an exact copy of a given _file_.  The former SHOULD produce a
> functionally-identical copy of a given _zone_.
>
> ( I say 'SHOULD' because a number of implementations do not produce
>   functionally-identical copies, due to confusion about the existing
>   definition of AXFR, as has been noted previously. )
>
> This means, since there is no set standard for an actual zone file, that
> you can only (reliably) do rsync-over-ssh if you have identical server
> software on both servers.
Thank you. I should have said functionally identical. An AXFR transfer
has no defined order in the records transferred except that the first and
last records be the SOA and identical and of course any comments that
may have been in the original source file do not get transferred.

> If you have two servers using different zone file formats, that understand
> AXFR, you should be able to get working transfers of zones, without having
> to mess around with post-converting the zone file from one format to
> another, to say nothing of a separate process to detect changes and
> trigger a zone or server reload.
Yes, the storage of the data can be in any format, including a database.

> Hence, I support the general need for a clarification of AXFR so that
> various nameserver implementations can reliably act as both primary or
> secondary depending on local configuration.
>
> --==--
> Bruce.
Danny


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