> On Jan 15, 2015, at 1:33 PM, 神明達哉 <jin...@wide.ad.jp> wrote: > Jinmei, thank you for your good comments.
> At Thu, 15 Jan 2015 11:13:10 +0100, > Matthijs Mekking <matth...@pletterpet.nl> wrote: > >> IXFR with DNSSEC is suddenly not so small anymore. Do you recognize >> this? Olafur and I have some ideas on keeping those zone transfers >> small. Your feedback is appreciated. >> >> http://www.ietf.org/internet-drafts/draft-mekking-mixfr-01.txt > > I see the motivation, and the proposed approach of MIXFR may make > sense. But, just like for any kind of optimization ideas, I would > wonder whether this could be a premature one. Do you have any > measurement of the effect of this idea? This is a real good point, I would hope we (or others) have some information on that before we standardize, right now this just an idea to discuss. The quick back of the envelope calculations say 30-45% for DNSSEC signed zones, that are just being resigned. The milage on other operations my differ. This begs the question what is the best way to measure? > On the draft text (also related to this higher level point): > > The goal of this proposal is to allow small changes to be > communicated over UDP, and remove as much redundant information from > the zone transfer as possible. > > We still need to send new RRSIGs, and since the main concern is the > size of them (whether they are to be removed or added), I guess > sending a non-negligible number of RRSIGs could easily require TCP, > even if we can omit a half of them. So I'm not sure how often we can > avoid falling back to TCP (M)IXFR thanks to this in practice. Again, > some actual measurement or at least a quantitative analysis may help. > not sending the OLD RRsig’s is a big savings on its own, in particular when people use large RSA keys. Close to 50% when all you are just refreshing a signature on a one or two RRsets. > Regarding Section 5 (IXFR Gone Wild: Even more optimized transfers): > if we go this far, I wonder whether we might just use generic and more > efficient compression and exchange compressed data. > One of the oldest ideas on that was from Andreas Gustafsson was to wrap XFR transmission inside compressed transmission. But the biggest reason not to do compression is that RRSIG rdata is not compressible. 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. Olafur _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
