Blocking DNS versus Redirecting DNS

The Lurker

[H]F Junkie
Joined
Jul 1, 2001
Messages
13,581
I have been tracking down some errant ADware issues on my home network and I learned that some of my devices were completely bypassing the PFSense DNS resolver. That lead me to finding this link:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html

I am confused between redirecting DNS queries and blocking DNS queries. Both ultimately force the client to query the PfSense resolver, but what is the difference between redirecting and blocking?

While I am here, can someone explain why DNS over HTTPS cannot be blocked on the firewall? I am assuming because it uses the same port as regular traffic and its not possible to tell whats DNS versus everything else.
 

Farva

Extremely [H]
Joined
Feb 3, 2004
Messages
37,331
You need to set your rules for DNS only to your LAN and block external DNS.

1605926182874.png
 
Joined
Dec 1, 2011
Messages
910
I am confused between redirecting DNS queries and blocking DNS queries. Both ultimately force the client to query the PfSense resolver, but what is the difference between redirecting and blocking?

The names are pretty descriptive of what's going on. One simply blocks the connection, and it fails (and the client may or may not try another resolver). The other redirects it to some other destination (e.g., your own DNS resolver).


While I am here, can someone explain why DNS over HTTPS cannot be blocked on the firewall? I am assuming because it uses the same port as regular traffic and its not possible to tell whats DNS versus everything else.

Pretty much. Off-hand, about the only I can think of to block DoH is an application firewall that sniffed out the SNI and compared it to a list of known DoH resolvers. But that would still miss a lot and be a bitch to maintain. (And thankfully, even unencrypted SNI will not be a thing in the future.)
 

MrGuvernment

Fully [H]
Joined
Aug 3, 2004
Messages
19,607
Use the firewall to block port 53 and 853 then do an allow rule and point it to your PFSense box, as Farva put above. This way nothing can bypass DNS, unless it starts using DNS over HTTPS, then you are screwed. Do not do a redirect if you are trying to clean our adware.

You could also use pfblocker and block outbound connections to countries you know you never visit for content.
 

The Lurker

[H]F Junkie
Joined
Jul 1, 2001
Messages
13,581
Use the firewall to block port 53 and 853 then do an allow rule and point it to your PFSense box, as Farva put above. This way nothing can bypass DNS, unless it starts using DNS over HTTPS, then you are screwed. Do not do a redirect if you are trying to clean our adware.

You could also use pfblocker and block outbound connections to countries you know you never visit for content.

Why doesn't redirecting have the same affect as blocking or to put another way, what do both rules do together that redirecting would miss alone?


I am using PFblocker with geofencing as one of the protections but only to Africa I think.
 

Farva

Extremely [H]
Joined
Feb 3, 2004
Messages
37,331
Use the firewall to block port 53 and 853 then do an allow rule and point it to your PFSense box, as Farva put above. This way nothing can bypass DNS, unless it starts using DNS over HTTPS, then you are screwed. Do not do a redirect if you are trying to clean our adware.

You could also use pfblocker and block outbound connections to countries you know you never visit for content.

Why doesn't redirecting have the same affect as blocking or to put another way, what do both rules do together that redirecting would miss alone?


I am using PFblocker with geofencing as one of the protections but only to Africa I think.
Maxmind requires a subscription now, unless you are paying for it, then you can ignore this post.


If you are doing it another way, I'd love to know how.
 

MrGuvernment

Fully [H]
Joined
Aug 3, 2004
Messages
19,607
By simply blocking DNS, any systems using a DNS server that is not yours, will simply not work. You can then monitor your firewall logs for outbound requests on port 53 that are blocked and find your source
 

The Lurker

[H]F Junkie
Joined
Jul 1, 2001
Messages
13,581
By simply blocking DNS, any systems using a DNS server that is not yours, will simply not work. You can then monitor your firewall logs for outbound requests on port 53 that are blocked and find your source

But wouldn't that systems request come over 53 which would get redirected and similarly get logged?
 

The Lurker

[H]F Junkie
Joined
Jul 1, 2001
Messages
13,581
Maxmind requires a subscription now, unless you are paying for it, then you can ignore this post.


If you are doing it another way, I'd love to know how.

They have a free version of their service you can register for to use with geo fencing. It's explained 3 minutes in.
 
  • Like
Reactions: Farva
like this

Shikami

Gawd
Joined
Apr 5, 2010
Messages
745
You can have a host on the network either friendly or hostile (taken over). This host can then use DNS of its own accord to look up whatever it wants to resolve. It can point to a malicious host(s) and allow packets into the LAN for compromise-very important due to the fact that that most firewalls in use have no ingress filter to internal connections after NAT/Resolved host(s) handshaking. Many IoT's have Google's DNS integrated into them to send the data to their servers. For example, an Amazon Echo will use Google's DNS to send analytics. Redirecting DNS will force the DNS request for that host to 8.8.8.8 to have to use the pfSense's DNS servers. Basically, if it tries to go outside of the network, NAT captures the requests and then makes it go through Resolver's settings.

