OpenShift 4 DNS Deep Dive

OpenShift 4 DNS
Deep Dive

Architecture, Resolution Flows & Troubleshooting Methodology

Session Agenda

45-Minute Structured Deep Dive

02

1

DNS Foundations

Why DNS Matters in OpenShift 4
CoreDNS vs Node Resolver
DNS Operator Overview

2

Architecture

Cluster DNS Components
Pod DNS Resolution Flow
Service Discovery Mechanism

3

Configuration

DNS Operator Config
Custom DNS Forwarding
DNS Policy & Options

4

Troubleshooting

Common DNS Failures
Diagnostic Commands
Real-World Scenarios

5

Best Practices

DNS High Availability
Performance Tuning
Disconnected Environments

6

Q&A

Interactive Discussion
Case Review
Resources & References

Why DNS is Critical in OpenShift 4

The Invisible Fabric of Cluster Communication

03

!

Every Pod Depends on DNS

Service-to-service communication via service.namespace.svc.cluster.local
External API calls (Red Hat registries, cloud providers)
Operator lifecycle management (OLM catalog sources)
Image pull operations (registry resolution)
etcd cluster discovery and peer communication

Support Reality: 30%+ of "networking" cases are actually DNS misconfiguration or resolution failures masked as connectivity issues.

⚡

DNS Failure Cascade

DNS Failure

↓

Image Pull Failures

↓

Operator CrashLoop

↓

Service Unreachable

↓

App Downtime

Key Insight: DNS is not just a "networking" component—it's a cluster-critical infrastructure service. When DNS fails, everything fails.

OpenShift 4 DNS Core Components

Three Layers of DNS Resolution

04

1

DNS Operator

Namespace: openshift-dns-operator
Manages CoreDNS daemonset
Watches DNS CR (cluster)
Updates CoreDNS config via ConfigMap
Reconciles on node changes

2

CoreDNS (DaemonSet)

Namespace: openshift-dns
Runs on every node via DaemonSet
Listens on 172.30.0.10:53 (cluster IP)
Resolves cluster.local and forwards upstream
Metrics exposed on port 9154

3

Node Resolver (systemd-resolved)

Runs on every RHEL CoreOS node
Manages /etc/resolv.conf
Intercepts DNS queries from host
Forwards to CoreDNS for cluster domains
Uses /etc/resolv.conf for upstream

4

Service Network

Cluster IP: 172.30.0.10 (default)
Kubernetes service: dns-default
Endpoints point to CoreDNS pods
iptables/IPVS rules distribute traffic

Architecture Principle: DNS is distributed by design. Every node runs its own resolver, eliminating single points of failure for DNS resolution.

DNS Architecture Diagram

Complete Request Flow from Pod to External World

05

OPENSHIFT 4 CLUSTER

Pod A

(App)

Pod B

(App)

Pod C

(App)

Host (Node)

(Debug)

1. Query
mysvc.ns.svc
.cluster.local

1. Query
google.com

1. Query
api.redhat.com
.redhat.io

1. Query
registry
.redhat.io

  /etc/resolv.conf (injected by OpenShift)

  nameserver 172.30.0.10   search <namespace>.svc.cluster.local svc.cluster.local cluster.local

Service Network — 172.30.0.10:53 (UDP) → dns-default Service

CoreDNS Pod

(Node 1) — DaemonSet

CoreDNS Pod

(Node 2) — DaemonSet

CoreDNS Pod

(Node 3) — DaemonSet

2. cluster.local

(Kubernetes API)

2. Forward upstream

(External)

Kubernetes API Server

(Port 6443)

Upstream DNS

(Corporate / ISP)

3. Response back to Pod

Application Pod

resolv.conf

Service Network

CoreDNS Pod

Upstream / API

Key Point: CoreDNS pods run as DaemonSet, so every node has a local DNS resolver. The Service IP (172.30.0.10) is virtual and routes to the local CoreDNS pod via iptables/IPVS.

DNS Operator Deep Dive

The Control Plane of Cluster DNS

06

📋

Operator Resources

Resource	Name	Namespace
Deployment	dns-operator	openshift-dns-operator
DNS CR	default	Cluster-scoped
DaemonSet	dns-default	openshift-dns
Service	dns-default	openshift-dns
ConfigMap	dns-default	openshift-dns

