On 16-01-15 23:04, Bob Harold wrote: > 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
To clarify: A record with its CLASS set to ANY does *not* mean to delete/change the record in all available classes. Note that an XFR is encapsulated in SOA records that determine the zone name and class (see Figure 2). Only changes in the zone matching that name and class will be made. > confused? And everything in the zone must be in the same CLASS, so can > we drop the CLASS completely? Because everything in the zone must be in the same CLASS, we could drop it, bit we cam also reuse the CLASS field to introduce new functionality. That is what is being done here. Best regards, Matthijs > -- > Bob Harold > hostmaster, UMnet, ITcom > Information and Technology Services (ITS) > rharo...@umich.edu <mailto:rharo...@umich.edu> > 734-647-6524 desk > > On Fri, Jan 16, 2015 at 12:58 PM, Paul Vixie <p...@redbarn.org > <mailto:p...@redbarn.org>> wrote: > > > >> Olafur Gudmundsson <mailto: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 <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > > > > > _______________________________________________ > 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
