Dear users and nameserver operators,
As part of our efforts to increase DNS cache poisoning protection for UDP queries, we are planning to enable case randomization of DNS query names sent to most authoritative nameservers (see our security page description of the feature and https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00). We have been performing case randomization of query names since 2009 to a small set of chosen nameservers. This set of servers handled a minority of our query volume, so a year ago we started work on enabling case randomization by default. As part of this, we’ve identified a small set of nameservers (< 1000 distinct IPs) that do not handle case randomization correctly and have exempted these from case randomization. We are confident that case randomization will work without introducing significant increases in DNS query volume or resolution failures.
The case-randomized query name in the request will be expected to exactly match the name in the question section of the DNS server’s reply, including the case of each ASCII letter (A–Z and a–z). For example, if “ExaMplE.CoM” is the name sent in the request, the name in the question section of the response must also be “ExaMplE.CoM” rather than, e.g., “example.com.” Responses that fail to preserve the case of the query name may be dropped as potential cache poisoning attacks. Thus, nameservers that fail to preserve the query name in their response, or whose response to case-randomized requests is an unexpected error (SERVFAIL, NOTIMP, FORMERR, etc.) or a failure to respond, will negatively impact users' ability to resolve names in the domains they serve.
Generally, when nameservers mishandle case-randomized queries, we recommend asking the nameserver operator to correct their behavior. While our exception list will work around the problem for now, it may not get immediate updates for newly broken name servers.
We’ll have case randomization enabled in one or two regions starting on August 29th and enabled globally by the end of October. Meanwhile, we’ve already turned off case randomization to nameservers that we’ve identified as not handling it correctly.
If you believe you have discovered name resolution failures with Google Public DNS due to case randomization, please file a bug in our issue tracker referencing this announcement.Let us know if there's any question via https://developers.google.com/speed/public-dns/groups.
- In at least a few cases I have seen operators of recursive servers configure global forwarding to Google and a.n.other rather than just letting the box recurse for itself. They shouldn't, but they do.
- Many corporate authoritative (and other) implementations make use of devices for DNS-based load balancing that are not fully RFC-compliant and likely won't handle rANdOmiSEd case well. Sometimes they are the same people as in point 1). Asking these device vendors to "fix it" usually falls on deaf ears.
One compelling argument for any delay might be the lack of a convenient test function for domain owners to understand whether they might be affected. However, I was happy to discover that such a test function already exists: https://unboundtest.com/. I have no idea who is responsible for that website, but they deserve thanks (and potentially support from Google for running that service, as they may start getting a lot more traffic in the next few weeks). At any rate, if you can resolve a domain name on that website's form, Google Public DNS' ability to resolve that domain name should be unaffected by the use of case randomization.
As we previously announced, Google Public DNS [https://developers.google.com/speed/public-dns] is in the process of enabling case randomization of DNS query names sent to authoritative nameservers. We have successfully deployed it in some regions in North America, Europe and Asia protecting the majority (90%) of DNS queries in those regions not covered by DNS over TLS.
We are still deploying this feature incrementally, location by location. This is slower than originally planned because of the carefulness and our estimate of global enabling is around March to April 2023. Meanwhile, we are monitoring nameserver compliance and actively maintaining an exception list that disables case randomization for observed non-supporting nameservers. While our exception list avoids issues with the majority of the problem servers for now, it may not get immediate updates for newly broken nameservers in the future. We strongly recommend that nameservers preserve the query case in the response or support TCP (as we retry over TCP if case randomization fails) as a fallback.
One subtle issue we’ve seen is that some servers exhibit sporadic case-randomization non-compliance for the same query parameters. They may appear to have a short-term response cache that can “replay” answers to previous or concurrent (differently) case-randomized queries.If you believe you have discovered name resolution failures with Google Public DNS due to case randomization, please file a bug in our issue tracker [https://developers.google.com/speed/public-dns/groups#issue_tracker]. Let us know if there's any question via https://developers.google.com/speed/public-dns/groups.