Ändern eines A-Datensatzes in einen CNAME ohne Ausfallzeit

Ich habe einen Domainnamen (derzeit auf dyn.com gehostet) mit einem Eintrag A, der auf unsere Produktions-IP-Adresse verweist.

Wir wechseln zu Amazon EC2 und verwenden einen Load Balancer mit der Empfehlung, CNAMEanstelle eines ADatensatzes einen zu verwenden, da Load Balancer die IP-Adresse möglicherweise regelmäßig ändern.

Leider scheint es mir nicht möglich zu sein, diesen Übergang nahtlos durchzuführen. Ich muss zuerst den A-Datensatz löschen und dann den CNAME hinzufügen, was möglicherweise zu Ausfallzeiten führt, wenn sich der neue Datensatz verbreitet.

Gibt es eine Möglichkeit, dies reibungslos und ohne (oder mit nur minimalen) Ausfallzeiten zu tun?

Es ist ein Trick , den Sie hier verwenden können. Das heißt, Wesley ist ein kluger Kerl und du solltest ihm zuhören. Ich werde nicht dafür bezahlt, das zu sagen, aber ich hoffe, dass ich das eines Tages ändern kann.

Angenommen, Sie versuchen, einen Datensatz zu ändern, der wwwin einer Zone mit dem Namen example.com....

• Erstellen eines temporären Platzhalters Ein Datensatz ( *) in der Zone. Übernehmen Sie die Änderung. Testen Sie es, stellen Sie sicher, dass der Platzhalterdatensatz wie erwartet funktioniert und überschreiben Sie die NXDOMAIN-Antworten.
• Entfernen Sie den wwwA-Datensatz. Verpflichten.
• Fügen Sie Ihren neuen CNAME-Datensatz hinzu. Verpflichten. Nochmal testen.
• Entfernen Sie den Platzhalterdatensatz *, wenn Sie zufrieden sind.
• Folgen Sie Wesleys Rat und finden Sie einen DNS-Anbieter, der Sie nicht zwingt, durch solche Reifen zu springen.

Da dies Ihr Ruf ist, möchten Sie vielleicht eine kurze Auffrischung darüber erhalten, was Wikipedia über die Verarbeitung von Platzhaltern zu sagen hat. Stellen Sie sicher, dass Sie einen Platzhalter mit der gleichen Punktzahl wie der zu entfernende Datensatz hinzufügen, da Platzhalterdatensätze keinen Punkt durchlaufen. (als Label bezeichnet, wenn Sie den richtigen RFC-Begriff wünschen)

Dies sollte auch selbstverständlich sein, aber alle diese Tests sollten direkt auf Ihren autorisierenden Servern ausgeführt werden. ( Nicht gegen den Standard-Resolver, der für den Computer konfiguriert ist, von dem aus Sie den Test ausführen)

Wir wechseln zu Amazon EC2 und verwenden einen Load Balancer mit der Empfehlung, einen CNAME anstelle eines A-Datensatzes zu verwenden

Ich hoffe aufrichtig, dass Sie Ihre Apex-Domain nicht CNAMEEN. Wenn Ihr DNS-Host sich selbst respektiert, ist dies nicht zulässig. Wenn es ein beschämender und schleimiger Wirt ist, werden Sie es können, aber Sie werden ein Stück Ihrer Seele verlieren (aber Sie verwenden EC2 trotzdem, so dass es den Anschein hat, dass die Sorge um Ihre Seele bereits minimal ist).

Quoth Amazon:

Sie können keinen CNAME-Datensatz verwenden, um Ihre Zonenspitze Ihrer Instanz für den elastischen Lastausgleich zuzuordnen. DNS-Regeln verbieten die Erstellung eines CNAME-Eintrags an der Zonenspitze (z. B. example.com). Wenn Sie beispielsweise den Domainnamen example.com besitzen, können Sie einen CNAME-Eintrag für den Subdomainnamen foo.example.com verwenden, nicht jedoch für den Zonen-Apex example.com.

Weitermachen ...

