DNS Spoofing & DNS-based Attacks — Maritime Cybersecurity Learning (Lesson 13)

📚 Series Maritime Cybersecurity Learning Roadmap | PART 2 Lesson 13 of 8 · Course Index →

PART 2 · Lesson 13 DNS · Infrastructure DNSSEC · DoH

DNS Spoofing & DNS-based Attacks

How DNS works · Cache Poisoning · DNS Hijacking · DNS Tunnelling · DNSSEC · DNS over HTTPS and TLS · Maritime VSAT DNS Risk — attacks that subvert the internet's naming system to redirect and intercept traffic.

Captain Paul

Maritime Cybersecurity · IACS UR E26/E27

September 2026

🎯 Lesson Objective

After this lesson you can explain how DNS resolution works, describe DNS cache poisoning and DNS hijacking attacks, explain what DNS tunnelling is and how it is used to bypass security controls, describe DNSSEC and how it defends against cache poisoning, explain DNS over HTTPS (DoH) and DNS over TLS (DoT), and identify the specific DNS security risks affecting maritime vessels over satellite communications links.

Every internet connection begins with a DNS lookup. When a browser, application, or operating system wants to connect to mail.example.com, it first asks the Domain Name System to resolve that name to an IP address. Only then does the actual connection begin. DNS is the telephone directory of the internet — an essential, distributed, globally replicated infrastructure that every networked device depends on dozens or hundreds of times per day.

DNS was designed in 1983 for a small, trusted academic network. It was not designed with authentication, encryption, or integrity verification. A DNS response is taken at face value — there is no mechanism in classic DNS to verify that the answer received is genuine and not forged. This fundamental design gap has been exploited in a variety of DNS-based attack techniques that redirect traffic, intercept communications, and exfiltrate data covertly.

For maritime professionals, DNS attacks are particularly relevant in two contexts: the VSAT satellite link that ships use to communicate with the internet (where the DNS resolver configuration is controlled by the satellite service provider, and manipulation is possible at multiple points in the chain), and port network environments where crew devices may connect to networks with compromised DNS resolvers.

1. How DNS Resolution Works — The Target

When a device needs to resolve a domain name, the process follows a hierarchy of queries. The device's DNS resolver (usually the ISP or corporate resolver configured by DHCP) checks its local cache first. If not found, it queries the root servers (which delegate to the TLD servers for .com, .org, etc.), then the authoritative nameserver for the domain. The final authoritative answer — the IP address — is returned and cached locally for a period defined by the record's TTL (Time to Live).

DNS RESOLUTION CHAIN

Device → Local Cache → Recursive Resolver
Recursive Resolver → Root Server (which root?)
Root Server → TLD Server (.com?)
TLD Server → Authoritative NS (example.com?)
Authoritative NS → IP Address: 93.184.216.34
Resolver → Device (cached for TTL seconds)

Each of these steps transmits a UDP packet over port 53, unauthenticated and unencrypted in classic DNS. The DNS transaction ID (a 16-bit number) is supposed to match responses to requests, but in practice this provides minimal protection against a positioned or lucky attacker.

2. DNS Attack Techniques

DNS Attack Taxonomy

DNS Cache Poisoning	The attacker sends a forged DNS response that arrives before the legitimate response, injecting a false IP address into the resolver's cache. All users whose devices query that resolver then receive the forged address and connect to the attacker's server, believing it is the real destination. The Kaminsky Attack (2008) demonstrated this could be done in minutes with available tools by randomising the source port and transaction ID simultaneously. Cache poisoning affects all users of the compromised resolver until the TTL expires.
DNS Hijacking	Rather than poisoning the cache, the attacker directly modifies DNS records at the authoritative source — either by compromising the domain registrar account (credential theft, social engineering), the DNS hosting provider, or a router whose DNS settings the attacker has modified. DNS hijacking at the registrar level is used in sophisticated supply chain and espionage campaigns to redirect all traffic for a domain to attacker-controlled infrastructure.
DNS Tunnelling	DNS queries are rarely blocked at the network perimeter — organisations that block HTTP and HTTPS outbound traffic often still allow DNS. An attacker who has compromised an internal host can encode data in DNS queries (e.g. in subdomains) and exfiltrate it to an attacker-controlled nameserver, bypassing data loss prevention controls. DNS tunnelling is also used by malware for command-and-control (C2) communications. Detection requires DNS traffic analysis for anomalously long or frequent subdomains.
DNS DDoS Amplification	As discussed in Lesson 8, DNS is commonly abused as a DDoS amplification vector. A small DNS query (60 bytes) for a large record can produce a response of 3,000+ bytes — a 50× amplification factor. Open DNS resolvers (those that respond to queries from any IP) are used to reflect and amplify traffic against a target by spoofing the source IP.

3. Defences — DNSSEC, DoH, and DoT

🔐 DNSSEC

DNS Security Extensions add cryptographic signatures to DNS records. The authoritative nameserver signs each record with its private key; the resolver validates the signature using the corresponding public key, which is itself chained back to the root via a trust hierarchy. A poisoned or modified DNS response will fail signature validation and be rejected. DNSSEC is the definitive defence against cache poisoning and record modification in transit.

Limitation: DNSSEC does not encrypt DNS queries — it only authenticates records. It protects integrity but not confidentiality. Many domains have not deployed DNSSEC despite it being available.

🔒 DNS over HTTPS / DNS over TLS

DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries between the client and the resolver, preventing eavesdropping on DNS traffic and on-path tampering. They protect against an attacker on the local network (port Wi-Fi, VSAT) who could otherwise observe and manipulate DNS queries in transit. Modern browsers support DoH natively; operating systems increasingly support DoT.

