Thanks @DanSchaper , does it mean there's nothing I can do about it? Strange though that the domain name is resolved by google or cludflare's dns.
BTW: using the same tool, applied on google.com domain resolves in even more errors, yet the domain name is resolved correctly by unbound.
The response by Plex staff is to "disable DNSSEC". Which I read as "We know it's broken but we're not going to fix it."
The reason Google and Cloudflare resolve it is because they are not enforcing DNSSEC. The domain resolves fine insecurely, the problem is that Plex have set it up to sign records in the plex.tv zone but then haven't finished the configuration to validate the signatures. The .tv zone owners have published a record that says the plex.tv zone can not be signed. So either Plex sends the proper records to the parent zone or they disable DNSSEC signing of their records. When you combine secure and insecure records in the same zone you get a failure because it looks like someone is trying to impersonate records.
As for the google zone, you can see all of the google.com have a red "No RRSIGs found" which means the records are not signed, and the google.com zone has "No DNSKEY records found". That means the entire zone is not signed and DNSSEC isn't enabled on the zone so there is no attempt to validate DNSSEC for the google.com zone.
Compare that to how Plex has signed RRSIGs and DNSKEY records. They've just broken the chain so that you can not validate the signed records. That's why DNSSEC validation fails, this is one of the situations that DNSSEC was designed for and the failure of the validation is correct.
Edit: It's truly as simple as Plex going in to Cloudflare and toggling the DNSSEC box. Not sure why they don't.
Aha, got it! Makes sense.
Back to my q.: is there anything I can do to bypass ( maybe ) DNSSEC enforcing? Other people are saying they use unbound and they can access plex.tv
They probably have DNSSEC validation disabled in unbound.
I don't know offhand how you can set up unbound to ignore certain zones for DNSSEC validation and have it enabled for everything else. Might search around and see if that is a possibility.
Can you try changing this line in unbound from yes to no? It does create a small security concern but it would be interesting to see if that fixes things.
harden-dnssec-stripped: <yes or no>
Require DNSSEC data for trust-anchored zones, if such data is
absent, the zone becomes bogus. If turned off, and no DNSSEC
data is received (or the DNSKEY data fails to validate), then
the zone is made insecure, this behaves like there is no trust
anchor. You could turn this off if you are sometimes behind an
intrusive firewall (of some sort) that removes DNSSEC data from
packets, or a zone changes from signed to unsigned to badly
signed often. If turned off you run the risk of a downgrade at-
tack that disables security for a zone. Default is yes
harden-dnssec-stripped: no => makes no difference for me:
root@pihole:~# dig plex.tv @127.0.0.1 -p 5335
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> plex.tv @127.0.0.1 -p 5335
;; global options: +cmd
;; no servers could be reached
Thanks, I'm trying to find out where I'm wrong and what I'm missing here.
That's a rather large log - it seems it's covering more than just one dig plex.tv run.
I can't really read those logs very well, but besides the SERVFAIL that unbound ultimately returns as a reply, I see missing DNSKEYs as well as a rather large count of TCP errors similar to:
debug: tcp error for address ip4 37.209.192.6 port 53 (len 16)
I can't explain why that fails, as I've never seen that before.
That probably doesn't mean much, as that's from unbound's logs - you may want to raise this with unbound's support, where they are more familiar with reading those logs.
But let me try a guess:
You mentioned earlier that you run pfsense.
Do you allow outbound port 53 for both UDP as well as TCP from your Pi-hole host machine?
Yes, here's from the pfsense logs, where 192.168.3.107 is pihole host making a dig request for plex.tv and passing through:
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.