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@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus