[rssac-caucus] Opening RSSAC-002 for revision [AXFR]

[P Vixie]

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>