Subject: Zone Immortality

From: Kevin Darcy <[email-masked]>
Date: Wed, 20 Aug 2008 23:32:38 -0400

RFC 1034 states:

    Each secondary server is required to perform the following operations
    against the master, but may also optionally perform these operations
    against other secondary servers.  This strategy can improve the transfer
    process when the primary is unavailable due to host downtime or network
    problems, or when a secondary server has better network access to an
    "intermediate" secondary than to the primary.

Now, disregarding the obsolete "secondary" language (we now call them 
"slaves"), and the obviously-incorrect word "following" (which can't 
possibly be right, since this is the last paragraph of the section -- 
there is nothing relevant "following"), one notes the blatant ambiguity 
of "these operations". Which operations? Minimally, checking the serial 
number and performing a zone transfer if it has increased? I think that 
much is fairly obvious.

What's a little *less* obvious, and the point of my missive, is whether, 
when and/or how "these operations" might include the following, from a 
previous paragraph: "

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[sic] discard it."

The problem with slaves resetting their EXPIRE timers every time they 
perform a successful refresh from another slave is that the slaves may 
be in a reciprocal or circular -- A refreshes from B, B refreshes from 
C, C refreshes from A -- relationship, so the zone may become 
"immortal", i.e. even when it is deleted from the primary master, the 
slaves continue to keep the zone alive indefinitely by constantly 
refreshing each other.

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.

Yet, having slaves in a reciprocal or circular relationship is a 
perfectly _valid_ arrangement. It ensures that, if the primary master 
goes down for an extended period of time (i.e. multiple REFRESH cycles), 
all slaves in the set eventually converge on the latest-available 
version of the zone.

I would suggest, therefore, that if this language in 1034 cannot or will 
not be clarified/updated in the foreseeable future, so as to outlaw this 
"optional" replication topology, that implementors review their 
refresh/expire logic, and if it doesn't already exist in their 
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 
large enterprises --such as ours -- to build highly robust and available 
DNS infrastructures without having to struggle with zone-immortality 
risks/issues.

                  - Kevin

--
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: Thu, 21 Aug 2008 14:28:09 +1000

> DNS infrastructures without having to struggle with zone-immortality 

	There are lots of existing ways to address this.

	* Outlaw loops.
	* Don't reset the expire counter on refresh from peers only
	  on transfer from peers.

	* Use DNSSEC to make data go stale.

	Extend AXFR/IXFR/SOA to add a expiry counter.  The master would
	always set this to SOA EXPIRE.  The slave would report it's
	current value for that counter.

	This fits well into EDNS as it is a hop-by-hop value.

	It would also address the N * expiry problem that currently
	exists when you have a deep transfer graph.

	e.g.  <EXPIRE><4><COUNTER>

	The slave would add a <EXPIRE><0> option to its SOA
	refresh queries and to IXFR and AXFR queries.

	The slave would use the maximum of the returned value and
	it's expire counter on SOA serial matches to refresh queries
	or IXFR up to date responses to set its expire counter.

	The slave would use this value rather than the SOA expire
	field to initialise it's expire counter on IXFR/AXFR which
	change the zone content.

	The slave will perform a sanity check to ensure that the
	returned value is no greater than the SOA expire field.  If
	it is greater then it will use the SOA expire field instead.

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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 21 Aug 2008 01:00:19 -0400

Kevin Darcy wrote:
> there is nothing relevant "following"), one notes the blatant 
> ambiguity of "these operations". Which operations? Minimally, checking 
> the serial number and performing a zone transfer if it has increased? 
> I think that much is fairly obvious.
>
> What's a little *less* obvious, and the point of my missive, is 
> whether, when and/or how "these operations" might include the 
> following, from a previous paragraph: "
>
> 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[sic] discard it."
>
> goes down for an extended period of time (i.e. multiple REFRESH 
> cycles), all slaves in the set eventually converge on the 
> latest-available version of the zone.
>
> I would suggest, therefore, that if this language in 1034 cannot or 
> will not be clarified/updated in the foreseeable future, so as to 
> outlaw this "optional" replication topology, that implementors review 
> their refresh/expire logic, and if it doesn't already exist in their 
> successful refresh, from "peer"  sources, which do not. This would 
> allow large enterprises --such as ours -- to build highly robust and 
> available DNS infrastructures without having to struggle with 
> zone-immortality risks/issues.

