Unbound vs Forwarding for DNS
-
So, if I use unbound for DNS and an Ad comes up requesting a China server it is going to hit a Chinese server requesting DNS. If I use Forwarding for DNS to QUAD9 then the Chinese DNS will be forwarded from QUAD9.
If you have Pfblocker blocking China then DNS is still working off China servers with unbound and Forwarding is not using QUAD9.
I believe this is true. I posted and steve kind of answered. More than I understand. I asked under an another topic so I am moving here under DNS. So, I can fully understand.
I also asked if you can block outbound on the LAN side. If you block China on the firewall on the WAN side a packet will be sent and the return will be blocked. If you block on the LAN side no packet will be sent to China. The problem is if you block on the LAN side you can take a performance hit routing local networks with lots of ACLs. If you backup a local hardrive across networks then I assume then the data needs to run all those ACLs for China since they are on the LAN side.
I was kind of asking this using Pfblocker to block China. I have never run Pfblocker.
But Steve implied to me that outbound will not be blocked on the LAN side? So, are we sending packets to China and blocking the return? How is this working? I would rather not send anything to China. I don't want to block the return packet only after sending data to China.If we need to move to Pfblocker this is fine also.
So right now I am running Forwarding for DNS to QUAD9 so China receives nothing from me.
I am up in the air about Pfblocker. Will it LAN side block?PS
I can get around any performance local LAN ACLs hit as I use a Cisco layer 3 switch for local routing. -
@coxhaus Only the first connection/packet is compared to firewall rules, then it will find the connection in the state table (list of open connections) and allow it. So it doesn't process every rule for every packet.
Ignoring floating rules for a minute...
Firewall rules are checked as packets arrive on an interface. So as the packet from LAN to China arrives on LAN it is blocked or allowed.
After the packet goes past LAN and is allowed then the packet goes out WAN. The response is allowed because there is an open state/connection. Rules on WAN do not apply at all.
pfBlocker can be used to block by country. One needs a free MaxMind account to download the country data.
If you resolve DNS directly then yes your router will potentially contact name servers in other countries. And yes you can forward to Quad9 instead. (just disable DNSSEC like I mentioned in the other thread)
-
@SteveITS
On the LAN side, outbound. So once the state table with the first connection packet is set to blocked by checking the rules then all other connection packets are blocked by the state table. but only the first packet is checked.WAN firewall rules work on inbound only so they are not checked on outbound. Assume they work the same as outbound but instead are inbound.
This is kind of what I was thinking.
If you block China on the WAN side, then all data will be sent because WAN is not checked on outbound and the return packets will be blocked.
If China initiates and your block is on the LAN side then it will flow inbound because you are only blocking out bound but NAT takes care of it and blocks it.
So you really want to block China on the LAN side.
-
@coxhaus the state table doesn’t block anything it only allows what was previously allowed by firewall rule.
The rest is correct. :) of course for an internet packet to get to LAN it has to be allowed by WAN rule or NAT+rule.
-
@SteveITS
Yes, you could block China on both sides but the important one is LAN.I could not find a setting for DNSSEC under Forwarding. So, I assume it is off. It works well with 24.03.
-
@coxhaus DNSSEC is an option in Unbound/Resolver, as is forwarding. But DNS Forwarder/dnsmasq works also.
-
@coxhaus said in Unbound vs Forwarding for DNS:
If you have Pfblocker blocking China then DNS is still working off China servers with unbound and Forwarding is not using QUAD9.
How this all works :
Unbound can resolve directly, or it asks another resolver to do its job for unbound, that doesn't really matter. (still strange, a resolver has to ask a resolver .... why ?).
What happens is :
A device on your LAN asks to pfSense, using UDP or TCP, to port 53 of pfSense, where unbound is listening : "Gime the IPv4 of feishu.cn ?".
Unbound will look into its cache first (!), and if it is there, with a positive TTL, it will reply direct with the A it already has.
If unbound doesn't have the answer, it will start to resolve (or forward).
It starts by using some internal Python API calls, and, as you have pfblockerng installed, these function get called in the very beginning, even before unbound starts to actually contact outside DNS resources (resolving, forwarding, whatever).
The pfBlockerng python file will compare the looked for host name, in this case "feishu.cn", with the main big pfBlockerng DNSBL list it has assembled from all your our DNSBL feeds.
If there was a hit (match), the python function will resturn direct to unbound with the answer "Found it : it's 0.0.0.0 !!" and the LAN device will get that answer.
Of course, with 0.0.0.0 the device can't connect to "anything".
Btw : If you chose for the totally, IMHO useless, DNSBL WebServer/VIP logging, the unbound (pfBlockerng) return 10.10.10.1 which is RFC1918 so also useless for the LAN device.No need to block or do anything with your WAN interface.
Because DNS to the 53 port of pfSense is by nature not encrypted, it is in theory possible to have some IDS tool inspect the incoming (LAN) Ethernet DNS packets, and have the payload (the data part) analyzed, so it can recognize a DNS lookup request, compare the payload text with a DNSBL, and when there is a hit, discard the packet (really bad behavior : the device will repeat the request over an over).
Or send a NAK back - or some other pre build NAK answer.
But why bother : unbound is very able to handle DNSBL (using a file it loads at startup) just fine - or even better, using the so called python mode. -
@Gertjan
I think I will stay with DNS Forwarding on port 53 to QUAD9. I don't think anybody will hack from a US big ISP to QUAD9. I think it is a better risk than a query to a China DNS server using unbound. They could be making lists of all the queries hitting their servers. I rather not be on that list.I am not interested in getting a returned broadcast address or a private address. Maybe I will install SNORT again. I think they have a DNS packet inspector.
