DNS-Record-Set-Deduplizierer

Doppelte dns-Records finden und entfernen

DNS Records

Case-sensitive comparison

Results

Enter DNS records to find and remove duplicates

Der DNS Record Set Deduper analysiert Zonendateien oder DNS-Record-Listen, um doppelte Einträge, widersprüchliche Konfigurationen und redundante Records zu identifizieren, die unvorhersehbares Auflösungsverhalten verursachen. Fügen Sie Ihre Zonendatei-Inhalte ein und erhalten Sie eine bereinigte Ausgabe, in der exakte Duplikate entfernt, TTL-Konflikte aufgelöst und CNAME-Verstöße gekennzeichnet sind.

DNS-Record-Duplikate verstehen

DNS-Zonen sammeln im Laufe der Zeit Altlasten an. Jeder Administrator, der eine Zonendatei von einem Vorgänger geerbt hat, kennt das Gefühl: Hunderte von Records, einige offensichtlich veraltet, einige verdächtig ähnlich, und keine Dokumentation, die erklärt, welche tatsächlich benötigt werden. Doppelte und widersprüchliche Records verursachen nicht immer offensichtliche Ausfälle -- sie verursachen intermittierende, schwer zu diagnostizierende Probleme, die Stunden an Fehlersuche verschwenden.

Die gefährlichste Art der Duplizierung ist der CNAME-Konflikt. Die DNS-Spezifikation (RFC 1034) ist eindeutig: Wenn ein CNAME-Record bei einem Namen existiert, dürfen keine anderen Record-Typen bei diesem selben Namen existieren. Wenn diese Regel verletzt wird, gehen verschiedene DNS-Resolver unterschiedlich mit dem Konflikt um. Einige geben den CNAME zurück und ignorieren den A-Record, andere geben den A-Record zurück und ignorieren den CNAME, und einige geben einen SERVFAIL-Fehler zurück. Das Ergebnis ist, dass Ihr Dienst von einigen Standorten aus funktioniert, aber nicht von anderen, oder intermittierend funktioniert, abhängig davon, welchen Resolver der Client zufällig verwendet. Diese Ausfälle sind notorisch schwer aufzuspüren, da die Symptome nicht auf DNS als Ursache hindeuten.

Weniger dramatisch, aber dennoch problematisch sind exakte Duplikate und TTL-abweichende Duplikate. Exakte Duplikate (gleicher Name, Typ und Wert, die zweimal vorkommen) sind harmlos, fügen aber Rauschen zu Ihrer Zone hinzu und erschweren die Wartung. TTL-abweichende Duplikate (gleicher Name, Typ und Wert, aber unterschiedliche TTL) können Caching-Inkonsistenzen verursachen: Ein Resolver könnte den Record für 300 Sekunden cachen, während ein anderer ihn für 3600 Sekunden cached, was zu unterschiedlichem Verhalten bei verschiedenen Clients führt. Dieser Deduper scannt alle diese Kategorien und gibt klare Empfehlungen für jedes gefundene Problem.

So deduplizieren Sie DNS-Records

Fügen Sie Ihre Zonendatei-Inhalte oder eine Liste von DNS-Records (Name, Typ, TTL, Wert) ein
Der Deduper scannt nach exakten Duplikaten, TTL-abweichenden Duplikaten und CNAME-Konflikten
Überprüfen Sie jedes markierte Problem mit seiner Erklärung und dem vorgeschlagenen Lösungsvorschlag
Akzeptieren oder lehnen Sie die vorgeschlagenen Änderungen für jede Kategorie ab
Kopieren Sie die bereinigte Ausgabe mit entfernten Duplikaten und aufgelösten Konflikten

Erkannte Arten von DNS-Duplikaten

Exakte Duplikate

Records, bei denen Name, Typ und Wert identisch sind -- nur einer wird benötigt.

; Vor der Deduplizierung
www    A    203.0.113.10
www    A    203.0.113.10    <- Duplikat

; Nach der Deduplizierung
www    A    203.0.113.10

TTL-abweichende Duplikate

Gleicher Name, Typ und Wert, aber unterschiedliche TTL-Werte. DNS-Server können unvorhersehbare TTLs zurückgeben.

; Vorher -- widersprüchliche TTLs
api    A    300    198.51.100.5
api    A    3600   198.51.100.5

