Subject: [dnsext] axfr-clarify-10 section 7, Zone Expiry Timer

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 29 Jan 2009 14:14:18 +0200

draft-ietf-dnsext-axfr-clarify-10.txt section 7 quotes RFC1034 section
4.3.5, and then goes on to say:

   Perhaps what is not clear in the paragraph regarding the EXPIRE
   interval timer is that it is only reset to the EXPIRE parameter when
   a new zone is loaded.  A new zone means a zone with a higher serial
   number than the most recently loaded zone.  The EXPIRE interval timer
   is not reset automatically as a result of a zone transfer as a zone
   could be (mistakenly) transferred with the same or lower serial number.

This would mean that when a zone changes less frequently than once per
EXPIRE interval, the slaves stop serving it as soon as the EXPIRE
interval has passed, even though they are perfectly up-to-date.  That
would be ... bad.

I understand this is an attempt to fix the problem that if two slaves
do serial checks from one another, the zone will never expire, but
this particular cure would be far worse than the disease.

I suggest removing section 7 in its entirety.  If the working group
considers the expiry problem important, it can be dealt with in a
separate draft.
-- 
Andreas Gustafsson, [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: Chris Thompson <[email-masked]>
Date: 29 Jan 2009 13:57:59 +0000

>this particular cure would be far worse than the disease.

Agreed. There are zones whose SOA serial doesn't change for years on end.

The "clarification" is completely contrary to existing practice.

>considers the expiry problem important, it can be dealt with in a

We do of course have Mark's draft-andrews-dnsext-expire-00.txt, which
is exactly relevant in this context, but namedroppers seemed not to
like it.

-- 
Chris Thompson
Email: [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 29 Jan 2009 16:42:55 +0200

> is exactly relevant in this context, but namedroppers seemed not to

To me, the question is whether that problem is important enough to
solve completely, given the complexity of a complete solution.  If we
think expiry must work perfectly for transfer graphs with loops, at
any cost, then draft-andrews-dnsext-expire-00.txt seems like a fine
first draft of a solution.  But if not, then we could just say that
zone transfer graphs with loops are NOT RECOMMENDED, and that
administrators need to be aware that deep zone transfer graphs make
expiry take longer.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Jan 2009 10:53:10 -0500

>The "clarification" is completely contrary to existing practice.

I think I misunderstood the problem.  Let me ask something, given 
what is below describes my new understanding of the problem.

#  The EXPIRY timer is reset when 1) there is a new serial number and 2) when
#  a master server confirms that the existing serial number is still in place.
#
#  The EXPIRY time is not to be reset when a slave confirms that the serial
#  number is still in place.
#
#  The problem is that an AXFR client does not know if the AXFR server is a
#  master or a slave.

Is that right?  If that is the case, then the text in -10 is 
certainly wrong.  In -11 I would plan to describe the problem and 
then recommend avoiding loops.  Unless there's some other comments.

BTW - I plan to rev the document in the next week or so.  I'm 
scanning the email these days and will do a editing pass in the 
coming 7 days.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 08:37:29 +1100

In message <[email-masked]>, Chris Tho
> is exactly relevant in this context, but namedroppers seemed not to

	No some like it.  Some don't seem to think it is worth the
	effort.  Some think that expire is there so that slaves
	don't have to clear up old zone.  Some want a complete
	examination of what it means to expire a zone despite RFRC
	103[45] stating the purpose.
	
	Expire is there so that stale data is not being served.

	I wrote the draft because users have managed to get themselves
	into the position where there were slaves that didn't expire
	a zone AND THEY COMPLAINED TO US THAT EXPIRE DID NOT WORK.

	I look at all the alternatives I could imagine and every
	one of the alternative did not work reliably.

	Telling them not to use have loops is really a non-starter,
	they will do it anyway and things will break.

	Static configuration of upstream vs peer effectively removes
	the backup paths.  You may have a path were new updates can
	propogate but you loose the refresh path which results in
	zones expiring while there is still a valid axfr path.

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