starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #53] [Server] ResponseCode for NSEC on non-existent RecordType should be NoError #35

New issue

Closed

opened 2026-03-07 22:18:12 +03:00 by kerem · 6 comments

kerem commented

2026-03-07 22:18:12 +03:00

Owner

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

It appears that NSEC records returned from other servers (google) respond with NoError rather than NxDomain. It's possible that the TRust-DNS server is also responding incorrectly to standard queries on overlapping names, but no matching RecordType as well.

This should be validated in the RFCs. NSEC validation on the clientside is fuctioning appropriately.

Originally created by @bluejekyll on GitHub (Oct 17, 2016). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/53 It appears that NSEC records returned from other servers (google) respond with NoError rather than NxDomain. It's possible that the TRust-DNS server is also responding incorrectly to standard queries on overlapping names, but no matching RecordType as well. This should be validated in the RFCs. NSEC validation on the clientside is fuctioning appropriately.

kerem

2026-03-07 22:18:12 +03:00

closed this issue
added the
bug

unclear

crate:server
labels

kerem commented

2026-03-07 22:18:13 +03:00

Author

Owner

@Darkspirit commented on GitHub (Sep 25, 2017):

@bluejekyll

It's possible that the TRust-DNS server is also responding incorrectly to standard queries on overlapping names, but no matching RecordType as well.

from http://dnsviz.net :

example.com/AAAA: The server returned a no error (NOERROR) response when queried for example.com having record data of type AAAA, but returned a name error (NXDOMAIN) when queried for example.com having record data of type CNAME. (<IPv6 address>, UDP_0_EDNS0_32768_4096)

@Darkspirit commented on GitHub (Sep 25, 2017): @bluejekyll > It's possible that the TRust-DNS server is also responding incorrectly to standard queries on overlapping names, but no matching RecordType as well. from http://dnsviz.net : > example.com/AAAA: The server returned a no error (NOERROR) response when queried for example.com having record data of type AAAA, but returned a name error (NXDOMAIN) when queried for example.com having record data of type CNAME. (\<IPv6 address\>, UDP_0_EDNS0_32768_4096)

kerem commented

2026-03-07 22:18:13 +03:00

Author

Owner

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

I recently had a chance to review some of the additional RFCs on this. When requesting DNSSec responses, a properly signed negative response should contain only NSEC records, and return a NoError response code.

The TRust-DNS server currently is doing the wrong thing by returning NSEC records and an NxDomain. The Resolver/Client I believe is doing the correct thing in either case, only caching when there it is either not validating DNSSec or caching only in the NoError w/NSEC records case. (NSEC3 is currently not supported).

Is this causing you any specific issues?

@bluejekyll commented on GitHub (Sep 25, 2017): I recently had a chance to review some of the additional RFCs on this. When requesting DNSSec responses, a properly signed negative response should contain only NSEC records, and return a NoError response code. The TRust-DNS server currently is doing the wrong thing by returning NSEC records and an NxDomain. The Resolver/Client I believe is doing the correct thing in either case, only caching when there it is either not validating DNSSec or caching only in the NoError w/NSEC records case. (NSEC3 is currently not supported). Is this causing you any specific issues?

kerem commented

2026-03-07 22:18:13 +03:00

Author

Owner

@Darkspirit commented on GitHub (Sep 25, 2017):

No I think this wasn't related to NSEC, but only to the quoted sentence from you.
I think dnsviz wanted to say that when "AAAA example.com" exists, (the missing) "CNAME example.com" can't be NXDOMAIN and should get a different error code?

(Edit: I don't know what I'm talking about. My comment was cheeky, sorry. I should have said: "I don't understand what you say about NSEC, I only understood that one sentence from you I cited.")

@Darkspirit commented on GitHub (Sep 25, 2017): No I think this wasn't related to NSEC, but only to the quoted sentence from you. I think dnsviz wanted to say that when "AAAA example.com" exists, (the missing) "CNAME example.com" can't be NXDOMAIN and should get a different error code? (**Edit**: I don't know what I'm talking about. My comment was cheeky, sorry. I should have said: "I don't understand what you say about NSEC, I only understood that one sentence from you I cited.")

kerem commented

2026-03-07 22:18:13 +03:00

Author

Owner

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

Well, specifically for the query on CNAME at example.com, this would be an error in the zone setup. CNAMEs should not be stored at the SOA, so that's a configuration the DNS authority shouldn't allow, and a resolver should probably ignore... It's actually not at all clear to me what the response code should be in that case.

CNAME: https://tools.ietf.org/html/rfc1912#section-2.4

relevant rfcs to negative caching:

negative caching: https://tools.ietf.org/html/rfc2308
nsdomain: https://tools.ietf.org/html/rfc8020
Aggressive use of NSEC (draft): https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-04#section-5.1

@bluejekyll commented on GitHub (Sep 25, 2017): Well, specifically for the query on CNAME at example.com, this would be an error in the zone setup. CNAMEs should not be stored at the SOA, so that's a configuration the DNS authority shouldn't allow, and a resolver should probably ignore... It's actually not at all clear to me what the response code should be in that case. CNAME: https://tools.ietf.org/html/rfc1912#section-2.4 relevant rfcs to negative caching: negative caching: https://tools.ietf.org/html/rfc2308 nsdomain: https://tools.ietf.org/html/rfc8020 Aggressive use of NSEC (draft): https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-04#section-5.1

kerem commented

2026-03-07 22:18:14 +03:00

Author

Owner

@Darkspirit commented on GitHub (Oct 18, 2017):

With Ed25519 and P-384 I have the following behavior:
On Android I could make one connection to dev.terrax.net. Reloading the page brought a connection error. I had to restart Firefox to be able to visit the web site again (for one page view).
On a freshly booted Windows I was also able to make one connection (with multiple subrequests) to https://dev.terrax.net , but not after restarting Edge or when trying with Firefox afterwards.
I do not have these problems with my local Unbound on Debian Testing.

So I set up https://dev2.terrax.net (which is handled by powerdns) and it works.

from you:

It's possible that the TRust-DNS server is also responding incorrectly to standard queries on overlapping names, but no matching RecordType as well.

from dnsviz:

dev.terrax.net/AAAA: The server returned a no error (NOERROR) response when queried for dev.terrax.net having record data of type AAAA, but returned a name error (NXDOMAIN) when queried for dev.terrax.net having record data of type A. (2a01:4f8:c0c:2c12::50, UDP_0_EDNS0_32768_4096)

I assume Windows first requests the AAAA record and I can make one connection, then it requests the A record, gets NXDOMAIN as response and does negative caching? (I don't exactly know what I'm talking about and I want to apologize for this. I may be totally wrong.)

https://dev.terrax.net

IPv6-only (maybe this is a problem of its own?) trust-dns-server (fresh compiled from master and now with P-384 to reduce warnings): http://dnsviz.net/d/dev.terrax.net/dnssec/
IPv6-only HTTPS: https://www.hardenize.com/report/dev.terrax.net#www_https

https://dev2.terrax.net

Dualstack PowerDNS
IPv6-only HTTPS: https://www.hardenize.com/report/dev2.terrax.net#www_https

Both domains are pointing to the same IPv6 address with one certificate having two SAN entries.

@Darkspirit commented on GitHub (Oct 18, 2017): With Ed25519 and P-384 I have the following behavior: On Android I could make one connection to dev.terrax.net. Reloading the page brought a connection error. I had to restart Firefox to be able to visit the web site again (for one page view). On a freshly booted Windows I was also able to make one connection (with multiple subrequests) to https://dev.terrax.net , but not after restarting Edge or when trying with Firefox afterwards. I do not have these problems with my local Unbound on Debian Testing. So I set up https://dev2.terrax.net (which is handled by powerdns) and it works. ![dns](https://user-images.githubusercontent.com/17962859/31697598-ed88c8fc-b3b8-11e7-89d0-1ce33c80f1e7.png) from you: > It's possible that the TRust-DNS server is also responding incorrectly to standard queries on overlapping names, but no matching RecordType as well. from dnsviz: > dev.terrax.net/AAAA: The server returned a no error (**NOERROR**) response when queried **for** dev.terrax.net having record data of type **AAAA**, but returned a name error (**NXDOMAIN**) when queried **for** dev.terrax.net having record data of type **A**. (2a01:4f8:c0c:2c12::50, UDP_0_EDNS0_32768_4096) I assume Windows first requests the AAAA record and I can make one connection, then it requests the A record, gets NXDOMAIN as response and does negative caching? (I don't exactly know what I'm talking about and I want to apologize for this. I may be totally wrong.) https://dev.terrax.net * IPv6-only (maybe this is a problem of its own?) trust-dns-server (fresh compiled from master and now with P-384 to reduce warnings): http://dnsviz.net/d/dev.terrax.net/dnssec/ * IPv6-only HTTPS: https://www.hardenize.com/report/dev.terrax.net#www_https https://dev2.terrax.net * Dualstack PowerDNS * IPv6-only HTTPS: https://www.hardenize.com/report/dev2.terrax.net#www_https Both domains are pointing to the same IPv6 address with one certificate having two SAN entries.

kerem commented

2026-03-07 22:18:14 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 18, 2017):

This is a great report. Thank you. I do think that I have NxDomain and Empty records being returned incorrectly.

@bluejekyll commented on GitHub (Oct 18, 2017): This is a great report. Thank you. I do think that I have NxDomain and Empty records being returned incorrectly.

kerem referenced this issue

2026-03-16 01:53:44 +03:00

[PR #35] [MERGED] Name::zone_of should be case-insensitive as well #1201