Day 30/31 of the 40-Day Kubernetes Challenge : Mastering DNS Basics

What is DNS?

DNS (Domain Name System) is a crucial part of how the internet works. It translates human-readable domain names like example.com into IP addresses (e.g., 192.0.2.1), allowing browsers to locate and retrieve the desired website. This translation process involves several steps that query various DNS servers:

  1. Recursive DNS Resolver: The user's device queries the recursive resolver, which is responsible for finding the IP address associated with the domain name.

  2. Root Name Servers: If the recursive resolver doesn't have the answer, it contacts the root name servers.

  3. TLD Servers: The root server directs the resolver to the top-level domain (TLD) servers (e.g., .com, .net), which point it to the authoritative name servers.

  4. Authoritative Name Servers: Finally, the authoritative server provides the IP address for the requested domain.

  5. Response: The IP address is returned to the user, allowing the browser to connect to the website.

How DNS Works (Detailed)

  1. User Query: When you type example.com in a browser, the first step is the query sent to the recursive DNS resolver. This resolver might already have the IP address cached, in which case the response is immediate.

  2. Root Servers: If not, the resolver queries one of the 13 root name servers, which respond with the location of the TLD name servers (for .com, .org, etc.).

  3. TLD Name Servers: The TLD name servers then direct the request to the authoritative name servers that manage the domain example.com.

  4. Authoritative Response: These authoritative name servers finally return the corresponding IP address for the domain.

  5. Completion: The IP address is returned to the user’s browser, allowing it to connect to the correct web server.

This entire process happens within milliseconds, ensuring seamless browsing experiences.

Types DNS Record

DNS records are used to map domain names to IP addresses and provide various details about how requests should be handled for a specific domain. Here are the most common types of DNS records:

1. A Record (Address Record)

  • Purpose: Maps a domain name to an IPv4 address.

  • Example: example.com -> 192.0.2.1

  • Use Case: This is the most common DNS record and is used to connect domain names to servers hosting websites.

2. AAAA Record (IPv6 Address Record)

  • Purpose: Maps a domain name to an IPv6 address.

  • Example: example.com -> 2001:0db8:85a3::8a2e:0370:7334

  • Use Case: Used for domains that are hosted on servers using the IPv6 protocol.

3. CNAME Record (Canonical Name Record)

  • Purpose: Points a domain or subdomain to another domain name (aliasing).

  • Example: www.example.com -> example.com

  • Use Case: Used to point multiple domain names to a single domain without duplicating A or AAAA records.

4. MX Record (Mail Exchange Record)

  • Purpose: Directs email to mail servers for a domain.

  • Example: example.com -> mailserver1.example.com

  • Use Case: Determines how email messages should be routed for the domain, indicating which mail servers should handle emails.

5. TXT Record (Text Record)

  • Purpose: Stores text information about a domain, often for verification or security purposes.

  • Example: Used for verification in domain ownership, SPF (Sender Policy Framework), or DKIM (DomainKeys Identified Mail).

  • Use Case: Commonly used for verifying domain ownership with services like Google or AWS, or for setting up SPF records for email security.

6. NS Record (Name Server Record)

  • Purpose: Specifies which name servers are authoritative for a domain.

  • Example: example.com -> ns1.example.com, ns2.example.com

  • Use Case: Directs DNS queries to the appropriate name servers for the domain.

7. SOA Record (Start of Authority)

  • Purpose: Provides authoritative information about the domain, including the primary name server, the email of the domain administrator, and timestamps for zone updates.

  • Example: Includes details like serial number, refresh interval, retry time, and expiration time for DNS data.

  • Use Case: Used by DNS servers to manage the distribution of DNS records and ensure zone transfers are synchronized.

8. PTR Record (Pointer Record)

  • Purpose: Maps an IP address back to a domain name (reverse DNS lookup).

  • Example: 192.0.2.1 -> example.com

  • Use Case: Often used in email verification to confirm that an IP address is associated with a specific domain name, improving email deliverability.

9. SRV Record (Service Record)

  • Purpose: Specifies the location (host and port) of services for a domain, like SIP (Session Initiation Protocol) or XMPP (Extensible Messaging and Presence Protocol) services.

  • Example: _sip._tcp.example.com -> sipserver.example.com

  • Use Case: Used to define services and ports associated with a domain, enabling applications to locate specific services.

