To the technical community: It was brought to our attention the particularity of the encoded representation of the .nz DNSKEY in a post to NZNOG (thanks to Andy Linton). Further investigation confirmed the encoding was unique among the DNSSEC-enabled TLDs. To provide a clear explanation, let's walk through the decoding of the root zone DNSKEY: . 107464 IN DNSKEY 257 3 8 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ) ; key id = 19036 . 107464 IN DNSKEY 256 3 8 ( AwEAAdNW7YIhcTdqXrzgZjJJ35VjAFT1ArvnhAzXDm7A uGxSQqmGBRmjJvBv0xS4gahB9mj6ekF0dVKoeZgLmNAj o8hj2JI7K281YTo2R5k3mKSc4hOCP55hR22r5hIsPJoT 19pv/VdZQfyTzZ96frQ16qRa9+/GSjzjtFfQv16FwE7R ) ; key id = 55231 The DNSKEY rdata is represented in BASE64, which once decoded, will provide the public component of the key used to generate signatures. According to RFC3110, the encoding for the key follows the structure below: ------------------------------------------------------------------------------ RSA Public KEY Resource Records RSA public keys are stored in the DNS as KEY RRs using algorithm number 5 [RFC2535]. The structure of the algorithm specific portion of the RDATA part of such RRs is as shown below. Field Size ----- ---- exponent length 1 or 3 octets (see text) exponent as specified by length field modulus remaining space ------------------------------------------------------------------------------- For the root zone DNSKEY with the SEP bit on, the decoding looks like dig dnskey . +short | grep '^257' | awk '{print $4}' | base64 -d | xxd -l 12 -b 0000000: 00000011 00000001 00000000 00000001 10101000 00000000 ...... 0000006: 00100000 10101001 01010101 01100110 10111010 01000010 .Uf.B where * exponent_length is the first byte (00000011). This indicates the next three bytes are the exponent. * exponent (00000001 00000000 00000001), which in decimal is 65537, the 4th number of Fermat. * modulus is represented by the rest of the data. The DNSKEY for .nz looks like nz. 3600 IN DNSKEY 257 3 8 ( BAABAAGwfTiEoh71o6S55+Mdy1qqVRnpKY1VHznrv+wx rPfvRGB5VivFFPFN+33fsaTxJQTceOtOna7IKxTffj6p bBG4a9vtk2FqF551IwXomKWJnzRVKqYzuAx+Os/5gLIN BH7+qRWAkJwCdQXIaJGyGmshkO5Ci5Ex5Cm3EZCeVrie 0fLI03Ufjuhi6IJ7gLzjEWw84faLIxWHEj8w0UVcXfaI 2VL0oUC/R+9RaO7BJKv93ZqoZhTOSg9nH51qfubbK6FM svOWEyVcUNE6NESYEbuCiUByKfxanvzzYUUCzmm+JwV7 7Ebj3XZSBnWnA2ylLXQ4+HD84rnqb1SgGXu9HZYn ) ; key id = 2517 nz. 3600 IN DNSKEY 256 3 8 ( BAABAAGD+q3p2XDCb6SvAbACB/NPdljxhpBx2O9ZnvF2 OYb6kViMJ5dgxYDcFtvL5RW31Bc7UDvseoQPUK1wora3 BtUTylo1xd5PN/lV600mrNGRxfmw77Hen/MXH5GQrjaj O+rFP1xce1/jdyvCciJzrYRcPL9p4c/eGoJK3ZMubiu1 OQ== ) ; key id = 27212 which once decoded, looks like dig dnskey nz +short | grep '^257' | awk '{print $4}' | base64 -d | xxd -l 12 -b 0000000: 00000100 00000000 00000001 00000000 00000001 10110000 ...... 0000006: 01111101 00111000 10000100 10100010 00011110 11110101 }8.... In this case, * exponent_length is the first byte (00000100), representing a decimal value of 4 * exponent covers the next four bytes (00000000 00000001 00000000 00000001), which converted to decimal is 65537. * modulus is represented by the rest of the bytes. The encoding for the .nz DNSKEY is different. According to RFC3110, Section 2 -------------------------------------------------------------------- Leading zero octets are prohibited in the exponent and modulus. -------------------------------------------------------------------- So the encoding being used is RFC non-compliant. We tracked down the issue to the PKCS#11 library recommended by the HSM manufacturer. Despite the wrong encoding, everything is working as far as we are aware, including validation using BIND 9.7 and Unbound 1.4.9, reinforcing the spirit of Postel's Law. Duane Wessels from Verisign reported our DNSKEYs cause some BIND utilities to generate different results: $ dig nz dnskey | grep 257 > nz.key $ dnssec-dsfromkey nz.key nz. IN DS 54026 8 1 CC0EFEDAA4AA09CFB05E72E765A97BD5A9BFD1FE nz. IN DS 54026 8 2 48B0A194EE26C9D59BCC683CBC7A3495BB0AAA51ECC75533DBC76408 F0F70458 where the DS records submitted to the root zone are nz. 6446 IN DS 2517 8 2 ( 02240B41DFDDAECA2D6227D75A3575D5BA2FD07E2157 7F1C506D98BE491D6FF3 ) nz. 6446 IN DS 2517 8 1 ( CB5F686CB7A500B344E33DBC5CA8183A4E5579EC ) Other tools such as Net::DNS or ldns-key2ds produce the expected output. We are currently deciding the best course of action to correct the wrong encoding, we'll keep you informed. Kind Regards, -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535