It raises an interesting question, if more than one slave transfers the 
zone with the same serial. Should all subsequent transfers from those 
slaves necessarily get the same result (i.e. related to EXPIRE timer 
logic), or perhaps whichever of the slaves transfered the zone *last*, 
would legitimately have a slightly better value (since its own EXPIRE 
timer started ticking later)?

Here's my suggestion:

If a zone is transfered *from* a slave, the values for the TTLs should 
be modified downwards by the local EXPIRE timer. Only transfers from a 
zone master should have the original TTL values from the SOA used for 
timers.

This would mean that all recipients of a transfer from a slave would 
have EXPIRE timers that fire at the same time as the slave - effectively 
synchronizing the expiry for any slave^n-th that doesn't succeed in 
doing a refresh from some source with a better SOA SN *or* EXPIRE timer.

It basically functions analogously to NTP source "stratum", where 
stratum is monotonically increasing across peerings...

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 14:52:00 +0900

> all slaves in the set eventually converge on the latest-available 

A hidden assumption of 1034 is that such convergence will occur
within a period much shorter than the expiration period.

If not, you have an administrative problem a lot more serious
than a small variation of expiraiton period.

							Masataka Ohta

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 25 Aug 2008 23:56:33 -0400

> 	it is greater then it will use the SOA expire field instead.
I wasn't really angling to have a new protocol extension added, just 
pointing out an ambiguity in the spec, cautioning implementors as to the 
consequences of not carefully dealing with the ambiguity, and putting 
out one suggestion for how implementors could give administrators a way 
to avoid the immortality problem.

Your option "Don't reset the expire counter on refresh from peers only 
on transfer from peers" sounds like a slightly-more-fleshed-out version 
of what I was proposing ("differentiat[ing] true 'master' replication, 
which reset[s...] from 'peer' sources, which do not"). Thus, I approve 
:-). However it is formulated, the implementation would need to 
distinguish "peer" from "master".

Option "Outlaw loops" is simplest, in the Draconian sense, but as I 
think I explained in my original message, can be viewed as suboptimal, 
since it does not facilitate full convergence of all slaves during an 
extended outage of the master. Also, there is the question of how 
"outlaw loops" could be reliably enforced within the implementation, 
unless an overall management framework is assumed (and if such a 
framework is assumed, why not just assume, further, that the zone in 
question will be automatically deleted on all slaves when it is deleted 
on the master, thus rendering EXPIRE pointless and mooting the problem).

I can't comment intelligently on the DNSSEC solution, since, 
confessedly, I'm still somewhat of a DNSSEC neophyte. But, does the 
concept of "expire" in DNSSEC run parallel to the usual EXPIRE mechanism 
of "classical" DNS? Or does it override it?

As for the "expiry counter" idea, I like it, but to be perfectly honest, 
I don't know that either the immortality problem, or the N*EXPIRE issue, 
or both, can generate enough enthusiasm to get any traction for a 
protocol extension, at this time (given the other pressing DNS-security 
concerns at the moment).

               - Kevin

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Aug 2008 14:56:05 +1000

> protocol extension, at this time (given the other pressing DNS-security 

	The draft to describe this is written and posted.

	draft-andrews-dnsext-expire-00.txt

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Sun, 31 Aug 2008 07:25:23 +1000

>	* Don't reset the expire counter on refresh from peers only

I'd reset the expiry only after the successful transfer of an zone 
with an incremented serial number.  That would take care of loops.

>	* Use DNSSEC to make data go stale.

Don't do that.  Don't overload the meaning of the RRSIG temporal 
fields.  They are meant to protect the cryptography, not convey any 
meaning of the data.

At 1:00 -0400 8/21/08, Brian Dickson wrote:
>zone master should have the original TTL values from the SOA used for timers.

The problem is distinguishing between a master and a slave.

>within a period much shorter than the expiration period.

Many assumptions of that era no longer are valid. ;)

>than a small variation of expiraiton period.

Not necessarily.  There are applications of DNS on disjointed 
networks such as very remote places (which hardly exist anymore), 
sea-going vessels, inter-planetary applications.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.