DNS | XB Field Notes

Useful hostnames distinguish local identity, service names, and lookup scope

A useful name gives people and software a reference they can carry across an address change. That reference needs a defined scope and owner. A machine’s local hostname, a service’s DNS name, and an instance identifier may intentionally differ. Naming them clearly helps operators understand logs and deployments without pretending that one label automatically establishes every other identity in the system. ...

In the EDNS-off article fixture, UDP returns 462 bytes with TC set and two of four TXT records. A TCP retry on the working path returns 892 bytes with TC clear and all four records.

DNS needs a working TCP path when a UDP answer is truncated

DNS supports both UDP and TCP. A server sets the TC flag when a response is truncated for the available message space. A client receiving that flag must handle the incomplete result, commonly by retrying over TCP. This is about the DNS response limit in use, not proof that the physical network cannot carry any larger UDP datagram. ...

In the article’s local example, IPv6 remains first in the candidate list but its stopped listener refuses the connection; the sequential client then succeeds through IPv4.

Dual-stack address ordering and successful connection choice are separate

Discovering A and AAAA records provides possible destinations. It does not select a successful connection by itself. Address ordering, source-address selection, routing, and the application’s connection algorithm all contribute. RFC 6724 describes default source and destination selection rules, while applications can impose their own choices. A program requesting only IPv4 has already narrowed the result before any dual-stack connection strategy can act. ...

A client advertises 4096 bytes but the source server caps UDP at 1232. A truncated answer can require TCP; the path still determines delivery.

EDNS advertises UDP capacity without guaranteeing path delivery

EDNS extends DNS through an OPT pseudo-record. Among other information, a request can advertise the UDP payload size its sender is prepared to receive. This allows answers beyond the traditional 512-byte DNS limit. It is an advertisement within a DNS exchange, not a network path-MTU discovery protocol or a promise that every intervening device will deliver a datagram of that size. ...

For a direct query without aliases, NXDOMAIN means the name is missing, while NODATA means the requested type is missing. Authoritative negative lifetime is the smaller of SOA TTL and MINIMUM.

Negative DNS answers preserve absence until their cache lifetime expires

DNS can return useful information by saying that data is absent. NXDOMAIN reports a name error; NODATA describes a successful response without the requested record type. In a direct query without aliases, these distinguish a nonexistent name from an existing name that lacks the requested data. Caching those results avoids repeating the same unsuccessful upstream lookup for every client request. ...

A configured trust anchor leads to a parent-signed DS RRset. Its digest identifies a child DNSKEY; the child key relationship supports verification of the signed RRset. The parent does not directly sign the child key.

DNSSEC validates a chain of signed data, not merely the presence of signatures

DNSSEC adds origin authentication and integrity checking for DNS data. RRSIG records sign RRsets, DNSKEY records publish verification keys, and a parent’s DS record identifies a child DNSKEY through a digest. The parent signs its DS RRset; it does not simply sign the child’s public key directly. Validation follows these relationships from a configured trust anchor to the requested data. ...

Two paths resolve choice.lab.test. A glibc application using files dns returns the hosts-file address 127.0.0.9; a direct dig query to the DNS authority returns 127.0.0.2.

Resolution order depends on the application and its name-service path

A hostname lookup starts with the program making it. On Linux, an application using glibc name-service interfaces can consult the services listed for hosts in /etc/nsswitch.conf. A program with its own DNS client may take a different path. There is no universal sequence in which every application checks a cache, then a hosts file, then the internet. ...

The old endpoint keeps serving across the DNS switch while the new endpoint is already ready. The overlap continues into observation; changing TTL cannot rewrite cached answers.

DNS changes need a cache-aware rollback window

Prepare the TTL ahead of time, observe authoritative and recursive answers, and keep both endpoints valid through the cache window.