Subject: [dnsext] Re: Zone Immortality

From: Peter Koch <[email-masked]>
Date: Mon, 15 Sep 2008 19:12:18 +0200

On Wed, Aug 20, 2008 at 11:32:38PM -0400, Kevin Darcy wrote:

> Now, disregarding the obsolete "secondary" language (we now call them 
> "slaves")

{it's not that easy; master and slave actually terms to describe both ends
 of an XFR operation, where primary and secondary refer to the root of the
 XFR dependency graph and very other node, repsectively.  The problem
 occurs in cases where several servers are both master and slave.
 \end{terminology-rant}}

> Surely it cannot have been the intent for zones to become "immortal". 
> That would defeat the whole purpose of having EXPIRE in the first place.

>From an operational perspective I'm not sure I understand what you're trying
to achieve here. "expire" and its consequences have alwas appeared little
predictable to me.  Mark will know BIND's history much better, but I remember
seeing SERVFAIL responses or "valid" answers with just the AA bit missing.
Zone "expiry" never occured to me as a desirable feature that I'd rely upon.
Instead it's trying to put an end to waste of resources of repeated SOA-
and maybe even XFR attempts.  Insofar it's a relief to the slave system
less than a feature to securely and predictably phase out DNS zones.
I'd see that at the name server management level.

> implementation, provide a way for administrators to differentiate true 
> "master" replication sources, which reset the EXPIRE timer on each 
> successful refresh, from "peer"  sources, which do not. This would allow 

When a succesful refresh with the non-primary-master doesn't influence the
expire timer, why try it in the first place?

-Peter

--
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: Mark Andrews <[email-masked]>
Date: Tue, 16 Sep 2008 10:26:22 +1000

> expire timer, why try it in the first place?

	Peter, look at the following two common senarios (1 & 2) and the
	two solution senarios (3 & 4).  Kevin is worried about senario 2.
	I'm worried about both senarios 1 and 2.

	Senario 1:
		Simple transfer graph, no loops.

	primary:
		<no masters>
	secondary1:
		masters { primary; };
	secondary2:
		masters { primary; };
	secondary3:
		masters { secondary1; secondary2; };

	When the primary falls over when do secondary1, secondary2 and
	secondary3 stop serving the zone?

		secondary1 <expire>
		secondary2 <expire>
		secondary3 <expire>*2

	Senario 2:
		A transfer graph with a loop between secondary1 and secondary2.

	primary:
		<no masters>
	secondary1:
		masters { primary; secondary2; };
	secondary2:
		masters { primary; secondary1; };
	secondary3:
		masters { secondary1; secondary2; };

	When the primary falls over when do secondary1, secondary2 and
	secondary3 stop serving the zone?

		secondary1 never  (as answers from secondary2 restart timer)
		secondary2 never  (as answers from secondary1 restart timer)
		secondary3 never

	Senario 3:
		A transfer graph where you can identify peers.
		"peers" are "masters" that don't reset expiry timer.

	primary:
		<no masters>
	secondary1:
		masters { primary;
		peers { secondary2; };
	secondary2:
		masters { primary; };
		peers { secondary1; };
	secondary3:
		masters { secondary1; secondary2; };

	When the primary falls over when do secondary1, secondary2 and
	secondary3 stop serving the zone?

		secondary1 <expire>
		secondary2 <expire>
		secondary3 <expire>*2

	Senario 4:
		A transfer graph with loops using the EDNS EXPIRE option
		from draft-andrews-dnsext-expire-00.txt.
	primary:
		<no masters>
	secondary1:
		masters { primary; secondary2; };
	secondary2:
		masters { primary; secondary1; };
	secondary3:
		masters { secondary1; secondary2; };

	When the primary falls over when do secondary1, secondary2 and
	secondary3 stop serving the zone?

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

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 15 Sep 2008 20:41:15 -0400

> I'd see that at the name server management level.
Often the master and slaves are not under the control of a common name 
server management system, e.g. an ISP and their customer.

Even when present, name server management tools break or glitch 
sometimes. EXPIRE is a backstop for when that happens, to prevent stale 
data -- and consequent inconsistent answers -- from persisting indefinitely.
> expire timer, why try it in the first place?
In order to get the latest copy of the zone available, when the primary 
master is down temporarily.

- Kevin

---

From: Peter Koch <[email-masked]>
Date: Tue, 16 Sep 2008 11:21:39 +0200

Hi Mark,

> 	I'm worried about both senarios 1 and 2.

I think I understand the observation, both that sometimes "expiry" doesn't
take effect and that it might take multiple "expire" intervals.  However,
I'm not convinced that the proposed solution goes into the right direction
or isn't worse than the observation (not to name it a problem).
First, the SOA timer semantics have always been between master and slave,
now redefining the expire timer to always refer to the primary master is
a major step.
Second, what are the expectations of a "controlled expire"?  Is the slave
supposed to permanently deconfigure the zone? How would it be brought back to
life?  We both know that people choose all kinds of interesting expire values
and with today's interpretation, they can fix stuff and slaves will sync in
again.
Third, part of which is described in <draft-koch-dns-unsolicited-queries-02.txt>,
currently expired (no pun): Even if a "controlled expire" would remove the
respective statements from a slave's configuration, you'd not be able to get
rid of the (lame) delegation this way. Even worse, while the effects Kevin
and you described keep old data around, they at least avoid 100% lame delegations,
which every now and then result in query storms.

So, a better description of the requirements would help clarify the problem
that a redefinition of the expire timer is a proposed solution to.  And it
might turn out that the problem can't be solved in-band sufficiently.

-Peter

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Sep 2008 10:13:48 +1000

> now redefining the expire timer to always refer to the primary master is

	Not really.  The master dies.  The slaves die after the
	expire period has elapsed.  It doesn't matter if the slave
	is direct or indirect.

	This makes the more complicated transfer graphs behave the
	same as the simple star transfer graph.

> supposed to permanently deconfigure the zone?  How would it be brought back
> to life?

	The slave is supposed to forget about the current zone
	*contents* and continue attempting to transfer a new copy of
	the zone until it succeeds.   This is exactly the same as
	if the slave has just been configured for a zone.

	This has not changed.

> We both know that people choose all kinds of interesting expire values

	Not if they have expired.  They should re-transfer.

> rid of the (lame) delegation this way.

	Yes the zone would go lame.  This is what is supposed to happen.

> Even worse, while the effects Kevin

	Only avoid them when there is a loop.