Re: Extending UPDATE to add/remove zones

On 18/10/2013, at 12:17 AM, Mukund Sivaraman <[email protected]> wrote:

> One more thing:
> 
> RFC 1035 calls for durable storage of zone data. This is not a strict
> requirement for configured secondaries if you consider that a secondary
> can AXFR data from scratch during startup and store it in volatile
> memory. There are no updates to zone data made at secondaries -
> transfers not being considered as updates to data.
> 
> So far, the "catalog" (RFC 1035) is a part of the secondary
> implementation's static configuration. The secondary can run without
> writing to durable storage.
> 
> The case where a secondary crashes, loses its dynamic configuration
> should be addressed. Is an admin expected to reconfigure the secondary
> on startup each time? Is the secondary expected to save the updated
> catalog to durable storage? (The latter may not be agreeable to
> everyone, so support for both should be considered.)

I think that is an implementation specific decision that should not be hard-coded in the protocol.  i.e. some may choose to require a dynamic re-configuration while others may store the configuration persistently.

Jay

> 
> 		Mukund


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext