[Server] ResponseCode for NSEC on non-existent RecordType should be NoError about trust-dns HOT 6 CLOSED

@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)

from trust-dns.

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?

from trust-dns.

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.")

from trust-dns.

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

from trust-dns.

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.

from trust-dns.

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

from trust-dns.