Sven Ruppert

1. Getting started – trust in everyday internet life

Anyone who enters a web address like “www.example.de” into the browser expects a familiar website to appear within seconds. Whether in the home office, at the university, or in the data center, access to online services is now a given. The underlying technical processes are invisible to most users; even in IT practice, they are often taken for granted. One of these invisible processes is name resolution by the Domain Name System (DNS).

DNS is the phone book of the Internet. It ensures that human-readable domain names are translated into numeric IP addresses so that computers worldwide can communicate with each other. Without DNS, there would be no URLs, emails, or APIs. Nevertheless, DNS has had a shadowy existence in the security discourse for a long time. It is not a purely technical detail but rather a central link in the trust relationship between the user, application, and infrastructure.

Because DNS works in the background, it is a popular target for attackers. DNS attacks aim to disrupt, manipulate, or redirect this process for your own purposes, with potentially serious consequences. Anyone who relies on a domain name always leading to the correct IP address risks falling into a well-disguised trap. The affected applications appear to continue to work perfectly—they just communicate with the wrong counterpart.

This text highlights the diverse forms of attacks on DNS, how they work, and their implications for the operation and development of secure systems. Particular attention is paid to the question of how DNS must be considered from the perspective of modern applications, especially in Java, so as not to become the Achilles heel of an otherwise solid security architecture.

2. The Domain Name System – backbone of the digital world

The Domain Name System has become integral to today’s Internet communication. It was developed in the early 1980s to replace the increasingly confusing web of growing hostnames with a scalable, hierarchical structure. Instead of remembering IP addresses, people can now use spoken domain names, and rely on them reliably pointing to the correct servers.

The basic job of DNS is to translate a string like “www.uni-heidelberg.de“ to an IP address like “129.206.100.168”. This process occurs in several steps and is handled by different types of servers. The process usually begins with the so-called resolver – a system service or external service provider that accepts requests from end devices. This resolver in turn queries root name servers, top-level domain servers (e.g. for .de, .com, .org) and finally authoritative name servers until it finds the IP address it is looking for.

The concept of caching is essential to DNS’s efficiency. Each resolver stores already resolved queries for a defined period of time to speed up re-queries. Operating systems and applications can also maintain their own DNS caches. This behavior contributes significantly to reducing global DNS traffic, but it is also one of the biggest weak points, as later chapters will show.

DNS is based on the User Datagram Protocol (UDP) and is stateless and unencrypted by design. Although extensions such as DNSSEC or DNS-over-HTTPS exist, they are far from being used widely in everyday life. This means that DNS remains an open system, efficient but vulnerable. The assumption that DNS “just works” quickly becomes a dangerous illusion from a security perspective.

3. Invisible Attack Surface – Why DNS is vulnerable

The architecture of the Domain Name System follows the paradigm of openness. This means that requests are standardised, unencrypted, and mostly stateless, which is precisely why they are particularly high-performance. But the very properties that make DNS a robust part of the Internet infrastructure also pose serious risks. The vulnerability of the DNS is not an accidental by-product of modern forms of attack but is rooted in the original system design.

DNS was designed when the Internet was a trusted space characterised by academic collaboration and open standards. Security mechanisms were not part of the design goal at the time. Accordingly, DNS still lacks built-in integrity, authenticity, and confidentiality. Queries are not verified, answers are not signed, and the source is not checked. This creates attack vectors that are still being exploited today by actors of all stripes.

Additionally, DNS requests are typically transmitted over UDP, which makes them easy to forge or intercept. Transaction IDs and ports offer minimal protection against spoofing, but these hurdles are technically easy to overcome with today’s means. Even with TCP-based fallbacks, absolute protection is lacking without additional measures such as DNSSEC.

A particular vulnerability lies in the caching behavior of resolvers and applications. Once saved, answers are considered valid for a certain period, regardless of whether they were correct or manipulated. Attackers can specifically exploit this behavior to inject false answers into the cache and thus redirect many subsequent requests. This so-called cache poisoning is one of the oldest but still most effective attacks on the DNS.

DNS is therefore not a secure anchor of trust, at least not without additional measures. Anyone using DNS in a security-critical architecture, such as modern Java applications, cloud APIs or container infrastructures, should know the inherent weaknesses. DNS is robust, but it can also be manipulated. This makes it an attractive target – and an often underestimated attack surface.

4. DNS cache poisoning – The classic attack

Among the numerous attack methods on the domain name system, DNS cache poisoning—also known as DNS spoofing—is considered particularly perfidious. The aim of this attack is to manipulate the caching of DNS responses. The attacker injects a fake DNS response into a resolver’s cache, with the effect that all subsequent queries to a specific domain name point to a false IP address. The affected users usually do not notice the attack: the website looks as usual, except that the attacker controls it.

