Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Cloud DNS verwendet das folgende Verfahren, um Abfragen von Compute Engine-VM-Instanzen und Google Kubernetes Engine-Knoten (GKE) zu beantworten.
Bei anderen Compute Engine-VMs als GKE-Knoten folgt Cloud DNS der Reihenfolge der Auflösung für VPC-Netzwerke, um eingehende Abfragen zu verarbeiten. Jede VM muss so konfiguriert sein, dass sie die IP-Adresse des Metadatenservers (169.254.169.254) als Nameserver verwendet.
Antwortrichtlinien auf Clusterebene und private Zonen
Übereinstimmung mithilfe von Regeln in Antwortrichtlinien auf GKE-Clusterebene Cloud DNS sucht in allen relevanten Antwortrichtlinien auf Clusterebene in GKE nach einer Regel, bei der das DNS-Namenattribut möglichst genau mit der Abfrage übereinstimmt. Cloud DNS verwendet das Abgleichverfahren „Längstes gemeinsames Suffix“, um Antwortrichtlinien auf Clusterebene zu prüfen.
Wenn Cloud DNS eine übereinstimmende Antwortrichtlinienregel findet und die Regel lokale Daten bereitstellt, gibt Cloud DNS die lokalen Daten als Antwort zurück und schließt den Vorgang zur Namensauflösung ab.
Wenn Cloud DNS eine übereinstimmende Antwortrichtlinienregel findet und die Regel die Antwortrichtlinie umgeht, fährt Cloud DNS mit dem nächsten Schritt fort.
Wenn Cloud DNS keine übereinstimmende Antwortrichtlinie findet oder wenn es keine anwendbare Antwortrichtlinie auf Clusterebene für den Knoten gibt, fährt Cloud DNS mit dem nächsten Schritt fort.
Einträge in privaten Zonen auf Clusterebene abgleichen Cloud DNS sucht in allen verwalteten privaten Zonen auf Clusterebene nach einem Eintrag, der so weit wie möglich mit der Abfrage übereinstimmt. Cloud DNS verwendet die Abgleichmethode „Längstes gemeinsames Suffix“, um Einträge in privaten Zonen auf Clusterebene zu finden.
Wenn der Zonenname einer privaten Zone in Clusterebene die beste Übereinstimmung für die Abfrage ist, verwendet Cloud DNS die Eintragsdaten dieser Zone, um die Anfrage zu lösen.
Wenn die Zone einen Eintrag enthält, der genau mit der Abfrage übereinstimmt, gibt Cloud DNS die Daten dieses Eintrags zurück.
Wenn die Zone keinen übereinstimmenden Eintrag enthält, gibt Cloud DNS NXDOMAIN zurück.
Wenn der Zonenname einer Weiterleitungszone in Clusterebene die beste Übereinstimmung für die Abfrage ist, leitet Cloud DNS die Abfrage an eines der Weiterleitungsziele der Weiterleitungszone weiter, um die Namensauflösung abzuschließen. Cloud DNS gibt eine der folgenden Antworten zurück.
Die Antwort, die vom Weiterleitungsziel empfangen wurde.
Eine SERVFAIL-Antwort, wenn das Weiterleitungsziel nicht auf Cloud DNS reagiert.
Übereinstimmung mit dem alternativen Nameserver des VPC-Netzwerks Wenn das VPC-Netzwerk eine Serverrichtlinie für ausgehenden Traffic hat, leitetGoogle Cloud die Abfrage an einen der in dieser Richtlinie definierten alternativen Nameserver weiter, um die Namensauflösung abzuschließen.
Wenn in der ausgehenden Serverrichtlinie zwei oder mehr alternative Nameserver vorhanden sind, werden diese von Cloud DNS anhand eines internen Algorithmus sortiert. Ausgehend von gleichen Rängen steigen alternative Nameserver aufgrund einer höheren Rate erfolgreicher Antworten (einschließlich NXDOMAIN-Antworten) und aufgrund der kürzesten Umlaufzeit (der niedrigsten Antwortlatenz) in der Rangfolge auf.
Cloud DNS sendet Abfragen an alternative Nameserver und gibt Antworten mit dem folgenden Verfahren zurück.
Wenn in der ausgehenden Serverrichtlinie zwei oder mehr alternative Nameserver vorhanden sind, sendet Cloud DNS die Abfrage zuerst an den alternativen Nameserver mit dem höchsten Rang und dann an den alternativen Nameserver mit dem nächsthöheren Rang, wenn Cloud DNS keineAntwort vom alternativen Nameserver mit dem höchsten Rang erhält. Wenn Cloud DNS keine Antwort vom nächsten alternativen Nameserver erhält, werden alternative Nameserver in absteigender Reihenfolge abgefragt, bis die Liste der alternativen Nameserver aufgebraucht ist.
Wenn Cloud DNS eine Antwort von einem alternativen Nameserver empfängt, gibt Cloud DNS diese Antwort zurück. Antworten enthalten NXDOMAIN Antworten.
Wenn Cloud DNS keine Antwort von allen alternativen Nameservern in der ausgehenden Serverrichtlinie erhält, synthetisiert Cloud DNS eine SERVFAIL-Antwort. Informationen zur Fehlerbehebung bei der Verbindung mit alternativen Nameservern finden Sie unter Netzwerkanforderungen für alternative Nameserver.
Wenn das VPC-Netzwerk keine Serverrichtlinie für ausgehenden Traffic hat, fährt Cloud DNS mit dem nächsten Schritt fort.
Übereinstimmung mithilfe von Regeln in Antwortrichtlinien auf VPC-Netzwerkebene Cloud DNS sucht in allen anwendbaren VPC-Netzwerk-Antwortrichtlinien nach einer Regel, bei der das DNS-Namenattribut so weit wie möglich mit der Abfrage übereinstimmt. Cloud DNS verwendet das Abgleichsprinzip „Longest Suffix“, um Antwortrichtlinien auf VPC-Netzwerkebene zu prüfen.
Wenn Cloud DNS eine übereinstimmende Antwortrichtlinienregel findet und die Regel lokale Daten bereitstellt, gibt Cloud DNS die lokalen Daten als Antwort zurück und schließt den Vorgang der Namensauflösung ab.
Wenn Cloud DNS eine übereinstimmende Antwortrichtlinienregel findet und die Regel die Antwortrichtlinie umgeht, fährt Cloud DNS mit dem nächsten Schritt fort.
Wenn Cloud DNS keine übereinstimmende Antwortrichtlinie findet oder wenn es keine anwendbare Antwortrichtlinie auf VPC-Netzwerkebene für die VM oder den Knoten gibt, fährt Cloud DNS mit dem nächsten Schritt fort.
Datensätze in verwalteten privaten Zonen auf VPC-Netzwerkebene abgleichen
Cloud DNS sucht in allen verwalteten privaten Zonen, die für das VPC-Netzwerk autorisiert sind, nach einem Eintrag, der der Abfrage so weit wie möglich entspricht. Cloud DNS verwendet die Abgleichmethode „Längstes gemeinsames Suffix“, um Einträge zu finden.
Wenn der Zonenname einer privaten Zone im VPC-Netzwerk die beste Übereinstimmung für die Abfrage ist, verwendet Cloud DNS die Eintragsdaten dieser Zone, um die Anfrage zu lösen.
Wenn die Zone einen Eintrag enthält, der genau mit der Abfrage übereinstimmt, gibt Cloud DNS die Daten des Eintrags zurück.
Wenn die Zone keinen übereinstimmenden Eintrag enthält, gibt Cloud DNS NXDOMAIN zurück.
Wenn die genaueste Übereinstimmung für die Abfrage der Zonenname einer Weiterleitungszone auf VPC-Netzwerkebene ist, leitet Cloud DNS die Abfrage an eines der Weiterleitungsziele der Weiterleitungszone weiter, um die Namensauflösung abzuschließen. Cloud DNS gibt eine der folgenden Antworten zurück.
Die Antwort, die vom Weiterleitungsziel empfangen wurde.
Eine SERVFAIL-Antwort, wenn das Weiterleitungsziel nicht auf Cloud DNS reagiert.
Wenn der am besten passende Wert für die Abfrage der Name einer Peering-Zone auf VPC-Netzwerkebene ist, beendet Cloud DNS den aktuellen Namensauflösungsprozess und startet einen neuen Namensauflösungsprozess aus der Perspektive des Ziel-VPC-Netzwerks der Peering-Zone.
Wenn die Anfrage nicht mit einer privaten Zone, einer Weiterleitungszone oder einer Peeringzone übereinstimmt, fährt Cloud DNS mit dem nächsten Schritt fort.
Übereinstimmende Einträge in internen Compute Engine-Zonen
Cloud DNS sucht in allen internen DNS-Zonen der Compute Engine nach einem Eintrag, der so weit wie möglich mit der Abfrage übereinstimmt. Cloud DNS verwendet die Abfrage nach dem längsten gemeinsamen Suffix, um Einträge zu finden.
Wenn die genaueste Übereinstimmung für die Abfrage ein interner DNS-Name der Compute Engine ist, gibt Cloud DNS die interne IP-Adresse der Netzwerkschnittstelle der VM oder den Rückwärtssuchzeiger als Antwort zurück und schließt damit die Namensauflösung ab.
Eintrag mit öffentlicher DNS-Abfrage abgleichen: Google Cloud Folgt dem Start of Authority-Eintrag (SOA), um öffentlich verfügbare Zonen abzufragen, einschließlich öffentlicher Cloud DNS-Zonen. Cloud DNS gibt eine der folgenden Antworten zurück.
Die Antwort, die von einem autoritativen Nameserver empfangen wurde.
Eine NXDOMAIN-Antwort, wenn der Eintrag nicht vorhanden ist.
Beispiel
Angenommen, Sie haben die zwei VPC-Netzwerke vpc-a und vpc-b sowie den GKE-Cluster cluster-a und die folgenden bereichsbezogenen Ressourcen:
vpc-a ist berechtigt, die folgenden privaten Zonen abzufragen. Beachten Sie den abschließenden Punkt in jedem Eintrag:
static.example.com.
10.internal.
peer.com. ist eine Peering-Zone, über die die Reihenfolge der VPC-Namensauflösung von vpc-b abgefragt werden kann.
vpc-a ist mit keinem ausgehenden Server oder Antwortrichtlinien verknüpft.
cluster-a ist berechtigt, eine private Zone mit dem Namen example.com abzufragen.
cluster-a ist auch mit keinem ausgehenden Server oder Antwortrichtlinien verknüpft.
Eine VM in cluster-a kann Folgendes abfragen:
example.com und untergeordnete Elemente (einschließlich static.example.com), beantwortet von der privaten Zone example.com, die für cluster-a autorisiert ist.
10.internal auf vpc-a.
peer.com durch Verwenden der Peering-Zone.
Eine VM, die nicht in cluster-a enthalten ist, kann Folgendes abfragen:
static.example.com und untergeordnete Elemente, beantwortet von der privaten Zone static.example.com, die für vpc-a autorisiert ist. Abfragen für example.com geben Internetantworten zurück.
10.internal auf vpc-a.
peer.com durch Verwenden der Peering-Zone.
Nächste Schritte
Informationen zu Lösungen für häufige Probleme, die bei der Verwendung von Cloud DNS auftreten können finden Sie unter Fehlerbehebung.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-11 (UTC)."],[[["\u003cp\u003eCloud DNS handles queries from Compute Engine VMs by following the VPC network resolution order, with each VM needing to use the metadata server IP address (169.254.169.254) as its name server.\u003c/p\u003e\n"],["\u003cp\u003eFor GKE nodes, Cloud DNS first attempts to match queries using cluster-scoped response policies and private zones before proceeding to the VPC network resolution order.\u003c/p\u003e\n"],["\u003cp\u003eThe VPC network resolution order involves matching queries against alternative name servers, VPC network-scoped response policies, managed private zones, Compute Engine internal zones, and finally, public DNS queries.\u003c/p\u003e\n"],["\u003cp\u003eLongest-suffix matching is utilized by Cloud DNS to scan cluster-scoped and VPC network-scoped resources for records or rules that match queries.\u003c/p\u003e\n"],["\u003cp\u003eOutbound server policies help reroute queries through alternative name servers, which are ranked based on response success rates and latency, for a faster resolution.\u003c/p\u003e\n"]]],[],null,["# Name resolution order\n\nCloud DNS uses the following procedure to answer queries from\nCompute Engine virtual machine (VM) instances and\nGoogle Kubernetes Engine (GKE) nodes.\n\nFor Compute Engine VMs other than GKE nodes,\nCloud DNS follows the [VPC network resolution\norder](#vpc_steps) to process queries it receives. Each VM must be configured to\nuse the metadata server IP address (`169.254.169.254`) as its name server.\n\nFor GKE nodes:\n\n1. Cloud DNS first attempts to match a query using [cluster-scoped\n response policies and private zones](#gke_steps).\n\n2. Cloud DNS continues by following the [VPC network\n resolution order](#vpc_steps).\n\nCluster-scoped response policies and private zones\n--------------------------------------------------\n\n1. **Match using rules in GKE cluster-scoped response\n policies**. Cloud DNS scans all applicable GKE\n cluster-scoped response policies for a rule where the DNS name attribute\n matches as much of the query as possible. Cloud DNS uses\n longest-suffix matching to scan cluster-scoped response policies.\n\n 1. If Cloud DNS finds a matching response policy rule *and* the\n rule serves local data, then Cloud DNS returns the local\n data as its response, completing the name resolution process.\n\n 2. If Cloud DNS finds a matching response policy rule *and* the\n rule's behavior bypasses the response policy, then Cloud DNS\n continues to the next step.\n\n 3. If Cloud DNS fails to find a matching response policy *or* if\n there isn't an applicable cluster-scoped response policy for the node,\n then Cloud DNS continues to the next step.\n\n2. **Match records in cluster-scoped private zones**. Cloud DNS scans\n all cluster-scoped managed private zones for a record that matches as much of\n the query as possible. Cloud DNS uses longest-suffix matching to\n find records in cluster-scoped private zones.\n\n 1. If the most specific match for the query is the zone name of a\n cluster-scoped private zone, Cloud DNS uses that zone's record\n data to resolve the request.\n\n - If the zone contains a record that exactly matches the query, Cloud DNS returns that record's data.\n - If the zone doesn't contain a matching record, Cloud DNS returns `NXDOMAIN`.\n 2. If the most specific match for the query is the zone name of a\n cluster-scoped forwarding zone, then Cloud DNS forwards the\n query to one of the forwarding zone's forwarding targets to complete the\n name resolution process. Cloud DNS returns one of the following\n responses.\n\n - The response received from the forwarding target.\n - A `SERVFAIL` response, if the forwarding target doesn't respond to Cloud DNS.\n 3. If the query doesn't match any cluster-scoped private zone,\n Cloud DNS continues to the [VPC network\n resolution order](#vpc_steps).\n\nVPC network resolution order\n----------------------------\n\n1. **Match using VPC network alternative name server** . If the\n VPC network has an [outbound server\n policy](/dns/docs/server-policies-overview#dns-server-policy-out),\n Google Cloud forwards the query to one of the [alternative name\n servers](/dns/docs/server-policies-overview#altns-targets) defined in that\n policy to complete the name resolution process.\n\n If two or more alternative name servers exist in the outbound server\n policy, Cloud DNS ranks the alternative name servers using an\n internal algorithm. Beginning with equal ranks, alternative name servers\n increase in rank based on higher rates of successful responses (including\n `NXDOMAIN` responses) *and* based on the shortest round-trip time (the lowest\n response latency).\n\n Cloud DNS sends queries to alternative name servers and returns\n responses using the following process.\n - If two or more alternative name servers exist in the outbound server\n policy, Cloud DNS first sends the query to the highest-ranked\n alternative name server, then to the next-ranked alternative name\n server if Cloud DNS does *not* receive *any* response from the\n highest-ranked alternative name server. If Cloud DNS doesn't\n receive any response from the next-ranked alternative name server,\n Cloud DNS continues to query alternative name servers by\n descending rank until it exhausts the list of alternative name servers.\n\n - If Cloud DNS receives a response from an alternative name\n server, Cloud DNS returns that response. Responses include\n `NXDOMAIN` responses.\n\n - If Cloud DNS does *not* receive a response from *all*\n alternative name servers in the outbound server policy,\n Cloud DNS synthesizes a `SERVFAIL` response. To troubleshoot\n alternative name server connectivity, see [Alternative name server\n network requirements](/dns/docs/server-policies-overview#altns-net-req).\n\n If the VPC network does *not* have an outbound server policy,\n Cloud DNS continues to the next step.\n2. **Match using rules in VPC network-scoped response\n policies**. Cloud DNS scans all applicable VPC\n network response policies for a rule where the DNS name attribute matches\n as much of the query as possible. Cloud DNS uses longest-suffix\n matching to scan VPC network-scoped response policies.\n\n 1. If Cloud DNS finds a matching response policy rule *and* the\n rule serves local data, then Cloud DNS returns the local data\n as its response, completing the name resolution process.\n\n 2. If Cloud DNS finds a matching response policy rule *and* the\n rule's behavior bypasses the response policy, then Cloud DNS\n continues to the next step.\n\n 3. If Cloud DNS fails to find a matching response policy *or* if\n there isn't an applicable VPC network-scoped response\n policy for the VM or node, then Cloud DNS continues to the next\n step.\n\n3. **Match records in VPC network-scoped managed private zones**.\n Cloud DNS scans all managed private zones authorized for the\n VPC network for a record that matches as much of the query as\n possible. Cloud DNS uses longest-suffix matching to find records.\n\n 1. If the most specific match for the query is the zone name of a\n VPC network-scoped private zone, Cloud DNS uses that\n zone's record data to resolve the request.\n\n - If the zone contains a record that exactly matches the query, Cloud DNS returns the record's data.\n - If the zone doesn't contain a matching record, Cloud DNS returns `NXDOMAIN`.\n 2. If the most specific match for the query is the zone name of a\n VPC network-scoped forwarding zone, then Cloud DNS\n forwards the query to one of the forwarding zone's forwarding targets to\n complete the name resolution process. Cloud DNS returns one of\n the following responses.\n\n - The response received from the forwarding target.\n - A `SERVFAIL` response, if the forwarding target doesn't respond to Cloud DNS.\n 3. If the most specific match for the query is the name of a VPC\n network-scoped peering zone, Cloud DNS stops the current name\n resolution process and begins a new name resolution process from the\n perspective of the peering zone's target VPC network.\n\n If the query doesn't match a private zone, forwarding zone, or peering zone,\n Cloud DNS continues to the next step.\n4. **Match records in Compute Engine internal zones** .\n Cloud DNS scans all applicable [Compute Engine\n internal DNS zones](/compute/docs/internal-dns) for a record that matches as\n much of the query as possible. Cloud DNS uses longest-suffix\n matching to find records.\n\n 1. If the most specific match for the query is a Compute Engine internal DNS name, Cloud DNS returns the internal IP address of the VM's network interface or its reverse lookup pointer as its response, completing the name resolution process.\n5. **Match record using public DNS query**. Google Cloud follows the\n start of authority (SOA) record to query publicly available zones, including\n Cloud DNS public zones. Cloud DNS returns one of the\n following responses.\n\n - The response received from an authoritative name server.\n - An `NXDOMAIN` response, if the record doesn't exist.\n\nExample\n-------\n\nSuppose that you have two VPC networks, `vpc-a` and `vpc-b`, and\na GKE cluster, `cluster-a`, along with the following scoped\nresources:\n\n1. `vpc-a` is authorized to query the following private zones. Note the trailing\n dot in each entry:\n\n - `static.example.com.`\n - `10.internal.`\n2. `peer.com.` is a peering zone that can query the VPC\n name resolution order of `vpc-b`.\n\n3. `vpc-a` is not associated with any outbound server or response policies.\n\n4. `cluster-a` is authorized to query a private zone called `example.com`.\n `cluster-a` is also not associated with any outbound server or response\n policies.\n\n5. A VM in `cluster-a` can query:\n\n - `example.com` and children (including `static.example.com`), answered by the private zone called `example.com`, authorized to `cluster-a`.\n - `10.internal` on `vpc-a`.\n - `peer.com` by using the peering zone.\n6. A VM that is *not* in `cluster-a` can query:\n\n - `static.example.com` and children, answered by the private zone called `static.example.com` authorized to `vpc-a`. Queries for `example.com` return internet responses.\n - `10.internal` on `vpc-a`.\n - `peer.com` by using the peering zone.\n\nWhat's next\n-----------\n\n- To find solutions for common issues that you might encounter when using Cloud DNS, see [Troubleshooting](/dns/docs/troubleshooting).\n- To get an overview of Cloud DNS, see [Cloud DNS overview](/dns/docs/overview).\n- To learn how to configure response policies, see [Manage response policies\n and rules](/dns/docs/zones/manage-response-policies)."]]
