A und AAAA prüfen: DNS Veröffentlichung und Verbindung trennen

Vier Fragen statt einer DNS Prüfung

Wenn eine Website auf einen neuen Server zeigt, werden oft mehrere Dinge unter dem Satz DNS funktioniert zusammengefasst. Tatsächlich sind es getrennte Fragen. Welche Nameserver sind für die Domain zuständig? Welche Adressen liefern diese Server aus? Welche Antwort erhält ein normaler Resolver? Und funktioniert die Website über jede veröffentlichte Adresse? Die letzte Frage reicht bis TLS und Anwendung. Eine Domain kann korrekt aufgelöst werden und trotzdem die falsche Website liefern. Eine direkte Verbindung kann umgekehrt gut funktionieren, obwohl die passende Adresse öffentlich gar nicht erscheint. Für eine nachvollziehbare Abnahme werden diese Ebenen einzeln getestet und im Bericht getrennt festgehalten.

A Einträge beziehen sich auf IPv4, AAAA Einträge auf IPv6. Die beiden Mengen müssen nicht gleich groß sein, aber jede veröffentlichte Adresse braucht einen passenden funktionierenden Dienst. Prüfen Sie Hauptdomain und www getrennt. Wenn www als Alias über eine weitere Domain aufgelöst wird, gehört diese Kette zur Untersuchung. Auch zusätzliche Namen wie ein Kundenportal können einen eigenen Zustand haben. Beginnen Sie mit einer Liste der tatsächlich benötigten Hostnamen. So vermeiden Sie eine Abnahme nur für die Startadresse, während gespeicherte Links oder Weiterleitungen später einen ungeprüften Namen verwenden. Ändern Sie dabei keine Mail oder andere Diensteinträge ohne einen konkreten Auftrag für diese Bereiche.

Die zuständigen Nameserver ermitteln

Eine Domainverwaltung kann DNS Einstellungen zeigen, obwohl die öffentliche Delegation andere Server nennt. Ermitteln Sie deshalb die zuständigen Nameserver über den regulären DNS Weg und prüfen Sie die Delegation, wenn die Antworten unklar sind. Bei einem Providerwechsel können alte und neue Zonen gleichzeitig existieren. Die Oberfläche des neuen Anbieters ist dann möglicherweise bereits gefüllt, wird aber noch nicht von der öffentlichen Delegation genutzt. Notieren Sie, welche Server tatsächlich zuständig sind und welche davon Sie direkt geprüft haben. Erst auf dieser Grundlage ist eine Aussage wie der neue Eintrag wurde veröffentlicht belastbar. Ein Screenshot der lokalen Zone genügt dafür nicht.

Das Werkzeug dig bietet viele passende Abfragen. Die BIND Dokumentation zu dig erklärt Zielserver und Optionen. Für eine direkte Prüfung fragen Sie jeden zuständigen Nameserver ausdrücklich nach dem gewünschten Typ und betrachten Antwortstatus sowie Flags. Der Hinweis auf eine autoritative Antwort ist dabei wichtig. Ein Server kann erreichbar sein und trotzdem nicht die zuständige Zone ausliefern. Bewahren Sie bei solchen Prüfungen den relevanten Antwortkopf auf. Eine nur kurze Liste von Adressen ist praktisch, verdeckt aber Angaben, die bei abweichenden oder leeren Antworten erklären, was tatsächlich passiert ist.

A und AAAA bewusst getrennt abfragen

Fragen Sie jeden benötigten Namen nach A und AAAA ab. Eine erfolgreiche A Antwort erlaubt keine Schlussfolgerung über IPv6. Ebenso beweist eine verfügbare IPv6 Adresse im Serverinventar keine veröffentlichte AAAA Antwort. Bei mehreren zuständigen Nameservern werden alle geprüft. Wenn deren Antworten voneinander abweichen, kann ein Teil der Besucher einen anderen Stand erhalten. Notieren Sie Werte und Zeitpunkt statt nur einen grünen Status. Für ein späteres Update ist außerdem wichtig, ob die Antwort mehrere Adressen enthält. Entfernen Sie keine davon auf Verdacht, bevor deren Zweck bekannt ist; sie kann zu einer bewusst betriebenen weiteren Station gehören.

dig @ns1.example.net example.org A +norecurse
dig @ns1.example.net example.org AAAA +norecurse
dig @ns2.example.net www.example.org A +norecurse
dig @ns2.example.net www.example.org AAAA +norecurse

Die Namen in diesen Beispielen sind Platzhalter. Verwenden Sie die zuvor ermittelten zuständigen Server und die eigene Domain. Lesen Sie eine leere Antwort sorgfältig: Sie kann bedeuten, dass der Name existiert, aber der abgefragte Typ fehlt. Ein nicht existierender Name ist ein anderer Zustand. Ein SERVFAIL verlangt wieder eine eigene Untersuchung, etwa des Resolverwegs oder der Validierung. Vermischen Sie diese Fälle nicht mit einem Verbindungsfehler des Webservers. DNS beantwortet die Frage nach dem Ziel. Ob dieses Ziel einen passenden Dienst ausliefert, wird anschließend auf einem anderen Weg geprüft. Diese Trennung spart viele unnötige Änderungen an bereits korrekten Zonen.

