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

[Romeo Zwart]

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
>