Demystifying DNS
Record Types
Other Records txt srv ptr
DNS offers a variety of record types for different purposes. In this lesson, we explore three additional DNS record types: TXT, SRV, and PTR records, each serving unique roles in domain management and service discovery.
TXT Records
TXT records were initially created to hold human-readable notes but have since evolved into versatile machine-readable data carriers. They are often used to verify domain ownership and authorize various services, such as 1Password, Google Site Verification, and email services secured by SPF (Sender Policy Framework).
To request a TXT record for a domain, you can use the dig command with the TXT option. Think of TXT records as digital sticky notes indicating that "the owner of this domain approves this service." Below is an example of how TXT records for kubernetes.io might appear:
$ dig kubernetes.io TXT
; <<>> DiG 9.10.6 <<>> kubernetes.io TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54797
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;kubernetes.io. IN TXT
;; ANSWER SECTION:
kubernetes.io. 3600 IN TXT "1password-site-verification=SOZCTQ66DFFXVGPOWOHMVDIBVI"
kubernetes.io. 3600 IN TXT "google-site-verification=qmfdQyHjWJBL78F9saApyW0VFRyymuSMpqMn8gtGmd0"
kubernetes.io. 3600 IN TXT "google-site-verification=oPORCoq9XU6CmaR7G_bV00CLmEz-wLGOL7XpeEuTt8"
kubernetes.io. 3600 IN TXT "v=spf1 include:_spf.google.com mail.kubernetes.io ~all"
;; Query time: 192 msec
;; SERVER: 2806:10c0:ffff:e::53(2806:10c0:ffff::e)
;; WHEN: Mon Jan 20 00:24:23 CST 2025
;; MSG SIZE rcvd: 338
In this example, the TXT records not only verify domain ownership for services like 1Password and Google, but the SPF record also restricts email sending to authorized servers, thereby reducing spoofing risks.
SRV Records
SRV records are essential for service discovery as they map specific services to a domain. These records act like digital pins on a map, indicating where a given service is running and how to connect to it. For example, in Kubernetes clusters, SRV records help pods locate and communicate with other services. Whenever services are created, modified, or removed via the Kubernetes API, CoreDNS automatically updates its SRV records, ensuring accurate service resolution.
Below is an example SRV record that helps locate a web server service:
_service_._protocol.name TTL class SRV priority weight port target
_http._tcp.webserver.default.svc.cluster.local. 30 IN SRV 0 100 8080 webserver.default.svc.cluster.local.
The diagram below visually represents how SRV records facilitate service discovery:
Additionally, observe how CoreDNS interacts with the Kubernetes API and cluster components:
Further Exploration
If you’re interested in a deeper exploration of Kubernetes service discovery with SRV records, let us know for a future lesson.
PTR Records
PTR records, also known as pointer records, are used for reverse DNS lookups. Unlike a standard DNS query that maps a domain name to its IP address, a reverse DNS lookup finds the domain name associated with a given IP address. The dig command with the -x flag is used for this purpose.
Consider the following example where a reverse DNS lookup is performed for the IP address 8.8.8.8:
$ dig -x 8.8.8.8
; <<>> DiG 9.10.6 <<>> -x 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50989
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa. IN PTR
;; ANSWER SECTION:
8.8.8.8.in-addr.arpa. 12215 IN PTR dns.google.
;; Query time: 22 msec
;; SERVER: 2806:10c0::ffff:e#53(2806:10c0:ffff:e)
;; WHEN: Mon Jan 20 00:55:29 CST 2025
;; MSG SIZE rcvd: 73
In a reverse DNS lookup, the IP address is reversed and appended to the .arpa top-level domain. For clarity, the following diagram explains this process, highlighting that while domain names are read left to right, IP addresses are processed from right to left for reverse mapping:
The reverse mapping continues with queries to subdomains until an authoritative answer is returned. In our example, the PTR record confirms that 8.8.8.8 maps to dns.google. You can validate this result by querying the A records of dns.google.com.
It is important to note that PTR records are created like any other DNS records within your hosted zone (using services such as Route 53, Cloudflare, or another registrar). However, you must own the IP address to create a PTR record. PTR records are most effective for static IP addresses since web applications relying on dynamic IP addresses might face limitations.
Important Note
Ensure that you have control over the IP addresses when setting up PTR records, as this is crucial for proper reverse DNS lookups and service authorization.
Watch Video
Watch video content