[rssac-caucus] Opening RSSAC-002 for revision [AXFR]
P Vixie
paul at redbarn.org
Tue Oct 20 17:34:10 UTC 2015
Bind8 used 16kbyte messages in axfr for exactly this reason. Bind9 should do the same.
On October 20, 2015 9:17:13 AM PDT, Ray Bellis <ray at isc.org> wrote:
>On 20/10/2015 16:50, Wessels, Duane wrote:
>
>> #3 Zone Size Metric
>> ===================
>>
>> Problem:
>>
>> Section 2.2 describes how to calculate the zone size as a
>wire-format
>> AXFR response. Since AXFR happens only over TCP, those DNS messages
>> also have a two-octet length prefix. The description is unclear
>whether
>> or not to include the two-octet length prefix in the reported value.
>>
>> Proposed Remedy:
>>
>> Amend the paragraph in section 2.2 to read:
>>
>> The size of the compiled root zone is measured in wire-format
>> AXFR response encoded as if to be transmitted in the smallest
>> number of messages with the names in the zone and the resource
>> records in each RRset sorted into DNSSEC order, and using
>> compression pointers wherever possible. Note that since AXFR
>> occurs over TCP, this measurement must also include the two-octet
>> size prefix for each message transmitted.
>
>I wasn't around when this was first set, and I'm not so bothered about
>the two byte per-message overhead, since there's no UDP to compare
>against.
>
>However - the current choice of using the 'smallest number of messages'
>is curious, particularly in light of the text in the remained of
>section 2.2
>
>We've recently observed that AXFRs from RIPE's 'k' root are
>(sometimes?)
>more than 10% shorter than those from our 'f' roots. I just ran a test
>and got 619050 bytes from 'k' vs 696472 for 'f'.
>
>The reason is that compression pointers can only address the first 16kB
>of any message. BIND defaults to 'smallest number of messages' by
>using
>as much of the 64kB maximum as possible but the corollary is that 3/4
>of
>the data doesn't get compressed at all.
>
>If the expectation is that operators will just perform an AXFR against
>their servers and measure the bytes received, that clearly isn't going
>to produce consistent results across all operators / implementations.
>
>Ray
>
>_______________________________________________
>rssac-caucus mailing list
>rssac-caucus at icann.org
>https://mm.icann.org/mailman/listinfo/rssac-caucus
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20151020/1bdc73c6/attachment.html>
More information about the rssac-caucus
mailing list