Day 30/31 of the 40-Day Kubernetes Challenge : Mastering DNS Basics
Table of contents
- What is DNS?
- How DNS Works (Detailed)
- Types DNS Record
- 1. A Record (Address Record)
- 2. AAAA Record (IPv6 Address Record)
- 3. CNAME Record (Canonical Name Record)
- 4. MX Record (Mail Exchange Record)
- 5. TXT Record (Text Record)
- 6. NS Record (Name Server Record)
- 7. SOA Record (Start of Authority)
- 8. PTR Record (Pointer Record)
- 9. SRV Record (Service Record)
- 10. CAA Record (Certification Authority Authorization)
- 11. TTL (Time to Live)
- CoreDNS in Kubernetes
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:
Recursive DNS Resolver: The user's device queries the recursive resolver, which is responsible for finding the IP address associated with the domain name.
Root Name Servers: If the recursive resolver doesn't have the answer, it contacts the root name servers.
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.Authoritative Name Servers: Finally, the authoritative server provides the IP address for the requested domain.
Response: The IP address is returned to the user, allowing the browser to connect to the website.
How DNS Works (Detailed)
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.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.).TLD Name Servers: The TLD name servers then direct the request to the authoritative name servers that manage the domain
example.com
.Authoritative Response: These authoritative name servers finally return the corresponding IP address for the domain.
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
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.
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.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.
Service Setup: Let’s assume you have two services:
frontend
andbackend
. Thefrontend
service communicates with thebackend
service via DNS. When the frontend needs to fetch data, it sends a request tobackend.default.svc.cluster.local
.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.
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:
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.
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
Subscribe to my newsletter
Read articles from Rahul Vadakkiniyil directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by