Resolvercache und TTL einordnen

Ein normaler Resolver kann eine zuvor erhaltene Antwort weiterverwenden. Daher kann die direkte autoritative Prüfung bereits neue Werte zeigen, während der eigene Browser noch einen alten Weg nutzt. Die TTL hilft, diesen Zeitraum einzuordnen, ist aber kein Versprechen für jede lokale Anwendung. Browser, Betriebssystem und zwischengeschaltete Dienste können eigene Zustände halten. Erfassen Sie deshalb die reguläre Antwort und den verwendeten Resolver. Ein bloßer Aufruf aus demselben Browser ist keine unabhängige DNS Prüfung. Wenn ein Wechsel geplant ist, kann eine rechtzeitig angepasste TTL helfen. Erst unmittelbar nach der Änderung senken zu wollen, beeinflusst bereits gespeicherte alte Antworten jedoch nicht rückwirkend.

Auch fehlende Antworten können zwischengespeichert werden. Wenn ein AAAA Eintrag zunächst nicht existierte und später ergänzt wurde, kann der eigene Resolver weiterhin den älteren fehlenden Zustand zeigen. Vergleichen Sie bei dieser Situation die direkte Antwort mit mehreren unabhängigen regulären Wegen. Leeren Sie den lokalen Cache nur dann, wenn Sie gerade den eigenen Zustand untersuchen wollen. Diese Maßnahme ändert nicht die Antwort für alle Besucher. Im Bericht ist daher zwischen lokal korrigiert und öffentlich überall beobachtet zu unterscheiden. Eine globale Aussage braucht passende Beobachtungen; sie entsteht nicht dadurch, dass auf einem einzelnen Rechner ein Cache zurückgesetzt wurde.

Die Website an der Zieladresse prüfen

Für eine direkte Prüfung der Website erhalten Sie den Domainnamen und legen nur die Zieladresse fest. Die curl Dokumentation beschreibt dafür unter anderem resolve sowie die Optionen für IPv4 und IPv6. Der Name bleibt wichtig, weil er sowohl die Hostwahl als auch die Zertifikatsprüfung beeinflusst. Eine Anfrage nur an die IP Adresse kann eine Standardseite oder ein anderes Zertifikat treffen. Nutzen Sie bei einer Abnahme keine ausgeschaltete TLS Prüfung. Wenn die Namensprüfung fehlschlägt, ist das ein echter Befund, der nicht durch eine bequemere Testoption zu einem Erfolg umgeschrieben werden darf.

Prüfen Sie zunächst jeden veröffentlichten Weg einzeln und danach die reguläre Domain. Bei IPv6 muss die Verbindung tatsächlich eine native IPv6 Adresse verwenden. Eine Darstellung mit dem Präfix ::ffff und einer IPv4 Adresse ist kein Nachweis für einen öffentlichen nativen IPv6 Pfad. Notieren Sie die entfernte Adresse und den Teststandort. Scheitert der IPv6 Aufruf bereits am lokalen Netz, lässt sich daraus keine Aussage über den Zielserver ableiten. Nutzen Sie einen geeigneten zweiten Prüfpunkt oder kennzeichnen Sie die Verbindung als offen. Unser Dualstack Test führt diese praktische Abnahme mit den verschiedenen möglichen Fehlergrenzen weiter aus.

Weiterleitungen und Inhalt gehören dazu

Ein erfolgreicher Verbindungsaufbau ist erst ein Zwischenstand. Prüfen Sie, ob die richtige Website erscheint und ob Weiterleitungen auf die gewünschte Hauptadresse zeigen. Nutzen Sie einen tiefen Pfad mit einem harmlosen Suchparameter. Eine Weiterleitung, die nur die Hauptseite korrekt behandelt, kann beim kurzen Test unbemerkt Links zerstören. Achten Sie bei www und Hauptdomain auch auf die Zertifikatsabdeckung: Der ursprüngliche HTTPS Name muss geprüft werden können, bevor der Client seiner Weiterleitung folgt. Eine korrekte Zielseite repariert nicht rückwirkend ein falsches Zertifikat auf dem Ausgangsnamen. Deshalb werden Ausgang und Ziel als eigene Schritte der Kette aufgenommen.

Bei einer Vorschau muss auf jedem Weg derselbe gewünschte Schutz gelten. Prüfen Sie A und AAAA, direkte Zielprüfung und reguläre Auflösung. Ein nicht autorisierter Besucher darf nicht über den zweiten Pfad an Inhalte kommen, die am ersten Pfad gesperrt sind. Das gilt auch für Medien und Schnittstellen. Wenn ein Cache oder ein CDN beteiligt ist, wird dieser zusätzliche Weg ausdrücklich getestet. Im Ergebnis kann stehen: autoritative Veröffentlichung korrekt, direkte IPv6 Verbindung geprüft, regulärer Cache noch alt. Diese Form ist nützlicher als ein pauschales fertig, weil sie den verbleibenden Schritt benennt, ohne bereits belegte Teile unklar zu machen.

Fehler nach ihrer Ebene ordnen