The process of such an attack is as technically interesting as it is security-relevant. The attacker does not wait for a resolver to resolve a specific domain but proactively tries to outsmart the resolver with fake answers. To do this, it must guess the transaction ID of the DNS request – a short, 16-bit random number – and respond faster than the legitimate DNS server. If this succeeds, the resolver accepts the incorrect answer as valid and stores it in the cache.

What is particularly critical is that this manipulation persists: As long as the cache entry remains valid (TTL), every new request will return the same fake answer. This way, individual users and entire organisations can be systematically misled – for example, on phishing sites, fake authentication services or malware sources. This can result in a REST API being accessed supposedly successfully in Java applications, even though a completely different infrastructure is responding in the background.

Modern DNS implementations now rely on additional protection mechanisms such as random source ports, rate limiting, or DNSSEC. But many resolvers—especially on local networks or outdated systems—remain vulnerable. Even browsers or libraries with built-in DNS caching can become targets.

For developers, this means that the trust assumption that InetAddress.getByName() always returns the “correct” address is dangerous. Explicit protective measures are required when DNS is used in security-critical contexts, for example, through the use of cryptographically signed DNS responses (DNSSEC), deliberate cache invalidation, or explicit validation of the remote site, for example, via TLS certificates.

DNS cache poisoning is a lesson in how a helpful performance optimization—caching—can turn into the exact opposite. Anyone who wants to operate or use DNS securely must understand how the system works and how easily it can be manipulated at its core.

5. Amplification and Deception – DNS as a vehicle for DDoS and tunneling

In addition to the targeted manipulation of DNS caches, there are other attack scenarios in which DNS serves as a technical vehicle for higher-level goals, such as denial-of-service attacks or secret data transmission. Two particularly relevant variants in this context are DNS amplification and DNS tunneling.

A DNS amplification attack is a form of reflected denial of service (DoS) that exploits the asymmetric structure of the DNS protocol. The attacker sends a small DNS query – often of type ANY – to an open resolver, but spoofs the source address to point to the victim. The resolver responds with a significantly larger amount of data than the request, which is sent directly to the victim. Multiplied across many resolvers, this creates a massive data stream that is explicitly used to overload servers. DNS amplification is so effective because the attacker can cause disproportionate damage with minimal use of resources.

Another gateway is DNS tunneling. This technique uses DNS packets to pass any other data through firewalls or security measures. Since DNS traffic is hardly restricted in many networks, the protocol is ideal for bypassing control authorities. The payload—such as commands to malware or stolen data—is hidden in seemingly legitimate DNS queries or responses. On the receiving end, this information is extracted and evaluated again. DNS tunneling is considered particularly insidious because it is difficult to detect using traditional security tools.

A simple Java example demonstrating how a DNS tunnel could be hidden in a seemingly legitimate HTTP communication can be implemented using Java SE’s on-board tools. In the following scenario, we implement a minimalist REST server with com.sun.net.httpserver.HttpServer, which receives DNS-like encoded data, representative of a possible C2 channel (Command & Control).

HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);

server.createContext(“/api/lookup”, exchange -> {

    if (“GET”.equals(exchange.getRequestMethod())) {

        URI requestURI = exchange.getRequestURI();

        String query = requestURI.getQuery();

        if (query != null && query.contains(“q=”)) {

            String domainPayload = query.split(“q=”)[1];

            String decoded = domainPayload.replace(“.”, ” “); // simplified payload decoding

            System.out.println(“[DEBUG] Empfangenes DNS-Tunnel-Payload: ” + decoded);

        }

        String response = “OK”;

        exchange.sendResponseHeaders(200, response.length());

        exchange.getResponseBody().write(response.getBytes());

        exchange.close();

    }

});

server.setExecutor(null);

server.start();

In this simplified simulation, a DNS-like query parameter is received via a REST interface – e.g. b. http://localhost:8080/api/lookup?q=cmd.run.download. The server “interprets” the dot as a separator of an encoded DNS structure, as is common in DNS tunneling. In a real attack variant, this mechanism would be used by malware or scripts for bidirectional data exchange. What is critical here is that the transport takes place over seemingly unsuspicious channels – HTTP, DNS, ICMP – while the actual payload is hidden deep in protocol structures.

Both types of attacks have in common that DNS is not a direct target, but rather a tool – a transport system for superimposed attack targets. This results in the need for administrators and developers to monitor DNS traffic functionally and from a security perspective. In Java-based architectures, DNS dependencies should be consciously modeled, logged and – where possible – checked for validation and integrity. A simple forwarding of data via DNS may seem harmless, but it may be the start of a widespread attack.

