[DNSOP] TIMEOUT resource record RDATA format revisited

[Tom Pusateri <[e-mail]>]

DNSOP,
	It’s exciting to see some implementation experience in bind 9 by Mark Andrews for TIMEOUT records and during this process several issues have come up with the current use of RDATA as the method to match represented records. Thanks Mark for all the work and feedback so far!

1. Representing multiple records RDATA within another records RDATA is difficult in the presentation format. This happens when written to a zone file and read back in. Multiple TXT records RDATA following each other has been tricky.

2. This is compounded by lengthy and complicated security records for uses like ACME and domain keys which are both time limited and potential uses of TIMEOUT records.

3. Creating TIMEOUT records and sending them with the nsupdate utility is also challenging with the RDATA method.

4. There is the (theoretical) possibility that a record already has max length. In this case it couldn’t be represented in a TIMEOUT record.

In the initial version, we used a HASH in the TIMEOUT RDATA to represent the records and it was suggested to fallback to the RDATA because the HASH was a “premature optimization”. This was good advice and we followed it. But now with the experience we feel the HASH optimization is no longer premature but appropriate and would like to change the TIMEOUT RDATA format back to a HASH. The HASH also has the advantage of being a fixed length per record which is nicer for parsing and presenting in zone files.

This time we are suggesting using the first 128 bits of SHA256 (instead of SHAKE128) due to the overwhelming request for this change earlier. Having talked to some security experts, we now feel comfortable with using only a portion of the calculated HASH without fear of collisions. This makes it the same length as an IPv6 address RDATA.

It was suggested that we include both methods (RDATA and HASH) but we would prefer to only have a single method in order that we don’t run into problems with capability differences between primary and secondary servers.

So hopefully everyone will approve of this change. If you have feedback one way or the other, we’d love to hear it.

Thanks,
Tom & Tim