There is also data that can be collected within the requests. Say you rather use a provided router, and therefore likely the ISP's DNS by default. Anything you look up shopping sites, diapers, whatever, you look up can then be metadata they collect and even fingerprint you. Your activity, and such on the internet is well known. You can even fingerprint the NTP requests from a host to the crystal used due to the variations of the jitter caused by heat and such-look it up. Everything gives data, even the act of not giving is data itself and truly cannot be escaped from. However limiting can be fun, and consuming of your admin'ing soul.

The biggest mistake that many make with pfSense is not running Resolver to query the root servers only. They think that encryption will "save" them. Funny thing is it is slower than the local request cache and resolution. You still send the request to a place that collects metadata, and you are not controlling your DNS request in a better secure method.

Limiting the DNS request to only be through the pfSense server and then not allow any third party or external resolution is very, very important. Honestly, every business and household should be at this level of security, and any ISP provider in which you cannot run your own endpoint is not worth it. If you ever watch your network you can see just how many devices try to talk to an external DNS's-it can be very eye opening about security for the newly initiated.

With pfBlocker you have a DNS sinkhole. Any rule that it not allowed is blocked. So, many ads, malware sites, etc will just get the packet dropped based on the feeds. However, there is an inverse relationship with security. As security increase usability will decrease. Working the feeds to be just right for usability can be a bit annoying, but you again will see how much will "call home." The caveat I do not like is how the talk on the network can increase much-much more due to blocking (sinkhole). But honestly, Do you really need all these devices?

Mix those the rules, forcing DNS to local server, NAT redirection of DNS requests to be force through the local server, and then finally sinkhole the requests can and should be practiced by all-if at all possible

To note when you have DNS redirect properly configured, in states summary you will have something akin to this LAN Address:12345 -> 127.0.0.1:53 (8.8.8.8:53). So, your Amazon Echo 192.168.0.x:12345 -> 127.0.0.1:53 (8.8.8.8):53 would get redirected to use local cache, root server lookup, or directed to the poorly secure "encrypted" server at Cloudflare...which BTW is a Google co-project.

If anyone is using pfSense, seriously do not use any other DNS servers. Just query root servers only.

Oh, one last thing...remember that when rejecting you allow the network to function and resolve routing issues. So, with the DNS redirection you want rejection. VLAN's , for example, you want blocking, due to the need to filter the networks and only allow particular local area network interaction. Blocking you are saying fuck you, such like pfBlocker helps with if-for instance-a malware packet tries to find its way in or out.


Oh, forgot....You cannot enforce DoH because you have to block/filter HTTPS, and how are you to do that when anything web related is HTTPS? DoH is an abomination, and anyone attempting to implement that should never be an advisor to security, or anyone allowed for anything networking. This is Big-Corp trying to change the rules so they can get away with things. Fucking asinine shit really. There never should be or have been an argument about it. DoT only, if you want to use "encryption."

Maxmind only requires registration.
 
Last edited:

bman212121

[H]ard|Gawd
Joined
Aug 18, 2011
Messages
1,719
You need to set your rules for DNS only to your LAN and block external DNS.

View attachment 301455

Keep in mind these rules are not completely blocking DNS. You can use TCP to send DNS requests, and generally speaking TCP is used when the message length is over 512 bytes.

Most DNS [RFC1034] transactions take place over UDP [RFC768]. TCP
[RFC793] is always used for full zone transfers (using AXFR) and is
often used for messages whose sizes exceed the DNS protocol's
original 512-byte limit. The growing deployment of DNS Security
(DNSSEC) and IPv6 has increased response sizes and therefore the use
of TCP. The need for increased TCP use has also been driven by the
protection it provides against address spoofing and therefore
exploitation of DNS in reflection/amplification attacks. It is now
widely used in Response Rate Limiting [RRL1] [RRL2]. Additionally,
recent work on DNS privacy solutions such as [DNS-over-TLS] is
another motivation to revisit DNS-over-TCP requirements.

Section 6.1.3.2 of [RFC1123] states:

DNS resolvers and recursive servers MUST support UDP, and SHOULD
support TCP, for sending (non-zone-transfer) queries.

However, some implementors have taken the text quoted above to mean
that TCP support is an optional feature of the DNS protocol.

The majority of DNS server operators already support TCP, and the
default configuration for most software implementations is to support
TCP. The primary audience for this document is those implementors
whose limited support for TCP restricts interoperability and hinders
deployment of new DNS features.

This document therefore updates the core DNS protocol specifications
such that support for TCP is henceforth a REQUIRED part of a full DNS
protocol implementation.

https://tools.ietf.org/html/rfc7766
 
Top