When experimenting with what would happen if we defined a well known TSIG key to provide a crypto hash for DNS/UDP to prevent fragmentation attacks being accepted it became clear that RFC2845 was not clear enough in error condition handling. See https://ednscomp.isc.org/compliance/alexa1m-tsig-wkk.txt for a summary of the results (this is being regenerated monthly).
The setting of the time fields on BADKEY is not well defined. We had implementations setting the values to zero. Handling of BADKEY with a bad time is also not handled well. I would recommend always copying the time fields from the request to the response for BADKEY and BADALG. This provides the client with some of off path spoof protection. The request’s algorithm field was not always copied to the response on BADKEY. There were various implementations that detected BADKEY but continued processing the query. NOERROR+BADKEY and REFUSED+BADKEY were seen. The ID field in the TSIG of the reply to a forwarded message is not well defined. i.e. should it be the original ID from the request’s TSIG or the ID of the forwarded message. While other data in the initial request is not expected with RFC2845 it should be hashed but otherwise ignored if non empty. There are also some STD13 issues see like returning FORMERR is not done by taking the query and setting the RCODE=FORMERR and setting QR=1. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
