security.googleblog.com Open in urlscan Pro
2a00:1450:4001:80f::2001  Public Scan

Form analysis
0 forms found in the DOM

Text Content

SECURITY BLOG

The latest news and insights from Google on security and safety on the Internet


GOOGLE PUBLIC DNS’S APPROACH TO FIGHT AGAINST CACHE POISONING ATTACKS

March 28, 2024
Tianhao Chi and Puneet Sood, Google Public DNS





The Domain Name System (DNS) is a fundamental protocol used on the Internet to
translate human-readable domain names (e.g., www.example.com) into numeric IP
addresses (e.g., 192.0.2.1) so that devices and servers can find and communicate
with each other. When a user enters a domain name in their browser, the DNS
resolver (e.g. Google Public DNS) locates the authoritative DNS nameservers for
the requested name, and queries one or more of them to obtain the IP address(es)
to return to the browser.

When DNS was launched in the early 1980s as a trusted, content-neutral
infrastructure, security was not yet a pressing concern, however, as the
Internet grew DNS became vulnerable to various attacks. In this post, we will
look at DNS cache poisoning attacks and how Google Public DNS addresses the
risks associated with them.


DNS CACHE POISONING ATTACKS

DNS lookups in most applications are forwarded to a caching resolver (which
could be local or an open resolver like. Google Public DNS). The path from a
client to the resolver is usually on a local network or can be protected using
encrypted transports like DoH, DoT. The resolver queries authoritative DNS
servers to obtain answers for user queries. This communication primarily occurs
over UDP, an insecure connectionless protocol, in which messages can be easily
spoofed including the source IP address. The content of DNS queries may be
sufficiently predictable that even an off-path attacker can, with enough effort,
forge responses that appear to be from the queried authoritative server. This
response will be cached if it matches the necessary fields and arrives before
the authentic response. This type of attack is called a cache poisoning attack,
which can cause great harm once successful. According to RFC 5452, the
probability of success is very high without protection. Forged DNS responses can
lead to denial of service, or may even compromise application security. For an
excellent introduction to cache poisoning attacks, please see “An Illustrated
Guide to the Kaminsky DNS Vulnerability”.


CACHE POISONING MITIGATIONS IN GOOGLE PUBLIC DNS

Improving DNS security has been a goal of Google Public DNS since our launch in
2009. We take a multi-pronged approach to protect users against DNS
cache-poisoning attacks. There is no silver bullet or countermeasure that
entirely solves the problem, but in combination they make successful attacks
substantially more difficult.







RFC 5452 AND DNS COOKIES

We have implemented the basic countermeasures outlined in RFC 5452 namely
randomizing query source ports and query IDs. But these measures alone are not
sufficient (see page 8 of our OARC 38 presentation).

We have therefore also implemented support for RFC 7873 (DNS Cookies) which can
make spoofing impractical if it’s supported by the authoritative server.
Measurements indicate that the DNS Cookies do not provide sufficient coverage,
even though around 40% of nameservers by IP support DNS Cookies, these account
for less than 10% of overall query volume. In addition, many non-compliant
nameservers return incorrect or ambiguous responses for queries with DNS
Cookies, which creates further deployment obstacles. For now, we’ve enabled DNS
Cookies through manual configuration, primarily for selected TLD zones.


CASE RANDOMIZATION (0X20)

The query name case randomization mechanism, originally proposed in a March 2008
draft “Use of Bit 0x20 in DNS Labels to Improve Transaction Identity”, however,
is highly effective, because all but a small minority of nameservers are
compatible with query name case randomization. We have been performing case
randomization of query names since 2009 to a small set of chosen nameservers
that handle only a minority of our query volume. 

In 2022 we started work on enabling case randomization by default, which when
used, the query name in the question section is randomized and the DNS server’s
response is expected to match the case-randomized query name exactly in the
request. 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 (and retried over TCP).

We are happy to announce that we’ve already enabled and deployed this feature
globally by default. It covers over 90% of our UDP traffic to nameservers,
significantly reducing the risk of cache poisoning attacks.

Meanwhile, we maintain an exception list and implement fallback mechanisms to
prevent potential issues with non-conformant nameservers. However we strongly
recommend that nameserver implementations preserve the query case in the
response.


DNS-OVER-TLS

In addition to case randomization, we’ve deployed DNS-over-TLS to authoritative
nameservers (ADoT), following procedures described in RFC 9539 (Unilateral
Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS). Real
world measurements show that ADoT has a higher success rate and comparable
latency to UDP. And ADoT is in use for around 6% of egress traffic. At the cost
of some CPU and memory, we get both security and privacy for nameserver queries
without DNS compliance issues.


SUMMARY

Google Public DNS takes security of our users seriously. Through multiple
countermeasures to cache poisoning attacks, we aim to provide a more secure and
reliable DNS resolution service, enhancing the overall Internet experience for
users worldwide. With the measures described above we are able to provide
protection against passive attacks for over 90% of authoritative queries.




To enhance DNS security, we recommend that DNS server operators support one or
more of the  security mechanisms described here. We are also working with the
DNS community to improve DNS security. Please see our presentations at DNS-OARC
38 and 40 for more technical details.



Google


NO COMMENTS :



Post a Comment


  



LABELS


 * #sharethemicincyber
 * #supplychain #security #opensource
 * android
 * android security
 * android tr
 * app security
 * big data
 * biometrics
 * blackhat
 * C++
 * chrome
 * chrome enterprise
 * chrome security
 * connected devices
 * CTF
 * diversity
 * encryption
 * federated learning
 * fuzzing
 * Gboard
 * google play
 * google play protect
 * hacking
 * interoperability
 * iot security
 * kubernetes
 * linux kernel
 * memory safety
 * Open Source
 * pha family highlights
 * pixel
 * privacy
 * private compute core
 * Rowhammer
 * rust
 * Security
 * security rewards program
 * sigstore
 * spyware
 * supply chain
 * targeted spyware
 * tensor
 * Titan M2
 * VDP
 * vulnerabilities
 * workshop





ARCHIVE


 *     2024
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      

 *     2023
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2022
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2021
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2020
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2019
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2018
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2017
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2016
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2015
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2014
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2013
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Aug
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2012
    * Jan
      
   
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Aug
      
   
    * Sep
      
   
    * Dec
      

 *     2011
    * Feb
      
   
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2010
    * Mar
      
   
    * Apr
      
   
    * May
      
   
    * Jul
      
   
    * Aug
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      

 *     2009
    * Mar
      
   
    * Jun
      
   
    * Jul
      
   
    * Aug
      
   
    * Oct
      
   
    * Nov
      

 *     2008
    * Feb
      
   
    * May
      
   
    * Jul
      
   
    * Aug
      
   
    * Oct
      
   
    * Nov
      
   
    * Dec
      

 *     2007
    * May
      
   
    * Jun
      
   
    * Jul
      
   
    * Sep
      
   
    * Oct
      
   
    * Nov
      




FEED


Follow @google
Follow

Give us feedback in our Product Forums.


 * Google
 * Privacy
 * Terms

Diese Website verwendet Cookies von Google, um Dienste anzubieten und Zugriffe
zu analysieren. Deine IP-Adresse und dein User-Agent werden zusammen mit
Messwerten zur Leistung und Sicherheit für Google freigegeben. So können
Nutzungsstatistiken generiert, Missbrauchsfälle erkannt und behoben und die
Qualität des Dienstes gewährleistet werden.Weitere InformationenOk