Big DNS Problems *Illustrated*
-
Hello guys!
I am currently having from a month now many problems with my DNS and Tidal. Sometimes I also get slow DNS resolving. The error code in Chrome is DNS_PROBE_FINISHED_BAD_CONFIG. With Tidal, I often have problems to load a non-downloaded song and, thus, it skips music or does not even load any music except the downloaded ones. Please refer to the following to understand my simplified network with only the essential info:
Moreover, my PFsense which is a laptop with i5, 16GB ram, 256GB SDD uses:- DNSec with 1.0.0.1 and 1.1.1.1 (Cloudflare's DNSes)
- PureNAT
-Antivirus function with the Squid Proxy - Resolver Live Sync in pfBlockerNG
I think the problem comes with my configuration on my Pfsense router. I disabled Squid and Snort. I, however, noticed the Tidal problem does not happen when I use a VPN on my client. The temporary solution to these DNS issues were to restart the restart my 4G router and then my DNS resolver, reboot my PFsense router, or wait. These problems comes many times per day. Every 2 hours about. It is not regular. I really do need DNSsec but I will try whenever possible to deactivate it.
Please help me and let me know if you need any more information.
PS: I have an amazing 4G connection with less than 12ms ping, 130mbps download, 30mbps upload.
-
@skalyx said in Big DNS Problems *Illustrated*:
DNS_PROBE_FINISHED_BAD_CONFIG
Try this :
Remove Squid.
Remove Snort.
Remove pfBlockerNG,
Remove "1.0.0.1 and 1.1.1.1"
I don't know what PureNAT is, but it's surely not needed, so remove it.
Put Resolver in the default, resolve mode.Now you reached the point with one possible conclusion : no more issues.
Go the other way around, do one step a day, and test every situation that triggered problems.
As soon as issues come back, will will know where you have to focus on.Btw : pfSense on a Laptop ????
-
@Gertjan
Hello,
I did not touch anything since I posted my problem here but it looks like the problem disappeared. I did not have the issue since then.However, I am sure it will happen so I will try the troubleshooting steps you wrote. Thanks for that.
Regarding the laptop, I just have a spare laptop with a broken screen and it works well. I tried on a desktop with multiple Ethernet ports and it performs as well.
Regarding the "pure Nat" it is a function we can activate in PfSense setting-advanced. Please refer to
Btw: I already tried uninstalling snort, squidy purenat. I suspect pfblockerng and DNSec to screw things over
-
UPDATE:
Problems started reoccuring this morning so I have tried to inspect my DNS settings once again. Here what I found:
I have removed the "private-domain: "plex.direct"" in the custom options situated in Services->DNS Resolver. It looks like it works but I will have to let it for some time. Tidal does not have any problem with this change. I will update whenever my "test time" is up. -
You shouldn't need to add a custom option for "plex.direct" anyway... pfSense already adds one to the config file it generates by default.
-
@virgiliomi said in Big DNS Problems *Illustrated*:
You shouldn't need to add a custom option for "plex.direct" anyway... pfSense already adds one to the config file it generates by default.
Since when?
There is nothing in the unbound showing that it does that - sorry but I believe your mistaken.. If you want prevent rebind issues with plex.direct you would have to put it in there yourself.
Here this direct from the /var/unbound.conf
# DNS Rebinding # For DNS Rebinding prevention private-address: 10.0.0.0/8 private-address: ::ffff:a00:0/104 private-address: 172.16.0.0/12 private-address: ::ffff:ac10:0/108 private-address: 169.254.0.0/16 private-address: ::ffff:a9fe:0/112 private-address: 192.168.0.0/16 private-address: ::ffff:c0a8:0/112 private-address: fd00::/8 private-address: fe80::/10 # Set private domains in case authoritative name server returns a Private IP address
There is nothing there for plex.direct to turn off rebind for it - maybe you turned off rebind completely if your not having issues with plex.direct..
-
Not sure. But I know if I go into /var/unbound/unbound.conf, there's already
private-domain: "plex.direct" domain-insecure: "plex.direct"
in there. And it's well above the area where custom options from the config page go.
-
Is it under this heading
# Set private domains in case authoritative name server returns a Private IP address
See my previous post edit on what is listed there.
If you setup a domain override?
-
So, the cause of my problems cannot be linked to this entry in custom options? I am surprised by the fact that I do not have any DNS problems since I removed it. I still need to see if it does fix it over time.
In fact, I was restored my PFsense last day and could not activate my DNS resolver until I removed : private-domain: "plex.direct". So, it may be the cause of my problem. I do not remember why I put that and have not had any Plex issue since the time I removed the entry. -
@johnpoz Ahh... so a domain override will put it there. That would be why then. I have one there, but it's basically to save Unbound a few steps since I was having issues with Plex resolution. Learn something new every day.
@skalyx I kinda went off on a tangent related to that option, not realizing that something else in my setup was putting it in the unbound configuration automatically. It seems odd to me that a setting related to Plex would clear up your issue with TIDAL though.
Apologies for the confusion.
-
@virgiliomi No worries, mate! Thanks to participating in my post! I am also surprised to the fact this entry caused problems with my DNS resolver and Tidal. I do not know... I will have to check further.
I now have Plex issues... I am forced to put it again. I get: "Unable to connect to "HDPlex" securely."
I will put it once again and hope my problem is not linked to it.
I will update ! -
Where are you overriding it to go? I don't use tidal - to honest not sure what plex is trying to do there at all..
Maybe chrome is doing its own sort of rebind protection? Best thing to do is sniff to see exactly what the client is asking for and what is or isn't getting returned, etc.
Can tell you for sure with out turning off rebind for plex.direct your going to run into issues - and prob only get indirect connections to your local plex box.
-
@johnpoz I'm overriding it to go to one of Plex's servers still (one of their secondary servers)... just saving Unbound a couple of resolution steps. I was running into timeout issues occasionally. I don't use TIDAL, so no idea what might be going on with that.
-
So your overriding it to go direct to the authoritative ns for plex? Yeah that would turn off dnssec and rebind..
Once the domain is resolved once - the authoritatives would be cached for the life of the ttl, and would not have to resolve any more? Would just have to ask the cached NS for the domain direct, if a record TTL had expired.
If your having timeouts on resolving - try turning on prefetch, and even the serve 0 ttl option.. This can help if you have slow resolving for specific domains.
-
Already had prefetch on... will turn on Serve 0 TTL also.
Again, apologies to the OP for the slight tangent... what turned out to be me trying to point something out has instead helped me... hopefully your issue can be resolved too, though not sure what has been given to me is at all related to your problem.
-
So just looked and the TTL on those ns for plex.direct are quite long
example
;; ANSWER SECTION: ns-plexdirect.plex.tv. 604800 IN A 82.94.168.7
Is your unbound restarting a lot @virgiliomi -- once that is looked up once, you should not have to resolve the NS for plex.direct again for quite some time.. 7 Days to be exact ;)
-
@johnpoz Are you talking to me John? I do not really understand your message.
Do you have any idea what my problem might be caused from?BTW, private-domain: "plex.direct" fixed "Unable to connect to "HDPlex" securely.".
-
@johnpoz Gonna PM you and we can continue chatting there so the topic can go back to the OP's issue.
-
Yeah sorry @skalyx me and @virgiliomi kind of got on a bit of tangent there from your problem.
So putting in plex.direct back into custom fixed your plex problem - but your still having issues with tidal? I guess I do the free trial thing and see if could duplicate your problem.
-
@johnpoz
No worries!
For the moment, TIDAL is working fine haha. Problems happen from time to time not constantly so I will have to see over time. -
UPDATE: I got the problem again with known website such as cloudflare.com etc. I will try to remove plex entry again in custom option (DNS Resolver).
Do you have any idea to help me out?
-
that plex.direct would have zero to do with resolving something on cloudflare unless your are maybe using it as reverse proxy for your plex? And even then it should not be a problem.
-
Yeah, this seems much more likely to be a DNS resolution issue. I would try running the resolver directly in resolving mode if you are going to have DNSSec enabled and see if the issue repeats.
Steve
-
@johnpoz Yes, it is logical. I do not use reverse proxy.
@stephenw10 Hmm. Could you please let me know how I can run the DNS resolver directly in resolving mode?
Thanks,
-
Resolving mode is the default setting. If you are using Cloudflare's DNS server though you would have to have set Unbound to forwarding mode. If you use that everything that request is forwarded to must support DNSSec otherwise results will be rejected.
Simply unchecking 'use forwarding mode' in Sevices > DNS Resolver will put it back to resolving directly.
Steve
-
If your going to "forward" then having dnssec enabled is utterly just a waste of resources..
If you forward to a dnssec resolver - then its being done for you already... If you ask for a dnssec to something that doesn't support it, be it yet another forwarder or even a resolver it really means nothing..
If you forward enabling dnssec on your forwarder is just pointless plain and simple.
If you want to use dnssec, then you either resolve directly like unbound does out of the box, or you forward to a resolver that is doing it for you like cloudflare.
-
@stephenw10 Thanks. But if I set as Unbound, I won't get DNSSEC anymore or will I?
My problem is not constantly with one domain. Actually, it happens time by time.
For instance, I am normally able to access YouTube.com or any other website. However, a time comes where I cannot say access these websites. I think my DNS Resolver crashes because when I restart it or wait for about 5-15 minutes everything works. When this situation happens, I can ping 8.8.8.8 or any other address so it really is a DNS issue.
That's really weird... I changed my hardware as well... -
And are you using pfblocker, it can really delay the start of unbound.. So if your unbound is restarting all the time say on dhcp lease registration, or pfblockers own cron job that runs every hour for example.. And your unbound is taking long to start then yeah you can run into stuff like what your talking about where stuff doesn't resolve and then all of sudden does.
You could also just have delays in resolving depending if your on a high latency line, or the authoritative ns you are asking info from is on the other side of the planet from you, or is just slow or your connection via peering to that network on via your isp is bad.
If your having trouble with specific domains resolving - then you need to troubleshoot the particulars of that problem.. Dig +trace can be your friend in troubleshooting specific domains lookup problems.
But if your going to forward to NS xyz, turning on dnssec in unbound is just pointless. Cloudflare already does dnssec - so you have zero reason to have it enabled in unbound.. You will get it if you want it or not if forwarding to their dnssec enabled IP.. They have other IPs you can use if you do not want dnssec.
-
@johnpoz said in Big DNS Problems *Illustrated*:
If you want to use dnssec, then you either resolve directly like unbound does out of the box, or you forward to a resolver that is doing it for you like cloudflare.
Thanks, John! So... You recommend me to let the forwarding mode in DNS Resolver and deactivate DNSSEC support? How can I activate unbound DNSSEC?
-
If your going to "resolve" with unbound and not forward then out of the box it would be doing dnssec.. You would have to on purpose uncheck the dnssec box if you didn't want unbound to be doing dnssec.
If your going to "forward" with unbound then yes you should uncheck the dnssec box - because it makes no sense to ask for dnssec info from where your forwarding.. It will not be actually validated, and is just waste of time.. The forwarder could send you back whatever it wants to be honest..
If you forward to a resolver like cloudflare that is doing dnssec, then no reason to ask it for anything - since its already doing it anyway be it you ask for it or not.
-
@johnpoz
I see. I think my network is quite good and my ISP as well. I think the problem is on my side configuration-wise... I am still looking... Also, when the problems come, the DNS issues are with all domains not only one.
So what about doing what Stephen recommend me which is:
"Simply unchecking 'use forwarding mode' in Sevices > DNS Resolver will put it back to resolving directly." and letting DNSSec support? -
Yes this is how pretty anyone should be using unbound - as resolver and using dnssec, this is the default out of the box configuration...
Only people that have specific needs/wants to forward for some reason that only they could understand.. I wouldn't go back to forwarding if you paid me ;) Need to change the default configuration.
There are some use cases where you would have to forward - for example if you on a high latency SAT connection for example.. Resolving just not really going to work on such a connection.
The reason resolving and using dnssec out of the box is default, is because the vast majority of the time this will be the best most secure option.. And will just work out of the box for pretty much everyone.. .Only in a situation where the ISP is directly manipulating dns queries or blocks outbound dns to anything other than their own NS could this be a problem.
-
Yup go back to the default DNS setup and see if problems go away. It sounds like you had moved away from that when the problems started.
A lot of people confuse DNSSec with encrypted DNS like DNS over TLS. Were you trying to use that against Cloudflare's servers?
Steve
-
@stephenw10 said in Big DNS Problems *Illustrated*:
A lot of people confuse DNSSec with encrypted DNS like DNS over TLS.
A lot of people confuse a lot of things when it comes to dns... For being really the backbone that allows the internet to even function its a shame really how little it is actually understood by the masses..
-
@johnpoz Thanks, John!
So, it was a misconfiguration then...! I followed a tutorial on internet on how to use Cloudflare DNS servers with DNSSEC. I guess they did not provide good info.
So what I just did now is :
My DNS servers the PFSense router is using are: 1.0.0.1 and 1.1.1.1
Could you please check if everything is alright?
With these settings, I am unable to solve any DNS queries... I do not know why. I rebooted my 4G router and PFsense router. So... I had to reactive the forwarding mode again which makes my DNS resolving queries work. Without it, nothing works. -
@stephenw10 No haha. I want DNSSec to verify the authenticity of domains. Actually my next steps were to add DNS over TLS. However, I just do not want to add it before everything works well...
Here is what I was planning to add into the DNS Resolver custom options:
server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.0.0.1@853
forward-addr: 1.1.1.1@853 -
BTW, I just noticed there is something new in General Setup DNS.
Please refer to this:
Should we add something here if I were going to use DNS over TLS? -
@skalyx said in Big DNS Problems *Illustrated*:
I guess they did not provide good info.
Yup falls in line with stephenw10 comment and my own - there a lot of people that don't actually understand dns at even a basic level... But they think they can write up guides on how to do XYZ.. Mindless of makes any actual sense or not..
Cloudflare resolver is already doing dnssec.. You have to do ZERO to have it do dnssec if you forward your queries to them..
Simple test will show you that..
Here 1.1.1.1 does dnssec, so if ask it for test fqdn dnssec-failed.org, it fails...
$ dig @1.1.1.1 dnssec-failed.org ; <<>> DiG 9.14.1 <<>> @1.1.1.1 dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11978 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dnssec-failed.org. IN A ;; Query time: 52 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Mon May 27 09:14:39 Central Daylight Time 2019 ;; MSG SIZE rcvd: 35
If you ask opendns - it returns IP that it shouldn't since that domain fails dnssec tests
$ dig @208.67.222.123 dnssec-failed.org ; <<>> DiG 9.14.1 <<>> @208.67.222.123 dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3941 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dnssec-failed.org. IN A ;; ANSWER SECTION: dnssec-failed.org. 7200 IN A 69.252.80.75 ;; Query time: 67 msec ;; SERVER: 208.67.222.123#53(208.67.222.123) ;; WHEN: Mon May 27 09:14:31 Central Daylight Time 2019 ;; MSG SIZE rcvd: 62
-
@johnpoz Thanks! I love learning stuff. I understand it better. The "dig" tool is definitely something I will have to learn about.
Unfortunately, we cannot believe everything on the internet!
It makes a lot of sense that we do not need to do DNSSEC with unbound if we forward our requests to a server that already makes DNSSEC queries for us. -
If you are not using forwarding mode then whatever you have set in System > General is not used. So right now you are not using Cloudflare's DNS.
There is a check box for DNS over TLS in the GUI now which you have checked. That doesn't do anything until forwarding mode is enabled but if you do then it will use the servers defined in General Setup and will try to reach them over TLS. No need to add any custom options. Disable DNSSec if you do that as discussed.
Nice test @johnpoz.
Steve