Subject: Automation of secondary DNS servers

From: "Jesper G. Hoy" <[email-masked]>
Date: Thu, 1 Mar 2001 14:59:31 -0500

Looking for feedback - and possibly assistance with composing an RFC.

Please let me know if I have missed an existing RFC on this topic.

A lot of our customers (we write and sell DNS server software) have asked us
about a way to automatically create (and delete) zones on secondary servers.
Preferably through some type of signaling from the primary and a periodic
synchronize mechanism.

This would greatly ease administration, as zone administration could be done
entirely on the primary server
And the chance of lame delegations on secondary servers would be
significantly reduced.

Currently each new zone must be created on both the primary and all
secondary servers (same for deletions).

The Notify OpCode (RFC1996) could easily be adopted for the "signaling" from
primary to secondary, but a new "zone list transfer" mechanism for periodic
synchronization would probably have to be devised.

Obviously we could implement a proprietary system, but since secondaries are
(or should be) off-site chances are that different software is used.
So to ensure cross-implementation compatibility I think a standard for
something like this would be very appropriate.

Looking forward to hearing your comments.

Regards
Jesper G. Hoy

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 01 Mar 2001 12:49:56 -0800

the right way to do this is with postprocessing of outofband data, not NOTIFY.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 01 Mar 2001 23:03:26 -0500

> something like this would be very appropriate.

Why bother with a "zone list transfer" mechanism? Just beef up NOTIFY with some
crypto-authentication and more intelligent and long-term retry logic, and
servers should be able to rely on it for auto-creation of slave zones.

Slave-zone deletions can be handled any number of ways, e.g. a) delete on
expiration, b) delete if master responds non-authoritatively X number of times,
c) delete if master answers non-authoritatively for Y interval of time.

Other than the NOTIFY extensions themselves, none of this should require any
protocol changes, since zone-configuration maintenance is pretty much left up
to the implementations anyway.

- Kevin