6. DNS Hijacking – When attackers dictate the path

While DNS cache poisoning focuses on manipulating cached responses, DNS hijacking targets the source itself: the DNS resolver or the infrastructure that controls it. The attack begins when users resolve their domain names – either on the local device, on the home router, on corporate networks, or via an ISP’s resolver.

With DNS hijacking, DNS requests are systematically redirected – for example, through manipulation of network settings, compromised firmware, malicious DHCP servers or malware that specifically changes the configuration of a system. The resolver then no longer returns the IP addresses expected by the user, but instead forwards requests to servers controlled by the attacker. In practice, this means: Even if a user “www.bank.de“ enters something in your browser, you don’t end up on the real online banking portal, but on a phishing page that looks real.

This attack is hazardous because it is often difficult to detect. Unlike classic phishing, which relies on fake links or typos, DNS hijacking makes the actual URL appear completely legitimate. The certificate can also appear valid under certain circumstances—for example, with local man-in-the-middle proxies or if the attacker manages to obtain a certificate via compromised certificate authorities.

Java applications are also potentially affected, primarily if they communicate dynamically with external services. If the host machine’s DNS configuration is compromised, all DNS lookups within the JVM are affected, from REST clients to LDAP connections to email components. The application often does not recognize the problem because the connection is technically established correctly, just to the wrong destination.

The only solution is to take measures that secure DNS on several levels: through fixed resolver configurations, validation of the other side via TLS, use of secure DNS protocols such as DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), and by monitoring for suspicious name resolutions. In security-critical Java applications, it is recommended to compare the resolved IP addresses with allowlists or even to forego DNS queries if the target systems are known.

DNS hijacking is a remarkably sophisticated form of deception because it attacks trust where it seems most evident: in the integrity of the technical infrastructure itself.

7. Attack detected – but how?

Detecting DNS attacks is one of the most challenging tasks in network security. This is primarily because DNS is a widespread, dynamic and often invisible protocol. Name resolution occurs in the background, usually without direct user contact, and is often only incompletely recorded in logs and monitoring systems. Accordingly, many DNS-based attacks remain undetected for a long time, mainly when they are carried out precisely and subtly.

A central problem: Neither the browser nor the application registers whether a DNS response was legitimate, as long as the response is formally correct. A manipulated result usually does not differ from a real one, unless it is actively checked. This is where anomaly detection methods come into play. They try to identify unusual behavior, such as sudden changes in the IP assignment of known domains, an accumulation of DNS responses with short TTL or unusual destination addresses outside of usual networks.

Intrusion detection systems (IDS) and DNS-specific monitoring solutions such as Zeek, OpenDNS or SecurityOnion can help detect such anomalies. However, the prerequisite is that DNS traffic is completely recorded and evaluated, which brings additional complexity with encrypted DNS (DoH/DoT). In controlled networks, it is therefore recommended to route DNS via dedicated resolvers that can be logged and monitored.

In Java applications, suspicious name resolutions can be detected by logging IP mappings, comparing against expected hostnames, or active whitelisting. Metrics such as the number of different IP addresses per domain over time or the reuse of certain, unexpected IP ranges are also valuable information.

In the long term, comprehensive validation of DNS responses via DNSSEC is essential in ensuring integrity. However, DNSSEC is not retroactive – it only protects when domain owners and resolvers actively work together. Accordingly, awareness of DNS attacks and their detection is a crucial component of any security strategy: Anyone who only sees DNS as a technical infrastructure risks being compromised exactly where trust begins – with name resolution.

8. Protective measures – think and implement DNS securely

8.1 General Network Protection Measures

Detecting DNS attacks is one of the most challenging tasks in network security. This is primarily because DNS is a widespread, dynamic and often invisible protocol. Name resolution occurs in the background, usually without direct user contact, and is often only incompletely recorded in logs and monitoring systems. Accordingly, many DNS-based attacks remain undetected for a long time, especially when they are carried out specifically and subtly.

A central problem: Neither the browser nor the application registers whether a DNS response was legitimate, as long as the reaction is formally correct. A manipulated result usually does not differ from a real one, unless it is actively checked. This is where anomaly detection methods come into play. They try to identify unusual behavior, such as sudden changes in the IP assignment of known domains, an accumulation of DNS responses with short TTL or unusual destination addresses outside of usual networks.

Intrusion detection systems (IDS) and DNS-specific monitoring solutions such as Zeek, OpenDNS or SecurityOnion can help detect such anomalies. However, the prerequisite is that DNS traffic is completely recorded and evaluated, which brings additional complexity with encrypted DNS (DoH/DoT). In controlled networks, it is therefore recommended to route DNS via dedicated resolvers that can be logged and monitored.#### 8.2 Security within Java applications

