DNS Is Not a Technical Detail, but a Business-Critical Service
When an employee enters a website address or an application connects to a cloud service, DNS translates the domain name into the IP address of the appropriate server. Without this mechanism, email, VPN access, websites, sales systems, and many internal services stop working. From a business perspective, DNS is therefore a shared dependency for nearly all digital operations.
This central role has two sides. If DNS is unavailable, the organization may experience downtime comparable to a network outage. If a DNS response is manipulated, a user may be directed to a fraudulent service even after entering the correct address. If DNS traffic remains outside the organization's control, the company loses the ability to detect some phishing attempts, communications with malware command-and-control servers, and data exfiltration activity.
The question for the board should therefore not be, "Are the DNS servers working?" but rather, "Does DNS reduce risk, provide visibility, and have resilience built into its design?" This is the difference between routine service maintenance and deliberate operational risk management.
Protective DNS: Stopping a Threat Before a Connection Is Established
Protective DNS analyzes DNS queries and responses in real time. It compares domains with information on known threats and can block an attempt to access a phishing site, connect to criminal infrastructure, or reach a domain used by malware. This occurs at a very early stage, before the computer establishes an actual connection with the malicious server.
For the business, this provides an additional layer of protection covering computers, phones, servers, IoT devices, and cloud resources. CSIRT KNF indicates that, in the Polish context, a reasonable minimum is the malicious-domain list maintained by CERT Polska. This should be supplemented with an independent source, because different providers observe different parts of the Internet.
The latter point has direct business implications. An overly aggressive policy may block a legitimate domain required by sales, accounting, or customer service. The deployment should therefore include a rapid exception process, a designated decision owner, and business-impact testing. Security must not be implemented at the cost of uncontrolled disruption to business operations.
Regain Control of DNS Traffic First
Even the best protective service will be ineffective if employees, browsers, or applications can use arbitrary public DNS servers. In addition, many browsers enable encrypted DNS to the browser provider's own servers by default, bypassing the organization's local security infrastructure. In such cases, some traffic circumvents corporate policies, logging, and blocking mechanisms. The organization sees only part of the picture and cannot effectively manage risks that remain invisible.
The most important step is therefore to route DNS traffic through an authorized corporate control point. This may be a locally maintained resolver (a resolver is a server that, at a device's request, finds the IP address assigned to a domain name so that the device can connect to the correct website or service), a cloud service, or a hybrid solution. At the same time, the organization should restrict direct use of external DNS services and properly configure browsers and mobile devices that can independently enable encrypted connections to public providers.
The objective is not to block encryption itself. Encrypted traffic should be directed to a resolver approved by the organization, rather than to an arbitrary service selected by a user or application. The mitigating measures are specific: block outbound DNS traffic (UDP/TCP port 53) except through authorized corporate servers; block unauthorized encrypted traffic (DoT on port 853, DoQ, and DoH); block domains associated with known public DoH servers; and enforce browser and mobile-device settings through MDM or Group Policy. These are standard configuration changes rather than the purchase of a new system - a category of measures offering high impact with low implementation complexity.
DNS Logs: Recording the Signals That Precede an Incident
DNS queries often leave a trace before an attack becomes visible in other systems. They may show that a computer attempted to connect to a phishing domain, a malware command-and-control server, or an unusual address used for data exfiltration. DNS logs are therefore a valuable source of information for incident response teams and post-incident investigations.
Collecting logs alone is not enough. They must be correlated with DHCP data, endpoint information, and firewall logs to identify the source of a query. Integration with SIEM and SOAR platforms facilitates pattern detection and accelerates response. Full logging, however, has a cost, so retention periods should reflect legal requirements, investigative needs, and budget constraints. The minimum requirement is clear: queries to malicious or prohibited domains must always be recorded. DNSTAP is the recommended format because it is less costly to operate than traditional query logging.
Encryption and DNSSEC: Two Complementary Mechanisms
These two concepts are often confused in discussions about DNS. Encrypted DNS, such as DoH, DoT, or DoQ, protects the confidentiality of the communication channel between a device and a resolver. It makes queries more difficult to intercept or alter in transit. DNSSEC adds digital signatures to DNS data, protecting the authenticity and integrity of the data itself and enabling the recipient to verify that a response came from the correct source and was not modified. However, DNSSEC does not conceal the content of queries.
Neither mechanism replaces the other. A company may encrypt a connection to an uncontrolled resolver and lose visibility. It may also use DNSSEC without encryption, confirming that a response is authentic while still exposing the query. The two solutions should therefore complement each other. Encryption should be deployed across controlled network segments, with logging on approved resolvers and telemetry from endpoints. This is a technical decision based on a risk assessment, not simply a feature to be switched on.
DNS Resilience Is Business Resilience
A DNS outage can halt business processes even when the applications and network connections themselves are functioning correctly. An organization should therefore maintain at least one primary and one secondary server for each zone, separated at the network level and, ideally, geographically. The report recommends a "hidden primary" model: the main server on which changes are made is not directly visible on the Internet, while secondary servers respond publicly.
An Internet-facing server should not simultaneously publish the organization's DNS data and resolve queries on behalf of users. Separating these roles reduces the attack surface. Resilience also requires controlled data transfers, authentication, monitoring, and failover testing.
Domain Hygiene: Small Oversights, Real Losses
Not every DNS incident begins with a sophisticated attack. A forgotten record pointing to an unused cloud service, an incorrect redirection, or publicly available information revealing infrastructure details may be enough. Such remnants can enable a subdomain takeover, facilitate reconnaissance, or undermine trust in the brand. Particular attention should be paid to the following areas:
- Orphaned records - an entry pointing to a cloud resource that the company no longer uses. An attacker may register the abandoned resource and take control of an address that formally belongs to the company. The remedy is automated auditing and the removal of unnecessary records.
- Look-alike domains (typosquatting and homoglyphs) - criminals register names that resemble the company's domain in order to deceive customers and employees. Organizations should monitor such registrations and defensively register the highest-risk variants. This protects the brand, not only the infrastructure.
- Excessive public information - companies sometimes publish DNS information about operating systems, locations, contact persons, or even internal IP addresses. This gives an attacker a map of the infrastructure without requiring a breach. The recommendation is to audit public records periodically. Records required for email (SPF, DKIM, and DMARC) should remain; all others require a clear justification.
Organizations need a recurring, preferably automated audit of public records, together with a process for removing entries that have no business owner. Every significant domain and subdomain should have an assigned owner, a defined purpose, and a review date. The company should also monitor registrations of names similar to its brand that could be used for phishing. Without cooperation among IT, security, marketing, legal, and service owners, a scanner will merely generate a list of problems that no one resolves.
Cloud, On-Premises Infrastructure, or a Hybrid Model?
There is no single model that is appropriate for every organization.
- An on-premises solution (the organization's own DNS servers) provides greater control over policies and data, but requires expertise and ongoing maintenance.
- Cloud services provide greater scale and richer analytics, but they increase vendor dependency, subscription costs, and the risk that the organization may be profiled through its DNS queries. Query history can reveal which tools the company uses, with whom it communicates, and what it may be planning. The practical guidance is therefore clear: when using the cloud, configuration data and logs should be stored and processed within the European Union.
- A hybrid model is usually the best compromise. It can combine both approaches: the cloud provides advanced protection, while local mechanisms maintain basic filtering during an outage. The decision should consider where logs are processed, regulatory requirements, latency, the vendor exit plan, and how the system behaves during unavailability. Contractual terms and processing within the EU are also important for sensitive data.
The board does not need to select a specific technology, but it should approve the decision criteria. The key question is whether, in the event of an outage or a dispute with the provider, the company will retain a minimum level of protection and operational capability or enter a "fail-open" mode in which traffic is allowed without filtering.
A Realistic Roadmap: Start with High-Impact Measures
The greatest value comes from measures that establish control and visibility.
- Stage one (minimum baseline) should include a DNS inventory, designation of a service owner, a central corporate DNS server, restrictions on the use of public DNS servers, and basic filtering using reputation lists. The organization should also introduce minimum security-event logging and a rapid process for handling false-positive blocks.
- In stage two (expanded controls), DNS logs should be integrated with the SIEM and correlated with DHCP, firewall, and endpoint data. This is also the right time to control DoH settings, implement DNSSEC validation, audit public records, monitor domains similar to the company's brand, and enforce configurations through MDM or Group Policy. The organization should also define metrics: the proportion of traffic passing through authorized resolvers, exception-handling time, the number of blocked attempts, and logging coverage.
- Stage three (maturity) introduces advanced anomaly and DNS-based data-exfiltration detection, automated response, hybrid solutions, and regular resilience testing. Only at this level should the organization invest in the most advanced mechanisms, such as policies by network segment and device type, provided that their cost is proportionate to the company's risk profile.
This sequence reduces project risk, delivers early results, and creates a foundation for further investment. The least effective approach is to purchase an advanced tool without first centralizing traffic, establishing complete telemetry, and assigning clear accountability.
Five Questions Management Should Ask the IT Department
- Does all DNS traffic pass through our servers, and can we demonstrate this through measurement rather than relying on a declaration?
- Can we quickly determine which device attempted to connect to a malicious domain?
- Do we block domains listed by CERT Polska and by an independent source, and who can unblock a business partner's domain in the event of a false positive?
- When did we last audit public DNS records for forgotten entries and excessive information disclosure?
- Do we monitor registrations of domains similar to ours, and do we know what action to take if they are used against our customers?
If any of these questions does not have a clear, documented answer, the organization has a specific gap that must be addressed.
Conclusion
DNS is one of the few security layers with a clearly favorable cost-to-impact ratio. Many of the CSIRT KNF recommendations involve configuration and governance improvements rather than capital investment, while protecting against one of the most common loss scenarios: an employee clicking a suspicious link or attachment. DNS does not have to remain an invisible source of risk. It can become a relatively straightforward and broadly effective layer of protection, provided that the company treats it as a critical service, combines technology with process, and develops its safeguards in stages.