Bei abweichenden autoritativen Antworten prüfen Sie Zonenstand und Synchronisierung der zuständigen Server. Bei korrekten autoritativen Antworten und alten Resolverdaten untersuchen Sie TTL und Cache. Bei korrekter Auflösung und fehlender Verbindung interessieren Routing, Firewall und Listener. Bei erfolgreicher Verbindung mit falscher Website kommt die Hostzuordnung hinzu. Bei falschem Zertifikat prüfen Sie TLS Zuordnung und Namen. Diese Reihenfolge folgt der Abhängigkeit der Ebenen. Ein Fehler im inneren Dienst kann nicht durch eine Änderung der TTL behoben werden. Ebenso löst ein Webserverneustart keine falsche öffentliche Delegation. Jede Prüfung bekommt deshalb eine konkrete Frage und einen passenden Beleg.

Wenn Sie den Anbieter einschalten, liefern Sie Domain, abgefragten Typ, Zielserver, Zeitpunkt und die relevante Antwort. Bei Verbindungsproblemen kommen Teststandort, Zieladresse und Fehlertext hinzu. Beschreiben Sie, welche Namen und Adressfamilien betroffen sind. Die Aussage nur IPv6 scheitert über eine reguläre Domain ist für den Netzbetrieb wesentlich konkreter als Website geht nicht. Entfernen Sie aber vertrauliche Parameter und Zugangsdaten aus dem Material. Ein kleiner nachvollziehbarer Test ist meist besser als ein großer ungeordneter Export. Der Ratgeber zur Alarmierung zeigt, wie aus solchen klaren Prüfungen später wiederholbare Überwachung entsteht.

DNS Änderungen mit engem Umfang planen

Vor einer Änderung sichern Sie den betreffenden Zonenstand und klären, welcher Dienst die Zone tatsächlich veröffentlicht. Ändern Sie nur die beauftragten Websiteeinträge. MX, Mailautokonfiguration und andere Namen können unabhängige Dienste betreffen. Ein Webumzug rechtfertigt deshalb keinen pauschalen Austausch aller Adressen in einer Zone. Für den Rückweg halten Sie die vorherigen Werte und deren Zweck fest. Planen Sie außerdem, wann der alte Dienst entfallen darf. Solange Resolver noch den alten Stand nutzen, kann dessen Abschaltung einzelne Besucher treffen. Ein sauberer Übergang berücksichtigt diesen Zeitraum und prüft beide Ziele, soweit sie während der Umschaltung relevant bleiben.

Für eine zusätzliche IPv6 Adresse ist die Betriebsbereitschaft vor der Veröffentlichung wichtig. Prüfen Sie Listener, Firewall, richtigen Host, TLS und Schutz direkt am vorgesehenen Ziel. Erst dann kommt die öffentliche AAAA Veröffentlichung und danach die reguläre Abnahme. Die Reihenfolge verhindert, dass ein noch ungeprüfter Pfad sofort für echte Besucher erreichbar wird. Ein vorhandener IPv6 Eintrag im Hostingpanel ist dabei nur ein Teil des Bestands. Ob der externe autoritative DNS Dienst denselben Wert ausliefert, muss ausdrücklich geprüft werden. Gerade bei getrennten DNS und Hostinganbietern ist diese Grenze häufig der Grund, warum eine lokale Einstellung keine öffentliche Wirkung zeigt.

Eine präzise Übergabe bleibt überprüfbar

Erstellen Sie am Ende eine kleine Ergebnistabelle mit Namen, A und AAAA, zuständigen Servern, regulärer Antwort, Verbindung und TLS. Fügen Sie zu jedem Beleg Zeitpunkt und Prüfweg hinzu. Kennzeichnen Sie offen gebliebene Teile konkret, zum Beispiel eine nicht verfügbare native IPv6 Verbindung am eigenen Testort. Schreiben Sie keine weltweite Erreichbarkeit, wenn Sie nur einen Standort geprüft haben. Ein klarer begrenzter Beleg ist trotzdem wertvoll. Bei späteren Fehlern kann das Team den Zustand mit demselben Weg vergleichen und erkennen, welche Ebene sich verändert hat. Die Dokumentation ist dadurch ein Ausgangspunkt für Diagnose statt nur ein Abschlussbild einer Oberfläche.

DNS ist korrekt abgenommen, wenn Veröffentlichung und Dienstweg getrennt belegt sind. Diese Arbeitsweise lässt sich für neue Domains, Umzüge und zusätzliche Adressfamilien wiederverwenden. Sie vermeidet falsche Sicherheit durch direkte IP Tests und falsche Serverdiagnosen durch alte Resolverantworten. Der wichtigste praktische Gewinn ist die klare nächste Handlung. Eine fehlende AAAA Antwort führt zur zuständigen DNS Stelle; eine veröffentlichte, aber nicht funktionierende IPv6 Adresse führt zum Netzwerk und Hostbetrieb. Wenn diese Grenze von Beginn an festgehalten wird, wird auch eine komplexere Domainanlage nachvollziehbar, ohne unnötig andere Dienste oder Projekte in den Eingriff einzubeziehen.