; Nachher -- niedrigste TTL beibehalten
api    A    300    198.51.100.5

CNAME-Konflikte

Ein Name hat sowohl einen CNAME-Record als auch andere Record-Typen, was gegen RFC 1034 verstößt. CNAME-Records müssen der einzige Record bei einem Namen sein (außer DNSSEC-bezogene Typen).

; Ungültig -- CNAME koexistiert mit A-Record
shop    CNAME    store.example.com.
shop    A        203.0.113.20       <- Konflikt

; Lösung: CNAME oder A wählen, nicht beides

Mehrfache CNAMEs

Mehrere CNAME-Records für denselben Namen sind ungültig -- ein Name kann höchstens einen CNAME haben.

; Ungültig -- zwei CNAMEs für denselben Namen
cdn    CNAME    d1234.cloudfront.net.
cdn    CNAME    cdn.otherprovider.com.  <- Konflikt

Wann Sie den DNS Record Set Deduper verwenden sollten

Konsolidierung von Zonen aus mehreren DNS-Anbietern oder Administratoren in eine einzelne Zone
Bereinigung von Legacy-Zonen, die über Jahre manueller Bearbeitungen redundante Einträge angesammelt haben
Validierung vor der Migration, bevor Zonen zwischen DNS-Anbietern verschoben werden, um keine Probleme mitzunehmen
Fehlerbehebung bei intermittierender DNS-Auflösung, die auf widersprüchliche Records zurückzuführen sein könnte
Bereinigung nach Zusammenführungen, nachdem Zonendateien von übernommenen Unternehmen oder zusammengelegten Abteilungen kombiniert wurden
Regelmäßige Zonenpflege als Teil der normalen DNS-Administrationspraxis

Wie DNS-Record-Konflikte Probleme verursachen

Unvorhersehbare Auflösung

Wenn doppelte Records mit unterschiedlichen TTLs existieren, können DNS-Caches je nachdem, welche Antwort sie zuerst erhalten haben, unterschiedliche TTL-Werte speichern. Dies führt zu inkonsistentem Caching-Verhalten über verschiedene Resolver hinweg und erschwert das Debugging.

CNAME-Verstöße

Die DNS-Spezifikation (RFC 1034, Abschnitt 3.6.2) besagt, dass wenn ein CNAME-Record bei einem Knoten vorhanden ist, keine anderen Daten bei diesem Knoten existieren sollten. Wenn diese Regel verletzt wird:

Einige Resolver geben den CNAME zurück und ignorieren andere Records
Andere Resolver geben die A/AAAA-Records zurück und ignorieren den CNAME
Einige Resolver geben einen Fehler zurück (SERVFAIL)
Das Verhalten kann je nach Resolver-Software und Version variieren

CNAME-Probleme am Zonen-Apex

Ein häufiger Fehler ist die Platzierung eines CNAME am Zonen-Apex (example.com), der mit den erforderlichen SOA- und NS-Records kollidiert. Dies ist immer ungültig. Verwenden Sie stattdessen ALIAS- oder ANAME-Records (anbieterspezifisch) oder A/AAAA-Records.

Deduplizierungsstatistiken

Der Deduper liefert eine Zusammenfassung der durchgeführten Aktionen:

Metrik	Beschreibung
Gescannte Records gesamt	Anzahl der Records in der Eingabe
Entfernte exakte Duplikate	Identische Records zusammengefasst
Aufgelöste TTL-Konflikte	Records mit abweichenden TTLs vereinheitlicht
Markierte CNAME-Konflikte	Ungültige CNAME-Koexistenz erkannt
Records in der bereinigten Ausgabe	Endgültige Record-Anzahl nach Deduplizierung

Zonenwartung in der Praxis

Der beste Zeitpunkt für die Deduplizierung einer Zone ist vor einer Migration. Wenn Sie Ihr DNS von einem Anbieter zu einem anderen verschieben, exportieren Sie typischerweise die Zone vom alten Anbieter und importieren sie beim neuen. Dies ist der ideale Moment für die Bereinigung der Zone, da Sie ohnehin jeden Record anfassen. Lassen Sie die Zone durch den Deduper laufen, lösen Sie die markierten Probleme und importieren Sie die bereinigte Version. So vermeiden Sie es, jahrelang angesammelte Probleme in Ihre neue Infrastruktur mitzunehmen.

