Topic: dns
-
Changing a DNS record with a rollback path: TTL lowering, cutover and verification
A DNS change reaches users only as fast as the old TTL expires in caches, so lower the TTL one full old-TTL period before the change, keep the old target serving until the new one is confirmed everywhere, and account for resolvers that serve stale data when authoritative servers are unreachable, as RFC 8767 allows.
-
Hostname, FQDN and reverse DNS consistency: why Kerberos and TLS name checks break when they disagree
Kerberos service tickets and TLS hostname verification both depend on the name a client resolves for a server matching the name the service believes it has. A mismatch between the configured hostname, /etc/hosts, forward DNS and the PTR record produces authentication and certificate errors that look unrelated to naming.
-
Inspecting and changing macOS network settings from Terminal: networksetup, scutil and DNS cache
networksetup and scutil read and change the active network service, DNS servers, proxies and computer name; dscacheutil and mDNSResponder clear a stale resolver cache after a DNS change so a re-test does not see the old answer.
-
Administering DNS Server zones and records from PowerShell, then verifying with Resolve-DnsName
Get-DnsServerZone, adding A and CNAME records, listing records with Get-DnsServerResourceRecord, the scavenging/aging settings that expire stale records, and clearing the resolver cache — with every write checked from the client side, not just the server's own view.
-
A local caching DNS resolver with Unbound: access-control, forwarding, and DNSSEC validation
Running Unbound as a caching resolver means restricting who may query it with access-control, choosing between full recursion and a forward-zone to an upstream resolver, keeping DNSSEC validation active with an auto-trust-anchor-file, and testing changes with unbound-checkconf before reload.
-
DNS records a web service depends on
A, AAAA and CNAME map names to addresses, MX routes mail, TXT carries verifications and policies, CAA restricts certificate issuers, NS delegates zones; check authoritative answers, not only a cached resolver, before and after changes.
-
Domain renewal, registrar lock and DNS ownership hygiene
A domain is lost by an expired card, a registrant mailbox on the same domain, or an unlocked account, not by attackers alone: keep clientTransferProhibited and the other client locks set (RFC 5731), auto-renew for several years, use a registrant address on a different domain, read the RDAP record for expiry and status, and know that after expiry registrars must interrupt resolution before deletion and that gTLDs offer a 30-day redemption period.
-
How long did clients keep using the old address after a DNS change, and which resolvers or clients ignored the TTL?
Open question: RFC 1035 defines the TTL as the interval a record may be cached before the source is consulted again, and RFC 8767 lets resolvers serve stale data when authoritative servers are unreachable; after a real record change with a lowered TTL, how long did traffic to the old address persist, and which resolvers, libraries or long-lived processes were responsible for the tail?
-
Email authentication: SPF, DKIM and DMARC
SPF lists the servers allowed to send for a domain, DKIM signs messages with a domain key, DMARC tells receivers what to do when both fail and where to send reports; all three are DNS TXT records that must stay in place when other records change.
-
Email authentication with SPF, DKIM and DMARC
SPF (RFC 7208) names the servers allowed to send for a domain, DKIM (RFC 6376) signs messages with a key published in DNS, and DMARC (RFC 7489) defines what receivers do on failure and where they send reports. All three are DNS TXT records that must survive every DNS change.
-
www versus apex domain: the CNAME restriction, cookie scope and which one to redirect to
The apex cannot be a CNAME because RFC 1034 forbids other data at a node that has one and the apex always carries SOA and NS records, so hosting on a provider's changing address needs A/AAAA records or a provider feature such as CNAME flattening; cookies set on the apex with a Domain attribute reach every subdomain. Pick one form, serve both in the certificate, and redirect the other permanently.
-
Diagnosing name resolution on a systemd host: resolvectl, resolv.conf, nsswitch and getent versus dig
On a systemd-resolved host, /etc/resolv.conf usually only points at a local stub listener, the real per-link DNS servers live in resolvectl, and /etc/nsswitch.conf decides whether getent hosts even asks DNS. Confusing these layers explains most "dig works but the application doesn't" reports.
Machine-readable: JSON