⚙️

Operator Responsibilities

Creates and manages CoreDNS DaemonSet
Generates CoreDNS Corefile from DNS CR
Updates ConfigMap on configuration changes
Rolls out CoreDNS pods on node additions
Exposes metrics for monitoring

🔍

DNS CR (Custom Resource)

apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: custom-dns
    zones:
    - example.com
    forwardPlugin:
      upstreams:
      - 10.1.2.3
      - 10.4.5.6
  nodePlacement:
    nodeSelector:
      node-role.kubernetes.io/worker: ""
  managementState: Managed

Command: oc get dnses.operator.openshift.io default -o yaml to view full configuration.

CoreDNS Corefile Analysis

Understanding the DNS Server Configuration

07

📄

Corefile Structure

.:53 {
    bufsize 512
    errors
    health {
        lameduck 20s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9154
    forward . /etc/resolv.conf {
        policy sequential
    }
    cache 900 {
        denial 9984 30
    }
    reload
}

🔧

Plugin Breakdown

bufsize 512 - Prevents UDP fragmentation
errors - Logs DNS errors to stdout
health - Liveness probe endpoint
ready - Readiness probe endpoint
kubernetes - K8s service discovery
prometheus - Metrics export
forward - Upstream delegation
cache - Response caching (15 min)
reload - Auto-reload on change

Important: The forward . /etc/resolv.conf plugin uses the node's resolv.conf, NOT the pod's. This is critical for upstream resolution.

Pod DNS Resolution Flow

Step-by-Step Internal Service Lookup

08

1️⃣

Step 1: Pod Init

Kubelet injects /etc/resolv.conf
Contains nameserver 172.30.0.10
Search domains configured:

search myapp.svc.cluster.local        svc.cluster.local        cluster.local        example.com

2️⃣

Step 2: Query Generation

App calls: curl mysvc
Resolver expands using search domains
First try: mysvc.myapp.svc.cluster.local
Then: mysvc.svc.cluster.local

3️⃣

Step 3: CoreDNS Processing

Query hits CoreDNS pod on same node
kubernetes plugin intercepts
Queries Kubernetes API for Service
Retrieves ClusterIP (e.g., 172.30.1.50)

4️⃣

Step 4: Response

CoreDNS returns A record
Pod receives ClusterIP
Traffic routed via Service Network
iptables/IPVS load balances to endpoints

Optimization: ndots:5 in resolv.conf means queries with ≥5 dots are treated as FQDNs, skipping search domain expansion.

External DNS Resolution Flow

How Pods Reach the Internet

09

🌐

Resolution Path

Pod Query
registry.redhat.io

→

CoreDNS
172.30.0.10

CoreDNS
Not cluster.local

→

Forward Plugin
/etc/resolv.conf

Node's
systemd-resolved

→

Upstream DNS
8.8.8.8 / Corporate

⚠️

Critical Chain

CoreDNS reads /etc/resolv.conf from the node, not the pod
Node's resolv.conf is managed by NetworkManager or systemd-resolved
Node must have valid upstream DNS configured
Disconnected environments need custom forwarders

🔍

Verification Commands

# Check node resolv.conf
oc debug node/ -- chroot /host cat /etc/resolv.conf

# Check CoreDNS pod resolv.conf
oc exec -n openshift-dns  -- cat /etc/resolv.conf

# Test resolution from pod
oc exec  -- nslookup registry.redhat.io

DNS Records & Zones in OpenShift

What Gets Resolved and How

10

📋

Record Types

Record	Format	Example
A/AAAA	<service>.<ns>.svc.cluster.local	172.30.1.50
SRV	_<port>._<proto>.<svc>.<ns>	web:80
PTR	<reverse-ip>.in-addr.arpa	mysvc.myns
CNAME	ExternalName Service	external.example.com

🎯

Special Zones

cluster.local - Internal services
in-addr.arpa - Reverse DNS (IPv4)
ip6.arpa - Reverse DNS (IPv6)
<cluster-domain> - Ingress routes

🔗

Service DNS Formats

# Standard service
myservice.mynamespace.svc.cluster.local

# Service with port name (SRV)
_http._tcp.myservice.mynamespace.svc.cluster.local

# Headless service (returns pod IPs)
myservice.mynamespace.svc.cluster.local
  → 10.128.0.10, 10.128.0.11

# ExternalName service
myservice.mynamespace.svc.cluster.local
  → CNAME: external.example.com

Headless Services: When clusterIP: None, DNS returns A records for all pod IPs directly, enabling direct pod-to-pod communication.

Custom DNS Configuration

Forwarders, Zones & Disconnected Environments

11

⚙️

Custom Forwarders

apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: corp-dns
    zones:
    - corp.example.com
    forwardPlugin:
      upstreams:
      - 10.1.2.3
      - 10.1.2.4:5353
  upstreamResolvers:
    policy: Sequential
    upstreams:
    - type: SystemResolvConf
    - type: Network
      address: 8.8.8.8
      port: 53

Policy Options: Sequential (failover), RoundRobin (load balance), Random

🏭

Disconnected Environment

No public DNS access available
Must configure internal DNS forwarders
Mirror registry DNS must resolve
OLM catalog sources need resolution

# Verify in disconnected
oc debug node/ -- chroot /host   nslookup registry.example.com

# Check if CoreDNS can reach forwarder
oc exec -n openshift-dns  --   dig @10.1.2.3 registry.example.com

Common Mistake: Setting upstream to 127.0.0.1 in node resolv.conf causes CoreDNS forwarding loops. Always use valid external IPs.

DNS Policies & Pod Configuration

Controlling Pod DNS Behavior

12

📋

dnsPolicy Options

Policy	Behavior	Use Case
ClusterFirst	Use cluster DNS (default)	Standard apps
Default	Use node resolv.conf	Host networking pods
ClusterFirstWithHostNet	Cluster DNS + host network	HostNetwork pods needing cluster DNS
None	Custom dnsConfig only	Advanced tuning

🔧

dnsConfig Options

dnsPolicy: "None"
dnsConfig:
  nameservers:
    - 10.1.2.3
  searches:
    - ns1.svc.cluster.local
    - mydomain.com
  options:
    - name: ndots
      value: "2"
    - name: edns0

⚠️

Important Considerations

ClusterFirst is default and recommended
ndots controls search domain expansion threshold
Lowering ndots reduces DNS query volume
Custom nameservers bypass CoreDNS entirely
HostNetwork pods default to Default policy

Scenario: High DNS Query Volume

App makes 1000s of queries to api.external.com. With ndots:5, each query triggers 4 search domain attempts first. Fix: Set ndots:2 or use FQDN with trailing dot: api.external.com.

DNS Troubleshooting Methodology

Systematic Approach to DNS Issues

13

🔍

The 5-Step Diagnostic Flow

Step 1
Identify Scope

→

Step 2
Check Components

One Pod? One Node? All Pods? External Only?

Step 3
Test Resolution

→

Step 4
Inspect Config

nslookup dig host curl -v

Step 5
Analyze Logs

→

Resolution
Fix & Verify

CoreDNS Node NetworkPolicy

Golden Rule: Always determine if the issue is cluster-internal (service.namespace.svc.cluster.local) or external (registry.redhat.io). The resolution paths are completely different.

Essential Diagnostic Commands

The Support Engineer's Toolkit

14

🎯

Pod-Level Testing

# Basic resolution test
oc exec  -- nslookup kubernetes.default

# Detailed DNS query with dig
oc exec  -- dig @172.30.0.10 mysvc.mynamespace.svc.cluster.local

# Check pod's resolv.conf
oc exec  -- cat /etc/resolv.conf

# Test external resolution
oc exec  -- nslookup registry.redhat.io

🖥️

Node-Level Testing

# Debug node and check resolv.conf
oc debug node/ -- chroot /host   cat /etc/resolv.conf

# Test node DNS resolution
oc debug node/ -- chroot /host   nslookup registry.redhat.io

# Check systemd-resolved status
oc debug node/ -- chroot /host   systemctl status systemd-resolved

🔧

CoreDNS Inspection

# Check CoreDNS pod status
oc get pods -n openshift-dns -o wide

# View CoreDNS logs
oc logs -n openshift-dns -l dns.operator.openshift.io/daemonset-dns=default

# Check CoreDNS metrics
curl http://:9154/metrics

# Verify Corefile config
oc get configmap dns-default -n openshift-dns -o yaml

📊

Operator & CR Status

# Check DNS operator status
oc get clusteroperator dns

# View DNS CR
oc get dnses.operator.openshift.io default -o yaml

# Check DNS service endpoints
oc get endpoints dns-default -n openshift-dns

# Verify DNS service
oc get svc dns-default -n openshift-dns

Common Issue #1: CoreDNS Pod Failures

DaemonSet Not Running on All Nodes

15

🔴

Symptoms

DNS resolution fails on specific nodes only
Intermittent DNS timeouts
oc get pods -n openshift-dns shows CrashLoopBackOff
NodeNotReady or SchedulingDisabled nodes

🔍

Root Causes

Node resource exhaustion (memory/CPU)
Image pull failures for CoreDNS
CNI network not ready on node
Taints preventing pod scheduling
Corrupted CoreDNS ConfigMap

🛠️

Resolution Steps

# 1. Check CoreDNS pod status per node
oc get pods -n openshift-dns -o wide   --sort-by='.spec.nodeName'

# 2. Check node status
oc get nodes  -o yaml | grep -A5 conditions

# 3. Check CoreDNS logs
oc logs -n openshift-dns  --tail=50

# 4. Force recreate if stuck
oc delete pod -n openshift-dns -l   dns.operator.openshift.io/daemonset-dns=default

# 5. Verify DNS operator is not degraded
oc get clusteroperator dns -o yaml

Pro Tip: If CoreDNS pods are crashing, check if the ConfigMap dns-default has valid Corefile syntax. Invalid syntax prevents CoreDNS from starting.

Common Issue #2: External DNS Resolution Fails

Pods Cannot Reach Internet or External Services

16

🔴

Symptoms

Image pull failures with "i/o timeout"
Applications cannot call external APIs
OLM operators stuck in "Pending"
Only external queries fail; internal works fine

🔍

Diagnostic Flow

Test from Pod

→

Fails?

Test from Node

→

Fails?

Check Upstream

→

Fix Forwarder

🛠️

Resolution Commands

# Test from pod (through CoreDNS)
oc exec  -- dig registry.redhat.io

# Test from node (bypass CoreDNS)
oc debug node/ -- chroot /host   dig registry.redhat.io

# Check node resolv.conf upstream
oc debug node/ -- chroot /host   cat /etc/resolv.conf

# Verify DNS operator forwarders
oc get dnses.operator.openshift.io default   -o jsonpath='{.spec.upstreamResolvers}'

# Test direct forwarder reachability
oc exec -n openshift-dns  --   dig @ registry.redhat.io

Disconnected Environments: Ensure your internal DNS forwarder can resolve registry and API endpoints. If using split-horizon DNS, verify the correct zone delegation.

Common Issue #3: NetworkPolicy Blocking DNS

The Silent DNS Killer

17

🔴

Symptoms

DNS works in default namespace but fails in project namespace
Pods with NetworkPolicy cannot resolve services
Intermittent resolution after policy application
connection timed out on DNS queries

🔍

Why This Happens

NetworkPolicy is whitelist-based by default
Default deny blocks all egress including DNS (UDP 53)
CoreDNS at 172.30.0.10 is in openshift-dns namespace
Must explicitly allow egress to DNS service

🛠️

Fix: Allow DNS Egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: myproject
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Best Practice: Always include DNS egress in your default NetworkPolicy templates. Without it, pods lose all DNS resolution capability.

Verification: oc exec -n myproject -- dig @172.30.0.10 kubernetes.default

Common Issue #4: Search Domain Problems

Excessive Queries and NXDOMAIN Storms

18

🔴

Symptoms

Extremely high DNS query volume (thousands/sec)
CoreDNS logs flooded with NXDOMAIN responses
Application latency due to DNS timeouts
Upstream DNS server overload

🔍

Root Cause

App uses short names (e.g., mysvc)
ndots:5 means 4 search domain attempts
Each attempt generates a query
Short names sent to upstream DNS
Upstream returns NXDOMAIN for cluster domains

🛠️

Solutions

# Solution 1: Use FQDN with trailing dot
curl mysvc.mynamespace.svc.cluster.local.

# Solution 2: Lower ndots in pod spec
dnsConfig:
  options:
    - name: ndots
      value: "2"

# Solution 3: Use absolute names in app config
# Instead of: mysvc
# Use: mysvc.mynamespace.svc.cluster.local

# Solution 4: Configure CoreDNS cache
# Already default: cache 900 (15 minutes)

Real-World Impact

A Java application doing 1000 requests/sec to db-service generated 4000 DNS queries/sec. After changing to FQDN db-service.myapp.svc.cluster.local., query volume dropped to 1000/sec.

Common Issue #5: DNS Operator Degraded

Cluster Operator Impact on DNS

19

🔴

Symptoms

oc get co dns shows Degraded=True
Cluster upgrades blocked
DNS configuration changes not applied
CoreDNS pods not updated on node changes

🔍

Investigation

# Check cluster operator status
oc get co dns -o yaml

# Check DNS operator pod
oc get pods -n openshift-dns-operator
oc logs -n openshift-dns-operator deployment/dns-operator

# Check DNS CR for errors
oc get dnses.operator.openshift.io default -o yaml

# Verify daemonset status
oc get daemonset dns-default -n openshift-dns

🛠️

Common Fixes

Image pull failure: Check registry auth and pull-secret
API server unreachable: Verify kube-apiserver health
RBAC issues: Check dns-operator serviceaccount permissions
Webhook failures: Verify validating webhooks
Resource limits: Check operator pod OOMKilled

Critical: If the DNS operator is degraded, do NOT manually edit CoreDNS ConfigMaps or DaemonSets. The operator will overwrite your changes. Fix the operator first.

Advanced Troubleshooting Scenarios

Complex DNS Issues & Deep Diagnostics

20

Scenario 1: Split-Horizon DNS

Internal and external zones have same name. Corporate DNS resolves app.example.com to internal IP, but pods need external IP.

# Add custom zone to DNS CR
spec:
  servers:
  - name: external-app
    zones:
    - app.example.com
    forwardPlugin:
      upstreams:
      - 8.8.8.8  # External DNS

Scenario 2: IPv6-Only Clusters

DNS queries over IPv6 failing. CoreDNS listens on both stacks by default, but node configuration may differ.

# Check CoreDNS is listening on IPv6
oc exec -n openshift-dns  --   netstat -tlnp | grep 53

Scenario 3: DNS Latency & Timeouts

Applications experiencing 5-second delays. Default DNS timeout in glibc is 5s with 2 retries.

# Check CoreDNS metrics for latency
oc exec -n openshift-dns  --   curl -s localhost:9154/metrics |   grep coredns_dns_request_duration_seconds

# Check for packet loss
oc debug node/ -- chroot /host   tcpdump -i any port 53 -c 100

Scenario 4: Custom CA for External DNS

CoreDNS forwarding to DNS-over-TLS (DoT) server with custom CA.

# Configure TLS in DNS CR
forwardPlugin:
  upstreams:
  - type: TLS
    address: 1.2.3.4
    port: 853
    tlsServerName: dns.example.com

DNS Metrics & Monitoring

Proactive Detection Before Customer Impact

21

📊

Key CoreDNS Metrics

Metric	Description	Alert Threshold
coredns_dns_requests_total	Query rate	> 10000/sec
coredns_dns_responses_total	Response codes	NXDOMAIN > 50%
coredns_forward_requests_total	Upstream queries	Sudden spike
coredns_forward_fails_total	Upstream failures	> 10/min
coredns_cache_hits_total	Cache efficiency	< 80% hit rate
coredns_dns_request_duration_seconds	Latency	p99 > 100ms

🔔

Prometheus Alert Example

- alert: CoreDNSHighFailureRate
  expr: |
    sum(rate(coredns_forward_fails_total[5m])) 
    / 
    sum(rate(coredns_forward_requests_total[5m])) > 0.1
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "CoreDNS high forward failure rate"

- alert: CoreDNSHighLatency
  expr: |
    histogram_quantile(0.99, 
    rate(coredns_dns_request_duration_seconds_bucket[5m])) > 0.5
  for: 5m
  labels:
    severity: critical

Access Metrics: CoreDNS metrics are scraped by cluster monitoring. Query via Thanos/Querier or oc exec into CoreDNS pod directly.

DNS in Disconnected Environments

Special Considerations for Air-Gapped Clusters

22

🏭

Requirements

Internal DNS must resolve mirror registry
OLM catalog sources need DNS resolution
Red Hat CDN endpoints must be resolvable (or blocked intentionally)
Node NTP servers need resolution
Internal CA CRL/OCSP endpoints

⚙️

Configuration Pattern

spec:
  upstreamResolvers:
    policy: Sequential
    upstreams:
    - type: Network
      address: 10.0.0.10    # Internal DNS
      port: 53
    - type: Network
      address: 10.0.0.11    # Secondary
      port: 53

✅

Validation Checklist

✓ oc debug node can resolve registry
✓ Pod can resolve mirror registry FQDN
✓ CoreDNS logs show no SERVFAIL for internal zones
✓ DNS Operator not degraded
✓ No fallback to external DNS leaking

Leakage Risk: If internal DNS cannot resolve a name and has forwarders to external DNS, you may have DNS leakage. Use conditional forwarding for specific zones only.

Mirror Registry: Ensure image.config.openshift.io/cluster spec.registrySources.insecureRegistries matches DNS-resolvable names.

DNS Best Practices

Production-Ready Recommendations

23

🏗️

Architecture

Use FQDNs in application configurations (trailing dot)
Implement redundant upstream DNS servers
Monitor CoreDNS metrics proactively
Document custom DNS zones and forwarders
Test DNS failover during maintenance windows

🔒

Security

Always allow DNS egress in NetworkPolicies
Use DNS-over-TLS for sensitive environments
Restrict CoreDNS access to cluster network only
Audit DNS query logs for anomalies
Validate DNSSEC if required by compliance

⚡

Performance

Keep ndots default (5) unless proven issue
Use CoreDNS cache effectively (default 15 min)
Avoid excessive search domain lists
Scale nodes horizontally for DNS load
Monitor forward plugin latency

📋

Operational

Never manually edit CoreDNS ConfigMaps
Use DNS CR for all configuration changes
Verify DNS operator health before upgrades
Include DNS checks in node health validation
Document custom DNS requirements in runbooks

Quick Reference Card

Essential Commands for Support Engineers

24

🎯

Status Checks

oc get co dns
oc get dnses.operator.openshift.io
oc get pods -n openshift-dns -o wide
oc get daemonset dns-default -n openshift-dns
oc get svc dns-default -n openshift-dns

🔧

Testing

oc exec  -- nslookup ..svc
oc exec  -- dig @172.30.0.10 
oc debug node/ -- chroot /host   nslookup 
oc exec -n openshift-dns  --   curl localhost:9154/metrics

📄

Configuration

oc get configmap dns-default -n openshift-dns
oc get dnses.operator.openshift.io default -o yaml
oc debug node/ -- chroot /host   cat /etc/resolv.conf

📊

Logs

oc logs -n openshift-dns -l   dns.operator.openshift.io/daemonset-dns=default
oc logs -n openshift-dns-operator   deployment/dns-operator
oc adm node-logs  --unit=crio

🚨

Recovery

# Restart CoreDNS pods
oc delete pod -n openshift-dns -l   dns.operator.openshift.io/daemonset-dns=default

# Check DNS operator not paused
oc get dnses.operator.openshift.io default   -o jsonpath='{.spec.managementState}'

# Should return: Managed

Bookmark This: Save these commands in your troubleshooting runbook. DNS issues are time-sensitive—having commands ready reduces MTTR.

Key Takeaways

What Every Support Engineer Must Remember

25

1

Architecture

DNS is distributed: CoreDNS DaemonSet on every node
Service IP 172.30.0.10 routes to local CoreDNS
Node's /etc/resolv.conf provides upstream
DNS Operator manages all configuration

2

Troubleshooting

Determine scope: internal vs external, one pod vs all
Check from pod, node, and CoreDNS levels
NetworkPolicy is a common silent cause
Search domains can cause query storms

3

Configuration

Use DNS CR, never manually edit ConfigMaps
Configure forwarders for disconnected environments
Always allow DNS egress in NetworkPolicies
Use FQDNs with trailing dot for efficiency

4

Mindset

DNS is infrastructure, not just networking
Log everything—CoreDNS logs are your friend
Monitor metrics before customers complain
Document custom DNS requirements

Golden Rule: When in doubt, check DNS first. It's the most common root cause disguised as a network, application, or infrastructure failure.

Questions & Discussion

OpenShift 4 DNS Deep Dive

Thank you for your attention