starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #10] [Client] NSEC3 validation not correctly implemented #305

New issue

Open

opened 2026-03-15 21:51:22 +03:00 by kerem · 7 comments

kerem commented

2026-03-15 21:51:22 +03:00

Owner

Originally created by @bluejekyll on GitHub (May 10, 2016).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/10

I don't think NSEC3 is necessarily something I want to support. I think there are probably better ways to support hiding the data in a zone. I'll post more on this in the future.

Originally created by @bluejekyll on GitHub (May 10, 2016). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/10 I don't think NSEC3 is necessarily something I want to support. I think there are probably better ways to support hiding the data in a zone. I'll post more on this in the future.

kerem added the

bug

crate:client

wontfix

labels

2026-03-15 21:51:22 +03:00

kerem commented

2026-03-15 21:51:33 +03:00

Author

Owner

@Timmmm commented on GitHub (Jul 11, 2016):

In what way is NSEC3 broken? I can't find any references to this other than Wikipedia saying

The proponents of DNSCurve argue that it is still easy to enumerate a zone protected by NSEC3 and present a proof of concept implementation. This attack could be mitigated by using more computationally intensive hash functions.

It appears to use brute force to crack the NSEC3 hashes though, which I wouldn't say makes it 'broken'.

@Timmmm commented on GitHub (Jul 11, 2016): In what way is NSEC3 broken? I can't find any references to this other than Wikipedia saying > The proponents of DNSCurve argue that it is still easy to enumerate a zone protected by NSEC3 and present [a proof of concept implementation](http://dnscurve.org/nsec3walker.html). This attack could be mitigated by using more computationally intensive hash functions. It appears to use brute force to crack the NSEC3 hashes though, which I wouldn't say makes it 'broken'.

kerem commented

2026-03-15 21:51:38 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jul 11, 2016):

Actually, I think you're reading more into this than I intended. My current implementation of NSEC3 is broken, and I currently don't plan on fixing it. Someone else is welcome to fix my algorithm (which I know is wrong) and fix, but I'm not sure I will.

As of now, I see other options as providing more benefit, and potentially fitting my needs better. For example, DNSCrypt can be used for private record lookups, which may obfuscate the need for NSEC3 all together. It doesn't fix it for public records, but if you really want NSEC3, do you really want public records?

I have also been thinking of some other additions to DNS that might make NSEC3 redundant as well, which I haven't thought through in enough detail yet, so I'll wait on sharing.

@bluejekyll commented on GitHub (Jul 11, 2016): Actually, I think you're reading more into this than I intended. My current implementation of NSEC3 is broken, and I currently don't plan on fixing it. Someone else is welcome to fix my algorithm (which I know is wrong) and fix, but I'm not sure I will. As of now, I see other options as providing more benefit, and potentially fitting my needs better. For example, DNSCrypt can be used for private record lookups, which may obfuscate the need for NSEC3 all together. It doesn't fix it for public records, but if you really want NSEC3, do you really want public records? I have also been thinking of some other additions to DNS that might make NSEC3 redundant as well, which I haven't thought through in enough detail yet, so I'll wait on sharing.

kerem commented

2026-03-15 21:51:43 +03:00

Author

Owner

@indolering commented on GitHub (Dec 3, 2016):

In what way is NSEC3 broken?

NSEC3 uses SHA1, very few iterations, and a single salt for the entire zone. It's not a problem if you sign your responses on-the-fly, but for offline signers it's basically a polite way of asking someone not to walk your zone.

DNSCrypt can be used for private record lookups, which may obfuscate the need for NSEC3 all together

DNSCrypt is not deployable, which is why DNS-over-HTTPS is a thing. Besides, VPNs are a better choice for network-level access control.

It doesn't fix it for public records

What? Online signers can just sign each NSEC3 response as it comes in. NSEC5 will remove the need to keep the ZSK around for signing NSEC3 responses....

but if you really want NSEC3, do you really want public records?

Do you really want to hand spammers a crawl file? You'll have to do it anyway, there is zero chance that the root TLDs will move to online signing of NSSEC5 responses.

@indolering commented on GitHub (Dec 3, 2016): > In what way is NSEC3 broken? NSEC3 uses SHA1, very few iterations, and a single salt for the entire zone. It's not a problem if you sign your responses on-the-fly, but for offline signers it's basically a polite way of asking someone not to walk your zone. > DNSCrypt can be used for private record lookups, which may obfuscate the need for NSEC3 all together DNSCrypt is not deployable, which is why DNS-over-HTTPS is a thing. Besides, VPNs are a better choice for network-level access control. > It doesn't fix it for public records What? Online signers can just sign each NSEC3 response as it comes in. NSEC5 will remove the need to keep the ZSK around for signing NSEC3 responses.... > but if you really want NSEC3, do you really want public records? Do you really want to hand spammers a crawl file? You'll have to do it anyway, there is zero chance that the root TLDs will move to online signing of NSSEC5 responses.

