DNS | XB Field Notes

Inside dnsmasq, a forwarded cached answer ages with TTL, while a configured host-record is generated from configuration. SIGHUP clears forwarded state while the configured record remains, even at local TTL zero.

dnsmasq separates forwarded cache entries from configured local names

dnsmasq can forward DNS questions upstream, retain supported answers in a bounded cache, and serve names configured locally. These are different sources of data. A repeated answer may be a cache hit or a local configuration result. Establishing which source supplied it is essential when a hostname disagrees with the authority or continues resolving after a cache flush. ...

Three lookups separated by 1.2 seconds contact the authority three times at TTL 1 and once at TTL 20 in the article example. Expiry alone does not schedule a query.

DNS TTL trades repeated upstream queries against retained answers

A DNS TTL is a lifetime attached to cached data, not a refresh job scheduled for every second. A cache can reuse a valid answer while it retains that entry. After expiry, a subsequent request usually requires fresh resolution unless another configured behavior applies. An idle record need not produce an upstream query merely because its TTL has reached zero. ...

An IPv4 DNS transport carries an AAAA IPv6 address. A separate connection is needed to test the service.

AAAA records publish IPv6 addresses without proving reachability

An AAAA resource record contains one 128-bit IPv6 address. An A record contains an IPv4 address. A name may have either type, both types, or several addresses within each type. These are separate RRsets, so A and AAAA can have different TTLs. Publishing AAAA makes an address discoverable through DNS; it does not create an interface, route, listener, or working application. ...

In the source example, the primary changes to 127.0.0.3 at serial 10 while the secondary remains at 127.0.0.2. Raising serial to 11 lets the secondary acquire the changed address.

Zone transfer copies authoritative data under explicit authorization and serial rules

AXFR transfers a complete DNS zone so another server or authorized client can obtain its data. A secondary can then answer authoritatively from its local copy. The protocol does not magically identify callers as legitimate authoritative servers: access control decides who may transfer. A zone is also a defined authority boundary, not every record in every delegated child zone or the organization’s entire DNS namespace. ...

A TLS boundary protects the client-to-resolver connection. The selected resolver can read the DNS question, and later recursion is not automatically encrypted.

DoT and DoH protect the connection to the resolver you authenticate

DNS over TLS and DNS over HTTPS protect DNS traffic on the encrypted connection between their endpoints. For a typical client, that connection ends at the selected resolver. The resolver can read the question and answer, and its later queries may follow different transports. Encrypting this hop does not automatically encrypt every recursive exchange or make the resolver unable to log the names it handles. ...

Three dependency boxes show alias, middle and target with independent TTLs of 9, 12 and 20 seconds from one answer. A separate HTTP identity band keeps Host as alias.lab.test plus the temporary port. The arrows are DNS dependencies, not URL redirects.

A CNAME changes DNS resolution while the requested hostname stays the same

A CNAME record associates an alias name with another DNS name. When resolving an address through that alias, a resolver follows the target until it obtains the requested data or encounters a failure. This lets a public hostname remain stable while its DNS dependency changes. It does not redirect a browser to another URL or replace the application’s requested hostname. ...

DNS answers rotate between A then B and B then A, but one saved application choice sends twelve requests to the selected peer and zero to the other in the article example.

Multiple DNS addresses do not guarantee balanced or healthy traffic

Several A or AAAA records at one name provide an address set. A DNS server may rotate the order it returns, but the receiving resolver and application decide how to use that set. Ordinary address records contain no request-load measurement or application-health result. Their presence alone does not promise equal traffic, automatic failover, or even a particular first address across implementations. ...

The healthy priority-10 target with weight 1 precedes the priority-20 backup with weight 65535; connection failure triggers client fallback.

SRV discovery gives clients targets and ports that they must interpret

An SRV record describes a service target using priority, weight, port, and a target hostname. Its owner normally combines a service label, transport label, and domain, such as _echo._tcp.lab.test. A client that understands that service can query SRV, obtain target addresses through A or AAAA, and connect to the advertised port. Ordinary hostname lookup does not automatically perform this application-specific discovery sequence. ...