Starting January 5, 2027, CNAME chasing behavior will change so that Cloud DNS

## Announcement Announcement Starting January 5, 2027, CNAME chasing behavior will change so that Cloud DNS follows CNAME chains between public and private zones. If your private zones or response policies have overlapping domain names with public CNAME targets, queries might resolve to unintended internal IP addresses or return resolution errors. The following table outlines the current and updated behaviors. | Source of CNAME answer | Current behavior (until January 5, 2027) | New behavior (starting January 5, 2027) | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cloud DNS public zone | Subsequent queries search only public DNS zones and internal DNS. Private zones, forwarding zones, and response policies are ignored. | Subsequent queries follow the complete VPC name resolution order: response policies, private zones, forwarding or peering zones, internal DNS, and public zones. | | Cloud DNS private zone | Subsequent queries search only authorized private zones. Public DNS zones are ignored. | Subsequent queries follow the complete VPC name resolution order. If the target isn't found in authorized private zones, Cloud DNS queries public DNS zones. | | Cloud DNS response policy zone | Cloud DNS systems don't perform queries for CNAME answers received from response policy local data rules. | Subsequent queries follow the complete VPC name resolution order. If the target isn't found in response policies or private zones, Cloud DNS queries public DNS zones. | Review your CNAME chasing needs before January 5, 2027\. Test your DNS query paths using `dig` or `nslookup` to identify CNAME chasing scenarios. * **Look for private-to-public CNAME chasing scenarios**: Look for CNAME answers from response policies or private zones that don't match any response policy or record in a private zone. Previously, these queries resulted in a `NXDOMAIN`answer but after January 5, 2027, these scenarios might match a record in a public zone or continue to be `NXDOMAIN` responses. * **Look for public-to-private CNAME chasing scenarios**: Look for CNAME answers from public zones that don't match any record in a public zone. Previously, these CNAME chasing scenarios would have resulted in a `NXDOMAIN` response. After January 5, 2027, these scenarios might match a response policy or record in a private zone or continue to be `NXDOMAIN` responses if the private zone doesn't have the record. * **For CNAME chasing scenarios under your control**: As best practice, configure matching time-to-live (TTL) values for all records in the CNAME chain. ## Announcement Announcement Starting January 5, 2027, Cloud DNS will disable full responses to DNS queries of type `ANY` (`QTYPE=ANY`) in [public authoritative zones](https://cloud.google.com/dns/docs/zones/zones-overview). Instead, a single resource record will return for `ANY` queries, chosen from the existing resource record sets that match the query. Standard traffic from web browsers, applications, and API traffic query specific record types directly and are therefore unaffected with no action required. However, certain legacy scripts, automated health checkers, debugging commands (for example, `dig example.com ANY`), or custom third-party monitoring systems that explicitly query `ANY` records will receive the first available record instead of a full zone inventory. You must complete the following configuration updates before January 5, 2027: * **Identify legacy queries**: Review internal tools, deployment scripts, or third-party DNS monitoring configurations for commands or API calls that request the `ANY` record type. Cloud DNS logs in Cloud Logging can be helpful with this. * **Transition to specific queries**: Update the tools to query the specific, individual record types they require (for example, querying for `A`,`AAAA`, `MX`, or `TXT` records separately). * **Retrieve full zone records**: If you use `ANY` queries to retrieve all records in a zone, use the Cloud DNS REST API (`resourceRecordSets.list`), the gcloud CLI (`gcloud dns record-sets list`), or the Google Cloud Console instead. Risks associated with not making these changes include the following: * **False monitoring alarms**: Automated uptime or DNS monitoring tools checking`ANY` responses may misinterpret the new response as a system failure and trigger false alerts. * **Broken automation pipelines**: Internal deployment or CI/CD scripts that rely on parsing a full zone dump with an `ANY` query will fail to retrieve the expected data payload and may crash. * **Disrupted IT diagnostics**: Network administrators running manual legacy troubleshooting commands will no longer see a quick summary of all domain records, which could delay active network incident diagnostics.