kerem commented

2026-03-15 21:51:49 +03:00

Author

Owner

@jedisct1 commented on GitHub (Dec 4, 2016):

DNSCrypt is not deployable

Why is it "not deployable"?

@jedisct1 commented on GitHub (Dec 4, 2016): > DNSCrypt is not deployable Why is it "not deployable"?

kerem commented

2026-03-15 21:51:54 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 5, 2016):

I seem to keep confusing people with this bug. I'll rename it. This is actually in reference to the TRust-DNS implementation of the NSEC3 validation code. Subsequently, after thinking about what NSEC3 is solving, I decided that I don't really see a need in implementing it myself, b/c if people are worried about privacy of the zone file, then they should probably use other mechanisms to hide it. There are many good recommendations in this thread to other options.

If someone else wants to take a stab at implementing validation for NSEC3, I'd gladly accept it.

@bluejekyll commented on GitHub (Dec 5, 2016): I seem to keep confusing people with this bug. I'll rename it. This is actually in reference to the TRust-DNS implementation of the NSEC3 validation code. Subsequently, after thinking about what NSEC3 is solving, I decided that I don't really see a need in implementing it myself, b/c if people are worried about privacy of the zone file, then they should probably use other mechanisms to hide it. There are many good recommendations in this thread to other options. If someone else wants to take a stab at implementing validation for NSEC3, I'd gladly accept it.

kerem commented

2026-03-15 21:51:59 +03:00

Author

Owner

@indolering commented on GitHub (Dec 6, 2016):

Why is it "not deployable"?

It simply tunnels information through DNS ports, which is based on the assumption that firewalls aren't checking to ensure that the data going through the DNS port is valid DNS traffic. This is why the DNS-over-HTTPS initiative was formed, since that would at least be vanilla HTTPS traffic.

It also has a non-nonsensical trust model. At best, it's good for providing privacy between the client and the resolver. That's fine if you control the entire stack, like OpenDNS, but it's not backwards compatible and still requires DNSSEC.

Subsequently, after thinking about what NSEC3 is solving, I decided that I don't really see a need in implementing it myself, b/c if people are worried about privacy of the zone file, then they should probably use other mechanisms to hide it.

There is no getting around NSEC3, it's required to validate responses from the root TLDs.

If someone else wants to take a stab at implementing validation for NSEC3, I'd gladly accept it.

👍

@indolering commented on GitHub (Dec 6, 2016): > Why is it "not deployable"? It simply tunnels information through DNS ports, which is based on the assumption that firewalls aren't checking to ensure that the data going through the DNS port is valid DNS traffic. This is why the DNS-over-HTTPS initiative was formed, since that would at least be vanilla HTTPS traffic. It also has a [non-nonsensical trust model](https://dankaminsky.com/2011/01/05/djb-ccc/). At best, it's good for providing privacy between the client and the resolver. That's fine if you control the entire stack, like OpenDNS, but it's not backwards compatible and still requires DNSSEC. > Subsequently, after thinking about what NSEC3 is solving, I decided that I don't really see a need in implementing it myself, b/c if people are worried about privacy of the zone file, then they should probably use other mechanisms to hide it. There is no getting around NSEC3, it's required to validate responses from the root TLDs. > If someone else wants to take a stab at implementing validation for NSEC3, I'd gladly accept it. :+1:

kerem commented

2026-03-15 21:52:04 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 6, 2016):

Here is my current broken implementation of NSEC3:

github.com/bluejekyll/trust-dns@2b705dc300/client/src/client/client.rs (L468)

Will save it here for posterity, as the old client may be removed, or become just a thin veneer on top of ClientFuture.

I'll say this, I read and reread the NSEC3 validation algorithm in the RFC (this was at least 6 months ago at this point), and I could not figure out for the life of me how it actually validated the negative response, i.e. it didn't make sense to me. NSEC is very straightforward and easy to implement. The NSEC3 record itself is properly constructed in TRust-DNS, just not the validation.

@bluejekyll commented on GitHub (Dec 6, 2016): Here is my current *broken* implementation of NSEC3: https://github.com/bluejekyll/trust-dns/blob/2b705dc3001c369cd75446996cc10c8f673a35c1/client/src/client/client.rs#L468 Will save it here for posterity, as the old client may be removed, or become just a thin veneer on top of ClientFuture. I'll say this, I read and reread the NSEC3 validation algorithm in the RFC (this was at least 6 months ago at this point), and I could not figure out for the life of me how it actually validated the negative response, i.e. it didn't make sense to me. NSEC is very straightforward and easy to implement. The NSEC3 record itself is properly constructed in TRust-DNS, just not the validation.

kerem referenced this issue

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

[PR #305] [CLOSED] (wip) use resolv_conf to parse resolv.conf files #1356