On Tue, 20 Oct 2015 18:18:54 -0000, P Vixie wrote:
"To my reading that very much looks like an expectation of consistent results across all operators."
Yes.
On October 20, 2015 11:08:11 AM PDT, Ray Bellis <ray@isc.org> wrote:
On 20/10/2015 17:58, Romeo Zwart wrote:
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.
In between the text Duane quoted, and what you've quoted above, RSSAC002 says:
"The size of the compiled root zone is not expected to change from operator to operator; but in an effort to ensure consistency in the root system all operators should report the size of the root zone so if there are any differe! nces that are seen on the platform they can be identified and remedied."
To my reading that very much looks like an expectation of consistent results across all operators.
To be fair, if everyone _emulated_ an AXFR using the given parameters, that's what you'd get, but if you perform a real AXFR and measure the results, you probably won't.
FWIW, I endorse the later suggestion that the measurement should be made on the *uncompressed* zone post AXFR.
To pick up at the end of this thread, what I'm hearing is: current goal A: "ensure consistency in the root system all operators should report the size of the root zone so if there are any differences that are seen on the platform they can be identified and remedied." current method A: report zone transfer size. But the problem Duane reported at the start of this thread is: transfer size is unclearly specified, so it's not consistent across letters. Various people have proposed tightening the definition, the limit of which is: proposed method B: basically do exactly what bind8 does, and anything else is a bug. That path WILL succeed in getting consistency across letters. I have nothing against bind8, but I think we've failed to accomplish the actual goal, because: "same size" != "no differences in contents". Given known attacks on md5 and threats on sha1, even some cryptographic hashes don't prove consistency. There seems little benefit (and non-zero cost!) to going to great lengths to get an perfect number, when it won't actually answer the question (!). I suggest we need to align our technical methods with the question we're asking. Perhaps either: new goal C: each root should detect changes in its trend of size. new method C: each letter should report zone transfer size consistently across its reporting (but not necessarily across other letters) OR old goal D: Each letter should guarantee consistency of the zone contents against the master copy. new method D: some cryptographic checksum on a precisely specified input that produces a result that actually proves goal D. But let's not incrementally create something that splits the difference, lest we build the worlds most carefully engineered, Stradivarius-esque ukulele. -John Heidemann