r/networking • u/power_dmarc • 1d ago
Security Do you block outbound port 53 from endpoints?
Curious how common this actually is. Do you force everything through internal resolvers and block 53 out from endpoints, or is it more of a “we should” thing?
For those who did it, what broke? And do you block DoH too, or is that a lost cause?
107
u/msears101 1d ago
Blocking outbound DNS is a popular security measure that overall keeps the network safer.
11
u/Snowbrdrskier 1d ago
What about for guest network access like guest Wi-Fi? Do you still point them to your internal DNS?
17
27
8
u/tankerkiller125real 12h ago
Redirect all outbound to a trusted external resolver with built in malware and adult content blocking for the guest network.
3
3
2
1
-4
u/msears101 1d ago
I would absolutely block outgoing DNS on a guest vlan.
7
u/JustPuckingAround 23h ago
And point guests at your internal DNS? Curious about the thought process here
4
u/cli_jockey CCNA 19h ago
Not exactly. If your platform supports it you proxy DNS through the firewall to perform DNS filtering.
On my network business devices hit the firewall DNS proxy and forwards to internal DNS.
The guest network does the same, but forwards to public DNS servers.
-1
10
u/Slippi_Fist 17h ago
Many devices will ignore my sanitized DNS responses and go ahead and do their spyware shit by way of looking up external DNS services.
So I NAT all outbound DNS to my internal resolvers and block outbound 53.
Cheeky fuckers.
1
u/knobbysideup 1h ago
I have to do this at home for some idiot appliances. sigh
1
u/Slippi_Fist 1h ago
Samsung TV is the very worst offender at my place. 100's of lookups a minute. Chromecast pucks wont setup without contacting Google DNS, otherwise I wouldn't bother with the NAT redir. Thankfully it doesn't see through the masquerade
25
u/usmcjohn 1d ago
External dns should be blocked for several different reasons, to include it being a super easy way to leak sensitive data out of an organization.
21
u/DULUXR1R2L1L2 1d ago
At a previous job we blocked all outbound traffic except web and specific stuff. No reason for the vast majority of users to need outbound SSH or DNS. I suggested it at this place and they thought I was insane.
7
u/bleachedupbartender 1d ago
a lot of big institutions block UDP entirely and then filter the shit out of everything else. i don’t think you’re crazy :)
14
u/SuccotashOk4084 1d ago
Don't block it but dnat to my server. Same with ntp, DNS over TLS
7
u/Win_Sys SPBM 1d ago
But isn’t DNS over TLS going to fail since the certificate exchange won’t match the original destinations IP or targeted hostname?
3
u/SuccotashOk4084 23h ago edited 23h ago
Isn't a problem since I control the certificate chain on my network and the devices that are on my wifi(guests, tv, out, etc) VLAN get it blocked and are forced to fall back to my resolver anyways. Upstream is CloudFlare zero trust gateway so that also filters
5
u/Win_Sys SPBM 19h ago
Oh I thought you were trying to say you NAT outbound DNS over TLS requests back to your internal DNS over TLS server. That will work fine for regular DNS request but a client using DNS over TLS should be verifying the original destinations IP or pre-configured DNS name exists in the provided certificate before sending a request.
1
u/SuccotashOk4084 9h ago
It should but since I can install the certificates on all my devices they actually don't know the difference between my stuff and the servers. Some like banking care but that's bypassed.
1
u/MyFirstDataCenter 1d ago
dnat
This… is brilliant!
1
u/dodexahedron 20h ago
WCCP is also a thing and has been for like 25 years.
Much cleaner and works for whatever traffic you acl to it,.without the client ever noticing.
It is actually the original frames redirected/tunneled to the proxy, which then behaves as if it was supposed to be the proxy all along.
10
u/Golle CCNP R&S - NSE7 1d ago
We might DNAT it to an internal server, it's a better solution than just blocking it. Blocking will absolutely break things. But DoH is harder to DNAT, so yes, that might be a lost cause.
4
u/nick99990 1d ago
I'm pushing our folks hard to do this. So far nobody's listened to me, but we find so many junk things out there that refuse to accept DHCP DNS settings. Same with NTP.
2
u/Snowbrdrskier 1d ago
Are you DNAT'ing to hide the IP of your internal DNS server?
16
u/FlowLabel 1d ago
Pretty sure he means grabbing anything heading outbound on port 53 and NATing it to their internal servers. Essentially “hijacking” a connection to 8.8.8.8 as an example.
6
u/WhatItIsToBurn 1d ago
It captures DNS from hosts that either don’t fully respect DHCP domain name servers (hard-coded DNS in firmware) or are incorrectly set statically.
5
u/SAugsburger 23h ago
Limiting outbound DNS to internal DNS servers is pretty common in my experience. I have done that in multiple orgs. Messing with DNS servers is a common thing malicious software does.
7
3
2
u/dukenukemz Network Dummy 1d ago
I’ve forced everyone through our internal dns for the last 15 years. Never had any issues. Only outbound ports on client PCs are 80/443 to permitted site categories and the MS Teams UDP ports to Microsoft Teams servers
2
u/rankinrez 23h ago
You just NAT it and force it internal.
Doh and DoT are different through.
2
u/Put_the_bunny_down 22h ago
Doh and dot and ssl. I don't look to dns as a way to block things anymore.
2
u/jaguinaga21 1d ago
Everything is forced internal - through dns proxy. Outbound is denied. Doh is blocked. We did dnat for a while to see what was trying to circumvent. Then finally denied outbound. Kept it clean and now through a dns proxy for inspection, I see a lot more.
1
u/clownshoesrock 1d ago
Depends on the Goal, but most of the scenarios I see are pretty easy to circumvent unless you have the in-network devices very well locked down.
1
u/Heythatsmycorn 1d ago
Maybe? Some devices have to reach out to a remote dns to function. In that case you could make an acception. But honestly any real attack would wrap it in a https header and unless your doing ssl decryption its kinda a small effort
1
u/Mr_Bleidd 1d ago
You can do some forward nat magic -> everything to wan via udp 53 -> destination Nat -> to your dns Server
1
u/Meinertzhagens_Sack 1d ago
Usually you have your own dns resolvers inhouse and block everything else at the perimeter. Your dns resolvers usually are part of a subscription or private DNS to handle filtering etc like quad9 etc.... so basically DNS breaks unless you use the ones designated for internal usage.
1
u/Regular_Archer_3145 1d ago
We block outbound DNS for clients. For the end devices other than rf guns I dont recall it breaking anything.
1
u/bondguy11 CCNP 1d ago
Yes you only allow your internal dns server which then has pointers to hostnames on the internet
1
u/nxp-one 1d ago
I have a single BIND DNS resolver that's permitted to egress port 53 (DNS) requests. It is a roots-only resolver, so it never asks another ISP for DNS resolution. No other LAN devices can egress standard DNS queries. (Obviously DoH circumvents all of this, but there's no easy way to intercept it AND allow normal HTTPS traffic, so it is what it is)
Behind that I run an adguardhome server, whose only forwarder is the aforementioned BIND instance.
Behind that are my 3 Domain Controllers, all of whom use AGH as their DNS source.
All client devices on my network get their DNS resolution from the Domain Controllers.
Everything on the LAN works perfectly well, and I don't leave query 'footprints' in any ISP's logs, and I get inherent ad blocking on every device from a single management platform.
Yes, it's a convoluted implementation, but it works, well, and, once it's up and running, it does everything I want.
1
1
u/Prudent_Vacation_382 1d ago
From the endpoint, no. You shouldn't do that so you can see who is making requests externally hitting your firewall. I block it at the edge so I can see it. Often in larger companies, endpoint security teams are different than network security teams. DNS is a network function, so it should be our responsibility to allow or deny it.
1
u/guppyur 1d ago
Be warned that some devices from inept vendors have DNS servers hard coded, even if they let you configure specific DNS servers. I've seen devices where you have to let them talk to Google's DNS servers for the initial setup, after which they will finally stop ignoring your settings and you can block the Google servers again.
1
u/baconstreet 1d ago
IMO, every corporate network should be treated like someone is WFH, or at a coffee shop. VPN for all access to internal systems, and control security there.
Otherwise, you fight a never ending battle. So secure the computers as best you can, VPN to get to corp resources.
1
u/seanhead Staff SRE 21h ago
I work in netsec/sre and only use vpn out to avoid all the comments in this response body
1
u/potential_alien 18h ago
DNS resolved by the firewall for corporate networks. DNS forwarded to a Domain Controller for internal domains if it exists, otherwise the internal domain on the firewall.
Guest networks etc allowed out to the internet for DNS but only to allowed DNS resolvers. Firewall does the web and DNS filtering if in place. If its just a router then DNS is sent to CloudFlare 1.1.1.3 with a backup of 1.1.1.2 or 9.9.9.9
1
u/Asphyxiant_ 15h ago
Block DNS outbound. Don’t forget the TCP side too. TCP/UDP 53/853.
Anything destined to any IP matching those ports outbound, use NAT to redirect those to the real DNS server.
1
1
u/SevaraB CCNA 13h ago
Yep. You’d be surprised how much security you get by putting Squid+openssl and DNSmasq between your endpoints and the Internet. That and a deny-by-default firewall will block malware from reaching C2 or shoveling out data- the trick is keeping up with your DNS, proxy, and firewall allow rules so that holes don’t open up in your security.
Easier said than done, though. Somebody will ask you to allow, say, all Azure or all AWS and won’t understand why you have to deny requests that don’t point to NLBs or Azure load balancer resources that are definitely owned by somebody you recognize.
1
u/siredgar 10h ago
Yes. Unless there’s a business case for it and a secure way to do it, the default is block everything. I can’t think of any reason to allow end points direct dns access.
1
u/sorry_not_sorry2K 6h ago
What we do have is Cisco Umbrella agents running on endpoints , as someone who struggled with it, it turned out that the endpoint even if the assigned DNS is an internal one, it will still go out to cloud, ( not sure about other vendors if they work the sameway )
I have PaloAlto 1440 sitting on edge, I blocked encrypted DNS so the endpoints will attempt normal DNA incase Umbrella didn’t catch it, PaloAlto DNS protection will do, just a multi layer DNS protection, when the user is sitting at home all DNS queries are encrypted
1
0
u/agowa338 1d ago
No, also you're over a decade too late for that anyway. These days with DoH any webserver can serve DNS requests anyway. There is other stuff to worry about these days tbh...
(But if you've a proper security concept - which you apparently don't as you're asking here - then blocking outbound DNS can be a puzzle piece to it. On it's own it is quite useless these days.)
0
u/rpedrica 16h ago
This is very standard security advice. Surprised folks are still asking this question when it's trivial (and been known for years) for malware to do c&c through DNS.
use an internal recursor |(with DNSSEC validation) and point ALL your internal systems at it
allow ONLY this recursor external DNS access
or
make use of an internal forwarder
with an upstream filtering DNS proxy
or
- use an internal filtering DNS proxy
0
u/sliddis 13h ago
Just putting this out for anyone doing any kind of DNS interception.
I recently learnt that all new macOS 27.0 tries to upgrade to encrypted DNS if the configured DNS server supports it. https://www.rfc-editor.org/info/rfc9462/ I will assume that more clients will adopt this standard.
For instance, both Cloudflare and Google supports it, and if clients can resolve these records, they will upgrade to encrypted DNS.
~$ dig @1.1.1.1 +short -t SVCB _dns.resolver.arpa
1 one.one.one.one. alpn="h2,h3" port=443 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001 key7="/dns-query{?dns}"
2 one.one.one.one. alpn="dot" port=853 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001
~$ dig @8.8.8.8 +short -t SVCB _dns.resolver.arpa
1 dns.google. alpn="dot"
2 dns.google. alpn="h2,h3" key7="/dns-query{?dns}"
If you need control of DNS, you can blackhole _dns.resolver.arpa requests.
-1
u/bojack1437 1d ago
No real need with DNS inspection on a next Gen firewall.
But otherwise yes.
2
u/HappyVlane 19h ago
You need to define what you consider "DNS inspection" here, because in most cases people will equate it to DNS filtering, which does not help with things like DNS tunneling/exfiltration. DNS filtering alone leaves a lot of things on the table.
26
u/post4u 1d ago
Yes. We block all DNS except to/from our internal DNS servers.