Lesson 06 — DNS Security

Learning Objectives

By the end of this lesson, you will be able to:

Understand Kubernetes DNS architecture
Learn how CoreDNS works
Understand service discovery
Learn DNS naming conventions
Identify common DNS security threats
Prevent DNS spoofing and DNS tunnelling
Secure DNS in Amazon EKS
Apply enterprise DNS security best practices

Why This Matters

Every application running inside Kubernetes depends on DNS.

When a frontend application communicates with a backend API, it rarely connects using an IP address.

Instead, it connects using names such as:

payment-service

user-service

database-service

Without DNS:

Applications cannot locate each other.
Microservices fail to communicate.
Service discovery breaks.
Cluster operations become unreliable.

Attackers also understand the importance of DNS.

DNS is commonly abused for:

Data exfiltration
Command & Control (C2)
DNS spoofing
DNS tunnelling
Malware communication
Internal reconnaissance

For Cloud Security Engineers, DNS is both a critical networking component and a valuable security monitoring source.

What is DNS?

DNS (Domain Name System) translates human-readable names into IP addresses.

Instead of remembering:

10.100.15.24

Applications simply use:

payment-service

DNS automatically resolves the name into the correct IP address.

DNS in Kubernetes

Kubernetes includes an internal DNS service called CoreDNS.

CoreDNS automatically creates DNS records for Kubernetes Services.

Example:

Frontend Pod

↓

payment-service

↓

CoreDNS

↓

10.96.5.20

↓

Payment Pod

Applications never need to know Pod IP addresses.

Why Kubernetes Uses DNS

Pods are temporary.

For example:

Payment Pod

↓

Deleted

↓

New Pod Created

↓

New IP Address

If applications communicated directly using IP addresses, they would fail whenever Pods were recreated.

DNS provides a stable method for discovering services.

Kubernetes Service Discovery

Service discovery allows applications to locate other services automatically.

Frontend

↓

API Service

↓

Database Service

↓

Notification Service

Developers only need to know service names—not IP addresses.

CoreDNS Architecture

Application Pod

↓

DNS Query

↓

CoreDNS

↓

Kubernetes API

↓

Service IP

↓

Application Connects

CoreDNS dynamically retrieves service information from the Kubernetes API Server.

DNS Naming Convention

Kubernetes automatically generates fully qualified domain names (FQDNs).

General format:

service.namespace.svc.cluster.local

Example:

payment-service.default.svc.cluster.local

Components:

Component	Description
payment-service	Service name
default	Namespace
svc	Kubernetes Service
cluster.local	Cluster domain

Applications can use either the short name or the full DNS name.

DNS Resolution Process

Example workflow:

Frontend Pod

↓

payment-service

↓

CoreDNS

↓

ClusterIP

↓

Payment Service

↓

Payment Pod

The DNS lookup happens automatically before communication begins.

Internal vs External DNS

Internal DNS	External DNS
Service discovery	Internet domains
CoreDNS	Public DNS providers
Cluster-local	Global
Private	Public

Kubernetes uses both depending on the destination.

DNS in Amazon EKS

Amazon EKS typically combines:

CoreDNS
Amazon VPC DNS
Amazon Route 53
VPC Endpoints

Architecture:

Pod

↓

CoreDNS

↓

Amazon VPC DNS

↓

Amazon Route 53

↓

Internet

This enables workloads to resolve both Kubernetes services and external AWS resources.

Common DNS Security Threats

Attackers frequently abuse DNS.

Examples include:

DNS Spoofing
DNS Cache Poisoning
DNS Tunnelling
DNS Amplification
Domain Generation Algorithms (DGAs)
Malicious DNS Servers
Command & Control communication

Because DNS is almost always allowed through firewalls, it is an attractive attack vector.

DNS Spoofing

DNS Spoofing tricks applications into connecting to malicious destinations.

Example:

Application

↓

payment-service

↓

Attacker DNS Response

↓

Malicious Server

Consequences include:

Credential theft
Malware delivery
Man-in-the-Middle attacks
Data interception

DNS Cache Poisoning

DNS servers temporarily cache responses.

If an attacker poisons the cache:

Application

↓

DNS Cache

↓

Malicious IP

↓

Attacker

Every application using the cache receives the malicious response until the cache expires.

DNS Tunnelling

DNS Tunnelling hides data inside DNS queries.

Example:

Compromised Pod

↓

DNS Query

↓

Attacker Domain

↓

Data Exfiltration

Attackers use DNS because:

DNS traffic is often trusted.
It bypasses some firewalls.
It is difficult to detect without monitoring.

Command & Control (C2)

Malware frequently communicates with external infrastructure using DNS.

Malware

↓

DNS Request

↓

Attacker Server

↓

Commands Received

Indicators include:

High volumes of DNS requests
Random-looking domain names
Long DNS query strings
Newly registered domains

DNS Security in Amazon EKS

Enterprise environments protect DNS using:

CoreDNS
Amazon Route 53 Resolver
Route 53 Resolver DNS Firewall
AWS Network Firewall
VPC Endpoints
DNS query logging
GuardDuty

These controls help detect malicious DNS activity and prevent communication with known malicious domains.

Route 53 Resolver DNS Firewall

AWS Route 53 Resolver DNS Firewall allows organisations to control which domains workloads may resolve.

Example:

Pod

↓

DNS Query

↓

DNS Firewall

