[GH-ISSUE #346] Validate all incoming data before caching or forwarding it #452

New issue

Open

opened 2026-03-15 22:32:54 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 22:32:54 +03:00

Owner

Originally created by @DemiMarie on GitHub (Feb 18, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/346

trust-dns should validate all incoming data before caching or forwarding it. That means:

checking that the data is syntactically correct
checking that the data is semantically well-formed
checking DNSSEC signatures, if enabled

Furthermore, trust-dns should drop all non-conforming input, and ensure that all output is conforming. This helps prevent attacks as CVE-2015-7547 (glibc getaddrinfo RCE) when trust-dns is used e.g. as the DNS server for a LAN.

Originally created by @DemiMarie on GitHub (Feb 18, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/346 trust-dns should validate all incoming data before caching or forwarding it. That means: - checking that the data is syntactically correct - checking that the data is semantically well-formed - checking DNSSEC signatures, if enabled Furthermore, trust-dns should drop all non-conforming input, and ensure that all output is conforming. This helps prevent attacks as CVE-2015-7547 (glibc getaddrinfo RCE) when trust-dns is used e.g. as the DNS server for a LAN.

kerem added the

trust

crate:server

docs

labels

2026-03-15 22:32:54 +03:00

kerem commented

2026-03-15 22:33:05 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 18, 2018):

Is it the server which is not currently doing this? I believe both the client and resolver meet all of these requirements.

I haven't yet built any forwarding features into the server, yet.

@bluejekyll commented on GitHub (Feb 18, 2018): Is it the server which is not currently doing this? I believe both the client and resolver meet all of these requirements. I haven't yet built any forwarding features into the server, yet.

kerem commented

2026-03-15 22:33:10 +03:00

Author

Owner

@DemiMarie commented on GitHub (Feb 18, 2018):

This (along with the other two issues I just raised) are more abstract principles, but yes I was referring to the Server. I was hoping that trust-dns could be used as a replacement for the insecure BIND and for djbdns, which is very secure (only one vulnerability ever discovered, and that only affected 32-bit systems), but is unmaintained (requiring 3rd party patches to support IPv6 and DNSSEC). Furthermore, I hope that trust-dns could be used as a forwarding server that essentially functions as a DNS firewall, protecting less secure systems. For example, the aforementioned glibc bug could only be exploited by malformed records, if I understand correctly.

To be clear, this involves more than what most DNS servers do; those would not have protected against the glibc bug.

@DemiMarie commented on GitHub (Feb 18, 2018): This (along with the other two issues I just raised) are more abstract principles, but yes I was referring to the Server. I was hoping that trust-dns could be used as a replacement for the insecure BIND and for djbdns, which is very secure (only one vulnerability ever discovered, and that only affected 32-bit systems), but is unmaintained (requiring 3rd party patches to support IPv6 and DNSSEC). Furthermore, I hope that trust-dns could be used as a forwarding server that essentially functions as a DNS firewall, protecting less secure systems. For example, the aforementioned glibc bug could only be exploited by malformed records, if I understand correctly. To be clear, this involves more than what most DNS servers do; those would not have protected against the glibc bug.

kerem commented

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

Author

Owner

@bluejekyll commented on GitHub (Feb 18, 2018):

Yes, this is a goal of mine as well. I have plans to build forwarding features into the Server, by way of incorporating the Resolver. I haven't started on that work. As an authority though, I think it meets the goals listed above.

The Resolver also implements all of those, so once forwarding is implemented, then a forwarding server should meet all of these requirements.

@bluejekyll commented on GitHub (Feb 18, 2018): Yes, this is a goal of mine as well. I have plans to build forwarding features into the Server, by way of incorporating the Resolver. I haven't started on that work. As an authority though, I think it meets the goals listed above. The Resolver also implements all of those, so once forwarding is implemented, then a forwarding server should meet all of these requirements.

kerem referenced this issue

2026-03-16 02:07:02 +03:00

[PR #452] [CLOSED] Bump serde from 1.0.45 to 1.0.47 #1448