Traffic Director and DNS name resolution

This document applies to Traffic Director with Envoy and the older APIs, which include forwarding rules.

It 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 Traffic Director 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 Traffic Director 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 Traffic Director 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:

  1. service-a first performs a DNS lookup for service-b.example.com to resolve service-b's IP address.
  2. The domain is resolved to 10.0.0.101 so that it matches the configured IP address of service-b's forwarding rule.
  3. 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.