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