Subject: [dnsext] draft-kerr-ixfr-only-01, or something more general?

From: Joe Abley <[email-masked]>
Date: Tue, 25 May 2010 02:31:32 +0200

Hi all,

There are other potential extensions or modifications to IXFR/AXFR. Someone mentioned a use-case for IXFR-ONLY where a slave server might prefer some out-of-protocol synchronisation mechanism (e.g. rsync) in preference to an AXFR. I've heard musings before about the use of compression with zone transfers, of which there is more than one choice of algorithm. I've heard of people interested in confidentiality of zone transfers, and algorithm agility for encryption seems necessary if you're going support encryption at all.

Does it make sense to re-consider the trend of AXFR, IXFR, IXFR-ONLY and other future variants as separate QTYPEs, and instead consider a more general XFR QTYPE which is extensible? Perhaps something that supports some form of capability negotiation between master and slave? Something that would allow a client to express a richer set of desires than just "AXFR please", "IXFR please, but AXFR will do" or "IXFR only"?

This is not a new idea; I'm quite sure I heard it from someone else (but I forget who, or where, or when).

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 25 May 2010 13:27:15 +0900

(2010/05/25 9:31), Joe Abley wrote:

> I've heard of people interested in confidentiality of zone transfers,
> and algorithm agility for encryption seems necessary if you're going
> support encryption at all.

You had better work on confidentiality of DNSSEC.

							Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Tue, 25 May 2010 11:05:08 +0200

> You had better work on confidentiality of DNSSEC.

Thanks, I'll get right on that.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 May 2010 09:16:53 -0400

At 2:31 +0200 5/25/10, Joe Abley wrote:
>Hi all,
>
>There are other potential extensions or modifications to IXFR/AXFR. Someone
>mentioned a use-case for IXFR-ONLY where a slave server might prefer some
>out-of-protocol synchronisation mechanism (e.g. rsync) in preference to an
>AXFR. I've heard musings before about the use of compression with zone
>transfers, of which there is more than one choice of algorithm. I've heard
>of people interested in confidentiality of zone transfers, and algorithm
>agility for encryption seems necessary if you're going support encryption
>at all.

FWIW, I mentioned on the list the desire to use IXFR or out-of-band 
(but I won't claim it as my idea).

Before we get too excited about trying to capture all the tricks used 
or desired in operations, we don't have to document every possible 
way of transferring a zone - there's lots of other things that 
haven't been documented in DNS.  (Such as "split" or incoherent DNS.)

As far as "encrypting" zone transfers, I have one word "use VPNs."  (;))

>Does it make sense to re-consider the trend of AXFR, IXFR, IXFR-ONLY and
>other future variants as separate QTYPEs, and instead consider a more
>general XFR QTYPE which is extensible? Perhaps something that supports
>some form of capability negotiation between master and slave? Something
>that would allow a client to express a richer set of desires than just
>"AXFR please", "IXFR please, but AXFR will do" or "IXFR only"?

When it comes to operating zone transfers, which we do a lot of, 
there have been no "gee I wish the protocol would do this 
differently" moments.  XFRs are like babies - little bundles of joy 
that poop a lot in the diaper but still you wouldn't change a thing.

OTOH there is one desire that comes up from time to time to have a 
means of synthesizing answers on the fly in a manner richer than what 
wild cards offer.  The design bottleneck is the transfer of the 
synthesis rules.  (RXFR - Rules Transfer?)

>I forget who, or where, or when).

Probably Shakespeare.  Or Einstein.  Or Foghorn Leghorn.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Masataka Ohta <[email-masked]>
Date: Tue, 25 May 2010 22:47:27 +0900

> Thanks, I'll get right on that.

Good luck, you stupid.

						Masataka Ohta