[rssac-caucus] Opening RSSAC-002 for revision [AXFR]
Romeo Zwart
romeo.zwart at ripe.net
Tue Oct 20 16:58:22 UTC 2015
On 15/10/20 18:17 , Ray Bellis 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.
Please keep in mind that for this particular metric 'consistent results
across all operators' are not necessarily to be expected. As RSSAC-002
itself also explains, the goal of providing this metric was "to detect
any trends in the growth of the zone". Of course serious issues like
truncated zone files are a different thing altogether, but size
differences related to compression differences could occur.
Cheers,
Romeo
>
> Ray
>
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
>
More information about the rssac-caucus
mailing list