Short answer: Encrypted DNS means carrying domain name queries encrypted instead of in plaintext: DNS over TLS (DoT) uses TLS on a separate port, while DNS over HTTPS (DoH) hides the query inside ordinary web traffic. If devices use it with an outside resolver, the network's DNS filter is taken out of the picture; this path should be closed with firewall rules.
Why classic DNS is plaintext
DNS is a protocol designed in the early years of the internet, and for a long time queries were carried unencrypted. A classic DNS query usually travels over port 53; any network device along the way can read which domain name is being queried, and a malicious intermediary can even alter the answer.
This openness makes two things possible. First, the network administrator can easily see and redirect DNS traffic; the classic method of DNS filtering relies on exactly this. Second, on a public Wi-Fi network, someone on the same network or a device along the path can monitor queries or send forged answers. Encrypted DNS became widespread as an answer to this second risk.
What are DoH and DoT, and how do they differ?
Both methods encrypt the query and the answer; the main difference between them is how the traffic looks on the network:
| Feature | Classic DNS | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|---|
| Port | 53 | 853 | 443 (same as web traffic) |
| Encryption | None | TLS | HTTPS (TLS) |
| Identifiable on the network | Easy | Easy, thanks to the port | Hard; blends into web traffic |
| Typical use | The network's default DNS | Operating systems, routers | Browsers, apps, routers |
Because DoT runs on its own port, the network administrator can see it and restrict it if necessary. DoH, on the other hand, looks like an ordinary HTTPS connection, so it can't be told apart by looking at the port alone. That is why the real challenge in protecting the filter lies on the DoH side.
The two faces of encrypted DNS
To position encrypted DNS correctly, you need to separate two different journeys:
- From the router to the filtering DNS: Your network's router forwards queries, encrypted, to the filtering DNS server chosen by the organization. This protects the queries' journey across the internet and is good practice.
- From the device to an outside resolver: A phone or browser sends its encrypted query directly to a public resolver without using the network's DNS at all. In this case, the network's policy is not applied.
The goal is to keep the first while blocking the second: encryption stays, but queries pass through the place the organization has chosen. This distinction also explains why measures taken against encrypted DNS don't reduce security.
How encrypted DNS bypasses the filter
There are three typical situations on a guest network. A browser's built-in encrypted DNS setting can be turned on by the user or, under some conditions, automatically. Smartphones' "private DNS"-style settings can route queries to an outside resolver at the operating system level. And some apps work with a resolver embedded inside them.
Most of these settings are designed not with bad intent but to protect the user's privacy. For a user who doesn't want their queries monitored in a café or an airport, they are meaningful protection. The problem is that the same setting also disables the security policy the organization deliberately applies; the solution is not to oppose encryption but to route the query to the organization's filtering DNS.
In all three situations the result is the same: the device never asks your filtering DNS, a blocked site can open, and the "who tried" visibility at the DNS layer is lost. One important point: the connection itself still passes through your firewall. Because access records are generated from firewall logs, internal IP, destination IP and port, NAT information, and user continue to be recorded; in other words, the 5651 record is not affected — what is affected is the filter's ability to block.
A VPN is a separate category: because all traffic goes through the tunnel, not just DNS but other network-level filters become invisible too. The firewall's application control can restrict known VPN traffic, but you have to accept that this can't be fully prevented on a guest network.
Steps to protect the filter on the guest network
The steps below are general network practices that can be applied with standard firewall policies on devices such as FortiGate, MikroTik, pfSense, or OPNsense. The exact menus and commands vary with your device's version.
Step 2 has two options. Blocking drops the query going to an outside DNS server; after a while the device falls back to the DNS the network provides. Redirecting silently diverts the same query to your own DNS; it lets some printers, cameras, or smart devices with a hard-coded DNS address keep working without problems. On a guest network, redirecting usually generates fewer complaints. Whichever path you choose, remember that the rule covers only unencrypted port 53 traffic, and that steps 3 and 4 are needed for encrypted queries.
Distribute a single DNS via DHCP
Have the guest network's DHCP settings distribute only the router or the filtering DNS address; don't add a second, unfiltered DNS address.
Restrict outbound port 53
Allow outbound UDP and TCP 53 traffic from the guest network only to the permitted DNS destination; block the rest or redirect it to your own DNS.
Close port 853 (DoT)
Block outbound 853 traffic from client networks. If the router itself connects to the filtering DNS over DoT, exclude that connection from the rule.
Block known DoH endpoints
Because DoH uses 443, the port can't be closed. Add the domain names of known encrypted DNS services to your block list and their addresses to a firewall rule; if your device supports it, make use of application control.
Turn the setting off on company devices
On staff computers, turn off browser and operating system encrypted DNS settings through central management policies, or pin them to the organization's DNS.
Separate guests and staff
Keep guest and staff networks on separate VLANs so you can write rules per network; details are in the network separation guide.
MikroTik: connecting to izgate DNS
On MikroTik devices running RouterOS 7.19 and later, izgate DNS connects with one click through Automatic Setup. The router connects to the izgate DNS server over encrypted DNS (DoH) with a device-specific key; devices on the network send their queries to the router, and the router forwards them, encrypted, to izgate. This way, the journey "from the router to the filtering DNS" stays encrypted.
Continuity has been considered too: if the server can't be reached, the router falls back to normal DNS within about 30 seconds and the internet is not cut off; when the server comes back, the filter turns itself on again. Automatic Setup also records the name of the visited site from the first packets of the connection. Adding steps 1–4 above on top of this connection prevents clients from bypassing the router and going to an outside resolver. For the full hotspot and log setup, see the MikroTik hotspot and 5651 guide.
FortiGate: izgate DNS and its own DNS filter
On FortiGate, you can connect to izgate DNS in two ways. For an encrypted connection, FortiOS 6.2 and later supports DoT, and 7.0 and later supports DoH; FortiGate forwards queries, encrypted, to izgate. In a simpler setup, the izgate DNS address is distributed in the guest DHCP. In both cases, the FortiGate is recognized by its public address registered with izgate; izgate DNS is not an open resolver and answers only registered devices. DNSSEC validation is enabled.
FortiGate's own DNS filter and web filter categories, on the other hand, come with the device's license and are independent of izgate. The two can be used together: izgate DNS performs category blocking without requiring a firewall license and adds the izgate category next to site names in the logs, while FortiGate's web filter provides additional page-level control and helps site names get recorded. For logging settings on the device side, see the guide to 5651 logging with FortiGate.
Verifying the setup
To see that the settings really work, run a short test with a test device connected to the guest network:
- Add a test domain to your own block list and try to open it from the test device; it should not open.
- On the test device, manually set DNS to a public outside resolver; name resolution should fail, or the query should still pass through the filter.
- Turn on the browser's encrypted DNS setting and try the same test name; the block should remain in place.
- Check on the Blocked screen that the test attempts appear with device and time information.
If a step doesn't turn out as expected, usually a DNS egress rule is missing or a second DNS address has been left in DHCP. For the general logic and limits of the filter, see the DNS filtering guide; for product details, see the DNS Security feature page and the izgate DNS Security page.
Frequently asked questions
Does restricting devices' use of encrypted DNS reduce security?
No, not when it is set up correctly. The goal is not to remove encryption but to make sure queries go to the filtering DNS chosen by the organization. Traffic between the router and the filtering DNS server can stay encrypted; only devices bypassing the network's policy and going directly to an outside resolver are restricted.
If a device uses encrypted DNS, are 5651 access records affected?
Because access records are generated from firewall logs, the connection itself continues to be recorded: internal IP, destination IP and port, NAT information, and user. What is affected is the DNS filter's ability to see and block that query. That is why outbound DNS traffic needs to be restricted to protect the filter.
If the izgate DNS server can't be reached, is the guest network left without internet?
A router connected with MikroTik Automatic Setup falls back to normal DNS within about 30 seconds if it can't reach the izgate DNS server; the internet is not cut off. When the server becomes reachable again, the filter turns itself back on.
On FortiGate, should I connect to izgate DNS with DoT or DoH?
FortiOS 6.2 and later supports DoT, and 7.0 and later supports DoH; you can choose whichever fits your device's version. If you don't want to set up an encrypted connection, distributing the izgate DNS address in the guest DHCP is also an option. In every case, the device is recognized by its public address registered with izgate.
This page is for information only; for the current text of the legislation, refer to the official source (mevzuat.gov.tr).
