Restriction of certain websites by name
Sometimes you need to restrict access to specific websites by domain name: in an office, school, hotel Wi-Fi, a family network, or on a server where you want to reduce risk (blocking malicious domains, ad networks, or distracting services). “By name” means you target the hostname (for example example.com) rather than a fixed IP. This is convenient, but modern HTTPS, CDNs, and frequently changing IPs make simple IP blocking unreliable. That’s why domain restrictions are usually implemented at the DNS layer or through a proxy/security gateway.
This guide covers several practical methods: the hosts file (quick and local), DNS-based blocking (best for whole networks), firewall techniques (limited for HTTPS), and proxy approaches that provide better control, logging, and policy enforcement. If you want centralized control for many devices, you typically implement it on a routing/security layer. You can build this using a managed router like Cloud Hosted Router MikroTik or run your own DNS/proxy node on Virtual Servers. For a full security perimeter with advanced policy and reporting, consider Fortinet Products and Solutions.
Important note: this article assumes you are restricting access inside a network or on systems you administer. Trying to control other people’s devices or networks without authorization is not a valid or safe scenario. The examples below assume you control the endpoints or the network layer (DNS/router/proxy).
1) Hosts file: the simplest local method
The hosts file lets you override DNS resolution on a single machine. You map a domain to 0.0.0.0 or 127.0.0.1, and the browser fails to load the site (or loads localhost). It’s fast for one computer, but not scalable because you must edit every device individually.
On Linux the file is usually /etc/hosts, on Windows it’s C:WindowsSystem32driversetchosts, and on macOS it’s /etc/hosts. After changes, you may need to flush DNS cache (systemd-resolved, browser cache, etc.) for immediate effect.
# example /etc/hosts 0.0.0.0 example.com 0.0.0.0 www.example.com
Limitations: hosts doesn’t handle wildcards (like *.example.com) without listing each subdomain. Modern services often use many subdomains, so hosts is best for quick fixes, not large-scale policy.
2) DNS blocking: the best approach for a whole network
DNS blocking means configuring a DNS resolver so that certain domains do not resolve (NXDOMAIN) or resolve to a “null” address. You can do this with dnsmasq, Unbound, BIND, Pi-hole, AdGuard Home, or a firewall/UTM device with DNS filtering. The advantage is centralization: point your router’s DHCP to your DNS resolver and every device follows the same rules.
A simple dnsmasq approach is mapping domains to 0.0.0.0. It works well, but note the bypass: users can switch to DNS over HTTPS/TLS (DoH/DoT) in a browser or app. If you need enforcement, you must block DoH endpoints, manage devices with policy, or use a security gateway that controls DNS traffic.
# dnsmasq example address=/example.com/0.0.0.0 address=/www.example.com/0.0.0.0
DNS-based control is excellent for malicious domains and ad/tracker lists. It can also provide allowlists, statistics, and exceptions. The downside is that DNS alone cannot stop access by direct IP (rare) and cannot control traffic inside VPN tunnels.
3) Firewalls and the HTTPS reality: why “by name” is hard at L3/L4
Traditional firewalls (iptables/nftables) filter by IP and port, not by hostname. Blocking “by name” at the firewall level is difficult because one IP can host hundreds of domains (CDNs) and IPs change frequently. Some solutions inspect TLS SNI (Server Name Indication) to infer the hostname, but this works only in specific cases and may degrade with ECH (Encrypted Client Hello) adoption.
That’s why robust domain-based control is typically DNS filtering + anti-bypass measures (DoH/DoT control), or a full proxy/UTM solution that can enforce policies and logging. In enterprise environments, UTM solutions (often including Fortinet) are common because they combine filtering, reporting, and identity-based policies in one place.
4) Proxy approach: maximum control and logging
An HTTP/HTTPS proxy (for example Squid) can restrict access by domain, URL patterns, categories, users, and time schedules. It also provides logs for compliance and troubleshooting. With HTTPS there are two broad modes: (1) CONNECT-level filtering (you can see the target domain but not full URLs), and (2) TLS inspection (you can see full URLs/content but must deploy a trusted CA certificate and have clear policy/legal approval). Many networks can achieve “block by domain” with mode (1) without deep inspection.
Proxies can be explicit (clients are configured to use them) or transparent (traffic is redirected). Transparent proxying is more complex in modern HTTPS environments and can cause unexpected issues, so explicit proxies plus network policy are often preferred. In practice, proxies are commonly deployed on a VPS or internal server, and DNS/firewall rules are used to reduce bypass options.
Which method should you choose?
If you need to block a couple of domains on one machine, edit the hosts file. If you need to block sites for an entire home or office network, use DNS filtering because it is simple to maintain and effective. If you need strong enforcement, user-based policies, and detailed logs, use a proxy or a UTM security gateway. In real environments, the best result is usually a combination: DNS blocks the baseline, and a firewall/proxy layer reduces bypass and provides reporting.
Finally, plan for bypass routes: VPNs, DoH/DoT, mobile data, alternate DNS settings, and browser features. Real enforcement requires not only technical controls but also operational policy: who can change DNS, how devices are managed, and how exceptions are documented. Technology without process often works only until the first advanced user tries to bypass it.