<html><head></head><body>Bind8 used 16kbyte messages in axfr for exactly this reason. Bind9 should do the same.<br><br><div class="gmail_quote">On October 20, 2015 9:17:13 AM PDT, Ray Bellis <ray@isc.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 20/10/2015 16:50, Wessels, Duane wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> #3 Zone Size Metric<br /> ===================<br /> <br /> Problem:<br /> <br /> Section 2.2 describes how to calculate the zone size as a wire-format<br /> AXFR response. Since AXFR happens only over TCP, those DNS messages<br /> also have a two-octet length prefix. The description is unclear whether<br /> or not to include the two-octet length prefix in the reported value.<br /> <br /> Proposed Remedy:<br /> <br /> Amend the paragraph in section 2.2 to read:<br /> <br /> The size of the compiled root zone is measured in wire-format<br /> AXFR response encoded as if to be transmitted in the smallest<br /> number of messages with the names in the zone and the resource<br /> records in each RRset sorted into DNSSEC order, and using<br /> compression pointers wherev!
er
possible. Note that since AXFR<br /> occurs over TCP, this measurement must also include the two-octet<br /> size prefix for each message transmitted.<br /></blockquote><br />I wasn't around when this was first set, and I'm not so bothered about<br />the two byte per-message overhead, since there's no UDP to compare against.<br /><br />However - the current choice of using the 'smallest number of messages'<br />is curious, particularly in light of the text in the remained of section 2.2<br /><br />We've recently observed that AXFRs from RIPE's 'k' root are (sometimes?)<br />more than 10% shorter than those from our 'f' roots. I just ran a test<br />and got 619050 bytes from 'k' vs 696472 for 'f'.<br /><br />The reason is that compression pointers can only address the first 16kB<br />of any message. BIND defaults to 'smallest number of messages' by using<br />as much of the 64kB maximum as possible but the corollary is that 3/4 of<br />the data doesn't get compressed!
at
all.<br /><br />If the expectation is that operators will just perform an AXFR against<br />their servers and measure the bytes received, that clearly isn't going<br />to produce consistent results across all operators / implementations.<br /><br />Ray<br /><br /><hr /><br />rssac-caucus mailing list<br />rssac-caucus@icann.org<br /><a href="https://mm.icann.org/mailman/listinfo/rssac-caucus">https://mm.icann.org/mailman/listinfo/rssac-caucus</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>