Dynamic Updates proposal

[postel@ISI.EDU (Jon Postel)]

Hi.  Anant Kumar (with some help from Steve Hotz) has 
developed the following scheme for dynamic updates to 
DNS data.  The focus here is on how to do the update,
with no discussion of security issues.  Of course, we
do need to deal with the security issues, but lets see
if we can agree on a processing scheme first.

Comments please.

--jon.

===========================================================================
--------------------------------------------
Dynamic Updates (version of August 27, 1993)
---------------

All updates to database happen at the primary. The secondaries pass on
any updates they receive, to the primary. This simplifies the problem
of inconsistent serial numbers on different servers and is consistent
with current DNS philosophy. 

On receipt of an update message at the primary, the following happens.

   Update tables
   Mark Entry DYNAMIC.
   Update SERIAL NUMBER.
   If (DELETE MESSAGE){
	set ZOMBIE_FLAG; 
   }
   If(currenttime >= NextNOTIFYtime){
	dump2disk and NOTIFY.
	NextNOTIFYtime = currenttime + InterNotifyTimer;
   }

NOTIFY (IXFR description has greater detail on this)
------
	Send SOA to secondaries, with Opcode NOTIFY

	/* must know about stealth secondaries.
	 * propose each "primary" or "secondary"in bootfile be followed by
	 * "stealth" ... zonename ... sec1 sec2 sec3 .... sec'n
	 */
dump2disk
---------
	dump_entry(DYN_FILE, SOA);
	For each DYNAMIC entry{

		/* dump to disk, the RR plus the serial number.
		 * if ZOMBIE, the FLAG says so and we do
		 * not need to do anything special
		 *
		 */
		dump_entry(DYN_FILE, entry);

	}

ON STARTUP
----------
read both files. use SOA with higher serial number.

for each entry in (list of secondaries)
	/*make sure we start our soft state from scratch */
	reset XFRserial;

On accessing a ZOMBIE entry
---------------------------
If (ZOMBIE && serial_number < minXFRserial[zone]){ /* if using soft-state */
	remove entry from core;
	free memory;
}

If we do not use soft-state but refuse IXFRs when the serial is too far
back in time, we can delete ZOMBIE entries when they fall behind the current
serial by "N".

thus, the test above can then be
	If(ZOMBIE && serial_number < current_serial - N){
		..;
		..;
	}

On XFR (A/I) from secondary
---------------------------
/*find the entry in XFR serial list corresponding to this guy*/
XFRserial_entry = find(secondary, XFRserial_list[zone])

/* remove this entry from the list*/
dequeue(XFRserial_entry, XFRserial_list[zone]) 

/*update entry to show that we just transferred */
update(XFRserial_entry, currentserial) 

/*put it back at the end of the list*/
enqueue(XFRserial_entry, XFRserial_list[zone])

Head of list always has the minimum XFR serial. Makes faster Reading.
this is necessary only if we are following the Soft-State mechanism.

On receiving a SIGHUP from owner of process on local machine.
-------------------------------------------------------------

	human updates serial number => M
	we have, in core	    => N

	If (NewNumNeeded)
		max(M,N) + 1
	else
		max(M,N)

We should read in only those records that bear serial number "M".
Alternatively, the DNS reloading section should do a diff of
the data file with data it has in core and load only entries
it doesn't have and assign them serial number as described above.
This way, the job of assigning per entry serial number is free
from human errors.

Should we periodically update the SOA record on the datafile to
reflect the latest??
---------------------------------------------------------------------
---------------------------------------------------------------------

Security issues, besides the obvious issue of updater authentication.

1. Updating data from zone file: We propose not to allow any dynamic
   updates that try to modify data that goes in the zone file. Only
   dynamically acquired data may be modified dynamically.

2. Preserve dynamic entries, backed up in a file, separate from the
   zone data file.


Updater authentication is an issue we have not addressed here. We believe
SNMP security or some signature based authentication protocol might be used
to screen incoming update packets, before the above mechanism is applied.

This document deals with "what happens to the update packet, once it
crosses all the authentication protocol hurdles".

===========================================================================