Thema: dns
-
Einen DNS-Eintrag mit Rollback-Pfad ändern: TTL absenken, Umschaltung und Verifikation
Eine DNS-Änderung erreicht Nutzende nur so schnell, wie die alte TTL in den Caches abläuft: Die TTL daher eine volle alte TTL-Periode vor der Änderung absenken, das alte Ziel bis zur überall bestätigten Umstellung weiterlaufen lassen und berücksichtigen, dass Resolver gemäss RFC 8767 veraltete Daten ausliefern dürfen, wenn die autoritativen Server nicht erreichbar sind.
-
Konsistenz von Hostname, FQDN und Reverse DNS: Warum Kerberos- und TLS-Namensprüfungen scheitern, wenn die Namen nicht übereinstimmen
Kerberos-Service-Tickets und die TLS-Hostnamenprüfung setzen voraus, dass der Name, den ein Client für einen Server auflöst, mit dem Namen übereinstimmt, den der Dienst für sich selbst annimmt. Weichen konfigurierter Hostname, /etc/hosts, Forward-DNS und PTR-Record voneinander ab, entstehen Authentifizierungs- und Zertifikatsfehler, die auf den ersten Blick nichts mit Namensauflösung zu tun haben.
-
macOS-Netzwerkeinstellungen im Terminal prüfen und ändern: networksetup, scutil und DNS-Cache
Mit networksetup und scutil lassen sich aktiver Netzwerkdienst, DNS-Server, Proxys und Computername auslesen und ändern; dscacheutil und mDNSResponder leeren nach einer DNS-Änderung den veralteten Resolver-Cache, damit ein erneuter Test nicht die alte Antwort liefert.
-
DNS-Server-Zonen und -Einträge mit PowerShell verwalten und mit Resolve-DnsName prüfen
Zonen mit Get-DnsServerZone abfragen, A- und CNAME-Einträge anlegen, Einträge mit Get-DnsServerResourceRecord auflisten, Scavenging- und Aging-Einstellungen für veraltete Einträge setzen und den Resolver-Cache leeren – jede Änderung wird clientseitig geprüft, nicht nur auf dem Server.
-
Lokaler Caching-DNS-Resolver mit Unbound: access-control, Forwarding und DNSSEC-Validierung
Unbound als Caching-Resolver zu betreiben heisst: Abfragen per access-control einschränken, zwischen vollständiger Rekursion und einer forward-zone zu einem Upstream-Resolver wählen, die DNSSEC-Validierung mit einer auto-trust-anchor-file aktiv halten und Änderungen vor dem Reload mit unbound-checkconf prüfen.
-
DNS-Einträge, von denen ein Webdienst abhängt
A, AAAA und CNAME bilden Namen auf Adressen ab, MX leitet E-Mails, TXT trägt Verifizierungen und Richtlinien, CAA schränkt Zertifizierungsstellen ein, NS delegiert Zonen; vor und nach Änderungen die massgeblichen Antworten prüfen, nicht nur einen zwischengespeicherten Resolver.
-
Domain-Verlängerung, Registrar-Sperre und Hygiene beim DNS-Eigentum
Eine Domain geht nicht nur durch Angreifer verloren, sondern durch eine abgelaufene Karte, ein Registrant-Postfach auf derselben Domain oder ein entsperrtes Konto: clientTransferProhibited und die übrigen Client-Sperren gesetzt halten (RFC 5731), für mehrere Jahre automatisch verlängern, eine Registrant-Adresse auf einer anderen Domain verwenden, den RDAP-Eintrag auf Ablauf und Status lesen, und wissen, dass Registrare nach Ablauf die Auflösung vor der Löschung unterbrechen müssen und dass gTLDs eine 30-tägige Redemption-Frist bieten.
-
Wie lange nutzten Clients nach einer DNS-Änderung weiter die alte Adresse, und welche Resolver oder Clients ignorierten die TTL?
Offene Frage: RFC 1035 definiert die TTL als das Zeitintervall, in dem ein Eintrag gecacht werden darf, bevor die Quelle erneut konsultiert wird, und RFC 8767 erlaubt Resolvern, veraltete Daten weiterzuverwenden, wenn autoritative Server nicht erreichbar sind; wie lange hielt nach einer echten Eintragsänderung mit gesenkter TTL der Verkehr zur alten Adresse an, und welche Resolver, Bibliotheken oder langlebigen Prozesse waren für den Ausläufer verantwortlich?
-
E-Mail-Authentifizierung: SPF, DKIM und DMARC
SPF listet die Server, die für eine Domain senden dürfen, DKIM signiert Nachrichten mit einem Domain-Schlüssel, DMARC teilt Empfängern mit, was zu tun ist, wenn beides fehlschlägt, und wohin Berichte gesendet werden; alle drei sind DNS-TXT-Einträge, die bestehen bleiben müssen, wenn andere Einträge geändert werden.
-
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: die CNAME-Einschränkung, der Cookie-Geltungsbereich und wohin umgeleitet werden sollte
Die Apex-Domain kann kein CNAME sein, weil RFC 1034 an einem Knoten mit CNAME andere Daten verbietet und die Apex-Domain stets SOA- und NS-Einträge trägt; Hosting auf einer sich ändernden Adresse eines Anbieters braucht deshalb A/AAAA-Einträge oder eine Anbieterfunktion wie CNAME-Flattening. Auf der Apex-Domain mit einem Domain-Attribut gesetzte Cookies erreichen jede Subdomain. Eine Form wählen, beide im Zertifikat ausliefern und die andere dauerhaft umleiten.
-
Namensauflösung auf einem systemd-Host diagnostizieren: resolvectl, resolv.conf, nsswitch und getent im Vergleich zu dig
Auf einem Host mit systemd-resolved verweist /etc/resolv.conf meist nur auf einen lokalen Stub-Listener, die tatsächlichen DNS-Server pro Link zeigt resolvectl an, und /etc/nsswitch.conf bestimmt, ob getent hosts überhaupt DNS befragt. Die Verwechslung dieser Ebenen erklärt die meisten Meldungen der Art «dig funktioniert, die Anwendung aber nicht».
Maschinenlesbar: JSON