Stay organized with collections
Save and categorize content based on your preferences.
DNS name resolution
This document applies to Cloud Service Mesh with Envoy and the older load-balancing
APIs, which include forwarding rules.
This document explains the relationship between a forwarding rule's virtual IP
address and how the forward rule is associated with a service. The document also
outlines how to plan and configure DNS for a service-to-service communication in
a Cloud Service Mesh service mesh.
Consider this example, in which there are three services, service-a,
service-b, and service-c, that communicate with each other. Developers often
use fully- qualified-domain names in their code for service-to-service
communication. If your domain name is example.com, the three services might be
represented as:
service-a.example.com
service-b.example.com
service-c.example.com
When you configure Cloud Service Mesh resources to create a service mesh,
you configure a forwarding rule for each of the services. A forwarding rule
represents the IP:Port pair of the destination service. For egress traffic to
be intercepted by an Envoy sidecar proxy, the destination IP address must match
with the IP address associated with the forwarding rule. Therefore, you need to
provision an IP address for each service. For example:
service-a.example.com has the IP address 10.0.0.100
service-b.example.com has the IP address 10.0.0.101
service-c.example.com has the IP address 10.0.0.102
The corresponding Cloud Service Mesh configuration has three forwarding rules,
FR1, FR2, and FR3, each using port 80:
FR1 has IP address 10.0.0.100:80, which is associated with service-a.example.com.
FR2 has IP address 10.0.0.101:80, which is associated with service-b.example.com.
FR3 has IP address 10.0.0.102:80, which is associated with service-c.example.com.
When service-a invokes service-b using the fully qualified domain name (FQDN)
service-b.example.com, three things happen:
service-a first performs a DNS lookup for service-b.example.com to resolve
service-b's IP address.
The domain is resolved to 10.0.0.101 so that it matches the configured IP
address of service-b's forwarding rule.
The Envoy proxy is now able to intercept traffic and route it to the backend
service that has service-b's backends, whether those are NEGs or MIGs.
You can configure a Cloud DNS managed private zone to host the resource
records for your services.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[],[],null,["# DNS name resolution\n===================\n\nThis document applies to Cloud Service Mesh with Envoy and the older load-balancing\nAPIs, which include forwarding rules.\n| **Note:** This guide only supports Cloud Service Mesh with Google Cloud APIs and does not support Istio APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nThis document explains the relationship between a forwarding rule's virtual IP\naddress and how the forward rule is associated with a service. The document also\noutlines how to plan and configure DNS for a service-to-service communication in\na Cloud Service Mesh service mesh.\n\nConsider this example, in which there are three services, `service-a`,\n`service-b`, and `service-c`, that communicate with each other. Developers often\nuse fully- qualified-domain names in their code for service-to-service\ncommunication. If your domain name is example.com, the three services might be\nrepresented as:\n\n- `service-a.example.com`\n- `service-b.example.com`\n- `service-c.example.com`\n\nWhen you configure Cloud Service Mesh resources to create a service mesh,\nyou configure a forwarding rule for each of the services. A forwarding rule\nrepresents the `IP:Port` pair of the destination service. For egress traffic to\nbe intercepted by an Envoy sidecar proxy, the destination IP address must match\nwith the IP address associated with the forwarding rule. Therefore, you need to\nprovision an IP address for each service. For example:\n\n- `service-a.example.com` has the IP address `10.0.0.100`\n- `service-b.example.com` has the IP address `10.0.0.101`\n- `service-c.example.com` has the IP address `10.0.0.102`\n\nThe corresponding Cloud Service Mesh configuration has three forwarding rules,\nFR1, FR2, and FR3, each using port `80`:\n\n- FR1 has IP address `10.0.0.100:80`, which is associated with `service-a.example.com`.\n- FR2 has IP address `10.0.0.101:80`, which is associated with `service-b.example.com`.\n- FR3 has IP address `10.0.0.102:80`, which is associated with `service-c.example.com`.\n\nWhen `service-a` invokes `service-b` using the fully qualified domain name (FQDN)\n`service-b.example.com`, three things happen:\n\n1. `service-a` first performs a DNS lookup for `service-b.example.com` to resolve `service-b`'s IP address.\n2. The domain is resolved to `10.0.0.101` so that it matches the configured IP address of `service-b`'s forwarding rule.\n3. The Envoy proxy is now able to intercept traffic and route it to the backend service that has `service-b`'s backends, whether those are NEGs or MIGs.\n\nYou can configure a Cloud DNS managed private zone to host the resource\nrecords for your services."]]