... da Load Balancer die IP-Adresse regelmäßig ändern können.

Nein, Load Balancer sollten IP-Adressen nicht regelmäßig ändern. Das ist irgendwie ihr Punkt. Sie bleiben gleich und fungieren als Abstraktionsschicht zwischen Verbrauchern und der Inhaltsinfrastruktur. Wenn Ihnen jemand gesagt hat, dass sich die IP-Adresse des Load Balancers regelmäßig ändern kann, bitten Sie ihn um Klarheit.

Amazon ELB ist vorhanden, daher besteht das Ziel darin, Ihre Domain dem Namen der ELB zuzuordnen. Ich verstehe die Situation jetzt.

Leider scheint es mir nicht möglich zu sein, diesen Übergang nahtlos durchzuführen. Ich muss zuerst den A-Datensatz löschen und dann den CNAME hinzufügen, was möglicherweise zu Ausfallzeiten führt, wenn sich der neue Datensatz verbreitet.

Ohne einige Multicast-Spielereien und vielleicht sogar einen Schuss BGP-Verrücktheit soll DNS selbst keine Änderungen der Ausfallzeit aufweisen. Sie können jedoch das Ausfallzeitpotenzial minimieren, indem Sie die TTL-Werte Ihrer Datensätze auf die niedrigste zulässige Zeitspanne senken. Normalerweise 60 Sekunden, aber wenn Ihr DNS-Host nicht zulässt, dass es so niedrig wird, dann polieren Sie Ihre Mistgabeln, weil das einfach schrecklich ist. Lassen Sie Ihre Datensätze unabhängig davon auf die niedrigstmögliche Anzahl fallen, und warten Sie dann, wie lange der vorherige TTL-Wert war. Wenn Ihr vorheriger TTL-Wert 3600 Sekunden betrug, warten Sie eine Stunde, nachdem Sie Ihren TTL-Wert auf 60 Sekunden geändert haben.

Wenn Sie so lange gewartet haben, können Sie Ihren A-Datensatz in einen CNAME ändern, und Sie haben ungefähr nur etwa 60 Sekunden Ausfallzeit.

Ich habe ähnliche Umstellungen durchgeführt, bei denen keine Ausfallzeiten auftraten, aber die Synchronisierung wurde für die Datenspeicher durchgeführt, sodass alle Transaktionen, die auf das alte und das neue System gefiltert wurden, während der trüben Umschaltperiode mit Backend-Magicks synchronisiert wurden. Das kostet normalerweise mehr Zeit und Mühe als gerechtfertigt, es sei denn, Sie haben es mit vielen Benutzern und Geld zu tun.

Die TTL beträgt bereits 60 Sekunden, die SOA NXDOMAIN TTL jedoch 1800 Sekunden

... was nur dann ein Problem ist, wenn in Ihrer Domain etwas passiert ist, das eine NXDOMAIN-Antwort zurückgibt, was nicht der Fall ist, wenn Sie Ihren Datensatz von einem A in einen CNAME ändern.

Das Entfernen des vorhandenen A-Datensatzes führt möglicherweise zu einer Ausfallzeit von bis zu 30 Minuten (soweit ich das beurteilen kann).

Nein, weil Sie nicht entfernen, sondern ändern und jeder vernünftige DNS-Host das Entfernen des A-Eintrags und das Hinzufügen des CNAME auf einen Schlag festschreiben würde, sodass Sie nicht mit NXDOMAIN auf Anfragen antworten.

Wenn Dyn jede Änderung an Ihrer Zone zu einer atomaren Aktion macht, die einzeln in die Zonendatei übernommen wird, können Sie möglicherweise NXDOMAIN-Antworten zurückgeben. Das ist eine schreckliche Sache für Dyn, aber nicht ganz überraschend.

was ich anscheinend mit dyn.com nicht ändern kann

Meine Meinung (die in Kombination mit 5 US-Dollar bei Starbucks eine Tasse Kaffee bringen kann): Dyn ist ein schrecklicher DNS-Host.