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!

Operations

@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.

DaddyGo

@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

Operations

@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 stuff

I 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..."

DaddyGo

@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.html

so I'll just put this in (brackets)

Operations

@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.html

so I'll just put this in (brackets)

I already used that one for my chromecast, i noticed :) Thanks for the extra tip!

DaddyGo

@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):

Operations

@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.

Gertjan

Just for the record :

Using DNSSEC
and
Forwarding

is 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.

DaddyGo

@operations said in DNS over TLS sometimes not able to open website:

Any more ideas?

that was my question pfBlockerNG logs?

because....

DaddyGo

@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 topic

https://forum.netgate.com/topic/109887/unbound-and-dnssec

Operations

So should i turn DNSSEC off or not? :)

@DaddyGo @Gertjan

DaddyGo

@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

Operations

@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?

DaddyGo

@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 ready

f.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 registrar

https://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 stuff

Gertjan

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'.

johnpoz

@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.