Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

[Brian Dickson <[e-mail]>]

On Fri, Jun 17, 2011 at 11:41 AM, Edward Lewis <[e-mail]> wrote:
> At 11:02 -0400 6/17/11, Brian Dickson wrote:
>
>> IXFR does not need to be over UDP.
>
> The point is that IXFR can be over UDP, not that it could be over TCP.
>
>> If the IXFR query is sent over TCP, the answer will either be an IXFR
>> (for real), or an IXFR which includes the whole zone.
>
> I don't think there is an understanding of IXFR.  I'd suggest reading 1995
> again and checking it against your code.  Perhaps your code missed
> something.

I am pretty sure I didn't miss anything.

The point is, that there could be a situation, for a large zone, such that:
- IXFR over UDP is never possible (too much flux for the capacity of UDP)
- "real" IXFR might or might not be possible due to purging
- AXFR is orders of magnitude bigger (e.g. 10^4 or more) than IXFR

The "clever" trick of "AXFR" (IXFR fallback) being too big for UDP,
can't be used.

Either a protocol change (non-standard, or standards-based) between
the client is needed,
or the client is forced to be very unfriendly, and abort the IXFR if
it doesn't see its own Serial
as the second RR of the IXFR. Closing the TCP socket is the only
mechanism it would have to do that.

>> There are plenty of zones that require IXFR-ONLY in order to
>> efficiently and effectively process zone updates.
>>
>
> Can you give me an example how your implementation is less "efficient"
> without IXFR-only and how you would alter your implementation to make use of
> it.
>
> That would help establish a justification...

I'll do my best.

First, let's presume there's a non-trivial amount of IXFR needed, and
a non-trivial number of servers involved.

The smallest non-trivial arrangement that comes to mind is the following:
- 1 hidden master (source of truth, originator of all zone data)
- a set of distribution servers (hidden again, feeding non-hidden servers)
- authority servers to the world, who get their zones via XFR from the
distribution servers

This can be scaled upward by adding additional layers of distribution,
if needed.
Redundancy across multiple servers at each layer is presumed. (The
redundancy on the hidden master itself is out of scope.)

Now, presume some kind of command-and-control infrastructure,
directing/coordinating the activities and functions of the servers.
Call it the MCP (master control program).

And also presume some kind of mini-command-and-control scripting on
each of the non-hidden authority servers, i.e. for when they boot up.
Call it the bcp (boot control program).

Here's an example design:
The MCP keeps track of the current Hidden Master Serial Number (HMSN).
The MCP also keeps track of the Distribution Server Serial Numbers
(DSSN), along with the DS state (up/down/booting/whatever).
And the MCP keeps track of the Authority Server Serial Numbers (ASSN),
along with AS state (up/down/booting/whatever).

The MCP can tell each DS to purge its IXFR database.
The MCP keeps track of what DSSN's are available for IXFR on a
server-by-server basis.
Every time the HMSN changes, the MCP cycles through the currently "up"
DS's, telling all but the "next" one to purge.
Thus, if there are "X" number of DS's up, there are as many as X-1
different IXFR's possible, based on the respective DSSN's.

If an Authority Server is down for a relatively brief period of time
(crash/reboot), there is a good chance it can get itself up to date by
an IXFR-ONLY.
It "goes around the circle", in the reverse order, looking for the DS
that can give it an IXFR-ONLY to bring it current.
Once it goes once around the circle without succeeding, it falls back
to an AXFR.
If it takes less time to reboot than it takes for "X-1" serial number
changes, the IXFR-ONLY will be possible.

Similarly, the HM->DS updates can also be via IXFR-ONLY, possibly
involving the use of DS->DS IXFR-ONLY for scalability.

The overall objective is to reduce the probability of requiring an
AXFR to near zero, and to also limit the overhead in terms of IXFR
state needed to achieve this.
Removing AXFR from anywhere but the edge, under normal operational
conditions, is important for big zones that change frequently.

If it were not for IXFR-ONLY, there would be no "clean" way to do this
- since IXFR fallback to pseudo-AXFR would interfere with the
attempts.

Observation:
A query for "what SNs do you have available for IXFR" would be the
equivalent", or similarly, an "can you IXFR me SN foo" query would
also do the trick.

However, both of these are non-atomic and introduce race conditions.
An IXFR-ONLY is atomic - if it is possible, the IXFR occurs; if not,
it says so.

Doing two queries (with non-trivial (network + cpu) delay between a
"can you IXFR me SN foo", and an "IXFR foo"), means a "yes" followed
by an unexpected AXFR, is the race condition.

Brian