#55 Wrong order of OPT and TSIG records in the wire format using stream signing

[Klaus Malorny]

Hi Brian,

I found a subtle problem between TSIG.applyStream and Message.toWire. For normally TSIG signed messages, the Message.toWire method takes care that the OPT record is the last record in the Additional section, but ensures that it still positioned before the TSIG record, which is generated by this method in-place.

However, if the TSIG.applyStream method is used to generate a TSIG record, this record is simply added to the message. When in comes to the conversion to the wire format by Message.toWire, the toWire method is not aware that the message is actually signed and places the OPT record after the TSIG record in the binary representation. Besides the wrong placement, it may also break the signature itself, but dig/BIND at least barks about the protocol violation before performing the validation.

I am unsure what the best way is to solve the problem. One way could be to add even more "magic" during the wire conversion to identify and reorder the special OPT and TSIG records in the Additional section. Another way could be to make the Message.addRecord more intelligent to ensure the correct ordering of the records in the Additional section at any time (at least if the message has been constructed by dnsjava). The third solution could be to move more logic from the stream signing code into the toWire class, i.e. that the signing also happens there also for the streaming mode.

In general it is questionable whether there is a need to include OPT records in AXFR/IXFR (where my problem occurred), although BIND as a server does it. My current workaround is simply to suppress the generation of the OPT record.

[Brian Wellington]

I might be missing something here, but I don't think either of the first solutions would work, as they both would end up with an incorrect signature, as the signature would have been calculated before the OPT record was added.

I don't think there is any reason to include an OPT record in an AXFR/IXFR response.

[Ingo]

If you still think this is an issue/use case, please create a pull request on dnsjava's new home at Github: https://github.com/dnsjava/dnsjava