On Fri, 2021-03-19 at 10:42 -0400, Ben Schwartz wrote: > Does anyone have an example of test vector presentation that they like? > Perhaps it should be structured as a pair of zone files representing the same > zone, one in SVCB format and one in RFC 3597.
tl;dr: +1 to that I recently implemented CSYNC in PowerDNS, and was greatly aided therein by RFC 7477 section 2.1.3, which I will quote here: === The following CSYNC RR shows an example entry for "example.com" that indicates the NS, A, and AAAA bits are set and should be processed by the parental agent for example.com. The parental agent should pull data only from a zone using a minimum SOA serial number of 66 (0x42 in hexadecimal). example.com. 3600 IN CSYNC 66 3 A NS AAAA The RDATA component of the example CSYNC RR would be encoded on the wire as follows: 0x00 0x00 0x00 0x42 (SOA Serial) 0x00 0x03 (Flags = immediate | soaminimum) 0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map) === In my case, I could take these hex octets, sprinkle in a few backslashes, and make the test case fit *our* codebase: test-dnsrecords_cc.cc: (CASE_S(QType::CSYNC, "66 3 A NS AAAA", "\x00\x00\x00\x42\x00\x03\x00\x04\x60\x00\x00\x08")) Ever since I've been wondering what the best format would be, though, so that vendors could exchange collections of test vectors. I already imagined OARC maintaining that collection even! I think your SVCB/3597 pairing might be that format. I know NLnetlabs and ISC have tools that can even generate the latter from the former (for supported types, of course), which makes testing and verifying implementations very easy if the RFC also shows that pair, and even allows users (and draft authors!) to do the same checks. The only thing I wonder about is whether we can combine the 3597 format with the 3 part breakdown 7477 did on the hexdump, which also is very educational. Of course, nothing prevents us from doing both the breakdown and a couple of 3597 pairings. So, +1 from me! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
