[GH-ISSUE #1981] Unsigned response to TSIG request with unknown key is not handled correctly #838

New issue

Open

opened 2026-03-16 00:30:12 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 00:30:12 +03:00

Owner

Originally created by @lrsksr on GitHub (Jun 28, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1981

Describe the bug
Per RFC2845 Section 4.3 and 4.5.1 an authoritative DNS server must respond with an unsigned TSIG response when the request key can not be recognized.
When trust-dns-client is confronted with this RFC-conform behavior, it throws a ProtoError with message "signature is not tsig". However, the actual response has the REFUSED bit set, which makes sense since the key could not be recognized.

To Reproduce

Send a TSIG dnsupdate request to a PowerDNS or other RFC-conform server with a key that it does not know

Expected behavior
The error message should say that the update was refused instead of complaining about the response not being signed as per the RFC.

System:
Not applicable

Version:
Crate: trust-dns-client (actually trust-dns-proto)
Version: 0.22.0

Additional context
Add any other context about the problem here.

Originally created by @lrsksr on GitHub (Jun 28, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1981 **Describe the bug** Per [RFC2845 Section 4.3 and 4.5.1](https://datatracker.ietf.org/doc/html/rfc2845#autoid-4) an authoritative DNS server must respond with an unsigned TSIG response when the request key can not be recognized. When trust-dns-client is confronted with this RFC-conform behavior, it throws a ProtoError with message "signature is not tsig". However, the actual response has the REFUSED bit set, which makes sense since the key could not be recognized. **To Reproduce** 1. Send a TSIG dnsupdate request to a PowerDNS or other RFC-conform server with a key that it does not know **Expected behavior** The error message should say that the update was refused instead of complaining about the response not being signed as per the RFC. **System:** Not applicable **Version:** Crate: trust-dns-client (actually trust-dns-proto) Version: 0.22.0 **Additional context** Add any other context about the problem here.

kerem added the

crate:proto

compliance

feature:tsig

labels

2026-03-16 00:30:12 +03:00

kerem commented

2026-03-16 00:30:23 +03:00

Author

Owner

@djc commented on GitHub (Jun 29, 2023):

Thanks for the report. Would you be able to submit a PR for this?

@djc commented on GitHub (Jun 29, 2023): Thanks for the report. Would you be able to submit a PR for this?

kerem commented

2026-03-16 00:30:28 +03:00

Author

Owner

@jcgruenhage commented on GitHub (Jun 29, 2023):

Improvements in this area in the near future contributed by us seem unlikely due to the complexity of the problem and our current time constraints. Fortunately, this bug only occurs when there is a misconfiguration, so it is not causing any major roadblocks. However, diagnosing the issue becomes challenging without utilizing a network analyzer to examine the DNS traffic directly. It would be beneficial to have a more informative error message from trust-dns-proto, but upon initial inspection of the code, it appears that we lack sufficient understanding of the internal workings of trust-dns-proto to address this at the moment.

@jcgruenhage commented on GitHub (Jun 29, 2023): Improvements in this area in the near future contributed by us seem unlikely due to the complexity of the problem and our current time constraints. Fortunately, this bug only occurs when there is a misconfiguration, so it is not causing any major roadblocks. However, diagnosing the issue becomes challenging without utilizing a network analyzer to examine the DNS traffic directly. It would be beneficial to have a more informative error message from trust-dns-proto, but upon initial inspection of the code, it appears that we lack sufficient understanding of the internal workings of trust-dns-proto to address this at the moment.

kerem commented

2026-03-16 00:30:34 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 29, 2023):

Thanks for reporting this. I don't think it will be hard to fix and it should be easy to add a test case for this to ensure conformance.

@bluejekyll commented on GitHub (Jun 29, 2023): Thanks for reporting this. I don't think it will be hard to fix and it should be easy to add a test case for this to ensure conformance.

kerem commented

2026-03-16 00:30:39 +03:00

Author

Owner

@jcgruenhage commented on GitHub (Jun 29, 2023):

It's very possible for this to be actually fairly easy, but @lrsksr and I sat over the code for a bit trying to understand what's even happening and then decided that we're not familiar enough with the low level bits and pieces in there to come up with a PR just yet.

@jcgruenhage commented on GitHub (Jun 29, 2023): It's very possible for this to be actually fairly easy, but @lrsksr and I sat over the code for a bit trying to understand what's even happening and then decided that we're not familiar enough with the low level bits and pieces in there to come up with a PR just yet.

kerem referenced this issue

2026-03-16 02:22:13 +03:00

[PR #838] [CLOSED] Bump http from 0.1.17 to 0.1.18 #1730