The Most Frequent DNS Management Errors and How to Fix Them

Want to be sure your DNS setup isn’t weakening your security or network performance? GREYCORTEX experts highlight the most frequent mistakes from countless network audits. This blog then breaks them down with practical examples and clear steps for remediation.

DNS plays a far greater role than simply resolving names to IP addresses. It shapes where users are redirected and reveals which servers devices connect to. DNS traffic is powerful: whoever controls or intercepts it can redirect users, map internal services, or extract sensitive data. That is why DNS remains one of the most overlooked but impactful parts of network security.

GREYCORTEX experts frequently uncover the same DNS mistakes during audits, even in mature infrastructures. This blog highlights the most frequent errors and shares recommendations on how you can address them:

❌ Unrestricted use of port 53
❌ Uncontrolled DNS over HTTPS (DoH) and DNS over TLS (DoT)
❌ Domains not registered or controlled by the organization
❌ Typographical errors in DNS server IP addresses

Unrestricted DNS Port 53 as a Security Risk

In many networks, outbound port 53 is left completely open. This means that any device on the internal network can connect to any other device on the Internet. This is used by both attackers and legitimate applications, which can cause a problem from a security perspective.

Attackers can use an open port 53 to the Internet to create a DNS tunnel. They can then send any data through it. For example, using lodine software, they can create an IP layer on top of the application’s DNS protocol and then use port 53 to transmit arbitrary data or create a reverse SSH tunnel from the Internet to the internal network. This creates permanent access, which allows an attacker to return to the internal network at any time.

Specifically, in the case of Iodine software, the created IP layer is transmitted hidden in strings that represent a third-order domain. From the perspective of a network communications analyst, the client is communicating with a legitimate DNS server on the internal network, but a closer look at the transmitted data will show that this is not the case.

Let’s have a look at this data in GREYCORTEX Mendel. As an example, there’s a device with the IP address 192.168.2.191 that is sending DNS queries to an internal DNS server with the IP address 192.168.2.52. In the figure below, you can see an example of several queries in the application’s log data itself that query the domain name freemovies.tk. The third-order domain name changes in each query and also looks very strange at first glance. Note also that the rrtype attribute contains an unusual NULL value.

Tips from GREYCORTEX experts:

✅ Block outbound port 53 for all but your authorized DNS servers.
✅ Monitor DNS logs for anomalies such as unusual third-level domain patterns or unexpected record types.
✅ Treat repeated NULL or other rare rrtype values as strong indicators of tunneling attempts.

When Port 53 Is Legitimately Needed

There are cases where port 53 still plays a role, for example, when clients must connect to corporate DNS resolvers or authorized external “secure DNS” providers. However, modern secure DNS providers increasingly rely on encrypted transports (DoH/​DoT) or agents that forward DNS queries inside port 443, reducing the need for open port 53.

Attackers also know that persistence can be hidden inside DNS traffic. Malware may use DNS responses to fetch commands or exfiltrate sensitive data. That is why unrestricted port 53 should never be treated as a default configuration.

Tips from GREYCORTEX experts:

✅ Restrict port 53 to trusted resolvers if it must remain open.
✅ Audit devices that attempt direct resolution against Internet DNS servers. This often signals malware activity or specific applications.

Uncontrolled DNS over HTTPS (DoH) and DNS over TLS (DoT)

Encrypted DNS protocols were designed to protect user privacy, but in corporate networks, they often create blind spots. DoH (port 443) and DoT (port 853) hides DNS traffic inside encrypted sessions, making it difficult to inspect or enforce security policies. The risks are the same as with open port 53: attackers can tunnel data, bypass corporate resolvers, or maintain persistence inside the network.

DoT can usually be restricted by blocking port 853, but DoH is far harder to control because it blends in with normal HTTPS traffic on port 443. Without inspection or monitoring, administrators may have no visibility into which DNS servers employees or malware are actually contacting.

Tips from GREYCORTEX experts:

✅ Block outbound port 853 unless explicitly required.
✅ Monitor TLS traffic for signatures and patterns of DoH usage inside port 443, and if this is unwanted traffic, you can block these DNS domains for port 443.

When You Don’t Own Your Domain

During audits, GREYCORTEX experts encountered a case where administrators created a second domain because they couldn’t fully migrate from the old one. The original domain was company.com, and the new one was company2v.com. At first glance, this looked like a harmless workaround. But the new domain was never registered by the organization and someone else registered it instead.

The implications were serious. When administrators deployed a proxy server via Windows Group Policy (GPO), workstations tried to reach wpad.company2v.com to fetch proxy settings. Since the company2v.com domain was controlled by an external party, the DNS resolution pointed those requests outside the company network. From there, the actual domain owner could direct internal devices to any server on the Internet.

This opened the door for a man-in-the-middle attack. For example, ransomware could be delivered under the guise of a legitimate download, such as firefox.exe. What seemed like a minor oversight in domain registration had turned into a direct attack path.

Tips from GREYCORTEX experts:

✅ Always register and control all domains that resemble your internal naming scheme.
✅ Audit which domains are in active use on your network and confirm ownership.
✅ Pay close attention to automatically generated names such as wpad.domain.com, which attackers often abuse.

Misspellings in DNS Server IP Addresses

DNS errors are not always the result of complex attacks. Sometimes, they come down to simple human mistakes. GREYCORTEX experts frequently encounter typos in DNS server configurations. For example, Google’s resolvers (8.8.8.8 and 8.8.4.4) are often mistyped as 4.4.4.4 or 8.8.6.6. Private ranges like 192.168.x.x may be entered without the leading digit, producing invalid addresses.

If the DNS server is configured incorrectly, the device cannot resolve domain names. On user-facing systems, this issue is usually caught quickly. But on devices with manually configured DNS, such as cameras, sensors, or IoT equipment, the error can persist unnoticed, preventing critical updates or creating hidden communication problems.

Mendel has detected such cases during audits, including one where thirteen devices repeatedly sent DNS queries to 8.8.6.6. Since no resolver exists at that address, all translations failed. In worst cases, an accidental typo may resolve to a legitimate DNS server on the Internet, causing internal DNS queries to leak outside the company.

Tips from GREYCORTEX experts:

✅ Use centralized configuration management to reduce manual DNS entry errors.
✅ Continuously monitor DNS traffic.

Why DNS Hygiene Demands Constant Attention

Modern attackers do not need to break firewalls if DNS gives them a way in. Unrestricted queries on port 53, DNS tunneling hidden inside DoT and DoH over 853 or 443, unregistered domains, or misconfigured servers all provide silent channels for persistence or exfiltration.

Continuous auditing and long-term monitoring are the only ways to uncover these errors before they escalate into outages or breaches. GREYCORTEX Mendel provides you with visibility into your DNS traffic, alerts on unauthorized resolvers, and detects tunneling patterns.

DNS errors are just one piece of the puzzle. Watch our webinar recording How to Analyse Network Performance Issues and learn how to detect other network anomalies that impact security and performance.