Please follow the below template, it will help us to help you!
Expected Behaviour:
My domain edmreleases.net does not resolve when using pi-hole
Actual Behaviour:
it should resolve
Debug Token:
87skybwxm9
Additional Context:
it was resolving fine initially and then it just stopped without a reason. It starts resolving again once I switch to another dns e.g. 1.1.1.1
That'd be my best guess since i've tried at least 100 most popular websites and all of them open fine. my other websites resolve just fine but this one does not.
Mostly irrelevant, here is a tail after digging on pihole directly
ubuntu@ubuntu:~$ dig edmreleases.net @127.0.0.1
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> edmreleases.net @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5138
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;edmreleases.net. IN A
;; Query time: 23 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Feb 18 16:53:01 UTC 2019
;; MSG SIZE rcvd: 44
ubuntu@ubuntu:~$ tail /var/log/pihole.log
Feb 18 16:52:54 dnsmasq[1436]: /etc/pihole/gravity.list metrics.brightcove.com is 0.0.0.0
Feb 18 16:53:00 dnsmasq[1436]: query[AAAA] discourse.pi-hole.net from 192.168.10.237
Feb 18 16:53:00 dnsmasq[1436]: cached discourse.pi-hole.net is NODATA-IPv6
Feb 18 16:53:01 dnsmasq[1436]: query[A] edmreleases.net from 127.0.0.1
Feb 18 16:53:01 dnsmasq[1436]: forwarded edmreleases.net to 1.0.0.1
Feb 18 16:53:01 dnsmasq[1436]: validation edmreleases.net is BOGUS
Feb 18 16:53:01 dnsmasq[1436]: reply edmreleases.net is 104.27.154.80
Feb 18 16:53:01 dnsmasq[1436]: reply edmreleases.net is 104.27.155.80
Feb 18 16:53:04 dnsmasq[1436]: query[A] metrics.brightcove.com from 192.168.10.244
Feb 18 16:53:04 dnsmasq[1436]: /etc/pihole/gravity.list metrics.brightcove.com is 0.0.0.0
Check that the time on the Pi-Hole host device is correct, since DNSSEC relies on an accurate time. If time is correct, then disable DNSSEC in Pi-Hole and see if the behavior continues.
This is a dnsmasq function, and there have been DNSSEC problems identified in dnsmasq. You are on the latest version of Pi-Hole, which contains v2.80 of dnsmasq. I would check the dnsmasq list at:
Note that with a local instance of unbound running, I was able to successfully dig that domain, and unbound also uses DNSSEC. So, the problem does not appear to lie with the domain authentication signature.
Can that be some sort of bad DNSSEC cache of sorts? since I did some changes to the domain in the day which includes changing the DNSSEC record at registrar
So one pattern I see here is that it goes bad as soon as I enable dnssec at pihole.
I'm not using pihole as DHCP if that matters. that's handled by my mikrotik router which sends pihole IP as DNS server.
DNSSEC on domains is kind of a dark art. Just doing a quick check on that domain looks like it's registered with Name and DNS is hosted at CloudFlare. So you deployed new DS keys to Name that Cloudflare provided for you? It does look like the domain signatures are all valid and you just may be in a window of waiting for the signed records to be propagated across the CloudFlare servers. Propagation can take up to 24 hours depending on various conditions.
How long ago did you upload the new DS key? Was it a replacement of DS keys or the first time converting from unsigned to DNSSEC for that domain? Have you tried restarting pihole-FTL to clear out the local cache? The response from Pi-hole is that the proper IP address is being returned from your upstream but the record that is being sent is not signed with the correct key. That is why you are seeing the BOGUS response in the log tailing.
I'd say this is the case (unless someone else has attempted to do it ... there are at least two other people who have access to that domain so I'm only 99% sure that I'm the first one to try it)
Multiple restarts, no success, I've even rebuilt it still no success.
If it's working it just may have been a cache issue on the CloudFlare resolver you were being routed to. No need to post the results here if things are all working.
