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 stuffRespect the forum and don't do this! PM , unless you want to give me money, hahahahahah!
-
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'. -
@daddygo said in DNS over TLS sometimes not able to open website:
As far as I know, this eSNI stuff is a half - abandoned project
Pretty sure its fully done with - the replacement is ECH (encrypted client hello). When that might be actually something is really hard to say.
But really without esni or ech, all of the encrypted dns technologies are half ass that don't really do anything.. Whats the point of hiding what your asking for something.domain.tld from the bad isp, when you actually go to that IP you send the name in the clear via the sni.
If the sni is hidden as well from the bad isp - when you go to the IP they would know your going to 1.2.3.4 but with CDNs - you could be going to 1 of 1000's of domains. So hiding the sni is really needed if any of the hiding your dns query is going to do anything other than hand your dns to xyz dns provider as well as your bad isp knowing where your going anyway.
An intelligent man is sometimes forced to be drunk to spend time with his fools
Please don't Chat/PM me for help, unless mod related
Read https://www.netgate.com/docs/pfsense/book/
SG-2440 2.4.5p1 | 4x SG-3100 2.4.4p3 | SG-4860 21.05 -
@johnpoz said in DNS over TLS sometimes not able to open website:
@daddygo said in DNS over TLS sometimes not able to open website:
As far as I know, this eSNI stuff is a half - abandoned project
Pretty sure its fully done with - the replacement is ECH (encrypted client hello). When that might be actually something is really hard to say.
But really without esni or ech, all of the encrypted dns technologies are half ass that don't really do anything.. Whats the point of hiding what your asking for something.domain.tld from the bad isp, when you actually go to that IP you send the name in the clear via the sni.
@johnpoz ,so you say fix you SNI.. okee... but how? :)
-
Fix? There is nothing for you to fix..
Until the browser and or app wanting to use tls/ssl and the resource your going to support a why to encrypt where your actually whatever.domain.tld there is nothing you can do to actually hide where your going from the isp other than full vpn.
They know what IP your going to, and via the sni that is in the clear in the handshake they will know your going to whatever.domain.tld without really much more effort than looking at their dns logs.
If they do it this way they know for sure you went there, with just dns traffic all they know is you asked about something.domain.tld, they don't know if you actually tried to go there.
-
@johnpoz said in DNS over TLS sometimes not able to open website:
Pretty sure its fully done with - the replacement is ECH (encrypted client hello).
Thanks for the confirmation, then it's finally abandoned project.
Yes, there is still a lot of work to be done to make the good old DNS standard more secure :)
-
@johnpoz said in DNS over TLS sometimes not able to open website:
Fix? There is nothing for you to fix..
Until the browser and or app wanting to use tls/ssl and the resource your going to support a why to encrypt where your actually whatever.domain.tld there is nothing you can do to actually hide where your going from the isp other than full vpn.
They know what IP your going to, and via the sni that is in the clear in the handshake they will know your going to whatever.domain.tld without really much effort than looking at their dns logs.
If they do it this way they know for sure you went there, with just dns traffic all they know is you asked about something.domain.tld, they don't know if you actually tried to go there.
Yeah my bad. "Fully done with" i kinda read so finish and usable instead of abandoned project.
-
From what I have been reading esni will never become a viable thing.. ech is the current direction, will that ever come to fruition is anyone's guess.
either method esni or ech or whatever else might come about is really a major task. Because its not only the client that has to do it - its also every resource you would be going to.
Its kind of how dnssec has never really gone full mainstream, while its been about for years and years. It depends on the domain to implement it.. This is the problem - many domains don't do it, and then there are ones that do it - and borked it up in their implementation to the point its only causing them issues.
And every registrar is suppose to support dnssec for the tlds that support it to be accredited - but sadly this is not true.. There are many registrars that do not actually have anyway to start using dnssec with domains you have registered with them, or their implementation is so bad that makes it almost impossible for your average joe to jump through the hoops required to get it to function..
