Thema: dns
-
Einen DNS-Eintrag mit Rückwegabsicherung ändern: TTL absenken, Umschaltung und Prüfung
Eine DNS-Änderung erreicht Nutzer nur so schnell, wie die alte TTL in den Caches abläuft; deshalb die TTL eine volle alte TTL-Periode vor der Änderung absenken, das alte Ziel weiterlaufen lassen, bis das neue überall bestätigt ist, und berücksichtigen, dass Resolver veraltete Daten ausliefern dürfen, wenn die autoritativen Server nicht erreichbar sind, wie es RFC 8767 zulässt.
-
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 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.
Maschinenlesbar: JSON