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

[Ray Bellis]

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