This is a cache of https://security.googleblog.com/2013/03/. It is a snapshot of the page as it appeared on 2025-08-19T16:21:19.273+0200.
Google Online Security Blog: March 2013
Security Blog
The latest news and insights from Google on security and safety on the Internet
Google Public DNS Now Supports DNSSEC Validation
March 19, 2013
Posted by Yunhong Gu, Team Lead, Google Public DNS
We
launched
Google Public DNS three years ago to help make the Internet faster and more secure. Today, we are taking a major step towards this security goal: we now fully support DNSSEC (
Domain Name System Security Extensions
) validation on our Google Public DNS resolvers. Previously, we accepted and forwarded DNSSEC-formatted messages but did not perform validation. With this new security feature, we can better protect people from DNS-based attacks and make DNS more secure overall by identifying and rejecting invalid responses from DNSSEC-protected domains.
DNS translates human-readable domain names into IP addresses so that they are accessible by computers. Despite its critical role in Internet applications, the lack of security protection for DNS up to this point meant that a significantly large portion of today’s Internet attacks target the name resolution process, attempting to return the IP addresses of malicious websites to DNS queries. Probably the most common DNS attack is
DNS cache poisoning
, which tries to “pollute” the cache of DNS resolvers (such as Google Public DNS or those provided by most ISPs) by injecting spoofed responses to upstream DNS queries.
To counter cache poisoning attacks, resolvers must be able to verify the authenticity of the response. DNSSEC solves the problem by authenticating DNS responses using digital signatures and public key cryptography. Each DNS zone maintains a set of private/public key pairs, and for each DNS record, a unique digital signature is generated and encrypted using the private key. The corresponding public key is then authenticated via a chain of trust by keys of upper-level zones. DNSSEC effectively prevents response tampering because in practice, signatures are almost impossible to forge without access to private keys. Also, the resolvers will reject responses without correct signatures.
DNSSEC is a critical step towards securing the Internet. By validating data origin and data integrity, DNSSEC complements other Internet security mechanisms, such as SSL. It is worth noting that although we have used web access in the examples above, DNS infrastructure is widely used in many other Internet applications, including email.
Currently Google Public DNS is serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day. However, only 7% of queries from the client side are DNSSEC-enabled (about 3% requesting validation and 4% requesting DNSSEC data but no validation) and about 1% of DNS responses from the name server side are signed. Overall, DNSSEC is still at an early stage and we hope that our support will help expedite its deployment.
Effective deployment of DNSSEC requires action from both DNS resolvers and authoritative name servers. Resolvers, especially those of ISPs and other public resolvers, need to start validating DNS responses. Meanwhile, domain owners have to sign their domains. Today, about 1/3 of top-level domains have been signed, but most second-level domains remain unsigned. We encourage all involved parties to push DNSSEC deployment and further protect Internet users from DNS-based network intrusions.
For more information about Google Public DNS, please visit:
https://developers.google.com/speed/public-dns
. In particular, more details about our DNSSEC support can be found in the
FAQ
and
Security
pages. Additionally, general specifications of the DNSSEC standard can be found in RFCs
4033
,
4034
,
4035
, and
5155
.
Update
March 21
: We've been listening to your questions and would like to clarify that validation is not yet enabled for non-DNSSEC aware clients. As a first step, we launched DNSSEC validation as an opt-in feature and will only perform validation if clients explicitly request it. We're going to work to minimize the impact of any DNSSEC misconfigurations that could cause connection breakages before we enable validation by default for all clients that have not explicitly opted out.
Update
May 6
: We've enabled DNSSEC validation by default. That means all clients are now protected and responses to all queries will be validated unless clients explicitly opt out.
Videos and articles for hacked site recovery
March 12, 2013
Posted by
Maile Ohye
, Developer Programs Tech Lead
We created a new
Help for hacked sites
informational series to help all levels of site owners understand how they can recover their hacked site. The series includes over a dozen articles and 80+ minutes of informational videos—from the basics of what it means for a site to be hacked to diagnosing specific malware infection types.
“Help for hacked sites” overview: How and why a site is hacked
Over 25% of sites that are hacked may remain compromised
In StopBadware and Commtouch’s 2012
survey of more than 600 webmasters of hacked sites
, 26% of site owners reported that their site was still compromised while 2% completely abandoned their site. We hope that by adding our educational resources to the great tools and information already available from the security community, more hacked sites can restore their unique content and make it safely available to users. The fact remains, however, that the process to recovery requires fairly advanced system administrator skills and knowledge of source code. Without help from others—perhaps their hoster or a trusted expert—many site owners may still struggle to recover.
StopBadware and Commtouch’s 2012 survey results for “What action did you take/are you taking to fix the compromised site?”
Hackers’ tactics are difficult for site owners to detect
Cybercriminals employ various tricks to avoid the site owner’s detection, making recovery difficult for the average site owner. One technique is adding “hidden text” to the site’s page so users don’t see the damage, but search engines still process the content. Often the case for sites hacked with spam, hackers abuse a good site to help their site (commonly pharmaceutical or poker sites) rank in search results.
Both pages are the same, but the page on the right highlights the “hidden text”—in this case, white text on a white background. As explained in
Step 5: Assess the damage (hacked with spam)
, hackers employ these types of tricks to avoid human detection.
In cases of sites hacked to distribute malware, Google provides verified site owners with a sample of infected URLs, often with their malware infection type, such as
Server configuration
(using the server’s configuration file to redirect users to malicious content). In
Help for hacked sites
, Lucas Ballard, a software engineer on our Safe Browsing team, explains how to locate and clean this malware infection type.
Lucas Ballard covers the malware infection type
Server configuration
.
Reminder to keep your site secure
I realize that reminding you to keep your site secure is a bit like my mother yelling “don’t forget to bring a coat!” as I leave her sunny California residence. Like my mother, I can’t help myself. Please remember to:
Be vigilant about keeping software updated
Understand the security practices of all applications, plugins, third-party software, etc., before you install them on your server
Remove unnecessary or unused software
Enforce creation of strong passwords
Keep all devices used to log in to your web server secure (updated operating system and browser)
Make regular, automated backups
Labels
#sharethemicincyber
#supplychain #security #opensource
AI Security
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
2025
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2024
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Aug
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2010
Nov
Oct
Sep
Aug
Jul
May
Apr
Mar
2009
Nov
Oct
Aug
Jul
Jun
Mar
2008
Dec
Nov
Oct
Aug
Jul
May
Feb
2007
Nov
Oct
Sep
Jul
Jun
May
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow