Subject: Re: [dnsext] draft-kerr-ixfr-only-01

From: Alfred Hönes <[email-masked]>
Date: Fri, 21 May 2010 00:35:19 +0200 (MESZ)

Folks,
a simple, fundamental, provoking question, and follow-up considerations:

What is the real benefit of (server-side) IXFR fallback to AXFR at all?

A slave could easily decide to retry via AXFR, based on any
policy desired, if it always got an error response when IXFR
cannot be served.  The additional delay by this procedure
would be negligible vs. typical times for AXFR.

I.e.: Why not making IXFR-only the normal behavior for IXFR?

What do deployed secondaries in case all IXFR attempts fail
(with any error code)?
Do they fall back to AXFR (on the client side) anyway?

Please note that I already had mentioned twice on this list that
after axfr-clarify (now in RFC-EDITOR state) is out, significant
parts of RFC 1995 regarding AXFR will be moot anyway; this WG has
decided in Spring 2008 (IIRC) that AXFR MUST NOT happen over UDP;
RFC 1995 seems to request supporting that.  :-(

As already indicated, IMO a thorough revision of RFC 1995 should be
the pathway to hell to go; if it turns out that backward compatibility
requirements do not allow changing IXFR to IXFR-only behavior (at the
IXFR server), IXFR-ONLY could be defined in a single document with
IXFR, otherwise a standalone document would not be needed anyway.

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: Paul Vixie <[email-masked]>
Date: Thu, 20 May 2010 22:59:51 +0000

> From: Alfred Hönes <[email-masked]>
> Date: Fri, 21 May 2010 00:35:19 +0200 (MESZ)
> ...

because there's a degenerate case of single packet axfr (for very small
zones) that was thought interesting by the WG at the time of RFC 1995.

> Please note that I already had mentioned twice on this list that after
> axfr-clarify (now in RFC-EDITOR state) is out, significant parts of RFC
> 1995 regarding AXFR will be moot anyway; this WG has decided in Spring
> 2008 (IIRC) that AXFR MUST NOT happen over UDP; RFC 1995 seems to request
> supporting that.  :-(

good catch.

> IXFR, otherwise a standalone document would not be needed anyway.

i agree.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 May 2010 10:05:59 +1000

In message <[email-masked]>, Alfred =?hp-roman8?B?SM5uZXM=?= w
> What is the real benefit of (server-side) IXFR fallback to AXFR at all?

The master is the only entity in a position to determine which
response style is bigger.

Extra work for single masters and recovery from other events where
the history is not available.

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

---

From: Michael Graff <[email-masked]>
Date: Thu, 20 May 2010 19:27:49 -0500

> response style is bigger.

Bigger is not the only metric to determine which is better.

If there is only one master, then I suspect IXFR-only is a loss.  That's
not what this feature is intended for.  It's for complicated
configurations where you have more than one master and full deltas
between those masters are not available.  In that case, you want to try
both masters with IXFR before resorting to AXFR.

- --Michael

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 21 May 2010 12:35:07 +0900

A lfred;

> What is the real benefit of (server-side) IXFR fallback to AXFR at all?

Simplicity by ignoring performance loss in very rare cases.

But, the proper question is "what is the real benefit of ixfr-only"
and the answer is "nothing".

An IXFR client will receive AXFR from an IXFR server, if:

	1) the client has very old copy of a zone but the copy
	has not yet expired

or

	2) the server has recently received AXFR

or

	3) the server has condensed differences

1) is a rare case (unless the zone is very small or changes very
frequently, the copy should have been expired) and, it is likely
that the client won't be able to receive IXFR from any other
server (unless some servers have longer memory of difference
information than others and such servers are queried after less
capable servers, which is not a reasonable configuration of
clients) that there is no point to introduce complication
to try all the servers.

2) is even more rare case occurs only for a short period after
the server experienced case 1) *AND* the server is the first
available server chosen by the client, which means, is negligible.
It should be noted that the client should be configured to avoid
servers (at least as the first server to try) which has been down
for a very long period.

For 3), is condensation used by some?

Note also that, trying all the servers (including dead ones)
requires retries and time-out, which reduces the merit of
NOTIFY.

						Masataka Ohta

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 21 May 2010 08:35:25 +0200

+1

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 May 2010 09:48:28 -0300

> I.e.: Why not making IXFR-only the normal behavior for IXFR?

I can think of one reason not to pursue this to its (il)logical conclusion:

The very existence of code+servers that do IXFR->AXFR fallback,
means that the ONLY way to know for sure that an IXFR is IXFR-only,
is if IXFR-only (the present ID under discussion) becomes a new standard.

Updating the IXFR standard to say no fallback, could result in clients
thinking
IXFR means IXFR-only, while servers might still think fallback is okay.

Unless IXFR-only is adopted, in which case the other arguments about
reasons/benefits for fallback (even over UDP) are likely to prevail.

Brian

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 21 May 2010 20:37:00 +0200 (MESZ)

Mark Andrews wrote:
>
> In message <[email-masked]>, Alfred Hönes writes:
>> Folks,

Correct.

> the history is not available.

I fear you misunderstood me; I did not call for *unconditional*
IXFR, but asked for the reason(s) of *automatic* fallback to AXFR
*by the IXFR server*, i.e. why not sending an indication to the
IXFR client and let'm decide what he wants to do -- i.e. the idea
of IXFR-only.

> Mark

Mark,
I'm particularly interested in hints from you (or your colleagues)

Kind regards,
  Alfred.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 21 May 2010 15:32:45 -0400

At 13:59 -0500 5/21/10, Michael Graff wrote:

>The idea is you can shop around first, and if you can get an IXFR you go
>for that.  The assumption is that this shopping around consumes less
>resources or maintains a better service level in other ways than just
>falling back to AXFR on the first try.

Or, if you can't IXFR the zone, you just don't do an AXFR - e.g., 
instead you page for out-of-band intervention to use a file transfer 
mechanisms to get the zone file over the wire.

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

Discussing IPv4 address policy is like deciding what to eat on the Titanic.

---

From: Michael Graff <[email-masked]>
Date: Fri, 21 May 2010 13:59:26 -0500

>>> Do they fall back to AXFR (on the client side) anyway?

The short answer is yes, you would eventually have to fall back to AXFR.

- --Michael

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 22 May 2010 06:49:20 +0900

(2010/05/22 3:37), Alfred wrote:

> i.e. why not sending an indication to the

Because it means considerable amount of extra complexity *and*
delay for almost nothing.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Sat, 22 May 2010 11:03:29 +1000

In message <[email-masked]>, Alfred =?hp-roman8?B?SM5uZXM=?= w
rites:
> Mark Andrews wrote:
> >
> > In message <[email-masked]>, Alfred HÎnes writes:
> >> Folks,

You missed the point.  If you only have one master then IXFR-ONLY
is a complete waste of time.  Normal IXFR is what you want and that
includes fallback to AXFR by the master.

IXFR-ONLY, IXFR and AXFR all have their places and clients need to
choose which one they will use based on a number of factors.

I'm also at a loss to see why the WG accepted IXFR-ONLY but rejected
EDNS EXPIRE.  They are both things designed to support more complex
zone transfer graphs.

Mark

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 27 May 2010 10:31:33 +0200

On 21.5.2010 00:59, Paul Vixie wrote:
>> From: Alfred Hönes<[email-masked]>

I agree as well and would help to make that happen -> that means 
ixfr-clarify or IXFRbis RFC, am I right?

Brian's comment about client not knowing if the server is 
IXFRwithFallback or IXFRwithoutFallback is valid, but it's not big 
burden, because you have only limited set of masters and you have some 
contractual partnership with them, so you can ask them to upgrade their 
servers.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------