Dns | XB Field Notes

Forwarded entries can expire or be cleared while configured local records remain available.

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. ...

Downstream caches receive the remaining TTL instead of starting another full authoritative lifetime.

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 AAAA answer identifies an IPv6 destination; a separate connection verifies whether it works.

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. ...

A secondary can serve its transferred zone until refresh and expiry rules require a newer copy or stop service.

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. ...

TLS protects one query path while the selected resolver still receives the plaintext DNS question.

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. ...

DNS follows the alias to an address while HTTP continues using the original hostname.

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 can return several peers while a client repeatedly chooses just one of them.

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. ...

DNS publishes service candidates; an SRV-aware client applies priority and connects to the advertised endpoint.

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. ...