Google Cloud | Networking

New Cloud DNS Response Policies Simplify Access To Google APIs

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 and aren’t accessible within the VPC SC perimeter. In addition, configuring access to 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 * 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 * containing the CNAME. You can then exempt unsupported names (like 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
    --network=<URL to your Google Cloud network>
    --description=”Response policy for VPC service controls”
gcloud beta dns response-policy-rules create googleapis-localdata
    --response-policy vpc-sc-response-policy
gcloud beta dns response-policy-rules create googleapis-wws-passthru
    --response-policy vpc-sc-response-policy

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 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
    --description=”Response policy for dev”
gcloud beta dns response-policy-rules create dev-server-rule
    --response-policy dev-response-policy
    --data=”<dev server IP>”

In the snippet above, set up the response policy and attach it to your DNS Zone. Then create the rule that serves up the development server IP for names that end in

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
    --network=<URL to your Google Cloud network>
    --description=”Response policy for blocking bad DNS names”
gcloud beta dns response-policy-rules create block-list-rule
    --response-policy blocklist-response-policy
    --data=”<IP of informational webserver, or invalid IP like>”

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 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.

By Karthik Balakrishnan(Product Manager) and Robert Mead(Software Engineer)
Source: Google Cloud Blog

For enquiries, product placements, sponsorships, and collaborations, connect with us at We'd love to hear from you!

Our humans need coffee too! Your support is highly appreciated, thank you!

Previous Article

Respond To Customers Faster And More Accurately With Dialogflow CX

Next Article
Google Cloud | Transaction Flow

Retailers Find Flexible Demand Forecasting Models In BigQuery ML

Related Posts