In Java applications, suspicious name resolutions can be detected by logging IP mappings, comparing against expected hostnames, or active whitelisting. Metrics such as the number of different IP addresses per domain over time or the reuse of certain, unexpected IP ranges are also valuable information.

In the long term, comprehensive validation of DNS responses via DNSSEC is essential in ensuring integrity. However, DNSSEC is not retroactive – it only protects when domain owners and resolvers actively work together. Accordingly, awareness of DNS attacks and their detection is a crucial component of any security strategy: Anyone who only sees DNS as a technical infrastructure risks being compromised exactly where trust begins – with name resolution.

8.3 Advanced protection measures at protocol and application level

Various protection measures can be implemented for Java applications to minimize the risks of DNS-based attacks. A key approach is securing the name resolution process within the JVM. The class InetAddress, for example, uses resolvers close to the operating system, which makes the JVM fundamentally vulnerable to manipulation at the system level. In security-critical applications, it can, therefore, make sense to implement your own resolvers with DNSSEC validation or to use external, verified services.

Additionally, it is recommended to be combined with transport encryption and hostname validation at the application level. The HttpClient from the java.net.http module in Java 11+ enables e.g. B. direct control over TLS certificate checking. By securing via public key pinning, certificate transparency logs or targeted whitelists, manipulated DNS responses can be detected and blocked.

Another security option is to use alternative DNS protocols such as DoH (DNS over HTTPS) or DoT (DNS over TLS) via upstream proxies. These can also be integrated into containerized environments such as Kubernetes as sidecar resolvers. A locally running DNS proxy (e.g., CoreDNS with DNSSEC and DoH support) can be used as a trustworthy source within the application.

A practical example of a hedging measure in Java is using your own X509TrustManager to not rely solely on the system-provided chain of trust for the TLS connection. This is particularly useful if you want to counter DNS manipulations that do not break the TLS channel but subvert a false certificate chain – for example, through a compromised CA certificate or a manipulated trust store.

TrustManager[] trustManagers = new TrustManager[] {

    new X509TrustManager() {

        public X509Certificate[] getAcceptedIssuers() {

            return new X509Certificate[0];

        }

        public void checkClientTrusted(X509Certificate[] certs, String authType) {

            // Application-specific testing – e.g. E.g. fingerprinting or pinning

        }

        public void checkServerTrusted(X509Certificate[] certs, String authType) throws CertificateException {

            for (X509Certificate cert : certs) {

                cert.checkValidity();

                if (!”CN=trusted.example.com”.equals(cert.getSubjectDN().getName())) {

                    throw new CertificateException(“Untrusted CN: ” + cert.getSubjectDN());

                }

            }

        }

    }

};

SSLContext sslContext = SSLContext.getInstance(“TLS”);

sslContext.init(null, trustManagers, new SecureRandom());

HttpClient client = HttpClient.newBuilder()

    .sslContext(sslContext)

    .build();

This example deliberately checks the subject of the server certificate passed. This makes it possible to ensure that the remote site actually has the expected identity, even if a DNS hijacker manipulates the target system. A more detailed check would be necessary in a productive system, for example, via public key pinning, dedicated trust stores or certificate chain validation.

Last but not least: DNS requests should be logged, checked for plausibility and ideally compared with an allowlist. This allows a simple but effective protective layer to be implemented, especially in applications where external communication is security-critical.

9. Conclusion – trust needs protection

Given the central role of the domain name system in virtually every form of modern network communication, it is remarkable how long DNS security played a secondary role in the architecture of many applications. The forms of attack highlighted here – from cache poisoning to DNS hijacking to tunneling and DDoS – clearly show that DNS is much more than a harmless auxiliary component. It is one of the most critical infrastructures of all, and simultaneously one of the most vulnerable.

Anyone who develops applications today that rely on Internet communication must think about DNS functionally and in terms of security. This applies to web portals, microservices, container environments, and IoT devices. In the Java ecosystem, in particular, the platform from version 11 provides numerous APIs and mechanisms to specifically secure DNS dependencies, be it through explicit TLS configurations, validation of target addresses, logging of suspicious resolutions, or the use of alternative resolvers.

DNS is not a static problem. The attack vectors continue to develop, and with them, the requirements for protective mechanisms. At a time when trust is becoming a currency of digital interactions, DNS can no longer remain a blind spot. It is time for DNS security to be established as an integral part of every security-conscious software and infrastructure architecture – in the code, operations and all stakeholders’ minds. logged, checked for plausibility and ideally compared with an allowlist. This allows a simple but effective protective layer to be implemented, especially in applications where external communication is security-critical.

Happy Coding

Sven