Maritime relevance: On VSAT links where the satellite provider operates the DNS resolver, DoH/DoT routes queries to a separate encrypted resolver, bypassing potential interception or manipulation at the provider level.

Additional DNS Security Controls

Registrar Account Security	Protect domain registrar accounts with strong, unique passwords and MFA. DNS hijacking via registrar compromise is a common entry point for sophisticated attackers targeting an organisation's internet presence.
DNS Monitoring	Monitor DNS traffic for anomalies: unusually long subdomain strings (tunnelling indicator), high volume of queries to unusual TLDs, queries to known malware C2 domains (via threat intelligence feeds), and unexpected changes to critical records.
Recursive Resolver Configuration	Use enterprise DNS resolvers that support DNSSEC validation, apply filtering (blocking known malicious domains), and are not exposed as open resolvers. Configure client devices to use only corporate DNS servers via DHCP enforcement, preventing use of attacker-configured resolvers on untrusted networks.
Block DNS Tunnelling	Deploy DNS traffic analysis that flags anomalously long or high-frequency subdomain queries. Block DNS queries to external resolvers that bypass corporate DNS. Restrict outbound DNS to the corporate resolver so tunnelling traffic cannot reach an attacker-controlled nameserver.

⚓ Maritime DNS Risk — VSAT and Port Networks

Vessels operating on VSAT links rely on the satellite service provider's DNS infrastructure. The resolver configuration is typically applied via DHCP from the satellite modem — the vessel's own IT department often has limited visibility into or control over which resolvers are used, or whether those resolvers perform DNSSEC validation.

In port, crew devices connecting to port Wi-Fi or cellular networks receive DNS configuration from the network operator. A compromised or attacker-controlled Wi-Fi access point can assign itself as the DNS resolver, positioning itself to intercept and redirect all DNS queries — and by extension, redirect all unencrypted or HTTPS-downgraded traffic to attacker-controlled servers.

Recommended controls for maritime operators: Enforce DoH or DoT on company devices so DNS queries are encrypted regardless of the underlying network. Configure a corporate DNS resolver (e.g. an always-on VPN that forces DNS through a company-controlled resolver) so the satellite provider or port network cannot intercept or manipulate DNS. Monitor DNS query logs from VSAT links for tunnelling indicators and unexpected record changes.

✍️ Author Insight — From the Field

Captain Paul · Maritime Cybersecurity Consultant · IACS UR E26/E27

DNS security receives significantly less attention in maritime cybersecurity assessments than it warrants. During E26 CRSI assessments, it is common to find that vessel IT configurations rely entirely on the VSAT provider's DNS resolver with no DNSSEC validation, no DoH/DoT enforcement on end devices, and no DNS traffic monitoring capability. The DNS resolver used by crew and officer laptops on board is often opaque to the ship's IT management.

The DNS configuration question — "who resolves your DNS and how do you verify the responses are authentic?" — frequently yields a response along the lines of "we use whatever the VSAT provider gives us". This is not an unreasonable operational default, but it represents a gap in the security architecture: the vessel's entire internet connectivity, including access to company email, fleet management systems, and OEM remote support portals, is routed through a resolver whose integrity the operator has not verified.

Minimum recommended posture: Enforce always-on VPN with split-DNS disabled (all DNS through corporate resolver), configure corporate resolver to enforce DNSSEC validation, enable DNS query logging with alerting on anomalous patterns, and include DNS configuration review in the scope of annual cybersecurity assessments and VSAT contract negotiations.

🎉 PART 2 Complete

Understanding Cyber Attacks — All 7 Lessons

You have completed all seven lessons of PART 2. You can now explain the core mechanisms of: Phishing & Social Engineering, Ransomware & the Cyber Kill Chain, DoS and DDoS Attacks, Man-in-the-Middle Attacks, SQL Injection, Cross-Site Scripting, and DNS-based Attacks — and their specific implications in maritime operational environments.

Continue to PART 3 →

✅ Key Takeaways — Lesson 13

• DNS translates human-readable domain names to IP addresses and was not designed with authentication or encryption.
• DNS Cache Poisoning injects false IP addresses into a resolver's cache, redirecting all users of that resolver to attacker-controlled servers.
• DNS Hijacking modifies authoritative DNS records by compromising the registrar or DNS hosting account — protect these accounts with MFA.
• DNS Tunnelling encodes data in DNS queries to exfiltrate data or establish C2 channels, bypassing traditional firewall controls.
• DNSSEC adds cryptographic signatures that allow resolvers to detect tampered or poisoned DNS responses.
• DoH and DoT encrypt DNS queries between the client and resolver, preventing local network eavesdropping and on-path manipulation.
• Maritime vessels over VSAT should enforce corporate DNS via always-on VPN and audit the DNS configuration included in satellite service agreements.

📚 PART 2 — Understanding Cyber Attacks

DoneLesson 6 — Phishing & Social Engineering

DoneLesson 7 — Ransomware & the Cyber Kill Chain

DoneLesson 8 — DoS and DDoS Attacks

DoneLesson 9 — Man-in-the-Middle (MitM) Attacks

DoneLesson 10 — SQL Injection

DoneLesson 11 — Cross-Site Scripting (XSS)

DoneLesson 12 — Zero-Day Vulnerabilities and Exploits

Current Lesson 13 — DNS Spoofing & DNS-based Attacks

✅ PART 2 Complete — All 8 Lessons Finished

← Return to Course Index

⚓ Join the ShipPaulJobs Community

Join →