Privates DNS
Erstellen und verwalten Sie private Domain Name System-(DNS-)Zonen .
Verwenden Sie DNS-Zonen (Private Domain Name Service), um private Zonen mit den von Ihnen angegebenen Domainnamen zu erstellen. Sie können die Zonen und Datensätze vollständig verwalten, um eine Hostnamenauflösung für Anwendungen bereitzustellen, die innerhalb und zwischen virtuellen Cloud-Netzwerken (VCNs ) und On-Premise- oder anderen privaten Netzwerken ausgeführt werden. Trafficmanagement ist nur für öffentliches DNS verfügbar und wird auf privatem DNS nicht unterstützt.
Ein privates DNS bietet auch netzwerkübergreifende DNS-Auflösung (z.B. für ein anderes VCN innerhalb derselben Region, regionsübergreifend oder für ein externes Netzwerk). Ein privates DNS kann in der OCI-DNS-API und in der OCI-Konsole verwaltet werden.
In privaten DNS verwendete Ressourcen
- Private DNS-Zonen: Private DNS-Zonen enthalten DNS-Daten, auf die nur aus einem virtuellen Cloud-Netzwerk (VCN) zugegriffen werden kann, wie private IP-Adressen. Eine private DNS-Zone hat ähnliche Funktionen wie eine Internet-DNS-Zone, bietet aber nur für Clients Antworten, die die Zone über ein VCN erreichen können. Jede Zone gehört zu einer einzelnen Ansicht.
- Private DNS-Zone-Datensätze: Für globale und private DNS werden unterschiedliche Datensatztypen unterstützt. Siehe Unterstützte Resource Records
- Private DNS-Views: Eine private DNS-Ansicht ist eine Sammlung aus privaten Zonen. Ein Zonenname kann zwar in vielen Ansichten verwendet werden, Zonennamen innerhalb einer Ansicht müssen jedoch eindeutig sein.
-
Privater DNS-Resolver: Ein von VCN dedizierter privater DNS-Resolver enthält die Konfiguration, die Antworten auf DNS-Abfragen innerhalb des VCN bereitstellt. Ansichten auf dem Resolver bestimmen die für die Auflösung geltende Zone und die Datensatzdaten. Resolver-Endpunkte im Resolver bieten neben dem Standard-Ingress auf 169.254.169.254 noch einen weiteren Ingress und Egress. Weitere Informationen finden Sie unter Private DNS-Resolver.
- Privater DNS-Resolver-Endpunkt: Verwenden Sie Resolver-Endpunktressourcen zum Einrichten von Ingress und Egress im VCN. Resolver-Endpunkte konsumieren IP-Adressen in dem Subnetz, in dem Sie sie erstellen. Für jeden Resolver-Endpunkt wird eine zugehörige VNIC erstellt.
- VCN: Wenn Sie ein VCN erstellen, wird automatisch auch ein dedizierter Resolver erstellt.
- Subnetz: Ein Subnetz in einem VCN wird beim Erstellen von Volume-Endpunkten verwendet. IP-Adressen aus dem Subnetz werden für Listening-Vorgänge und die Adressweiterleitung belegt.
- Network Security Group (NSG): Optional können Sie eine Liste der Netzwerksicherheitsgruppen für Volume-Endpunkte konfigurieren. NSGs steuern Ingress- und Egress-Traffic zum und vom Resolver-Endpunkt.
Weitere Informationen zu VCN-Ressourcen finden Sie unter Private DNS-Resolver in der Networking-Dokumentation.
Geschützte Ressourcen
- Alle VCN-dedierten Resolver
- Standardansichten: Jeder VCN-dedizierte Resolver verfügt über eine geschützte Standardansicht. Sie können der Standardansicht weitere Zonen hinzufügen, es gelten jedoch Einschränkungen für die Zonennamen, um Konflikte mit geschützten Zonen zu vermeiden. Wenn ein Resolver gelöscht wird und seine Standardansicht nicht geschützte Zonen enthält, wird die Standardansicht in eine nicht geschützte Ansicht konvertiert, anstatt sie zu löschen. Sie können zusätzlich zur Standardansicht eine Ansicht erstellen und einem Resolver zuordnen, sodass ihre Zonen im VCN aufgelöst werden können.
Konfiguration und Auflösung
DNS
Sie können einen vollständigen oder teilweisen Domainbaum erstellen. Eine Ansicht kann von einer beliebigen Anzahl von Resolvern verwendet werden und private DNS-Daten innerhalb einer Region VCN -übergreifend verwenden. Sie können diese Zonen für Split-Horizon-DNS verwenden, weil derselbe Zonenname sowohl in einer privaten Zone als auch in einer Internetzone verwendet werden kann. Unterschiedliche Antworten können für öffentliche Abfragen und private Abfragen in einem VCN bereitgestellt werden.
Das Subnetz für private DNS-Endpunkte darf nur IPv4 sein. Eine Anforderung zum Erstellen eines privaten DNS-Endpunkts in einem IPv6-fähigen Subnetz ist nicht erfolgreich.
Fügen Sie Regeln hinzu, um die Logik für die Beantwortung von Abfragen zu definieren. Der einzige unterstützte Regeltyp ist FORWARD. Diese Regel leitet eine Abfrage basierend auf der Client-IP oder dem Ziel-QNAME bedingt an eine Ziel-IP weiter. Die Ziel-IP-Adresse kann sich auf ein On-Premise-Setup, ein privates Netzwerk oder einen Listener-Resolver-Endpunkt in einem anderen VCN beziehen. Die Resolver-Regel qnameCoverConditions deckt genaue Übereinstimmungen und auch Subdomains ab.
- Alle zugeordneten Ansichten werden in der angegebenen Reihenfolge ausgewertet. Die Standardansicht wird zuletzt ausgewertet, wenn sie nicht explizit in der Liste enthalten ist.
- Resolver-Regeln werden in der angegebenen Reihenfolge angewendet. Die erste Resolver-Regel, die mit der View übereinstimmt, wird angewendet. Jede Regel, die weiter unten in der Liste mit doppelten Bedingungen (einschließlich keine Bedingungen) zu einer vorherigen Regel steht, wird nie ausgewertet. Ein Beispiel für eine nicht erreichbare Regel ist eine spezifischere qnameCoverCondition oder clientAddressConditions nach einer allgemeineren Regel. Wenn die allgemeinere Regel eine Übereinstimmung ist, wird die spezifischere Regel nie ausgewertet.
- Die Abfrage wird über das Internet aufgelöst.
Beispiel: Wenn ein Abfragename in einer Zone in einer privaten Ansicht enthalten ist und der Name nicht in der Zone vorhanden ist, gibt die Zone eine autoritative NXDOMAIN -Antwort zurück.
VCN
Für Ingress- und Egress-Traffic zwischen VCNs oder zwischen VCNs und On-Premise-Netzwerken ist Konnektivität erforderlich. Für das Herstellen einer Verbindung ist möglicherweise ein lokales Peering-Gateway (LPG ) oder ein Remote-Peering-Gateway (RPG ) zwischen VCNs erforderlich. Die Verbindung zwischen einem VCN und On-Premise-Netzwerken erfordert entweder FastConnect oder einen IPSec -Tunnel (IPSec-VPN).
VCN-Sicherheitslisten und alle referenzierten NSGs müssen den erforderlichen Traffic zulassen. DHCP muss in der Sicherheitsliste für Ingress und Egress aktiviert sein und die IP-Adresse des entsprechenden Resolver-Endpunkts enthalten. Die Sicherheitsregeln für Listening-Endpunkte müssen verbindungslosen UDP -Ingress auf Zielport 53, verbindungslosen UDP-Egress auf Quellport 53 und TCP -Ingress auf Zielport 53 zulassen. Die Sicherheitsregeln für Weiterleitungsendpunkte müssen verbindungslosen UDP-Egress auf Zielport 53, verbindungslosen UDP-Ingress auf Quellport 53 und TCP-Egress auf Zielport 53 zulassen.
Anwendungsfälle
Benutzerdefinierte DNS-Zonen in einem VCN
Private DNS-Zonen werden in Ansichten gruppiert. Alle VCN-dedizierten Resolver verfügen über eine automatisch erstellte Standardansicht. Um eine benutzerdefinierte DNS-Zone zu erstellen, die aus einem VCN aufgelöst wird, erstellen Sie entweder die private Zone in der Standardansicht des dedizierten Resolvers, oder erstellen Sie die Zone in einer neuen Ansicht, und fügen Sie sie der Liste der zugeordneten Ansichten des dedizierten Resolvers hinzu. Eine ausführliche Anleitung zum Einrichten finden Sie im Help Center unter Private DNS-Zonenansichten und Resolver konfigurieren.
Split-Horizon
Erstellen Sie private Zonen mit denselben Namen wie öffentliche Namen im Internet. Fügen Sie die Zonen dann einer der Ansichten des VCN -Resolvers hinzu. Innerhalb des VCN werden die Namen basierend auf der privaten DNS-Konfiguration aufgelöst. Für dieselben Namen werden also verschiedene Antworten zurückgegeben, je nachdem, woher die Anforderung stammt.
Gemeinsam genutzte private DNS-Zonen innerhalb einer Region
VCNs in derselben Region können Anforderungen aus den privaten Ansichten der anderen VCNs auflösen. Beispiel: Sie möchten diese Lösung mit VCN A und VCN B implementieren. Fügen Sie die Standardansicht des dedizierten Resolvers von VCN A den zugeordneten Ansichten des dedizierten Resolvers von VCN B hinzu. Fügen Sie dann die Standardansicht des dedizierten Resolvers von VCN B den zugeordneten Ansichten des dedizierten Resolvers von VCN A hinzu.
Dieselbe private Zone oder Gruppe von privaten Zonen kann über mehrere VCNs hinweg erneut verwendet werden. Diese Lösung kann das Duplizieren von DNS-Konfigurationen reduzieren. Erstellen Sie eine Ansicht, und fügen Sie ihr mindestens eine private Zone hinzu. Fügen Sie für jedes VCN die neue Ansicht der Liste der zugeordneten Ansichten des dedizierten Resolvers des VCN hinzu. Eine ausführliche Anleitung zum Einrichten finden Sie im Help Center unter Private DNS-Zonenansichten und Resolver konfigurieren.
DNS-Auflösung zwischen VCNs
Senden Sie Anforderungen zwischen VCNs mittels Resolver-Endpunkten. Die VCNs können in verschiedenen Regionen vorhanden sein. Für diese Lösung wird ein lokales oder ein Remote-Peering-Gateway (LPG /RPG ) benötigt. Um Traffic von VCN A an VCN B zu senden, fügen Sie dem Resolver von VCN B einen Listening-Endpunkt hinzu. Fügen Sie dann dem dedizierten Resolver von VCN A einen Weiterleitungsendpunkt hinzu. Erstellen Sie eine Regel für den dedizierten Resolver von VCN A, der Traffic über den Weiterleitungsendpunkt von VCN A an die Adresse des Listening-Endpunkts von VCN B weiterleitet. Um Traffic in beide Richtungen zwischen den VCNs zu senden, fügen Sie jedem dedizierten Resolver einen Weiterleitungs- und einen Listening-Resolver-Endpunkt hinzu. Fügen Sie anschließend für jeden dedizierten Resolver eine Regel hinzu. Eine ausführliche Anleitung zum Einrichten finden Sie unter A-Team Chronicles/Private DNS-Implementierung.
Konnektivität zwischen einem VCN und On-Premise-Name Servern
Anforderungen können in beiden Richtungen zwischen einem VCN und On-Premise-Name Servern gesendet werden. Für diese Lösung ist eine Konnektivität zwischen dem VCN und dem On-Premise-Netzwerk mit FastConnect oder einem IPSec -Tunnel (IPSec-VPN) erforderlich. Um Traffic an ein VCN zu senden, fügen Sie dem dedizierten Resolver einen Listening-Endpunkt hinzu, und senden Sie den Traffic an dessen Adresse. Um Traffic von einem VCN zu senden, fügen Sie dem dedizierten Resolver einen Weiterleitungsendpunkt hinzu sowie eine Regel, die Traffic über diesen Endpunkt an die Adresse des On-Premise-Name Servers weiterleitet. Eine ausführliche Anleitung zum Einrichten finden Sie unter A-Team Chronicles/Private DNS-Implementierung.
Erweiterte Anwendungsfälle
VCNs können für verschiedene Anwendungsfälle eingerichtet werden. Ein einzelnes VCN könnte sowohl mittels Peering mit einem anderen VCN verbunden sein als auch für die Verbindung mit einem On-Premise-Name Server konfiguriert werden. Die Weiterleitung kann auch über viele VCNs hinweg verkettet werden.
Unterstützte Resource Records
Der Oracle Cloud Infrastructure DNS-Service unterstützt viele Resource-Record -Typen. Die folgende Liste enthält eine kurze Erläuterung der Zwecke der einzelnen unterstützten Datensatztypen für privates DNS. Informationen zu öffentlichem DNS finden Sie unter Öffentliches DNS - Unterstützte Resource Records. Geben Sie bei der Eingabe von Datensatzdaten keine vertraulichen Informationen ein. Über die RFC-Links erhalten Sie weitere Informationen zu den Datensatztypen und der Datenstruktur.
Hinweis zu RDATA
OCI normalisiert alle RDATA in das am besten maschinenlesbare Format. Die zurückgegebene Darstellung von RDATA kann sich von der anfänglichen Eingabe unterscheiden.
Beispiel:
Die RDATA für die Datensatztypen CNAME, DNAME und MX können einen oder mehrere absolute Domainnamen enthalten. Wenn die angegebenen RDATA für einen dieser Datensatztypen nicht mit einem Punkt zur Darstellung des Roots enden, wird der Punkt hinzugefügt.
www.example.com --> www.example.com.
Sie können verschiedene DNS-Librarys verwenden, um RDATA vor der Eingabe zu normalisieren.
| Programmiersprache | Library |
|---|---|
| Go | DNS-Library in Go |
| Java | dnsjava |
| Python | dnspython |
Privates DNS - Resource-Record-Typen
- A
- Ein Adressdatensatz, mit dem ein Hostname auf eine IPv4-Adresse ausgerichtet wird. Weitere Informationen zu A-Datensätzen finden Sie unter RFC 1035.
- AAAA
- Ein Adressdatensatz, mit dem ein Hostname auf eine IPv6-Adresse ausgerichtet wird. Weitere Informationen zu AAAA-Datensätzen finden Sie unter RFC 3596.
- CAA
- Ein Zertifizierungsstellen-Autorisierungsdatensatz wird von einem Domainnameninhaber verwendet, um eine oder mehrere Zertifizierungsstellen anzugeben, die zum Ausstellen von Zertifikaten für diese Domain berechtigt sind. Weitere Informationen zu CAA-Datensätzen finden Sie unter RFC 6844.
- CNAME
- Ein kanonischer Namensdatensatz identifiziert den kanonischen Namen für eine Domain. Weitere Informationen zu CNAME-Datensätzen finden Sie unter RFC 1035.
- DNAME
- Ein Delegierungsnamensdatensatz hat ein ähnliches Verhalten wie ein CNAME-Datensatz, aber er ordnet einen gesamten Unterbaum unter einem Label einer anderen Domain zu. Weitere Informationen zu DNAME-Datensätzen finden Sie unter RFC 6672.
- MX
- Ein Mail-Exchanger-Datensatz definiert den Mailserver, der E-Mails für eine Domain akzeptiert. MX-Datensätze müssen auf einen Hostnamen verweisen. MX-Datensätze dürfen nicht auf einen CNAME oder eine IP-Adresse verweisen. Weitere Informationen zu MX-Datensätzen finden Sie unter RFC 1035.
- PTR
- Ein Pointer-Datensatz ordnet eine IP-Adresse einem Hostnamen zu. Dieses Verhalten entspricht dem Gegenteil eines A-Datensatzes, der einen Hostnamen einer IP-Adresse zuordnet. PTR-Datensätze werden häufig in Reverse-DNS-Zonen verwendet. Weitere Informationen zu PTR-Datensätzen finden Sie unter RFC 1035.
- SRV
- Mit einem Service-Locator-Datensatz können Administratoren mehrere Server für eine einzelne Domain verwenden. Weitere Informationen zu SRV-Datensätzen finden Sie unter RFC 2782.
- TXT
- Ein Textdatensatz enthält beschreibenden, menschenlesbaren Text. Für bestimmte Anwendungsfälle kann er auch nicht menschenlesbaren Inhalt umfassen. Dieser Datensatztyp wird häufig für SPF- und DKIM-Einträge verwendet, die nicht menschenlesbare Textelemente erfordern. Weitere Informationen zu TXT-Records finden Sie unter RFC 1035.
Erforderliche IAM-Policys
Um mit privatem DNS arbeiten zu können, benötigt ein Benutzer genügend Berechtigungen (über eine IAM-Policy). Benutzer in der Administratorengruppe verfügen über die erforderliche Berechtigung. Wenn ein Benutzer nicht zur Administratorengruppe gehört, kann eine bestimmte Gruppe mit einer solchen Policy private DNS verwalten:
Allow group <GroupName> to manage dns in tenancy where target.dns.scope = 'private'Wenn Sie mit Policys nicht vertraut sind, finden Sie weitere Informationen unter Erste Schritte mit Policys und Allgemeine Policys. Weitere Informationen zu Policys für privates DNS finden Sie unter DNS-Policy-Referenz.
Private DNS-Aufgaben
Privates DNS einrichten
Private DNS-Aufgaben
VCN-Aufgaben
Weitere Informationen zum Erstellen eines VCN mit einem dedizierten DNS-Resolver finden Sie unter Überblick über VCNs und Subnetze und DNS in Ihrem virtuellen Cloud-Netzwerk.