All my upstream DNS servers configured in Pi-hole settings are DNSSEC capable but yet, Pi-hole fails for first query but then all subsequent calls (same query) are successful. Any idea why it fails first time? This happens everytime.
The following is a snippet of log showing fail, followed by success
2023-08-19 10:33:22 A sigok.ippacket.stream lion OK (answered by dns.google#53) SECURE CNAME (1481.4ms)
2023-08-19 10:33:21 A sigok.ippacket.stream lion OK (answered by dns.google#53) INSECURE CNAME (717.7ms)
INSECURE isn't a failure. It's a valid indication that the reply provided did not contain the required information to determine if the response was correctly signed or not.
My initial guess is that dns.google is not providing the full information.
Is this happening with just this domain or with others? Does it happen with another upstream or just google?
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.
@DanSchaper
Sorry for the incorrect wording on my part, let me clarify. I meant to say the first time, the DNS query/response was not transmitted via TLS which I understand Pi-hole indicates as "INSECURE". I understand it can happen if the host you are trying to resolve either does not contain a DS domain records or key/signature invalid etc but my question is it is the same host i.e. "sigok.ippacket.stream" used on both cases however the first time it fails (i.e. insecure) and second time it is successful (i.e. secure). Does this make sense? I tried to directly hitting dns.google using dig and every single time it returns authenticated response, also it is the same case for other DNSSEC capable servers like quad9 when Pi-hole end up using it instead of google.
@DanSchaper
I found the problem, it is totally unrelated to Pi-hole; it turned out to be dig client. I didn't realize dig version comes with macOS (even the latest OS) is really old (DiG 9.10.6). Once I got the current dig version (DiG 9.18.18) everything worked perfectly.
