Subject: Re: [dnsext] AXFR Clarify -- open issue w/ 'zone loading'

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 07 Jan 2009 10:26:32 +0100

Hi Ed,

This rejection is based on the zone content in some way? Such that a
future retrieval of the same serial number would present the same data
and result in the same rejection?  What sort of rejection is under
consideration?

Best regards,
   Wouter

Edward Lewis wrote:
> To the below, I added this as a separate paragraph.
> 
> "If a server rejects data contained in an AXFR session, the server
> SHOULD remember the serial number and not attempt to retrieve the
> same zone version again."
> 
> (Yeah, a one sentance-er.  Didn't want to mess with Alfred's work. ;))
> 

--
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: Wed, 7 Jan 2009 08:44:57 -0500

Yes.  Rejection might be - form errors, syntax errors, lack of 
closing SOA, etc.

For the rest of this answer I'll define a few local variables.

Zone in publication (ZIP) = the version of the zone currently being 
used to answer queries.

Zone in transfer (ZIT) = the version of the zone that is either 
currently being transferred or has been entirely transferred but has 
not yet been pressed into publication.

ZIP(#) means ZIP with serial number #  (They are both arrays.)
ZIT(#) means ZIT with serial number #

Let's say the ZIP (1) has been running for some time and has an 
expiry timer remaining with 86400 seconds (1 day).  A ZIT emerges 
with serial #2.  It has problems, so the server decides to not 
publish ZIT(2).  ZIP(1) stays running for up to another day.

For the next few hours, the server keeps being informed of ZIT(2). 
As this version was once rejected, the server never asks it's AXFR 
client code to get the version.

Finally, the server learns of ZIT(3). That is retrieved, passes 
inspection (because in this version the admin has fixed the typo that 
caused the rejection) and becomes the new ZIP(3).

At 10:26 +0100 1/7/09, W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Ed,
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
>iEYEARECAAYFAklkdUgACgkQkDLqNwOhpPhn+QCglyH5AglxZmTp3sNDoBitBEy/
>z2oAnR2/knCo/PZTRwVONE2/zL+qtuTL
>=9BsD
>-----END PGP SIGNATURE-----

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 07 Jan 2009 15:25:46 +0100

Hi Ed,

Yes, I am with you here, but I think some errors may be more transient.
For example, form errors, lack of closing SOA, could be the result of
one implementation.  Now, the operator resets the AXFR server or deploys
other implementations in a load balancing setup.  The next notify for
ZIT(2) should not be ignored, but a transfer attempted.

Formerrors may even be mitigated by asking the next AXFR server in the
list of AXFR servers, whose implementation may be different or whose
data may not be corrupted.

A wildcarded DNAME for example, I agree is much more likely to be linked
to the serial number.

Best regards,
   Wouter

Edward Lewis wrote:
> Yes.  Rejection might be - form errors, syntax errors, lack of closing
> SOA, etc.
> 
> Zone in publication (ZIP) = the version of the zone currently being used
> to answer queries.
> 
> currently being transferred or has been entirely transferred but has not
> yet been pressed into publication.
> 
> Let's say the ZIP (1) has been running for some time and has an expiry
> timer remaining with 86400 seconds (1 day).  A ZIT emerges with serial
> #2.  It has problems, so the server decides to not publish ZIT(2). 
> ZIP(1) stays running for up to another day.
> 
> For the next few hours, the server keeps being informed of ZIT(2). As
> this version was once rejected, the server never asks it's AXFR client
> code to get the version.
>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Jan 2009 09:42:49 -0500

It comes down to ">" or ">="?

The problem is that as an AXFR client, the implementation of the 
remote isn't known.  Even differing network addresses may lead to the 
same (operating systems 101) process.  E.g., dual stack.

An open question to the group.  If you have rejected a certain 
ZIT(#), does repeated retrievals of a ZIT(#) cause harm?  Is there 
danger of a programmed infinite loop?  Will a buggy holder of ZIP(#) 
repeatedly tell a server that it has #, or is this done just once?

I am assuming that for any #, the zone is the same up and down, the 
only difference would be how an AXFR server is implemented.

Maliciously, can I throw a ton of NOTIFY(#) at servers to make them 
create TCP connections and request AXFR to a victim (tying up the TCP 
stack there)?  This is one reason I sided with > and not >= in the 
text.

At 15:25 +0100 1/7/09, W.C.A. Wijngaards wrote:
>iEYEARECAAYFAklku2oACgkQkDLqNwOhpPgYbACfY/MVBOUJSSlJsIGrHK62fNAt
>Z+EAoLLWS14CYzm4KC2g9nUqi+HR7hpo
>=LETJ

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 7 Jan 2009 16:12:06 +0100 (MEZ)

> A wildcarded DNAME for example, I agree is much more likely to be linked

I also agree with the details of the mechanism as described by Ed.
IMO, that was a detailed explication of the original text that

>>>>>  same zone version again."

However, even beyond what Wouter has mentioned above, there might be
more error types an AXFR client could suffer from, which should not
be blamed to the zone content, but to the server or "the network".

I suggest to distinguish error cases arguably due to problems with
zone content and other errors leading to a failure of the AXFR and
hence keeping the current 'ZIP' unchanged.  The 'wait for new S/N'
behavior seems to be appropriate only in the former case.
Arguably, that already was the intent of Ed's text, but it might be
useful to even better clarify that intent.
After reconsidering the terminology in the draft, it also seems
to be prudent to  s/server/AXFR client/g .

Let me try to synthesize the whole discussion into a revised sentence:

| "If an AXFR client rejects the zone data contained in an otherwise
|  successful AXFR session, it SHOULD remember the serial number and
|  not attempt to retrieve the same zone version again from the same
|  AXFR server."

Can we build consensus on that variant?

BTW:  I support proceeding to WGLC with the draft now, and in this
case, WG chairs please consider this comment as a first LC comment.

Best regards,
  Alfred.

>> ...

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 7 Jan 2009 16:25:10 +0100 (MEZ)

Ed,
sorry, my last message crossed with your's.

> stack there)?  This is one reason I sided with > and not >= in the

Well, the group of authoritative servers for a zone (== the NOTIFY
'domain') should normally be under a closed group of admins, and
'foreign' NOTIFYs should be ignored anyway.

Thus, the damage of following the 'schedule' parametrized in the
SOA data should be sufficient to pace down the AXFR traffic to a
tolerable rate.  From an operational point of view, it indeed might
be preferable to retain self-healing behavior within the group of
authoritative servers, in order to minimize the amount of operator
intervention needed for recovery in case of trouble; ideally, the
recovery action should remain confined to the site where the original
error has been introduced/caused.

Therefore, I recommend to not specify overly restrictive behavior.

Hopefully, the proposal for revised text in my previous message
should be enough to remind implementers of taking due care of error
scenarios.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Jan 2009 13:43:39 -0500

>|  not attempt to retrieve the same zone version again from the same

I'd like to call the group's attention to the last 4 words of Alfred's comment.

"the same AXFR server."

Do folks think that it is reasonable to determine that?  I mean, I 
have in the past had a single DNS process run on multiple IP 
addresses and made it appear to be multiple machines.  In another 
case "ns0.example.biz" had an A record of a machine in one room and a 
AAAA record of a machine in another room. ('ssh ns0.example.biz' did 
get me the wrong machine, yes, so I don't recommend doing that.)

More benignly, dual stacking in name servers will probably be all the 
rage soon.

That's why I wonder if you can spec out "the same AXFR server."

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 7 Jan 2009 21:52:25 +0100 (MEZ)

> At 16:12 +0100 1/7/09, Alfred Hönes wrote:
>
> Do folks think that it is reasonable to determine that?  I mean,
> I have in the past had a single DNS process run on multiple IP

Folks,

I did not envision a particular algorithm, simply a (perhaps
prioritized) list of possible AXFR servers for a zone which
the AXFR client is allowed to use.  Each entry in that list
constitutes a conceptional (candidate) AXFR server.
That will suffice.

Note #1: See the implementation note below for a sketch of details.

Note #2: A possible future "AXFR over SCTP" specification might
         leverage SCTP's built-in handling of multi-homing,
         in the sense you had in mind above.

The whole ruleset is intended to establish some kind of
'high water mark' for the workload on the authoritative servers
and the network components interconnecting them in the zone content
error case; in particular, it aims at setting some *finite* limit
if the zone content has gone bad (presumably by human error) --
no more, no less.
Thus, it is not of particular relevance if a single AXFR server
instance is tried, e.g., twice, due to dual-homing, instead of only
once.
The 'classicial' rules would have allowed (almost) indefinite
repetition.  *That* makes the difference!

Furthermore, usually the AXFR distribution graph for a zone will be
subject to configuration, not auto-dicovery.  Consequently, a zone
operator who bothers with his proven high error rate in producing
zone content (!) might only allow a restricted set of AXFR server
addresses (per zone) for a particular (slave) authoritative server,
if he wants to limit the number of AXFR trials even more.

To re-state: The above proposal was intended as an engineering
compromise, trying to find a balance between two goals in a manner
that can easily be specified and (hopefully) easily be implemented:
limiting useless traffic to some degree vs. better resilience, i.e.,
chance of automatic recovery if something unexpectedly runs havoc,
with less manual intervention at the AXFR client side.

Implementation note:

  The only client-side (per zone) state needed to implement this
  strategy literally would be one Serial proven as ill, and an
  'already tried' Boolean flag per candidate server.  On fully
  successful AXFR, reset all that stuff; on first-time error,
  set s/n and one flag; if needed set more flags for more failed
  attempts for the same s/n; if higher s/n becomes visible,
  again reset all stuff.

  That's a conceivable model, not intended to be included in the
  draft.  The message needed there simply is: reduce the number
  of nonsensical retries in cases where is is probable that
  tehse wouldn't help either; that's the externally visible
  behavior I propose to specify in the memo.

Kind regards,
  Alfred.

--

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Jan 2009 12:15:09 +1100

In message <a06240800c58a6df49732@[192.168.1.101]>, Edward Lewis writes:
> ZIT(#), does repeated retrievals of a ZIT(#) cause harm?

	No.  It will just waste bandwith and cpu cycles.

> Is there danger of a programmed infinite loop?

	No.

> Will a buggy holder of ZIP(#) repeatedly tell a server that it has #,
> or is this done just once?

	If the master side is buggy it can do anything :-)
	A conformant NOTIFY master will send NOTIFY messages when the
	zone changes and, optionally, when the server is started.
 
> stack there)?  This is one reason I sided with > and not >= in the 
 
	NOTIFY(#) does NOT trigger a AXFR.  It triggers SOA or IXFR
	queries.  It the SOA or IXFR processing indicate that a
	transfer is required then that will occur.

	A zone which has content which is rejected by the slave
	will be retried at retry interval and will expire after
	expire interval.

	I don't think it is worth designing something to optimise
	this very rare event.

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Jan 2009 08:30:13 -0500

>	transfer is required then that will occur.

Okay - a NOTIFY does not carry the serial number.  For the purposes 
of AXFR, read "NOTIFY(#)" as meaning "the NOTIFY server receives and 
responds to a NOTIFY, triggering an SOA query and getting a response 
with serial number #."  (Of course, an IXFR=ZIP(serial) could be 
sent, but this is AXFR clarify.)

Questions from that: An AXFR client is not activated unless the 
refresh/retry timer expires?  (From RFC 1996: "should behave as 
though the zone given in the QNAME had reached its REFRESH interval") 
Or is activated at start up(?)?

>	will be retried at retry interval and will expire after

What I am getting from this is - ">=".  But if the zone is rejected, 
it can't expire. ???

Is it safe to assume that if ZIP(#) is running, the AXFR client 
should never ask for serial number # again (modulo arithmetic and all 
that)?  If the previous ZIT(#) failed, it should ask for that # again 
(in a way following the same rules as is ZIP[#-delta] is running and 
no failed transfer ever happened before?)

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 08 Jan 2009 14:55:54 +0100

Hi Ed,

Edward Lewis wrote:
> Okay - a NOTIFY does not carry the serial number.  For the purposes of

A Notify can carry a serial number (the entire SOA RR in fact), or it
can not carry a serial number.

Even if it has a serial number, it triggers a SOA or IXFR query, and
later on AXFR may be done (if IXFR fails, SOA ok, etc).

Infinite loops in getting new zone information are not a problem.
Because the retry interval is set, this means that the axfr client will
not retry excessively.

Only if the axfr client is kicked into action by a notify, could it
retry excessively if it received excessive amounts of notifies.  This
could be viewed as a problem with notifies (use TSIG).  Or notifies for
a version could be ignored if ZIT(#) failed for it.  The discussion is
moving towards NOTIFY and IXFR ...  The action of doing an AXFR is thus
done?

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Jan 2009 10:12:20 -0500

>moving towards NOTIFY and IXFR ...  The action of doing an AXFR is thus

Yeah, all of the NOTIFY, IXFR concerns are out of scope for the draft 
but having the background is good.  The essential question is whether 
the text that Alfred suggested meets group consensus (which is, of 
course, for the chairs ultimately to judge and me, as editor, to 
record):

There are a few variations on the ending of this.  "The call on the 
field (American NFL sports reference)" is

- not attempt to retrieve the same zone version again from the same 
AXFR server."

alternates are

- attempt to retrieve the same zone version again from the same AXFR server."

IOW ">= and not >"

- not attempt to retrieve the same zone version again.

IOW "> globally"

So, it seems there is no danger in attempting to retry the transfer 
for the same version number, but even from the same source?

PS - I'll also s/successful/successfully completed/ in the sentence.

Is this a better version?

| "If an AXFR client rejects the zone data contained in an otherwise
|  successfully completed AXFR session, it SHOULD attempt to retrieve
|  the same zone version again."

"SHOULD" - "MAY" - ?

>iEYEARECAAYFAklmBeoACgkQkDLqNwOhpPjjXgCfUTsU8/1oprQ8Ul/SV+I8wQ9m
>/isAn0ASj/enYg9/nSi2cvOgbvUpichy
>=cbzO