Subject: [dnsext] expiry

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Jan 2009 17:08:28 -0500

I wanted to separate this from the older threads because it is no 
longer clear to me that this belongs in AXFR clarify and I don't 
recall all of the stuff surrounding the expire draft from Mark A.  I 
just want to see if I understand the issue.

First I have to say that RFC 1034 isn't that clear about EXPIRE. 
Here's the relevant text:

# The periodic polling of the secondary servers is controlled by
# parameters in the SOA RR for the zone, which set the minimum acceptable
# polling intervals.  The parameters are called REFRESH, RETRY, and
# EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
# waits REFRESH seconds before checking with the primary for a new serial.
# If this check cannot be completed, new checks are started every RETRY
# seconds.  The check is a simple query to the primary for the SOA RR of
# the zone.  If the serial field in the secondary's zone copy is equal to
# the serial returned by the primary, then no changes have occurred, and
# the REFRESH interval wait is restarted.  If the secondary finds it
# impossible to perform a serial check for the EXPIRE interval, it must
# assume that its copy of the zone is obsolete an discard it.

(Oh, bottom of page 28, section 4.3.5.)

Starting backwards, the EXPIRE timer goes off only if is impossible 
to perform a serial check.  What does it mean "impossible to perform?"

The text about EXPIRE omits the work "primary" that is used earlier 
in the paragraph.  There's "checking with the primary" that seems to 
indicate that only primaries (or masters) can be AXFR servers.

Getting back to something I posted earlier - it seems that the EXPIRE 
timer is reset when ever the serial number is checked at a 
primary/master server, not when the serial is new.

When a secondary/slave is checked - which seems to be not in the 
original design - the EXPIRE timer should not be reset or a zone 
could "live forever."

(BTW, I do agree with Alfred now that this is all out of scope for 
AXFR clarify.  But I am still curious.)

Does this mean that DNS implementations that allow a slave to slave 
off a slave are not in compliance with this part of 1034?

Of course, if reality says that slaving off slaves is "good" then we 
should work out the kinks and keep the feature.  Code and ops trump 
specifications.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Jan 2009 11:34:56 +1100

In message <a06240800c5a7d50a7bf4@[10.31.200.212]>, Edward Lewis writes:
> --============_-978855583==_ma============
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 

	People want all the servers for a zone to have the latest
	content regardless of where a failure is.

	People want to have hidden masters.
	
	People want zones to expire at a known interval after the
	master goes away.

	People want simple configuration.

	To make the above all work reliably was why I wrote the
	draft.  As a added bonus it provides a mechanism to help
	with other requests we have had.

	People want to know if their slaves are properly refreshing
	the zone.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Edward Lewis <[email-masked]>
Date: Fri, 30 Jan 2009 11:01:32 -0500

So now I see the situation as this:

The original specification assumed that AXFR servers were masters, 
AXFR clients were slaves, thus there was no chance of an EXPIRY timer 
reset loop.

Operational experience has shown that slaves working as AXFR servers 
works and is desirable because it adds resilience to the zone 
distribution process.  As is common though, when something is 
developed in the field architectural aspects are overlooked.  In this 
case, the use of slaves as AXFR servers creates the EXPIRY timer 
reset loop.

So, to be relevant to the operations community, the IETF ought to 
publish a document on this issue, even if there is no specification 
update.  This issue, along with split-view zones and perhaps another 
operational technique ought to be documented for the sake of 
completeness of the IETF DNS document sets.

Perhaps this ought to be thrown to DNSOP.  But they've tried to 
tackle split-view before and never took that up:

http://www.ietf.org/mail-archive/web/dnsop/current/msg03901.html

(I submitted extensive comments on that, but the document never came 
to RFC.  IOW - my recommendation is not just a "someone should do 
something" complaint.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468