DNS over TLS sometimes not able to open website
-
I have setup my Pfsense (2.4.5) to use DNS over TLS from Cloudflare. So 1.1.1.1 with a hostname filled and the settings needed on the DNS resolver page. I see traffic on port 853 so this is working.
I use a Windows Server 2019 domain setup. So my clients look at DC01 en 02 for DNS and they point at PFSense (DNS forwarder).
This works fine 90% of the time. But sometimes i am not able to open a website.
The error than is: DNS_PROBE_FINISHED_NXDOMAIN
When i turn my WiFi on my phone off (and use cellular network) i am able to open the website. When i temporarly change the DNS server on my Windows client it also works. So the problem most likely is my DNS. I am also not able to ping the address from my client.
For example this site, it is in Dutch but the content is not important.
https://www.nr1motor.nl/honda/alle-bouwjaren/cbr-1100-xx-blackbird-onderdelen/motor/bouten-kit.html
I do use PFBlocker to block Google ads etc. I don't think this has something to do with this problem but still good to know for troubleshooting.
How can i solve this? Many thanks in advance.
-
@operations said in DNS over TLS sometimes not able to open website:
to use DNS over TLS from Cloudflare. So 1.1.1.1
Hi,
I run the same setup without any problems
Do you happen to have Harden DNSSEC Data - Unbound checked?
-
Thanks for you reply and i am sorry to have to ask but how do i do this?
Dig @ 1.1.1.1 URL in command prompt line doesn't work.
I am able to ping nr1motor.nl from pfsense btw.
So maybe the problem is in my Domain DNS server...
Then again all they do is use the DNS Forwarder. -
@operations said in DNS over TLS sometimes not able to open website:
Dig @ 1.1.1.1 URL in command prompt line doesn't work.
Check a few settings, one by one:
Final check here:
and here (I control DNS queries across multiple networks)
-
@daddygo said in DNS over TLS sometimes not able to open website:
@operations said in DNS over TLS sometimes not able to open website:
Dig @ 1.1.1.1 URL in command prompt line doesn't work.
Check a few settings, one by one:
Final check here:
and here (I control DNS queries across multiple networks)
@daddy go
You fixed it :) one more question:
picture 1: DNS Resolution Behavior was not correct. So i changed this.
picture 2: Do i also need to set the "static DHCP" option if my pfsense is NOT my DHCP server? DHCP relay is on and pointed to my Windows DHCP server.
resolven would be / is nice, at the moment i have added all my subnets (so this 101.168.192.in-addr.arpa) under Do,main Overrides (DNS Resolver).picture 3: HARDEN DNSSEC Data was turned on, so i turned it off.
Since this wasn't setup 100% correct, isn't it strange i only had this problem on a couple of websites?
Many thanks! -
@DaddyGo ,
With regards to picture 4. This shows what it should (now).
I still see my TV decoder box using 1.1.1.1 @ port53. But that is fine. It is a isolated vlan. -
@operations said in DNS over TLS sometimes not able to open website:
picture 2: Do i also need to set the "static DHCP" option if my pfsense is NOT my DHCP server?
it depends on your choice and your DHCP configuration
I use a lot of static addresses, since the "Register DHCP leases in the DNS Resolver"
does not work properly, not at all in pfBlocketNG Python mode, so I use the static stuff -
@daddygo said in DNS over TLS sometimes not able to open website:
@operations said in DNS over TLS sometimes not able to open website:
picture 2: Do i also need to set the "static DHCP" option if my pfsense is NOT my DHCP server?
it depends on your choice and your DHCP configuration
I use a lot of static addresses, since the "Register DHCP leases in the DNS Resolver"
does not work properly, not at all in pfBlocketNG Unbond mode, so I use the static stuffI also use a lot of static IPs. Almost all...
But the fact i am not using pfsense as DHCP server doesn't make the option useless?EDIT: Cannot enable the option... "DHCP server must be enabled..."
-
@operations said in DNS over TLS sometimes not able to open website:
I still see my TV decoder box using 1.1.1.1 @ port53. But that is fine. It is a isolated vlan.
There are hard coded DNS things like IoT and things like setup-box, etc.
I recommend this, for you, in addition to the DoT setting:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
if the TV box stops working, give it a free pass to DNS53 with a rule
this is the dumber version of the one I recommend:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.htmlso I'll just put this in (brackets)
-
@daddygo said in DNS over TLS sometimes not able to open website:
@operations said in DNS over TLS sometimes not able to open website:
I still see my TV decoder box using 1.1.1.1 @ port53. But that is fine. It is a isolated vlan.
There are hard coded DNS things like IoT and things like setup-box, etc.
I recommend this, for you, in addition to the DoT setting:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html
if the TV box stops working, give it a free pass to DNS53 with a rule
this is the dumber version of the one I recommend:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.htmlso I'll just put this in (brackets)
I already used that one for my chromecast, i noticed :) Thanks for the extra tip!
-
@operations said in DNS over TLS sometimes not able to open website:
But the fact i am not using pfsense as DHCP server doesn't make the option useless?
I use DHCP only with static mapping....
and a couple of IP address (in DHCP) for unexpected things on the network, for example if you need to test a new device or the factory device need DHCP is requested for first configuration
f.e. (PS4):
-
@DaddyGo ,
Since i was able to open the nr1motor.nl website i thought the problem was solved. But i have found a new one that doesn't work.
www.kvk.nl
Again in Dutch, it is our chamber of commerce website. But that is once again not so relevant ;)
And again when i use my cellular network the website works fine. When using my network (by wifi) i get the dns probe error.
Any more ideas?
EDIT: never mind :) i tried to open a Google ad link which is blocked by PFBlocker. By choice.
-
Just for the record :
Using DNSSEC
and
Forwardingis what can be considered as mutual exclusive.
When forwarding, shut down DNSSEC in Unbound.
A Resolvers does the DNSSEC checking - and in your (both) cases 1.1.1.1 is doing the DNSSEC as 1.1.1.1 is the resolver. You just have to trust the DNS traffic that it (1.1.1.1) is giving to you, unbound can't check for it self any more.
Even when you leave 'DNSSEC' on, it won't do a forwarding first ( to 1.1.1.1) , and then a complete resolve to check the DNSSEC chain. That wouldn't make sense. -
@operations said in DNS over TLS sometimes not able to open website:
Any more ideas?
that was my question pfBlockerNG logs?
because....
-
@gertjan said in DNS over TLS sometimes not able to open website:
is what can be considered as mutual exclusive.
Hi,
Hmmmm...?
there is truth in the approach, but it is not relevant to the topichttps://forum.netgate.com/topic/109887/unbound-and-dnssec
-
-
@operations said in DNS over TLS sometimes not able to open website:
So should i turn DNSSEC off or not? :)
The CF 1.1.1.1 / 1.0.0.1 (and his friends .0.2, etc.) is a DNSSEC validating resolver (PubDNS), ergo does the work for you...
Unfortunately, life is not kind to DNSSEC and it is not fully developed, maybe it will become something in the future, but many DNS sys. Dev. are thinking in a different direction.
https://dnscrypt.info/faq
(pls. look at the diagrams, I don't want to show the debate between DNSCrypt and DNSSEC)
+++
https://easydns.com/dns/dnssec/So the CF has already guaranteed you that he has already checked the DNSSEC stuff, when your Unbound resolver (pfSense) calls him and receives data
I did not notice a significant change if DNSSEC is ticked or not...
pls. play with it, you too, a little bit here :)
https://dnssec.vs.uni-due.de/
https://www.cloudflare.com/ssl/encrypted-sni/and watch the behaviour
-
@daddygo said in DNS over TLS sometimes not able to open website:
@operations said in DNS over TLS sometimes not able to open website:
So should i turn DNSSEC off or not? :)
The CF 1.1.1.1 / 1.0.0.1 (and his friends .0.2, etc.) is a DNSSEC validating resolver (PubDNS), ergo does the work for you...
Unfortunately, life is not kind to DNSSEC and it is not fully developed, maybe it will become something in the future, but many DNS sys. Dev. are thinking in a different direction.
https://dnscrypt.info/faq
(pls. look at the diagrams, I don't want to show the debate between DNSCrypt and DNSSEC)
+++
https://easydns.com/dns/dnssec/So the CF has already guaranteed you that he has already checked the DNSSEC stuff, when your Unbound resolver (pfSense) calls him and receives data
I did not notice a significant change if DNSSEC is ticked or not...
pls. play with it, you too, a little bit here :)
https://dnssec.vs.uni-due.de/
https://www.cloudflare.com/ssl/encrypted-sni/and watch the behaviour
I already used the cloudflare encrypted sni website to check in the past, but since we are
talking about it anyway :p I don't have a pass on the encrypted sni check. Is it easy to solve this?So what you are saying is it would not make a difference if i would just use port 53 (so the normal way) to 1.1.1.1 since they are using DNSSEC anyway? Is it correct?
-
@operations said in DNS over TLS sometimes not able to open website:
I don't have a pass on the encrypted sni check. Is it easy to solve this?
As far as I know, this eSNI stuff is a half - abandoned project due to slow browser code development, hmmm not really abandoned just slowed down...
So for now I'm not dealing with this encrypted "client hello" stuff, yet...
because it is not readyf.e.:
https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/@Operations "So what you are saying is it would not make a difference if i would just use port 53 (so the normal way) to 1.1.1.1 since they are using DNSSEC anyway? Is it correct?"
Nope, because
DNSSEC does not encrypt the traffic between the CF DNS server and pfSense, that's what DoT is for.Be careful with this, because unencrypted DNS traffic is 53, not the same as 853 with TLS.
DNSSEC only checks that the content is valid, since it is assigned to DOMAIN....
mitigate the possibility of MITM attack
f.e (DNSSEC):
watch this f.e., so you can set it up for DOMAIN, for example, at CloudFlare + Namecheap registrarhttps://support.cloudflare.com/hc/en-us/articles/360006660072-Understanding-and-configuring-DNSSEC-in-Cloudflare-DNS
these things should not be confused: DoT , DoH, DNSSEC are different and have different approaches
+++edit:
although each in its own way tries to make up for the shortcomings of the old DNS standard, in this privacy-sensitive world you can't use purely TXT-based DNS stuffCats bury it so they can't see it!
(You know what I mean if you have a cat) -
DNSSEC : when a resolver is used, and you get an answer that states DNSSEC is ok, you know that the answer is valid, and not spoofed or tampered by some one.
Internet's DNS root servers are signed, so classic port 53 UDP (and TCP !) is used to communicate usual DNS traffic (A, AAA, NS, SOA, MX, etc) and DS/RRSIG /DNSKEY traffic.
'anyone' can see what you do, but you'll be sure you got the right answer.DOT : this DNS traffic is TLS from the start, from 'you' to a central resolver, the 'third party'. As the main Internet's root server don't use DOT, you have to trust some company to do the classic resolving (using DNSSEC if avaible, or not), and then have it send to you the results 'encrypted'. See it as a VPN-for-DNS.
Native DOT+DNSSEC will be possible, as soon a the entire "DNS back bone" is made compatible : the root servers and all the TLD's, and all the name servers. This will add a huge workload on all these system, which are often just 'offered to the public' by non-profit organisations.
DNSSEC generates more (3 or 4 times) more traffic as classic DNS.
No other special treatment is needed on the root servers or TLS, and or name servers. The requesting resolver does final the 'verification job'.
