What is DNS?
DNS (Domain Name System) is the hierarchical, globally distributed naming system that translates
human-readable names such as historian.plant.example or example.com into IP addresses that devices use to find each other on a network. It is often called the
phonebook of the internet: you remember a name, DNS looks up the number. DNS was specified in November
1987 in RFC 1034 and RFC 1035 and runs on port 53 over UDP and TCP by default. In OT networks DNS is less visible than in office IT, yet it decides whether systems such as Active Directory, certificate checks and historians keep working.
Without DNS you would need to know the numeric IP Address of every system, and every address change would have to be applied by hand on every client.
🧠 How does a DNS lookup work?
A lookup (query) usually passes through four roles:
-
Stub resolver - the DNS client in the operating system of your workstation, HMI or server asks the question, for example “what is the A record for
example.com?“. - Recursive resolver - a server run by your organisation or provider that finds the answer on behalf of the client and stores it temporarily (cache).
-
Root and TLD servers - if the answer is not cached, the resolver asks a root server
which name servers are responsible for
.com, then asks a TLD server which name servers handleexample.com. -
Authoritative name server - this server returns the definitive answer, for example the
address
192.0.2.10.
Every answer carries a TTL (time to live) in seconds. Until it expires, the resolver serves the answer from its cache, which is why root servers are not consulted for every lookup. There are 13 root server identities (A to M), run by 12 organisations and spread over more than 2,000 locations through anycast. RIPE NCC in Amsterdam operates K-root.
🔧 Which DNS records matter most?
| Record type | Function | IT/OT example |
|---|---|---|
A |
Maps a name to an IPv4 address | scada01 → 10.20.1.11 |
AAAA |
Maps a name to an IPv6 address | Newer IIoT gateways |
CNAME |
Alias for another name | historian → hist-prod-02 |
PTR |
Reverse lookup: IP to name | Readable names in firewall and SIEM logs |
SRV |
Locates a service plus port | How clients find a Domain Controller |
MX |
Points to mail servers | Alarm emails from a SCADA server |
TXT |
Free text, including SPF and DKIM | Domain verification, email security |
NS |
Indicates which name servers are authoritative | Delegating a subzone |
SOA |
Administrative data for the zone | Serial number and expiry timers |
Typical TTL values range from 300 seconds (fast changes, for example during failover) to 86,400 seconds (one day, for stable records). A short TTL makes switchover quicker but increases the load on name servers.
🛡️ What are the DNS risks and how do you reduce them?
DNS was designed in the 1980s without authentication or encryption, which makes the protocol attractive to attackers and a recurring security topic.
| Risk | What happens? | Security measure |
|---|---|---|
| Cache poisoning / spoofing | A forged answer ends up in the resolver cache | DNSSEC validation, up-to-date resolver software, random source ports |
| Exfiltration via DNS tunnelling | Data is hidden in long subdomain names | DNS Monitoring and blocking suspicious queries |
| Command and control | Malware fetches instructions via DNS | Internal resolvers only, reputation-based filtering |
| Unwanted resolvers | Clients bypass internal DNS, for example via DNS over HTTPS | Block outbound port 53 and known DoH services via a Firewall or Proxy |
| DDoS on name servers | Names can no longer be resolved | Redundant, distributed name servers |
| Domain hijacking | Registration or NS records are abused | Registrar lock, MFA on the registrar portal |
Two events show why this matters. In July 2008 Dan Kaminsky disclosed a design flaw (CVE-2008-1447) that let attackers poison the cache of almost any resolver; vendors released coordinated patches that randomised source ports. On 21 October 2016 the Mirai botnet, made up largely of compromised IoT devices, took down DNS provider Dyn, leaving major websites unreachable for hours.
DNSSEC adds digital signatures to DNS answers (RFC 4033 to 4035, 2005). The root zone has been signed since 2010. Encrypting the query itself is done with DNS over TLS (RFC 7858, port 853) or DNS over HTTPS (RFC 8484, port 443), both built on TLS.
🏭 Why does DNS matter in OT environments?
Many PLCs and field devices communicate using fixed IP addresses and do not use DNS themselves. Even so, hybrid IT/OT networks rely on DNS in more places than people often expect:
-
Windows domains - SCADA
servers, engineering workstations and historians in an OT domain locate their domain controller through SRV records such as
_ldap._tcp.dc._msdcs.<domain>. If DNS fails, logons and group policy fail too. - Certificates - OPC UA and other TLS connections often check that the host name in the certificate matches. A wrong DNS entry then results in rejected connections; see Certificate Management.
- Time and addressing - NTP sources are often configured by name, and DHCP can update DNS records automatically.
- Remote access and cloud - remote access solutions, licence servers and IIoT platforms use names outside your own network.
- Local name resolution - systems behind an air gap often rely on a hosts file. That is a static list, not DNS; it replaces DNS and must be updated by hand after every address change.
Much ICS equipment handles incorrect DNS settings poorly: long time-outs during start-up, delayed logons or connections that only recover after several minutes.
🧭 How do you set up DNS for an OT network?
A practical approach in line with the Purdue Model and IEC 62443:
- Dedicated resolvers per zone - place an internal resolver in each OT zone or in the DMZ. OT systems never query internet DNS directly.
-
Separate namespaces - use a separate internal zone for OT so that IT changes do not
affect OT names. Avoid made-up domains such as
.local, which is reserved for multicast DNS (port 5353), or.corp. Choose a subdomain of a domain you have registered, such asot.example.com, or the top-level domain.internal, which ICANN permanently reserved for private use in July 2024. - Restrict forwarding - let OT resolvers forward only to a trusted resolver in the DMZ, and block outbound ports 53 and 853 and known DoH services for every other system. This fits network segmentation.
- Redundancy - configure at least two resolvers per client; see Redundancy.
- Validate and log - enable DNSSEC validation on the boundary resolver and send query logs to a SIEM. An HMI that suddenly queries unknown domains is a strong signal.
- Manage as a configuration item - document records, TTLs and ownership just as you would firewall rules.
In the Netherlands DNSSEC has been on the Forum Standaardisatie “comply or explain” list since 2012, so government bodies must apply it when procuring ICT or explain why they do not. Under NIS2 and the Dutch Cybersecurity Act, in force since 15 August 2026, DNS service providers themselves fall under digital infrastructure. For other essential and important entities, reliable name resolution is part of the required measures for network security and continuity. The Dutch NCSC recommends DNSSEC validation and monitoring of DNS traffic.
❓ Frequently asked questions
What does DNS stand for?
DNS stands for Domain Name System. It is the naming system that converts human-readable names into IP addresses, so users and systems do not have to remember numeric addresses. DNS is defined in RFC 1034 and RFC 1035 from 1987.
Which port does DNS use?
Classic DNS uses port 53 over both UDP and TCP. TCP is used for large answers and zone transfers. Encrypted DNS over TLS uses port 853, and DNS over HTTPS uses port 443.
What is the difference between DNSSEC and DNS over HTTPS?
DNSSEC uses digital signatures to verify that a DNS answer is genuine and unaltered, but it encrypts nothing. DNS over HTTPS encrypts the query between client and resolver, but does not prove that the answer is correct. The two therefore complement each other.
Do PLCs need DNS?
Most PLCs communicate using fixed IP addresses and do not need DNS for their control task. In OT, DNS is mainly used by Windows systems such as SCADA servers, historians and engineering workstations. A PLC that suddenly generates DNS traffic therefore deserves a closer look.
Why should an OT network have its own DNS resolver?
With its own DNS resolver, name resolution keeps working when the link to IT or the internet goes down. You can also control which domains OT systems may query and log every query. That reduces the risk of DNS tunnelling and command-and-control traffic.
What is DNS cache poisoning?
In DNS cache poisoning an attacker places a forged answer in a resolver’s cache, so clients are sent to the wrong IP address. The best-known variant is the Kaminsky attack from 2008. DNSSEC validation and up-to-date resolver software are the main countermeasures.
📌 In summary
DNS is the foundational naming system that translates domain names into IP addresses, making it a silent dependency of both IT and OT networks. Setting up DNS deliberately in OT, with dedicated resolvers per zone, restricted forwarding, DNSSEC validation and logging, prevents outages and closes an important attack path. That makes DNS a standing concern within Cybersecurity.
