Wir sind gerade auf einen neuen internen DNS-Resolver migriert und haben eine Einschränkung entdeckt, die unsere Fähigkeit beeinträchtigt, nach bestimmten Datensätzen zu suchen.
Unsere interne (private) autoritative Domäne ist example.net.. Wir haben einen CNAME-Eintrag für , service.example.net.der sich auflöst inname-1234567890.region.elb.amazonaws.com.
name-1234567890.region.elb.amazonaws.com.löst sich in verschiedene A-Einträge auf, deren Werte von AWS verwaltet werden. Wir verwalten weder die öffentliche Zone amazonaws.com noch die Einträge innerhalb dieser Zone.
Unser vorheriger DNS-Resolver hat CNAME-Einträge „verfolgt“, eine Suche service.example.net.könnte also Folgendes zurückgeben:
$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net. 300 IN CNAME name-1234567890.region.elb.amazonaws.com.
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.3
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.4
Die Antwort enthält die IPs der A-Einträge, auf die der CNAME verweist. Alles gut.
Unser neuer DNS-Resolver „jagt“ keine CNAME-Einträge. Der gleiche Lookup mit dem neuen Resolver sieht folgendermaßen aus:
$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net. 300 IN CNAME name-1234567890.region.elb.amazonaws.com.
... beachten Sie die fehlenden A-Einträge. Kontaktversuche service.example.netüber Ping, Curl, Python-Anfragen usw. führen alle zu „Unbekannter Host“-Fehlern.
Wir können das Verhalten unseres neuen DNS-Resolvers nicht ändern. Gibt es eine Option im Linux-Kernel oder einen lokalen DNS-Resolver, um CNAME-Einträge vom Client zu „verfolgen“, so wie es unser alter DNS-Resolver auf der Serverseite tat?
Zum Kontext: Unser neuer DNS-Resolver ist GCPs Cloud-DNS, dasUnterlagenDieses Verhalten.
Einige zusätzliche Kontext-/Kommentarantworten:
- example.net ist eine private, intern verwaltete Zone in Cloud-DNS, die uns gehört.
- amazonaws.com ist eine öffentliche Zone, die von AWS verwaltet wird.
- Wenn ich mich recht entsinne, sendet eine Outbound-Server-Richtlinie mit zusätzlichen NameservernalleAnfragen an diese Nameserver, die Cloud-DNS überschreiben
- Soweit ich mich erinnere, sind ALIAS-Einträge nur in öffentlichen Zonen verfügbar, nicht in privaten Zonen.
- service.exmaple.net. ist ein CNAME-Eintrag in der privaten, verwalteten Cloud-DNS-Zone example.net.
- wir sind bei AWS nicht vertreten und können deshalb Route53 nicht verwenden.
Antwort1
Anstatt direkt auf die internen IPs des Load Balancers zu verweisen, müssen Sie auf den öffentlichen DNS-Namen des Load Balancers verweisen
name-1234567890.region.elb.amazonaws.com
Entfernen Sie also die A-Einträge und ändern Sie den CNAME-Wert in den öffentlichen DNS-Namen des Load Balancers.
Antwort2
Ich wollte ein Update zu dieser Frage bereitstellen. Seit dieses Problem entdeckt wurde, hat GCP damit begonnen, eine experimentelle Funktion für Cloud-DNS einzuführen, die öffentliche CNAME-Einträge verfolgt. Zum Zeitpunkt des Schreibens (April 2024) muss diese Funktion explizit beim GCP-Support angefordert werden. Ich bin mir nicht sicher, wann sie allgemein verfügbar sein wird.
Bevor uns diese Funktion zur Verfügung gestellt wurde, haben wir das Problem umgangen, indem wir beispielsweise eine private Weiterleitungszone amazonaws.comin unserem Cloud-DNS erstellt haben, die an öffentliche DNS-Resolver weiterleitet (wir verwenden 8.8.8.8, 1.1.1.1 usw.). Dies funktioniert, da CNAME-Chasing in Cloud-DNS zwischen privaten Zonen aktiviert ist. Da amazonaws.comCloud-DNS dies nun als private Zone betrachtet, werden CNAME-Chasing-Anfragen jetzt normal aufgelöst.
Antwort3
Zum Auflösen von AWS-Datensätzen empfehle ich, Route53 von AWS aus zu verwenden. Sie können Ihren internen DNS-Server beispielsweise an Route53 weiterleiten lassen. Unbound ist ein DNS-Revolver, der das kann.
Amazon Route 53 ist ein skalierbarer und hochverfügbarer Domain Name System (DNS)-Webservice von Amazon Web Services (AWS). Er übersetzt benutzerfreundliche Domänennamen wie example.com effektiv in IP-Adressen, die Computer verwenden, um sich gegenseitig im Internet zu identifizieren. Hier ist eine Übersicht über einige der wichtigsten Funktionen und Konzepte von Route 53:
- Domänenregistrierung: Mit Route 53 können Sie Domänennamen registrieren und verwalten. Sie können neue Domänen kaufen oder vorhandene zu Route 53 übertragen.
- DNS-Dienst: Route 53 fungiert als DNS-Dienstanbieter und ermöglicht Ihnen die Verwaltung der DNS-Einträge für Ihre Domäne. Zu DNS-Einträgen gehören beispielsweise A-Einträge (die Domänennamen IP-Adressen zuordnen), CNAME-Einträge (die Domänennamen anderen Domänennamen zuordnen), MX-Einträge (die Mailserver angeben) und mehr. Integritätsprüfungen und Failover: Route 53 kann Integritätsprüfungen an Ihren Endpunkten, z. B. Webservern, durchführen und den Datenverkehr automatisch von fehlerhaften Endpunkten zu einwandfreien Endpunkten umleiten. Diese Funktion wird häufig zur Implementierung von Failover- und Notfallwiederherstellungslösungen verwendet.
- Verkehrsmanagement: Route 53 bietet Verkehrsmanagementfunktionen, mit denen Sie steuern können, wie DNS-Abfragen basierend auf verschiedenen Faktoren wie Latenz, Geolokalisierung, gewichtetem Routing und mehr weitergeleitet werden. Auf diese Weise können Sie die Leistung und Verfügbarkeit Ihrer Anwendungen optimieren.Integration mit AWS-Services: Route 53 lässt sich nahtlos in andere AWS-Services wie Amazon S3, Elastic Load Balancing (ELB) und Amazon CloudFront integrieren. Sie können Route 53 beispielsweise verwenden, um den Datenverkehr an Ihre ELB-Load Balancer oder CloudFront-Verteilungen weiterzuleiten.
- DNSSEC: Route 53 unterstützt DNS Security Extensions (DNSSEC), die Ihrer DNS-Infrastruktur durch die digitale Signierung von DNS-Einträgen eine zusätzliche Sicherheitsebene hinzufügen. Insgesamt ist Route 53 ein vielseitiger und zuverlässiger DNS-Dienst, der die Grundlage für die Weiterleitung des Datenverkehrs zu Ihren Anwendungen und Diensten im Internet bildet. Es bietet erweiterte Funktionen zur Verwaltung von DNS, zur Verbesserung der Leistung und zur Gewährleistung hoher Verfügbarkeit.