10. CAA Record (Certification Authority Authorization)

  • Purpose: Specifies which certificate authorities (CAs) are permitted to issue SSL/TLS certificates for the domain.

  • Example: example.com -> issue "letsencrypt.org"

  • Use Case: Enhances security by controlling which certificate authorities are authorized to issue certificates for the domain, preventing misuse.

11. TTL (Time to Live)

  • Purpose: This is not a DNS record type, but rather a parameter that defines how long a DNS record should be cached by resolving servers and clients.

  • Example: TTL: 3600 seconds

  • Use Case: Determines how frequently DNS resolvers should refresh their records, impacting website load times and DNS changes propagation.

CoreDNS in Kubernetes

What is CoreDNS?

CoreDNS is a flexible, extensible DNS server that’s commonly used in modern Kubernetes environments. It is designed to handle service discovery and DNS-based routing within a Kubernetes cluster, where each service is assigned a DNS name. This allows services to communicate with each other via DNS resolution, instead of relying on hardcoded IP addresses.

In Kubernetes, CoreDNS is deployed as a DNS server inside the cluster, helping resolve internal service names like my-service.my-namespace.svc.cluster.local into their corresponding IP addresses. This automatic service discovery is a key feature of Kubernetes, making it easier for microservices to communicate without manual configuration.

How CoreDNS Works in Kubernetes

  1. Kubernetes API Integration: CoreDNS watches the Kubernetes API for updates on service and pod IP addresses. When a new service is created, Kubernetes updates the DNS records in CoreDNS.

  2. Service Discovery: When a pod or service within the Kubernetes cluster makes a DNS query (e.g., for my-service.my-namespace.svc.cluster.local), CoreDNS handles the query and responds with the correct IP address for the requested service.

  3. Plugins: CoreDNS supports plugins that extend its capabilities. For example, the kubernetes plugin is responsible for interacting with the Kubernetes API and handling DNS records within the cluster. Other plugins enable caching, logging, or even custom DNS resolution logic.

Example of CoreDNS in Kubernetes

Imagine a Kubernetes cluster running a web application that consists of several microservices. Each microservice has its own deployment, service, and pods.

  1. Service Setup: Let’s assume you have two services: frontend and backend. The frontend service communicates with the backend service via DNS. When the frontend needs to fetch data, it sends a request to backend.default.svc.cluster.local.

  2. DNS Resolution: CoreDNS intercepts this DNS query, looks up the IP address of the backend service (using Kubernetes service discovery), and returns the correct IP address to the frontend service.

  3. Connection: The frontend service then connects to the backend via the resolved IP address.

By handling this service discovery automatically, CoreDNS eliminates the need to manually configure networking between services, simplifying the management of microservices architectures.

Use Case of CoreDNS in Kubernetes

A common use case of CoreDNS in Kubernetes is for service-to-service communication. Consider a large-scale microservices architecture where different services need to communicate with one another. Managing IP addresses manually in such an environment would be inefficient and prone to errors.

Example: Blue-Green Deployment with CoreDNS

In a blue-green deployment, where you have two versions of an application running side-by-side, CoreDNS can help manage traffic routing between them. For instance:

  • Version A (blue) of the application is running on app-blue.svc.cluster.local.

  • Version B (green) is running on app-green.svc.cluster.local.

With CoreDNS, you can easily switch traffic between these two versions by updating the DNS records in CoreDNS, either manually or automatically, depending on your deployment strategy.

Other Use Cases:

  1. Scaling Services: When new pods are added to a service, CoreDNS automatically updates its records, allowing new traffic to be routed to the new instances.

  2. High Availability: In case of a node failure, CoreDNS ensures that the DNS records point to healthy pods, maintaining service availability.

Conclusion

CoreDNS is a vital component in Kubernetes clusters, making service discovery seamless and highly scalable. By understanding how DNS and CoreDNS work together, you can better manage communication between services and ensure that your Kubernetes environment runs efficiently. Whether it's managing large-scale microservices or ensuring smooth service-to-service communication, CoreDNS plays a critical role in the success of Kubernetes-based infrastructures.

Reference

https://www.youtube.com/watch?v=fDOoB4k4YSs&list=PLl4APkPHzsUUOkOv3i62UidrLmSB8DcGC&index=31

https://www.youtube.com/watch?v=VcWpZoRAQXE&list=PLl4APkPHzsUUOkOv3i62UidrLmSB8DcGC&index=32

0
Subscribe to my newsletter

Read articles from Rahul Vadakkiniyil directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Rahul Vadakkiniyil
Rahul Vadakkiniyil