Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception
-
[Mods: I've realised this should have been posted in the "DHCP and DNS" subforum, if you see this please feel free to move]
Hi,
So for a while now I have been running Unbound DNS resolver in pfSense, with forwarding using DNS-over-TLS to Quad9 servers. I have concerns over ISP manipulation of DNS results (before you ask - ISP choice where I live is limited, and the ISP is very reliable in other regards so moving is not an option). All local machines use Unbound on pfSense as their DNS server, and any requests on port 53 and 853 to other DNS servers are blocked. Everything was working nicely...
But this week all sorts of things started to break - simple website access such as Google and most other domains started to break. I couldn't even ping Google. After a long process of narrowing it down, it appears the ISP has started blocking port 853. When I remove all my rules blocking DNS requests going to other servers, and then issue these commands on my Mac, the port 53 command succeeds but the 853 does not.
nc -vz 8.8.8.8 53 nc -vz 8.8.8.8 853
This is the same for 1.1.1.1:853, 9.9.9.9:853 and portquiz.net:853 so I can only conclude that they are blocking port 853 entirely. Why would they do that? No idea but to me that implies they want to retain an ability to mess with normal DNS and prevent people bypassing that.
So.... I tried switching to Unbound as resolver without forwarding... and everything seems to be working well. But I am trying to understand the difference in terms of mitigating the threat of interception of DNS results.
-
DNS-over-TLS: My understanding was that as long as it is working/connecting, the ISP is unable to see/monitor your DNS results, and you are guaranteed accurate results from the forwarder (trust assumed), as requests and replies are encrypted so interception is not possible. I liked this. But now I can't do it because port 853 is blocked, and I don't think pfSense supports DNS-over-https.
-
Unbound as validating resolver without forwarding, and DNSSEC: My understanding is that the ISP can still see/monitor what your DNS requests are, and attempted manipulation could occur because the requests are unencrypted, but then the results would be un-trusted by Unbound and rejected because the DNSSEC chain of trust would have been broken.
A few questions...
-
Is my description above correct? Am I missing anything?
-
In resolver-only mode, what happens if I am asking for DNS for a domain that does not have DNSSEC enabled, can the reply be manipulated? Does the validation/rejection only work for domains that have DNSSEC properly implemented?
-
These are my settings, have I done it right or is there something I should change?
Many thanks in advance.....
-
-
Additional question, am seeing lots of these in Unbound logs, what do they mean?
Jun 19 13:46:25 unbound 22807:0 notice: remote address is 195.22.26.248 port 53 Jun 19 13:46:25 unbound 22807:0 notice: sendto failed: Permission denied Jun 19 13:43:57 unbound 22807:3 notice: remote address is 195.22.26.248 port 53 Jun 19 13:43:57 unbound 22807:3 notice: sendto failed: Permission denied Jun 19 13:42:45 unbound 22807:3 notice: remote address is 54.86.13.40 port 53 Jun 19 13:42:45 unbound 22807:3 notice: sendto failed: Permission denied Jun 19 13:42:45 unbound 22807:3 notice: remote address is 54.86.13.40 port 53
-
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
Why would they do that?
If an ISP starts blocking destinations and ports, they normally make some statement.
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
DNS-over-TLS: My understanding was that as long as it is working/connecting, the ISP is unable to see/monitor your DNS results, and you are guaranteed accurate results from the forwarder (trust assumed), as requests and replies are encrypted so interception is not possible.
Well, no. You forward (securely) to a resolver. Loosing DNSSEC on the way. And DNSSEC is the only way to be sure answers are good.
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
I am asking for DNS for a domain that does not have DNSSEC enabled, can the reply be manipulated? Does the validation/rejection only work for domains that have DNSSEC properly implemented?
Yes & Yes.
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
have I done it right or is there something I should change?
Yep.
Are you sure this is used by any of your devices on LAN ? : -
Thanks a lot for your replies....
@Gertjan said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
If an ISP starts blocking destinations and ports, they normally make some statement.
This is in the developing world... they don't say anything about anything :-)
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
DNS-over-TLS: My understanding was that as long as it is working/connecting, the ISP is unable to see/monitor your DNS results, and you are guaranteed accurate results from the forwarder (trust assumed), as requests and replies are encrypted so interception is not possible.
Well, no. You forward (securely) to a resolver. Loosing DNSSEC on the way. And DNSSEC is the only way to be sure answers are good.
I didn't realise that you lost DNSSEC when forwarding. But surely if you are using a trusted forwarder like Cloudflare, Quad9 etc then they are doing DNSSEC. Bottom line is I am willing to trust the results those services provide, I just don't trust the ISP. It's a home setup and I'm not doing anything unusual, but I don't want false DNS results either.
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
I am asking for DNS for a domain that does not have DNSSEC enabled, can the reply be manipulated? Does the validation/rejection only work for domains that have DNSSEC properly implemented?
Yes & Yes.
Thanks for clarifying. That's disappointing.
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
have I done it right or is there something I should change?
Yep.
Are you sure this is used by any of your devices on LAN ? :I don't think it is being used. I ticked that box when I was setting up DNS-over-TLS and kept it listening, just in case I did for some reason have a device that was using it. But I assume there's no harm to having that running even if you aren't using it?
-
@occamsrazor I have found that recent Android devices attempt to use the SSL/TLS functionality by default and fail. I haven't yet had time to troubleshoot this and it may or may not be an issue for your setup, but that's been my experience in a campus environment.
-
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
I just don't trust the ISP
Keep in mind :
By default, the resolver (unbound) doesn't use any of the ISP name servers.
When DNS requests come back with 'DNSSEC' results, you know the answer is sure.
If not, true, your ISP can see them, even interact on them if there is no DNSSEC info.
Keep in mind : I don't have the numbers, but DNSSEC isn't wide spread at the moment.Btw, strange that your ISP blocks 853 TLS/DNS requests - maybe it was selling DNS traffic them to 'some one'. You using 853 makes that info out of reach. Forcing you to use the clear '53'.
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
But I assume there's no harm to having that running even if you aren't using it?
I guess not.
edit : see also the remark of @beatvjiking -
For further perspective, in this situation I personally would run Unbound as a true resolver, rather than a forwarder, and keep the following option on:
Do not turn on the strict mode - it will break a lot of stuff.Caching queries and sending minimal content upstream, getting it from the source whenever possible, is going to prevent as many queries as possible from passing through your ISP, as well as ensuring locally that DNSSEC is in fact valid/trustworthy in as many parts of the chain as possible. In addition, queries will be minimal (if you already know where the root for .com is you don't need to ask again until that info expires, for example) and thus require more effort on your ISP's part to reconstruct (if that's what they're trying to do).
If they're taking port 853 off the table despite your wanting to use it, no sense in making it any easier for them to mess with your DNS :)
-
@Gertjan said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
I just don't trust the ISP
Keep in mind :
By default, the resolver (unbound) doesn't use any of the ISP name servers.Sure. What I mean is I don't trust the ISP to not deliberately intercept and alter results obtained from other servers.
When DNS requests come back with 'DNSSEC' results, you know the answer is sure.
If not, true, your ISP can see them, even interact on them if there is no DNSSEC info.
Keep in mind : I don't have the numbers, but DNSSEC isn't wide spread at the moment.Yes that's the problem. With DNS-over-TLS I could be sure that any results received were authentic (Based on the assumption that Cloudflare, Quad9, themselves are not giving false results and for my scenario, that is an assumption that I am happy to make). Whereas when using the resolver alone, I can be sure of results for DNSSEC-enabled domains, but for non-DNSSEC-enabled domains the results could still be manipulated and I would never know.
Btw, strange that your ISP blocks 853 TLS/DNS requests - maybe it was selling DNS traffic them to 'some one'. You using 853 makes that info out of reach. Forcing you to use the clear '53'.
Yes exactly, the only reason to block 853 would be to force people to use 53. And why would you want to do that except if you wanted to manipulate or monitor. The reason could be as simple as them wanting to block some websites, or monitor requests for the benefit of security services etc.
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
But I assume there's no harm to having that running even if you aren't using it?
I guess not.
edit : see also the remark of @beatvjikingI don't have any Android phones, but I do have various IOT and entertainment devices. I guess my reason for keeping it ticked was that if I did use a device that worked this way, then DNS wouldn't be broken for them (given I have a rule blocking 53/853 to any other destination).
-
@beatvjiking said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
For further perspective, in this situation I personally would run Unbound as a true resolver, rather than a forwarder, and keep the following option on:
Do not turn on the strict mode - it will break a lot of stuff.Caching queries and sending minimal content upstream, getting it from the source whenever possible, is going to prevent as many queries as possible from passing through your ISP, as well as ensuring locally that DNSSEC is in fact valid/trustworthy in as many parts of the chain as possible. In addition, queries will be minimal (if you already know where the root for .com is you don't need to ask again until that info expires, for example) and thus require more effort on your ISP's part to reconstruct (if that's what they're trying to do).
If they're taking port 853 off the table despite your wanting to use it, no sense in making it any easier for them to mess with your DNS :)
Thanks. I will try turning Query Name Minimization on.
Yes it's weird about the 853 blocking. I am still doing some testing including asking a friend on the same ISP to check if his link is the same... there's always a possibility I'm missing something and they are not really blocking, but it appears that way. -
I asked my friend to test on his line today with the same ISP and port 853 was not blocked. I then tried again today on my line, and now it is not blocked either.
When I test from both my Mac on the LAN, and from pfSense command line, I get this:
nc -vz 9.9.9.9 853 found 0 associations found 1 connections: 1: flags=82<CONNECTED,PREFERRED> outif en0 src 192.168.0.16 port 50240 dst 9.9.9.9 port 853 rank info not available TCP aux info available Connection to 9.9.9.9 port 853 [tcp/*] succeeded!
So that's weird, and I started to think it was maybe just a glitch with the ISP yesterday. So I figured I would try to re-enable DNS-over TLS. I changed nothing in the settings I posted a few posts above, except to re-enable Forwarding Mode, and restart Unbound. My general setup is this:
Bang.... suddently my Mac stops resolving DNS like it did before, even though this time my LAN machine still gets successful output from a port 853 test. It seems that the issue may be more to do with something inside pfSense or Unbound, rather than the ISP. What on earth could be going on?
I feel a bit stupid now with all these questions and your helpful answers, but whatever happens I'm certainly learning a lot, so thanks....
-
@occamsrazor said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
I can be sure of results for DNSSEC-enabled domains, but for non-DNSSEC-enabled domains the results could still be manipulated and I would never know.
And who says the info was not manipulated before cloudflare or google or whoever you forward to? They are just serving up what is in their cache - if has not been validated via dnssec, then it could be junk just as well.
You asking some forwarder for something doesn't mean its valid or has not been messed with.. Your just trusting them to not manipulate it more you trust your isp... Which to be honest doesn't make a lot of sense.. Who has more to gain from dns shenanigans some isp with x number of customers.. Or some site serving up dns to the globe? ;)
-
@johnpoz said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
And who says the info was not manipulated before cloudflare or google or whoever you forward to? They are just serving up what is in their cache - if has not been validated via dnssec, then it could be junk just as well.
That is possible, I am aware. And I know you feel strongly from previous discussions that resolver is a better option, and I respect your experience and opinion. But let's look at the pros and cons...
Resolver via ISP:
Pros: Does not go through middle man, can use DNSSEC, DNSSEC-enabled domains can be trusted and if interfered with results would be rejected.
Cons: Non-DNSSEC-enabled domains (of which it seems there are many) can be interfered with at the ISP level or anywhere inbetween. No DNS requests are encrypted so can be seen and monitored by ISP.DNS-over TLS with Quad9:
Pros: Requests to forwarder are encrypted and can't be interfered with. ISP can not monitor the DNS requests (although obviously can do to resulting connections to the IP addresses). Forwarder implements DNSSEC themselves so results they give for DNSSEC-enabled domains should be accurate unless they are messing with it themselves. Optional blocking of malicious domains at the DNS level.
Cons: Do you trust the forwarder?So yes, it really comes down to do you trust more the forwarder, or the ISP?
@johnpoz said in Understanding DNS validating resolver w/ DNSSEC vs DNS-over-TLS and interception:
Your just trusting them to not manipulate it more you trust your isp... Which to be honest doesn't make a lot of sense.. Who has more to gain from dns shenanigans some isp with x number of customers.. Or some site serving up dns to the globe? ;)
Well I am talking about ISPs in developing countries where:
- There is no legal framework governing what they do.
- Security services get anything they want from them with no rules or legal basis. If they walk in and tell the ISP to redirect some sites DNS they'll get it instantly.
- There is little to stop some malicious ISP employee from doing same.
- ISP Employees have previously leaked large amounts of personal subscriber information including passport and ID card information.
- Their own security and technical expertise is poorer, and so chance of them being hacked by third-parties.
- An example - one ISP (not mine) previously ran entire neighborhoods of customers in the same subnet with no vlans or firewalls between them.
- There is no technically-minded local userbase to monitor, determine or complain if the ISP is doing bad things. No-one globally is looking at what they do.
Versus.... Using Quad9 just as an example...
- A global DNS provider regulated as 501(c)(3) nonprofit organization (Charitable Organization, Educational Organization) founded by IBM, Packet Clearing House, & Global Cyber Alliance and based in California.
- A large global userbase capable of monitoring results, with frequent comparisons and tests made between it and other global DNS providers.
- As a result I would hope that if they were really messing with results, it would be found out by someone somewhere... and I don't see the incentive for them to do it given their nonprofit status.
So yes... for me I do trust such providers more than my ISP.
All of that said... I haven't been able to work out the issues I suddenly started having with DNS-over-TLS after it working seamlessly for a long time. I feel now the issue is something in pfSense not the ISP. But I don't currently have the time to spend on troubleshooting it so I'm sticking with straight resolver for now. While I still have less trust in its theoretical overrall privacy/authenticity in my particular situation.... I have to say it is performing very well indeed, is fast, and has had no issues.... so I may stick with it.
PS - I'm aware for optimal security from local/country issues it's better to just use a VPN, and I do use that selectively. And have the capability to apply it to my whole LAN. But I don't find it suitable for use on all my LAN and general use.