There seem to be a lot of "set CLASS to ANY" in the spec. But I thought that a.b.c class IN was totally unrelated to a.b.c class CHAOS, and deleting or changing one should not affect the other. Or am I confused? And everything in the zone must be in the same CLASS, so can we drop the CLASS completely?
-- Bob Harold hostmaster, UMnet, ITcom Information and Technology Services (ITS) rharo...@umich.edu 734-647-6524 desk On Fri, Jan 16, 2015 at 12:58 PM, Paul Vixie <p...@redbarn.org> wrote: > > > Olafur Gudmundsson <o...@ogud.com> > Friday, January 16, 2015 7:51 AM > ... > > One of the oldest ideas on that was from Andreas Gustafsson was to wrap > XFR transmission inside compressed transmission. > > > late BIND4 and early BIND8 had something called ZXFR that did this. it > never worked out of the box, but frederico neves in brazil fixed it and had > it running in production for his inter-site synchronization some time in > the mid/late 1990's. it's worth asking him if it was worthwhile (noting, > this was before incompressible DNSSEC signatures were added.) > > on the topic of this draft, the current IXFR encoding requires > transmitting the old RRsets, which in the case of DNSSEC are large. the > benefit of this is that it provides extra assurance of synchronization -- > if the receiver does not have the old RRsets then we know that IXFR can't > work, and AXFR is tried. > > my proposal at the time IXFR was being worked on back in DNSEXT was to use > the UPDATE encoding, which allows RRset deletion or replacement without > transmitting the old RRset. i still think that's a good plan, and if... > > I have a much more radical zone transfer proposal in the works that is over > persistent TCP > connections and that is ripe for secured and compressed transmission. > > > ...if we were going to do zone synchronization over a persistent TCP > session, then i would recommend once again the UPDATE encoding for the > individual deltas. > > -- > Paul Vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
