DNSSEC not work on any DNS

Expected Behaviour:

[On query tab status should be SECURED

  • Raspbian 10 buster
  • Pi-Hole v5.2.4
  • Web v5.4
  • FTL v5.7]

Actual Behaviour:

[No matter if I chose OpenDNS or Quad9 which IP supports DNSSEC and enable DNSSEC on Pi-Hole on query tab I got status UNSECURED for all domains like google, mcafee]

Debug Token:

[https://tricorder.pi-hole.net/afppw58uf8]

That's not a response we use, can you show a screenshot?

As of Pi-hole 3.3, you can see the DNSSEC status in the query log.

  • SECURE are records that have been signed and verified to be unchanged from the authoritative DNS server
  • INSECURE are records that either have no signature or DNSSEC is not implemented for the domain; either the domain is unsigned and not implementing DNSSEC or there are other issues
  • BOGUS are records that have been signed but have changed or been altered from the authoritative DNS server

You will see INSECURE, but that does not mean a bad record--just has not been implemented. BOGUS records are something to look at, either they have been altered in transit or the domain maintainer has not updated the records correctly. At present, 90% of the records you see will be INSECURE as there is not a lot of DNSSEC uptake currently.

If you see BOGUS on a test for a known bad record then things look like they are configured correctly. As more domains move to utilizing DNSSEC the INSECURE will tend to fade away, but we are a long ways away from full adoption of the technology.

2 Likes

My mistake it should be INSECURE.!



Did you read the rest of my comment?

Summarizing yours and DanSchaper's comments: DNSSEC is working correctly for you.

I read that information before I write here.
I use on android Net Analyzer and from this app I can create some DNS query for example TXT record.
When I query for example: google.com amazon.com Pi-Hole return to me these TXT record adn display INSECURE.
When i query for some fake not existing domain Pi-Hole return SECURE.
That mean something is wrong.
I query TXT record not A because don't want to get "cached" response.

No, both are expected and correct:

  1. INSECURE Google and Amazon:
    Neither Google nor Amazon have DNSSEC enabled as no DS records are found for amazon.com and google.com in the com zone.
    Also, no DNSKEY records are found for these domains.
  2. SECURE: The non-existent domain
    There are 2 DNSKEY records for the root domain .
    The root zone returns NXDOMAIN for a random domain (I tried efgqnegoiqeg) and signs this properly --> The answer is SECURE because it is validated to come from the root zone.

If you want to test DNSSEC with a real domain you should use one that actually employs DNSSEC. You can use, for instance:

  • sigok.verteiltesysteme.net (SECURE)
  • sigfail.verteiltesysteme.net (BOGUS and/or SERVFAIL)

It looks like bellow.
It is very strange that any of popular domains not support correctly DNSSEC.
This page also return error https://dnssec.vs.uni-due.de/


Make sure your computer is only using the Pi-hole as DNS server. Try also the steps under Test validation once from your computer and once directly from your Pi-hole.

Check out:

TL;DR:

[...] given the uncertainties about the goodness of DNSSEC, and the lack of flagrant issues with the existing PKI, it is no wonder that deployment is deemed non-urgent by the big companies. Let's get IPv6 working first

and

DNSSEC has military value, though: by preventing DNS poisoning, it helps in defending against big denial-of-service attacks that could be part of some global electronic warfare. I expect DNSSEC to be supported by governments, not by big companies -- but the days or ARPANET are long gone, and the Internet is the territory of private ventures nowadays.

As DL noted, you have another DNS resolver set up. If you read the REPLY status you'll see that sigfail properly returns a SERVFAIL response because the record is unsigned.

sigok is SECURE.

Google is unsigned.

Thanks for your help.
I understand that most websites not support DNSSEC and I will get INSECURE for most requests.
Now test finish correctly.


We can close this case.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.