Networking

New Cloud DNS response policies simplify access to Google APIs

#networking

Organizations building applications on top of Google Cloud make heavy use of Google APIs, allowing developers to build feature-rich and scalable services on Google Cloud infrastructure. But accessing those APIs can be tough if an organization uses VPC Service Controls to isolate resources and mitigate data exfiltration risks. Today, we’re introducing Cloud DNS response policies. This new feature allows a network administrator to modify the behavior of the DNS resolver according to organizational policies, making it easier to set up private connectivity to Google APIs from within a VPC Service Controls perimeter. 

To date, this has been a challenge for customers, especially for services whose APIs are not available within restricted.googleapis.com and aren’t accessible within the VPC SC perimeter. In addition, configuring access to restricted.googleapis.com is not straightforward: you have to create a new private DNS zone just to access Google services in addition to any existing private DNS zones and add records corresponding to the APIs in use. The simple approach of creating a wildcard *.googleapis.com DNS zone and pointing it to the restricted VIP will break services that are not available on the restricted VIP. 

Using Cloud DNS response policies helps simplify the user experience. Based on a subset of the Internet Draft for response policy zones (or RPZ), they allow you to modify how the resolver behaves according to a set of rules. As such, you can create a single response policy per network that allows for:

  • Alteration of results for selected query names (including wildcards) by providing specific resource records OR

  • Triggering passthru behavior that exempts names from matching the response policy. Specifically, a name can be excluded from a wildcard match, allowing normal private DNS matching (or internet resolution) to proceed as if it never encountered the wildcard.

You can use this to set up private connectivity to Google APIs from within a VPC Service Controls perimeter. It works by creating a response policy (instead of a DNS zone) bound to the network, then adds a localdata rule for *.googleapis.com containing the CNAME. You can then exempt unsupported names (like www.googleapis.com by creating a passthru rule. Queries then receive the restricted answer, unless they are for the unsupported name, in which case they receive the normal internet result.The following snippet illustrates how to achieve this:

  gcloud beta dns response-policies create vpc-sc-response-policy
    --networks=<URL to your Google Cloud network>
    --description="Response policy for VPC service controls"
gcloud beta dns response-policies rules create googleapis-localdata
    --response-policy vpc-sc-response-policy
    --dns-name="*.googleapis.com"
    --local-data=name="*.googleapis.com.",type="A",ttl=3600,rrdatas
="199.36.153.4|199.36.153.5|199.36.153.6|199.36.153.7"
gcloud beta dns response-policies rules create googleapis-www-passthru
    --response-policy vpc-sc-response-policy
    --dns-name="www.googleapis.com"
    --behavior=bypassResponsePolicy

There are some caveats to using Cloud DNS response policies though—passthru configurations cannot generate NXDOMAINS so they are not a replacement for an actual DNS Zone. 

Response policies can also be used in a couple of other ways as described here. A DNS zone with a name like example.com becomes responsible for the entire hierarchy beneath it. Response policy rules do not require a DNS zone to be created to modify the behavior of specific DNS names. Matching the response policy also happens before other processing, allowing other private DNS resources to be overridden. For instance if a dev network environment imports (via DNS Peering) a production DNS private zone, specific names can be “patched” to refer to dev endpoints without affecting the rest of the DNS zone. 

For instance:

  gcloud beta dns response-policies create dev-response-policy
    --networks=<URL to your Google Cloud network>
    --description="Response policy for dev"
gcloud beta dns response-policies rules create dev-server-rule
    --response-policy dev-response-policy
    --dns-name="*.dev.example.com"
    --local-data=name="*.dev.example.com.",type="A",ttl=3600,rrdatas="<dev server IP>"

In the snippet above, set up the response policy and attach it to your Cloud network. Then create the rule that serves up the development server IP for names that end in dev.example.com

A second example here allows you to block dangerous names on the Internet by redirecting them to an informational IP, without the overhead of managing potentially thousands of “stub” private DNS zones.

For instance:

  gcloud beta dns response-policies create blocklist-response-policy
    --networks=<URL to your Google Cloud network>
    --description="Response policy for blocking bad DNS names"
gcloud beta dns response-policies rules create block-list-rule
    --response-policy blocklist-response-policy
    --dns-name="bad.actor.com."
    --local-data=name="bad.actor.com.",type="A",ttl=3600,rrdatas="<IP of informational webserver, or invalid IP like 0.0.0.0>"

The snippet above first creates a response policy called ‘blocklist-response-policy’ that’s attached to your existing network/zone. It then creates a new rule that redirects all DNS requests for bad.actor.com to an informational webserver. 

Services without sacrificing security

Building rich applications cannot come at the cost of sacrificing security, especially in complex, multi-tenant environments. Cloud DNS response policies offer a new and flexible way to configure access to Google APIs.