dns.ximg.app

What is DNS?

DNS — the Domain Name System — is the internet's distributed, hierarchical phone book. Every time you type a hostname into a browser, curl, or SSH, DNS translates that human-readable name into the IP address the network actually needs to route your packets.

Designed by Paul Mockapetris and published in RFC 1034/1035 in 1987, DNS replaced the single centralized HOSTS.TXT file that had been manually distributed to every host on ARPANET. It is now the largest distributed database in the world, answering trillions of queries per day with no single point of control.

Key Concepts

UDP/53

Primary transport (TCP for large responses)

13

Root name server clusters (A–M)

TTL

Time To Live — seconds a record may be cached

RR

Resource Record — the fundamental data unit

FQDN

Fully Qualified Domain Name — ends with a trailing dot

Zone

A contiguous portion of the namespace under one authority

DNS Hierarchy

. (root — 13 clusters, operated by ICANN, VeriSign, RIPE, etc.)
├── com. (gTLD — operated by VeriSign)
│ ├── google.com. (authoritative zone — Google's nameservers)
│ │ ├── www.google.com.
│ │ └── mail.google.com.
│ └── ximg.com.
├── net. (gTLD — operated by VeriSign)
├── org. (gTLD — operated by Public Interest Registry)
└── app. (gTLD — operated by Google)
└── ximg.app. (authoritative zone — this server)
├── dns.ximg.app.
└── linux.ximg.app.

Caching Layers

A DNS query rarely reaches an authoritative server. Before hitting the network, it passes through several cache layers, each with its own TTL budget: the browser's internal DNS cache, the OS stub resolver, the local recursive resolver (often your router or ISP), and finally the authoritative nameserver. Each hop that has a cached answer stops the chain and returns immediately.

Negative caching (NXDOMAIN responses) is also stored for the duration of the SOA record's minimum TTL, preventing repeated lookups for names that do not exist.

Common Resource Record Types

A

Maps a hostname to an IPv4 address. The most fundamental record type — the end goal of most lookups.

ximg.app. 300 IN A 172.238.205.61

AAAA

Maps a hostname to an IPv6 address. Named "quad-A" because IPv6 is 4× the size of IPv4.

ximg.app. 300 IN AAAA 2a01:7e04::2000:30ff:fed5:d413

CNAME

Canonical Name — an alias pointing to another hostname. The resolver follows the chain until it hits an A/AAAA record. Cannot coexist with other records at the same name.

www.ximg.app. 3600 IN CNAME ximg.app.

MX

Mail Exchanger — designates the mail server(s) for a domain, with a priority value. Lower priority number = higher preference.

ximg.app. 3600 IN MX 10 mail.ximg.app.

TXT

Free-form text. Used for SPF, DKIM, DMARC email authentication, domain ownership verification (Google, Let's Encrypt), and ACME DNS-01 challenges.

ximg.app. 300 IN TXT "v=spf1 mx ~all"

NS

Name Server — declares which servers are authoritative for a zone. Every zone must have at least two NS records for redundancy.

ximg.app. 86400 IN NS ns1.linode.com.

SOA

Start of Authority — one per zone. Contains the primary nameserver, admin email, zone serial, and timing parameters (refresh, retry, expire, minimum TTL).

ximg.app. IN SOA ns1.linode.com. admin.ximg.app. 2026040401 3600 900 604800 300

PTR

Pointer — reverse DNS. Maps an IP address back to a hostname. Lives under the special in-addr.arpa. zone. Used by mail servers and logging tools.

61.205.238.172.in-addr.arpa. IN PTR ximg.app.

SRV

Service record — specifies host and port for a service. Used by SIP, XMPP, Minecraft, and other protocols to advertise endpoints.

_sip._tcp.ximg.app. IN SRV 10 20 5060 sip.ximg.app.

CAA

Certification Authority Authorization — restricts which CAs may issue TLS certificates for a domain. Prevents misissuance by unauthorized CAs.

ximg.app. IN CAA 0 issue "letsencrypt.org"

DNSKEY

Holds a public signing key for DNSSEC validation. Zone Signing Keys (ZSK) sign RRsets; Key Signing Keys (KSK) sign ZSKs.

ximg.app. IN DNSKEY 257 3 13 <base64-key>

DS

Delegation Signer — a hash of a child zone's KSK, stored in the parent zone. Creates the chain of trust from parent to child in DNSSEC.

ximg.app. IN DS 12345 13 2 <sha256-hash>

Full Recursive Resolution — step by step

When you look up dns.ximg.app and nothing is cached anywhere, here is exactly what happens:

1

Application calls getaddrinfo() — your browser, curl, or SSH client asks the OS resolver library to resolve the name.

2

OS checks local cache — the stub resolver checks /etc/hosts, then the OS DNS cache (nscd, systemd-resolved, mDNSResponder). If found, return immediately.

3

Stub resolver queries the recursive resolver — typically your ISP or a public resolver (8.8.8.8, 1.1.1.1). The stub sends a recursive query (RD=1) over UDP port 53.

4

Recursive resolver queries a root server — it asks one of the 13 root clusters (e.g., a.root-servers.net) for dns.ximg.app. The root doesn't know the answer but returns a referral to the .app TLD servers.

5

Recursive resolver queries the .app TLD servers — Google operates these. They don't know the answer either but return a referral to ximg.app's authoritative nameservers (e.g., ns1.linode.com).

6

Recursive resolver queries the authoritative nameserver — this server knows the zone and returns the actual A record for dns.ximg.app: 172.238.205.61.

7

Recursive resolver caches and returns the answer — it stores the result for the record's TTL duration, then returns it to the stub resolver, which passes it to the application.

8

TCP connection proceeds — your application now has the IP address and opens a TCP/TLS connection. The DNS phase is complete, typically within 50–200ms for a cold lookup.

Resolver Types

Stub Resolver

Minimal client built into every OS. Simply forwards queries to a configured recursive resolver. Does no iterative work itself. Lives in libc (getaddrinfo).

Recursive Resolver

Also called a "full-service resolver." Does the iterative work of following referrals from root → TLD → authoritative. Maintains a large cache. Examples: ISP resolvers, 8.8.8.8, 1.1.1.1, Unbound.

Authoritative Server

Has the definitive answer for a zone. Responds to queries with AA (Authoritative Answer) flag set. Does not recurse. Examples: BIND, NSD, PowerDNS, Linode DNS.

Forwarder

A resolver that passes all queries upstream to another resolver rather than iterating itself. Common in corporate environments to centralize DNS policy and logging.

dig — the definitive DNS query tool

dig ximg.app

Basic A record lookup — returns the answer section, TTL, and query stats

dig ximg.app AAAA

IPv6 address lookup

dig ximg.app MX

Mail exchanger records

dig ximg.app TXT

Text records — SPF, DKIM, domain verification tokens

dig ximg.app NS

Nameserver delegation records

dig ximg.app SOA

Start of Authority — serial, refresh, retry, expire, minimum TTL

dig ximg.app ANY

Request all record types (many servers limit this response)

dig @8.8.8.8 ximg.app

Query a specific resolver (Google Public DNS) instead of system default

dig +short ximg.app

Terse output — just the answer value(s)

dig +trace ximg.app

Full iterative resolution — shows every referral from root to authoritative

dig +noall +answer ximg.app

Print only the answer section, suppress stats and question

dig -x 172.238.205.61

Reverse DNS (PTR) lookup — resolves IP to hostname

dig +dnssec ximg.app

Request DNSSEC signatures (RRSIG records) in the response

dig +tcp ximg.app

Force TCP transport instead of UDP

dig +stats ximg.app

Show query time, server used, and message size

nslookup — interactive and scripted lookups

nslookup ximg.app

Basic lookup using system default resolver

nslookup ximg.app 8.8.8.8

Query against a specific nameserver

nslookup -type=MX ximg.app

Look up a specific record type

nslookup -type=NS ximg.app

List authoritative nameservers for a domain

nslookup 172.238.205.61

Reverse PTR lookup by IP address

host — simple one-line lookups

host ximg.app

A, AAAA, and MX records in a single concise output

host -t TXT ximg.app

Query a specific record type

host 172.238.205.61

Reverse PTR lookup

What DNSSEC Solves

Plain DNS has no authentication. A network attacker can intercept a UDP query and inject a forged response — a cache poisoning attack (Kaminsky attack, 2008) — redirecting users to malicious servers with no visible indication. DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses are authentic and unmodified.

DNSSEC does not encrypt queries (use DoH or DoT for that). It only provides authenticity and integrity via public-key signatures.

The Chain of Trust

DNSKEY

Each zone publishes its public signing keys as DNSKEY records. There are two types: the Zone Signing Key (ZSK) which signs regular RRsets, and the Key Signing Key (KSK) which signs the ZSK.

RRSIG

Every signed RRset has a corresponding RRSIG record containing the cryptographic signature. Resolvers use the zone's DNSKEY to verify the RRSIG before trusting the answer.

DS

The Delegation Signer record is a hash of the child zone's KSK, published in the parent zone. It links the parent's trust to the child — e.g., the .app TLD zone contains the DS record for ximg.app.

NSEC / NSEC3

Next Secure records prove authenticated denial of existence — if a name does not exist, the resolver gets cryptographic proof rather than just an unauthenticated NXDOMAIN. NSEC3 adds hashing to prevent zone enumeration.

Root of Trust

The chain terminates at the DNS Root Zone, which is signed by ICANN's Root Zone Management Partners. Recursive resolvers ship with the Root Zone's public key (the "trust anchor") hard-coded. This key is rotated periodically — the first root key rollover happened in 2018, causing disruption for resolvers that hadn't updated their trust anchors.

Validation status is indicated by the AD (Authenticated Data) flag in DNS responses. Use dig +dnssec +adflag to check whether a resolver is validating DNSSEC for a given name.

DNS over HTTPS / DNS over TLS

DoH — port 443

DNS queries sent as HTTPS requests to a resolver's HTTPS endpoint. Indistinguishable from normal web traffic. Used by browsers (Firefox, Chrome) to bypass local resolver interception. Resolver: https://1.1.1.1/dns-query

DoT — port 853

DNS queries sent over a dedicated TLS connection. Encrypts the query/response but is identifiable as DNS traffic by the port number. Easier for network operators to inspect or block. Resolver: 1.1.1.1:853

Verdict

SRV records are a solution to problems most systems don't have. In theory they let you advertise service endpoints — host, port, priority, weight — directly in DNS. In practice they are almost never what you actually need, they are poorly supported across tooling, and every system that adopts them ends up building a second discovery layer alongside them anyway.

The record type has existed since 2000 (RFC 2782). In that time the only places it achieved meaningful adoption are Kerberos/Active Directory (where you have no choice), XMPP (a protocol the internet mostly abandoned), SIP telephony (a stack that everyone working in it hates), and a handful of other niche protocols. That is not a track record — that is a warning.

What an SRV record looks like

_service._proto.name. TTL IN SRV priority weight port target

The full format — five fields, all mandatory, two of which (priority and weight) are almost always set to the same value and ignored

_http._tcp.ximg.app. 300 IN SRV 10 20 80 web.ximg.app.

A concrete example — and every HTTP client on earth will ignore this entirely and use the A record instead

The five fields

_service

Underscore-prefixed service name. _http, _xmpp, _sip. Must be registered with IANA or you are just making things up.

_proto

_tcp or _udp. That is the entire range of options. No TLS, no QUIC, no SCTP unless you feel like it.

priority

Lower number = higher preference. Identical to MX priority. Clients are supposed to try lower-priority targets first. Most don't.

weight

Weighted random selection among equal-priority targets. Load balancing in DNS. In practice: everyone sets it to 0 or 100 and ignores it.

port

The TCP/UDP port. The one genuinely useful piece of information in the record. The entire rest of the format exists to carry this one number.

Why they cause more problems than they solve

✗

Clients don't support them. curl, wget, browsers, most HTTP libraries, most database drivers — none of them look up SRV records. You add the record to DNS, nothing uses it, and you still have to configure every client with a hardcoded host and port anyway. The record is decorative.

✗

You are reimplementing a load balancer in DNS. Priority and weight are a bad approximation of what HAProxy, nginx upstream, or any modern load balancer does natively — with health checks, circuit breakers, connection pooling, and observability. DNS has none of that. The record goes stale and you have no idea.

✗

TTLs make failover slow. DNS caches the record for its TTL. If you set a long TTL, failover is slow. If you set a short TTL, you hammer your nameservers and fight negative caching everywhere. A proper load balancer fails over in milliseconds. SRV-based failover is best-effort and opaque.

✗

The naming convention is a bureaucratic tax. You cannot just use _myservice._tcp.example.com — you are supposed to register the service name with IANA. Nobody does this. Everyone invents names and then wonders why nothing interoperates.

✗

Debugging is painful. Most monitoring tools, dashboards, and on-call engineers do not think in terms of SRV records. When something breaks at 3am, "check the SRV record" is not in anyone's runbook. It is one more thing to rule out before you find the real problem.

✗

Service discovery is a solved problem. Consul, Kubernetes DNS (which does use SRV internally, invisibly), Eureka, AWS Cloud Map — these systems build proper service registries with health checks, metadata, and APIs. If you need service discovery, use one of them. If you don't need service discovery, you don't need SRV records either.

Who actually uses them

Active Directory / Kerberos — The one legitimate large-scale use case. AD publishes SRV records for domain controllers, Kerberos KDCs, and LDAP servers because the protocol spec requires it and Windows clients are built to look them up. If you are not running AD, this does not apply to you.

SIP / VoIP — Telephony vendors use SRV for SIP trunk discovery. SIP is also a protocol famous for being painful to operate, and SRV is one of many reasons why.

XMPP — Federated chat servers discover each other via SRV. XMPP federation is one of the few things in tech that works exactly as designed and that almost no one uses.

Kubernetes kube-dns — Generates SRV records for named service ports. You never write these by hand; the control plane manages them. The fact that k8s uses SRV internally and hides it from you entirely is the correct approach.

Notice the pattern: every use case is either a legacy enterprise protocol from the early 2000s, a system you have no choice about, or an abstraction layer that hides the SRV record from the operator. That is the clearest possible signal.

Bottom line

If a colleague proposes adding SRV records to solve a service-discovery or load-balancing problem, ask two questions: which clients will actually look up this record? and what does this give us that a proper load balancer or service registry does not? If there are no good answers, the SRV record is infrastructure theater — complexity added to look thorough, not because it helps anything.

The record type is not wrong. It is simply almost never the right tool, and the engineers who reach for it first are usually the same ones who will want to implement a full internal PKI next week.