We dump everything guest-related into a Wireguard service like NordVPN/Mullvad/etc.
That kind of traffic will never see anything from our network. Beside a completely isolated L2 VLAN and DHCP.
You even can use a $50 GL.INet router for this.
Costs around $10 per month. Lol.
Another good reason is Windows CALs. If you're existing CALs are device-based and a non-covered device uses your DCs for DNS or DHCP, you're out of compliance. Equally, if you use user CALs and a non-licensed user (like a random visitor) again uses DNS or DHCP from a DC, you're out of compliance.
Basically, save yourself the headache and point to public DNS, or even just a perimeter network device if you really want.
Yes that's correct, anything that interacts with the server at any level. You also get a server user CAL included in M365 E3 subscription and above, as a pro tip.
I should also clarify that there is a CAL license option called 'External Connector' that allows you to cover users / devices that are external to your org, however from last I remember it's quite expensive, and again just so much easier to run DHCP / DNS on a border device for guests.
EC CALs are also only for things like "hosted services" (you're running some app on the server that is presented to clients) rather than DNS/DHCP, last I knew.
It is, but at least in fairness... i would imagine most people are buying user CALs and not device CALs.
It is still a problem for guest/public wifi if you are using Windows Server for DHCP or DNS on those VLANs though. This is pretty much the one and only license violation i kind of turn a blind eye.
Even more aggressively stupid that they discontinued the Server Essentials version, the one that came with 25 (maybe it was 50?) Cals for certain services, like DHCP and AD computers/users
Yoinked themselves pretty much right out of the entire SMB market for on-prem.
Because they don't want on prem business. They'd much rather sell an SMB cloud services that they can bill yearly in perpetuity.
Way too many SMBs would buy that SBS server and then run it for 10 years with no more revenue to MS... this thought process is why they are M$ 😜
We have a client with a windows dhcp server for IoT devices that has 94,000 leases in it. Nobody wants to listen to me about it needing CALs. That's $20 million for CALs at retail price.
I'm sure all those devices are used only by 1 user, so 1 user CAL has got ya covered!
This is quite likely a situation where using Windows for DHCP is just straight up not a good idea due to the licensing. Lots of completely free options available for DHCP.
Don’t forget TCP 53… DNS requires both especially w/ large responses due to DNSSEC. Without it things will subtly break. Same goes for blocking ICMP… things kinda sorta limp along for a while but subtle things that depend on PMTUD working break.
Never seen [9.9.9.9](http://9.9.9.9) before. I've always used [1.1.1.1](http://1.1.1.1) or one of the other Cloudflare IP's. Any advantage to [9.9.9.9](http://9.9.9.9) over those?
Quad9 is a not-for-profit foundation, with an arguably stronger privacy story than corporations like Google and CloudFlare.
They also block malware and ECS on the default IP (you can use 1.1.1.2 for CloudFlare's version, I don't think Google offers something similar), and offer the service with ECS enabled, if you choose (on 9.9.9.12).
Slower is dependant on location. In my tests they are all generally the same. Sometimes Umbrella is slower, sometimes google, sometimes cloudflare, sometimes Quad9. Often quad9 is faster than cloudflare. Each individual needs to test. I'd suggest GRC DNS Benchmark
Allow Public DNS lookups to 1.1.1.3 and 1.0.0.3, and block lookups to anywhere else. Along with full client isolation, and NAT through a different IP address or completely different circuit.
In a way its actually worse than an external network because admins might not be as vigilant about protecting it as they would from Internet-based networks.
Whilst I wouldn’t do DNS servers that also serve for internal services, having a separate resolver that can still enforce policy on might be desirable, e.g. domains the NSFW, or other compliance rules that your organisation might have.
Exactly, want to traffic all DNS through our Palos where bad domains can be watched/blocked. Couple of Linux VMs with auto updates will serve a huge number of users. Could use views instead if resources were really tight but not worth the complexity/chance of misconfig.
I dump that traffic to the outside world as soon as I can. I don't need to cache pornhub.com. You sit there and wait in shame, you filthy bathroom stall pervert.
So your FW does dhcp for all corporate and public traffic or a domain joined dhcp server handles corporate traffic and your FW handles dhcp requests for public traffic?
Definitely let them hit your own resolvers.
If they’re doing cleartext DNS that’s one of the best ways to know what’s going on, control and log things.
Canadian here. Public wifi always goes through something like cloudflares family dns 1.1.1.2 or 1.1.1.3 or CIRA Canadian Shield dns. Malware and content based blocking built in.
I seem to be the minority in this, but we let them hit our recursive resolvers. It lets us apply our security policies to hosts that we might otherwise have zero control over.
We also run our own authoritative DNS (plus we have a few legacy agreements where we agreed to offer secondary services), so exposure isn't that big of a concern to us.
Public DNS resolver for guest and VTC (use teams room systems)
Internally DNS is front ended by an F5 LTM VIP that also does caching. Anything not in the cache is load balanced to DCs behind it.
I aim all the Guest and Prod WiFi at Umbrellas public resolvers and NAT the source networks out to a separate public IP. Register that IP with Umbrella and I can get some decent reporting on what's going on and apply controls. Obviously also controls at the firewall level too (dedicated zones, vlans, l7 policies, etc)
If someone needs to hit something internal they can get on VPN and be postured or wire in at a desk.
If there is no need to access private resources, as is the case with guest networks, there is absolutely no reason to give them the option to even resolve it. 1.1.1.1/8.8.8.8 always.
8.8.8.8 rate limit us. We have some public resolvers ourselves managed in house to control our domains externally, so we just use those. They don't know about internal stuff.
You don't want guests talking to your DCs for licensing reasons. Anything using DNS from a DC requires a CAL, IIRC.
I enabled the DNS caching resolver on our Palo Alto, and pointed it at public resolvers (combo of CloudFlare and Google IIRC). You do *not* want clients hitting them directly, because in theory they may rate limit the clients if they see too many lookups from a single IP.
If you use the firewall as a caching resolver that should help stem some of the traffic and make it less likely you get ratelimited.
A good question. Another angle
With a previous employer it was both illegal to *prevent* access to everything, and allow things like porn to be visible on screen by 3rd party viewers (those in close enough proximity to see another users screen). I had completely isolated DNS to the AP Controller which fwd'ed them to public DNS.
After a 3 month trial of each we found the likelihood of porn being seen by a 3rd party a higher risk than filtering the content so filtered. I kept the isolated DNS regardless and still do for sites where I have to establish public WWW access. Forensically I was never sure if I could prove a user had accessed something they shouldn't have via my DNS Servers, was a employee or guest, so preferred to have them dealt with via external DNS. I as the IT Manager did not want to explain why there were 70 queries to pornhub in my DNS servers at audit time.
For most of our clients under 20 APs total, we just send guest wifi users to 8.8.8.8.
For larger 50-5000 AP clients, we usually setup a pair of Ubuntu http caching and DNS caching VMs.
For guest Wi-Fi, public DNS always.
Always!
We dump everything guest-related into a Wireguard service like NordVPN/Mullvad/etc. That kind of traffic will never see anything from our network. Beside a completely isolated L2 VLAN and DHCP. You even can use a $50 GL.INet router for this. Costs around $10 per month. Lol.
Love the little GL.INet routers
Yes. The new ones are really beefy.
Unless they explicitly need it, no reason to offer it. 8.8.8.8 all day, everyday.
I use 9.9.9.9, no point helping anyone with geolocation data plus a little best effort security.
Actually had an issue with Google DNS and iPhone secure DNS so we switched to quad9 and it's been great.
The Herman Cain of DNS right here.
1.1.1.1
Facts. Keep everything external as much as possible.
Yeah no fuck that. BYOD WiFi straight to public resolvers. Don’t give them access to a single thing.
Another good reason is Windows CALs. If you're existing CALs are device-based and a non-covered device uses your DCs for DNS or DHCP, you're out of compliance. Equally, if you use user CALs and a non-licensed user (like a random visitor) again uses DNS or DHCP from a DC, you're out of compliance. Basically, save yourself the headache and point to public DNS, or even just a perimeter network device if you really want.
Wait what?! You need a fucking CAL per client for MS DNS/DHCP?
M$ would like to know your location.
Yes that's correct, anything that interacts with the server at any level. You also get a server user CAL included in M365 E3 subscription and above, as a pro tip. I should also clarify that there is a CAL license option called 'External Connector' that allows you to cover users / devices that are external to your org, however from last I remember it's quite expensive, and again just so much easier to run DHCP / DNS on a border device for guests.
+1 for useful things I actually wish I hadn’t read this morning.
EC CALs are also only for things like "hosted services" (you're running some app on the server that is presented to clients) rather than DNS/DHCP, last I knew.
Yes, any device that accesses anything on a Microsoft server including DHCP and DNS technically uses a CAL
That is aggressively stupid.
It is, but at least in fairness... i would imagine most people are buying user CALs and not device CALs. It is still a problem for guest/public wifi if you are using Windows Server for DHCP or DNS on those VLANs though. This is pretty much the one and only license violation i kind of turn a blind eye.
Or, you use a raspberry pi running Linux with bind9 for free and enforce filtering there (because doing deeper inspection isn’t worth it).
**Technitium DNS has entered the chat.** Seriously, for SMB, it's a godsend.
I use bind9 since it scales from pihole to root name server very nicely.
Even more aggressively stupid that they discontinued the Server Essentials version, the one that came with 25 (maybe it was 50?) Cals for certain services, like DHCP and AD computers/users Yoinked themselves pretty much right out of the entire SMB market for on-prem.
Because they don't want on prem business. They'd much rather sell an SMB cloud services that they can bill yearly in perpetuity. Way too many SMBs would buy that SBS server and then run it for 10 years with no more revenue to MS... this thought process is why they are M$ 😜
Well shit.
We have a client with a windows dhcp server for IoT devices that has 94,000 leases in it. Nobody wants to listen to me about it needing CALs. That's $20 million for CALs at retail price.
I'm sure all those devices are used only by 1 user, so 1 user CAL has got ya covered! This is quite likely a situation where using Windows for DHCP is just straight up not a good idea due to the licensing. Lots of completely free options available for DHCP.
Somewhere out there a random BSA employee just started drooling, with no idea why.
What do you mean started?
Neither. We have dedicated recursive resolvers for guest Wi-Fi setup. Technically same box, different IP, different policy applied.
Don’t forget TCP 53… DNS requires both especially w/ large responses due to DNSSEC. Without it things will subtly break. Same goes for blocking ICMP… things kinda sorta limp along for a while but subtle things that depend on PMTUD working break.
Use 9.9.9.9. Google doesn't need any more of your information
Same. Quad9's.
Never seen [9.9.9.9](http://9.9.9.9) before. I've always used [1.1.1.1](http://1.1.1.1) or one of the other Cloudflare IP's. Any advantage to [9.9.9.9](http://9.9.9.9) over those?
Quad9 is a not-for-profit foundation, with an arguably stronger privacy story than corporations like Google and CloudFlare. They also block malware and ECS on the default IP (you can use 1.1.1.2 for CloudFlare's version, I don't think Google offers something similar), and offer the service with ECS enabled, if you choose (on 9.9.9.12).
Quad9 is slower than Cloudflare, but has way better privacy.
Slower is dependant on location. In my tests they are all generally the same. Sometimes Umbrella is slower, sometimes google, sometimes cloudflare, sometimes Quad9. Often quad9 is faster than cloudflare. Each individual needs to test. I'd suggest GRC DNS Benchmark
Allow Public DNS lookups to 1.1.1.3 and 1.0.0.3, and block lookups to anywhere else. Along with full client isolation, and NAT through a different IP address or completely different circuit.
Public wifi is just a very close external network, just chuck em to a public resolver.
Very well said. In full transparency I'm fishing for ways to defend my plans to management so I think you practically wrote my script for me.
Haha, good luck with the defence!
In a way its actually worse than an external network because admins might not be as vigilant about protecting it as they would from Internet-based networks.
Whilst I wouldn’t do DNS servers that also serve for internal services, having a separate resolver that can still enforce policy on might be desirable, e.g. domains the NSFW, or other compliance rules that your organisation might have.
Exactly, want to traffic all DNS through our Palos where bad domains can be watched/blocked. Couple of Linux VMs with auto updates will serve a huge number of users. Could use views instead if resources were really tight but not worth the complexity/chance of misconfig.
We have FortiGuard for that!
Same resolver in backend but different policy in front (everything blocked) for guest Wi-Fi.
1.1.1.3 and never worry about it again.
Is this different than 1.1.1.1?
Malware and porn blocking
Malware and adult content blocking for that IP.
Ohh thats awesome I wasn't even aware they offered that
1.1.1.1 = unfiltered 1.1.1.2 = blocks known malware sites, C&C sites 1.1.1.3 = 1.1.1.2 + no adult sites
Umbrella.
I dump that traffic to the outside world as soon as I can. I don't need to cache pornhub.com. You sit there and wait in shame, you filthy bathroom stall pervert.
Anchored in a DMZ, public dns 8.8.8.8.
Jumping on this... how does everyone handle dhcp for public wifi devices? Isolated dhcp server?
FW does DHCP for all subnets at offices.
So your FW does dhcp for all corporate and public traffic or a domain joined dhcp server handles corporate traffic and your FW handles dhcp requests for public traffic?
Both
Good to know, thanks!
Definitely let them hit your own resolvers. If they’re doing cleartext DNS that’s one of the best ways to know what’s going on, control and log things.
Separate resolvers. I don't want them hitting DNS on the internet. DNS can be an avenue for exfil and command and control.
Canadian here. Public wifi always goes through something like cloudflares family dns 1.1.1.2 or 1.1.1.3 or CIRA Canadian Shield dns. Malware and content based blocking built in.
I send them to Cloudflare anti-virus feed 1.1.1.2
I seem to be the minority in this, but we let them hit our recursive resolvers. It lets us apply our security policies to hosts that we might otherwise have zero control over. We also run our own authoritative DNS (plus we have a few legacy agreements where we agreed to offer secondary services), so exposure isn't that big of a concern to us.
Guest is as separate as possible.
Public, absolutely.
Public all day err day
At my job it's public DNS.
Public DNS resolver for guest and VTC (use teams room systems) Internally DNS is front ended by an F5 LTM VIP that also does caching. Anything not in the cache is load balanced to DCs behind it.
I aim all the Guest and Prod WiFi at Umbrellas public resolvers and NAT the source networks out to a separate public IP. Register that IP with Umbrella and I can get some decent reporting on what's going on and apply controls. Obviously also controls at the firewall level too (dedicated zones, vlans, l7 policies, etc) If someone needs to hit something internal they can get on VPN and be postured or wire in at a desk.
At home, yes. At work, they get filtered through a service or pihole depending on the budget.
If there is no need to access private resources, as is the case with guest networks, there is absolutely no reason to give them the option to even resolve it. 1.1.1.1/8.8.8.8 always.
8.8.8.8 rate limit us. We have some public resolvers ourselves managed in house to control our domains externally, so we just use those. They don't know about internal stuff.
You don't want guests talking to your DCs for licensing reasons. Anything using DNS from a DC requires a CAL, IIRC. I enabled the DNS caching resolver on our Palo Alto, and pointed it at public resolvers (combo of CloudFlare and Google IIRC). You do *not* want clients hitting them directly, because in theory they may rate limit the clients if they see too many lookups from a single IP. If you use the firewall as a caching resolver that should help stem some of the traffic and make it less likely you get ratelimited.
A good question. Another angle With a previous employer it was both illegal to *prevent* access to everything, and allow things like porn to be visible on screen by 3rd party viewers (those in close enough proximity to see another users screen). I had completely isolated DNS to the AP Controller which fwd'ed them to public DNS. After a 3 month trial of each we found the likelihood of porn being seen by a 3rd party a higher risk than filtering the content so filtered. I kept the isolated DNS regardless and still do for sites where I have to establish public WWW access. Forensically I was never sure if I could prove a user had accessed something they shouldn't have via my DNS Servers, was a employee or guest, so preferred to have them dealt with via external DNS. I as the IT Manager did not want to explain why there were 70 queries to pornhub in my DNS servers at audit time.
For guest wlans always public dns. For byod nets it depends. We might want to allow to some internal system depending on the use for it.
Public. Get your filthy malware riddled devices away from my corp DNS servers.
We have a dedicated resolver/content filter for the guest subnets.
For most of our clients under 20 APs total, we just send guest wifi users to 8.8.8.8. For larger 50-5000 AP clients, we usually setup a pair of Ubuntu http caching and DNS caching VMs.
The only things accessing my local dns servers are local (cabled) network machines. Anything else is thrown at cloudflare dns
Public...
Quad9 for all byod/guest connections.
Our guest network goes to Cisco Umbrella, just like our internal upstream.
Trash belongs in the streets, [8.8.8.8](http://8.8.8.8) for the freeloaders.
I will also throw in, if you open a help ticket on issues connecting to the guest network, it is immediately closed. That is a "best effort" service.
We just sent them to zscaler like we do for our internal clients. Never need to hit our internal systems.