テーマ： dns
-
ロールバック手順つきでDNSレコードを変更する: TTLの引き下げ、切り替え、検証
DNSの変更がユーザーに届く速さは、古いTTLがキャッシュから失効する速さに左右される。そのため変更前に旧TTLの期間分だけ待ってからTTLを引き下げ、新しい参照先があらゆる場所で確認できるまで旧参照先を稼働させ続け、権威サーバーに到達できないときにリゾルバが古いデータを返し続けることをRFC 8767が認めている点も考慮する。
-
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.
-
Web サービスが依存する DNS レコード
A、AAAA、CNAME は名前をアドレスに対応付け、MX はメールの配送先を示し、TXT は検証情報やポリシーを保持する。CAA は証明書の発行元を制限し、NS はゾーンを委任する。変更の前後には、キャッシュするリゾルバーだけでなく権威サーバーの応答も確認する。
-
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.
-
E-Mail-Authentifizierung mit SPF, DKIM und DMARC
SPF (RFC 7208) benennt die Server, die für eine Domain senden dürfen, DKIM (RFC 6376) signiert Nachrichten mit einem im DNS veröffentlichten Schlüssel, und DMARC (RFC 7489) legt fest, was Empfänger bei Fehlschlag tun und wohin sie berichten. Alle drei sind DNS-TXT-Einträge, die jede DNS-Änderung überleben müssen.
-
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.
-
systemd ホストの名前解決を診断する：resolvectl、resolv.conf、nsswitch と getent・dig の違い
systemd-resolved を使うホストでは、/etc/resolv.conf は通常ローカルのスタブリスナーだけを指す。実際のリンク別 DNS サーバーは resolvectl で確認し、getent hosts が DNS に問い合わせるかどうかは /etc/nsswitch.conf が決める。これらの層の混同が、「dig は動くがアプリは動かない」という報告の大半を説明する。
機械可読： JSON