↓

Approved Domain

✓ Allowed

--------------------

Unknown Domain

✗ Blocked

This helps prevent malware from communicating with external infrastructure.

Enterprise DNS Architecture

Application

↓

CoreDNS

↓

Route 53 Resolver

↓

DNS Firewall

↓

AWS Network Firewall

↓

Internet

Every DNS request passes through multiple security controls before reaching external networks.

Enterprise Example

A multinational bank hosts hundreds of applications on Amazon EKS.

Applications communicate internally using:

payments.default.svc.cluster.local

↓

CoreDNS

↓

Payment Service

Outbound DNS requests pass through:

Route 53 Resolver
Route 53 DNS Firewall
AWS Network Firewall
Security monitoring

Blocked domains include:

Malware domains
Cryptocurrency mining pools
Known phishing sites
Command & Control infrastructure

This architecture protects critical financial systems while maintaining reliable service discovery.

Common DNS Security Risks

Cloud Security Engineers frequently identify:

Open DNS resolvers
Unrestricted outbound DNS
Missing DNS logging
DNS tunnelling
Misconfigured CoreDNS
Cache poisoning
Weak DNS monitoring
Public DNS usage
Missing DNS Firewall rules
Excessive DNS permissions

These weaknesses increase the risk of malware communication and data exfiltration.

Enterprise Monitoring

Security teams should monitor:

DNS query volume
Failed DNS lookups
Newly registered domains
Suspicious domain names
DNS tunnelling indicators
High-entropy DNS queries
External DNS usage
DNS Firewall events
CoreDNS health
DNS latency

DNS telemetry is a valuable source of threat intelligence.

DNS Security Design Strategy

A recommended enterprise approach:

Step 1

↓

Deploy CoreDNS

↓

Step 2

↓

Enable DNS Logging

↓

Step 3

↓

Implement Route 53 DNS Firewall

↓

Step 4

↓

Restrict External DNS

↓

Step 5

↓

Monitor DNS Queries

↓

Step 6

↓

Investigate Anomalies

This layered approach improves both security and visibility.

Best Practices

As a Kubernetes Security Engineer:

Use CoreDNS for Kubernetes service discovery.
Keep CoreDNS updated to the latest supported version.
Enable DNS query logging.
Use Route 53 Resolver DNS Firewall to restrict malicious domains.
Monitor for DNS tunnelling and unusual query patterns.
Prevent workloads from using unauthorised external DNS servers.
Use VPC Endpoints for AWS services to reduce unnecessary external DNS traffic.
Integrate DNS monitoring with GuardDuty and Security Hub.
Periodically review DNS Firewall rules.
Treat DNS as a critical security control rather than just a networking service.

Strong DNS security improves service reliability while helping detect malware, data exfiltration and attacker activity.

Real-World Scenario

A ransomware group compromises a container running in Amazon EKS.

The malware attempts to:

Resolve attacker-controlled domains
Download additional payloads
Exfiltrate encryption keys using DNS tunnelling

Because the organisation has implemented:

Route 53 Resolver DNS Firewall
DNS query logging
AWS GuardDuty
AWS Network Firewall
Continuous DNS monitoring

the malicious DNS requests are blocked and security analysts receive immediate alerts.

The attacker cannot establish Command & Control communication or exfiltrate sensitive information.

Key Takeaways

After completing this lesson, you should understand:

How Kubernetes DNS works
The role of CoreDNS
Kubernetes service discovery
DNS naming conventions
DNS spoofing and cache poisoning
DNS tunnelling and Command & Control attacks
Route 53 Resolver DNS Firewall
Enterprise DNS architectures
DNS monitoring and best practices

DNS is one of the most critical services in Kubernetes. Beyond enabling service discovery, it plays a major role in detecting malicious activity, preventing data exfiltration and supporting Zero Trust networking in Amazon EKS.

Knowledge Check

Question 1

Which DNS service is used by Kubernetes for internal service discovery?

A. Amazon Route 53
B. CoreDNS
C. BIND
D. kube-proxy

Answer: B

Question 2

What is the default fully qualified domain name (FQDN) format for a Kubernetes Service?

A. service.cluster.local
B. service.namespace.svc.cluster.local
C. namespace.service.local
D. service.aws.local

Answer: B

Question 3

Which attack technique uses DNS queries to secretly transfer data out of an environment?

A. DNS Spoofing
B. DNS Tunnelling
C. DNS Caching
D. DNS Replication

Answer: B

Question 4

Which AWS service can block DNS queries to known malicious or unauthorised domains?

A. Amazon CloudFront
B. Route 53 Resolver DNS Firewall
C. AWS Shield
D. Amazon Inspector

Answer: B

Question 5

Which of the following is considered an enterprise DNS security best practice?

A. Allow unrestricted use of public DNS servers.
B. Disable DNS logging to improve performance.
C. Enable DNS logging, use Route 53 Resolver DNS Firewall and monitor for DNS tunnelling.
D. Configure applications to communicate using Pod IP addresses instead of DNS.

Answer: C

What’s Next?

In the next lesson, you will learn about Service Mesh & mTLS, exploring how enterprise organisations secure service-to-service communication using Istio, Linkerd, Envoy Proxy, Mutual TLS (mTLS), identity-based networking and Zero Trust principles in Amazon EKS.

➡️ Next Lesson: Lesson 07 — Service Mesh & mTLS