[GH-ISSUE #200] DNSSEC Signature verification doesn't verify actual bytes received on the wire #390

New issue

Open

opened 2026-03-15 22:15:27 +03:00 by kerem · 2 comments

kerem commented

2026-03-15 22:15:27 +03:00

Owner

Originally created by @briansmith on GitHub (Sep 22, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/200

While working on PR #198, I noticed that signature verification doesn't operate on the bytes received on the wire. Instead, the message is parsed, then re-serialized, and then the signature is verified using the re-serialized version. This means that potentially bugs in the serialization logic could result in security issues, if an attacker can somehow get us to "fix" a bad value during the re-serialization.

Instead, the signature should be verified on the bytes received on the wire. In particular, the verify_message() function should go away, and the signature verification should be moved up the call chain to where the Message is initially constructed. Or, something like that; I admit I didn't read all this code carefully.

Originally created by @briansmith on GitHub (Sep 22, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/200 While working on PR #198, I noticed that signature verification doesn't operate on the bytes received on the wire. Instead, the message is parsed, then re-serialized, and then the signature is verified using the re-serialized version. This means that potentially bugs in the serialization logic could result in security issues, if an attacker can somehow get us to "fix" a bad value during the re-serialization. Instead, the signature should be verified on the bytes received on the wire. In particular, the `verify_message()` function should go away, and the signature verification should be moved up the call chain to where the `Message` is initially constructed. Or, something like that; I admit I didn't read all this code carefully.

kerem added the

bug

trust

crate:client

labels

2026-03-15 22:15:27 +03:00

kerem commented

2026-03-15 22:15:38 +03:00

Author

Owner

@bluejekyll commented on GitHub (Sep 23, 2017):

Nice catch.

@bluejekyll commented on GitHub (Sep 23, 2017): Nice catch.

kerem commented

2026-03-15 22:15:43 +03:00

Author

Owner

@briansmith commented on GitHub (Oct 2, 2017):

I looked into this. Basically, the signature is in a record that must be at the very end of the DNS message. Therefore, if we know the index i of the start of that signature record relative to the start of the whole message m, then it would be straightforward to verify the signature over &m[..i], or so. Doing this should make the resolver slightly faster and result in less heap churning (because there would be no malloc/free), but neither effect would be too notable. The main motivation for doing this is to reduce the attack surface for the signature verifier.

@briansmith commented on GitHub (Oct 2, 2017): I looked into this. Basically, the signature is in a record that must be at the very end of the DNS message. Therefore, if we know the index `i` of the start of that signature record relative to the start of the whole message `m`, then it would be straightforward to verify the signature over `&m[..i]`, or so. Doing this should make the resolver slightly faster and result in less heap churning (because there would be no malloc/free), but neither effect would be too notable. The main motivation for doing this is to reduce the attack surface for the signature verifier.

kerem referenced this issue

2026-03-16 02:04:35 +03:00

[PR #390] [CLOSED] Bump chrono from 0.4.1 to 0.4.2 #1402