Für die laufende Wartung sollten Sie die Zonen-Deduplizierung zu einem festen Bestandteil Ihres Change-Management-Prozesses machen. Jedes Mal, wenn Sie DNS-Änderungen vornehmen, lassen Sie den Deduper vor und nach der Änderung über die Zone laufen. Vor der Änderung erkennt er bestehende Probleme, die Ihre neuen Records beeinträchtigen könnten. Nach der Änderung erkennt er versehentliche Duplikate, die Sie möglicherweise eingeführt haben. Dies ist besonders wichtig in Umgebungen, in denen mehrere Administratoren Änderungen vornehmen, da Koordinationsfehler die häufigste Quelle für doppelte Records sind.

Ein praktischer Tipp für große Zonen: Konzentrieren Sie sich zuerst auf CNAME-Konflikte, da diese Records am ehesten Produktionsprobleme verursachen. Exakte Duplikate und TTL-Abweichungen haben niedrigere Priorität, da sie typischerweise subtile statt kritische Probleme verursachen. Wenn Ihr Deduper einen CNAME-Konflikt meldet, lösen Sie ihn sofort -- warten Sie nicht auf ein geplantes Wartungsfenster, da CNAME-Konflikte intermittierende Ausfälle verursachen können, die Ihre Nutzer gerade jetzt aktiv beeinträchtigen.

Häufig gestellte Fragen

Ist es sicher, mehrere A-Records für denselben Namen zu haben?

Ja. Mehrere A-Records für denselben Namen sind eine gültige und gängige DNS-Konfiguration namens Round-Robin-DNS. Zum Beispiel kann www.example.com mehrere A-Records haben, die auf 203.0.113.10 und 203.0.113.11 zeigen, für grundlegende Lastverteilung. Der Deduper markiert diese nicht als Duplikate, da sich die Werte unterscheiden.

Was sollte ich tun, wenn ein CNAME-Konflikt erkannt wird?

Entscheiden Sie, ob der Name ein Alias (CNAME) sein oder eigene direkte Records (A/AAAA/MX/etc.) haben soll. Ein CNAME leitet alle Anfragen für diesen Namen an das Ziel weiter, daher können Sie nicht gleichzeitig einen CNAME und einen MX-Record bei demselben Namen haben. Wenn Sie sowohl Webhosting als auch E-Mail bei einem Namen benötigen, verwenden Sie A/AAAA-Records anstelle von CNAME.

Behandelt der Deduper DNSSEC-Records?

Der Deduper erkennt korrekt, dass DNSSEC-Records (RRSIG, NSEC, NSEC3) mit CNAME-Records koexistieren können, was eine Ausnahme von der Standard-CNAME-Exklusivitätsregel ist, die in RFC 4035 definiert ist.

Warum habe ich doppelte Records, wenn ich nur einen Administrator habe?

Doppelte Records sammeln sich oft durch kleine betriebliche Gewohnheiten an: erneutes Hinzufügen eines Records, der vorübergehend zum Testen entfernt wurde, Einfügen von Records aus Dokumentation, ohne zu prüfen, ob sie bereits existieren, oder Anwenden von Terraform- oder Ansible-Konfigurationen, die nicht auf bereits bestehende Records prüfen. Automatisierte Bereitstellungstools neigen besonders zur Erstellung von Duplikaten, wenn sie nur Erstellungsoperationen verwenden, ohne auf bestehende Records zu prüfen.

Sollte ich bei der Auflösung von TTL-Konflikten die höhere oder niedrigere TTL beibehalten?

In den meisten Fällen behalten Sie die niedrigere TTL. Eine niedrigere TTL bedeutet, dass Änderungen schneller propagiert werden, was im Allgemeinen für die betriebliche Agilität wünschenswert ist. Die Ausnahme ist, wenn die niedrigere TTL offensichtlich ein Fehler war (z. B. eine TTL von 1 Sekunde bei einem Produktions-Record) oder wenn Sie ausdrücklich ein längeres Caching wünschen, um das DNS-Anfragevolumen zu reduzieren. Im Zweifelsfall sind 300 Sekunden (5 Minuten) ein vernünftiger Standard für die meisten Records.