DNS Leaking on all interfaces
-
I am a new pfSense user, so I might be missing something obvious. I go to dnsleak.com and no matter whether I am visiting from a machine on my vpn vlan or my clearnet vlan it still identifies comcast as my dns. I do not have DNS forwarding enabled, because my understanding is that it would then use those DNS servers all the time instead of my local cache and then the root DNS servers for anything lot locally cached. I admit I could be wrong in my understanding of how unbound works.
My DNS Server Settings are as follows:
My DNS Resolver settings are as follows:
I have a firewall rule that directs traffic from my VPN LAN to the VPN Gateway, and a NAT rule that takes anyIP from the VPN network and NATs it to the VPN network address. Other than that regular outgoing rules. Both networks leak DNS when I check dnsleak.com.
What is the proper way to set up my DNS so that it queries locally when able and only direct to the root DNS servers when unable to find the address locally? -
@cubeyglyph well since you have no remote - not sure what dns it would query.. But you could set it to this
But that is for what pfsense resolves - that wouldn't be you running some dnsleak test on some client on your network.. If you don't want clients to use anything other than pfsense for their dns, then set them to only use pfsense, and or block any other dns queries from your networks to anything other than pfsense.
-
@johnpoz This is the part that I think I am confused on. I thought that by default unbound would be reaching out to DNS Root servers, not the Comcast DNS servers supplied from the WAN interface. If I override the DNS, the DNS Resolution Behavior would point it locally first, then over the DNS forwarder (1.1.1.1 or whatever I set it to) instead of the DNS Root servers. Am I correct in this? Is there any way to stop Comcast from hijacking the DNS queries besides forwarding the DNS to a specific DNS server or am I SOL because of my internet provider?
-
@cubeyglyph said in DNS Leaking on all interfaces:
I thought that by default unbound would be reaching out to DNS Root servers
Yup that is out of the box what it does..
Why do you think comcast is hijacking your dns.. I find this highly highly unlikely..
Again - what some client does via some dnsleak site has zero to do with your settings on pfsense.. Unless!! you specifically have the client only set to use pfsense for its dns..
When using pfsense as your dns, which resolves via roots - a dns leak site will show your wan IP as the IP..
-
@cubeyglyph Problem is Unbound is doing it directly over your internet connection, so you see your IP-address from comcast there.
-
here is my dns leak test - with a resolver it will show your IP..
And again - what you have set in pfsense for dns, has ZERO to do with what your clients might be asking. If your seeing some comcast dns servers listed there - then your client is talking to them which has nothing to do with pfsense setup on be it resolves or forwards, etc.
Your setup shows pfsense resolving - it wouldn't be using comcast dns, but your client could be.
Why don't you sniff on pfsense wan and see where it is sending traffic.. If your saying your sending traffic only to roots and authoritative ns via normal resolving. And leak test shows you comcast dns.. ie via interception - that is a major concern.. There is one thing logging what users are going to via what they ask their dns, or even sniffing one what dns is being asked for but active interception and redirection is something that would be major news for an isp like comcast to be doing
-
@johnpoz
OK, I feel like a dunce, but let me make sure I understand you. The DNSLeak sites will always show my own IP no matter what because that is where the DNS queries are coming from notwhere they are reaching out to?
when I use nslookup, I get my firewall IP then Non-authoritative answers, indicating it was served from a cache (the domain I looked up below I have never searched for or visited before)Server: pf.ip.add.ress Address: pf.ip.address#53 Non-authoritative answer: Name: crazydomains.sg Address: 172.67.206.194 Name: crazydomains.sg Address: 104.21.69.91During the packet capture, The only traffic I saw going to what I identified as a Comcast IP were ICMP to the .1 address (gateway my router uses I am assuming). I filtered tcp.port == 53 and saw no dns queries at all.
So I guess the question comes down to, when I see Comcast on that DNS leak site, is that just indicating what IP is making the DNS requests?
Sorry if I'm missing something obvious here. -
@cubeyglyph yes - when you resolve you directly talk to the roots, and then the authoritative ns for whatever you are looking up.
So yes the dns servers will see your IP, be that comcast or wowway or cox or whatever ISP your connecting with..
How those dns leak tests work - is they have you query some random unique entry.. They run the dns server were that has to be looked up at.. So they can log what IP asked for this unique entry they told your browser to look up. So yeah when you resolve - this will be your IP.
-
OK great thank you, it appears that I just misunderstood what that result implied.
Regarding intercepting clients which make DNS requests to specific servers (I know Firefox can bypass DNS and send to encrypted DNS if enabled) how would I block them and redirect them to my pfsense for DNS? -
@cubeyglyph problem with doh is uses standard 443 so it not all that easy to block.. Unlike dot which uses port 853.. Redirection of said types of encrypted dns is not really possible with the way clients should be validating the cert.. Now you could do it if you knew exactly who the client was trying to talk to, and have him trust your ca so you could do a mitm sort of attack..
Anyhoo..
You can for sure block doh via lists that are available that lists the IPs and fqdn, etc. pfblocker can come in handy for such things.
For firefox you can also setup the canary record so it shouldn't be doing that, etc.
-
@johnpoz
Gotcha. Yeah I didn't really think about that but to be honest I don't care if some IOT device is using some hard coded DNS really, I mostly want to prevent human controlled devices, and not enough to do any SSL decryption for some one-off applications. Thanks for all the help on this! -
@cubeyglyph no problem.. Its not that I hate the idea of doh or dot.. What I don't like is things like browsers doing it on their own without explicit direction from the user to do such a thing.
And until such time that sni are not in the clear - its pretty pointless anyway. Its more of companies to draw dns traffic to their services and circumvent filtering on the local side..
Its all really bad news if you ask me.. I block that shit for sure..
And also not a fan of applications or devices doing any sort of hard coding of which dns to use even if just normal udp 53, A device or application should use what is set on the the device or parent OS be static or via dhcp - period!!
If stuff like browsers want to offer doh or dot as an option - great do that.. But you better not do it without explicit freaking permission from the person running the running the browser.. I don't care how stupid you think the user is ;) You shouldn't be doing anything other than using what the OS says to use for dns without specific OK and setting from the operator of said software..
