DHCP bypasses Firewall Rules?
-
Background: I set up my kids computers to use a special DNS server. I created a block rule for port 53 and set DHCP/DNS up to use 8.8.8.8 first, then use my special local server. The purpose for this is so i can enable the access and disable via firewall. I want a single firewall rule that allows me to turn on and off DNS access to certain servers which would allow me to block Google, but turn it on and off easily.
What I expect: If I cut off access via firewall rule, the clients should not be able to access servers, even those specified as DNS servers in the DHCP sectiion.
What I am seeing: The firewall is not blocking requests for DNS servers specified in client-specific DHCP/DNS. It appears DHCP DNS overrides Firewall Rules.
-
It does not. You have done something wrong. Post your rules.
There is no "use 8.8.8.8 first." You give two servers to the hosts and they can use them in any order they want.
-
Sure, Here we go.
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions * * * LAN Address 80 22 * * Anti-Lockout Rule 0/0 B 0/0 B IPv4 TCP * * closet server 53 (DNS) * none Allow kids machines to go to local dns 0/0 B IPv4+6 TCP Kids Machines * * 53 (DNS) * none Block previously non-passed requests to port 53 0/0 B IPv6 * LAN net * * * * none Default allow LAN IPv6 to any rule - changed to reje 331/129.52 GiB IPv4 * LAN net * * * * none Default allow LAN to any ruleThe devices in question have DNS set to 8.8.8.8, then my local 192.168.1.107 DNS server. However, if the device has 8.8.8.8 set, it does not block access to YouTube.
-
DNS is TCP/UDP, not TCP.
-
^^^^
And the client is usually UDP. TCP is used between servers to exchange records. -
IPv6 and DNSSEC can push a DNS response over 512 bytes and trigger TCP during normal resolution so you want to pass both from resolver clients to potential servers.
-
Yep, that's why I said "usually". However, the OP didn't allow for UDP, which is required, as UDP is tried first, then falls back to TCP when necessary.
-
"There is no "use 8.8.8.8 first." You give two servers to the hosts and they can use them in any order they want."
I want to stress this point as well from Derelict.. It is a common misconception that dns clients use listed dns is some sort of simple round robin order… While this might be true initially.. A client should try and use the first dns server listed. This is good maybe the first query, and if that is always fine and fast and no errors then sure you would expect the client to always use that dns.
But in the real world this is never the case. If you have more than 1 dns listed on a client, you can not be sure which one they are going to ask. And they sure don't ask them in any sort of order after client is been running for a while doing lots of dns queries. Well there is a some order to it, like everything in IT - there is a method.. But it can be a quite complicated algorithm that is used. Timeouts and neg responses play a roll as well does good queries and timing of them, etc.
Some quotes from, its a bit dated but still they haven't really overhauled the process.
https://technet.microsoft.com/en-us/library/dd197552(WS.10).aspx
DNS Processes and Interactions"The DNS Client service keeps track of which servers answer name queries more quickly, and it moves servers up or down on the list based on how quickly they reply to name queries."
"If at any point the DNS Client service receives a negative response from a server, it removes every server on that adapter from consideration during this search"Please feel free to do more research on the OS in use, the dns client your using and specifics too it, etc..
But what they don't do is ask dns 1, and if no answer ask dns 2, and then when looking for something else go to back to dns 1, etc.
In a nutshell If you list more than 1 dns server its going to be anyones guess what dns gets asked, and quite often if nx is returned then it doesn't go ask the other one.
The only time you should list more than 1 dns for a client is if all the dns your going to list return the same stuff. So for example if you want to use 2 public dns, ok sure - you don't care which one your asking for dns they will return the same stuff.. Or atleast they should for any public dns record.. There could always be differences in caches, etc. records that got changed but who you asked still had old record in cache, while other one ttl expired and they have new record. Be in the big picture they will return the same records for public stuff.
But public dns does not have clue one to anything you would be hosting locally, like your AD or box.mylocaldomain.tld etc.. If you have local stuff you want to resolve, then you should ONLY point to local dns!!! Now if you have more than 1 local nameserver that all house the same records for your local stuff - sure you can point to multiple of those.
But pointing to public dns like 8.8.8.8 and then some nameserver(s) that resolves your local stuff is a BORKED configuration!!! If you have local stuff you want to resolve then you should ONLY point to those local nameservers for dns.. And then those ns can either forward or resolve for your public stuff.
And yes dns can use udp and or tcp. If you want a working dns you should allow for both udp and tcp.. While yes normally udp is going to be used, as mentioned there are cases when tcp can and does get used. If you only allow udp you might have some issues, if you only allow tcp its prob going to be just a fail for most everything unless you tell your client to use tcp directly. Your rules that allow dns should be udp/tcp..
-
^^^^
As mentioned earlier, UDP is used, unless the response it greater than 512 bytes. When that happens, the server returns truncated info, with the truncation bit set. At this point, the client will request via TCP. The client does not start with TCP. It must start with UDP. Exchanging zone records, between servers, always uses TCP. but that wouldn't likely be a concern for a home user.
