Performing a signing algorithm rollover is not for the faint of heart

/in , /by

[vc_row][vc_column width=”2/3″][vc_column_text]We are proud of our DNSSEC heritage here at Secure64. We launched the first fully automated DNSSEC signing appliance in 2008, just weeks after security researcher Dan Kaminsky made public the flaws in the DNS protocol that DNSSEC addresses. Our goal from the very beginning was to make deploying DNSSEC simple and secure. And we are now fortunate to be trusted by many organizations including top level domains, regional internet registries, government agencies and communication service providers to secure their DNS infrastructure with DNSSEC.

So when our friends at RIPE approached us for help in performing an algorithm rollover, we jumped right in. RIPE uses our DNS Signer product to sign the reverse zones that they manage. Like other early adopters of DNSSEC, RIPE had been signing their zones for many years with the RSA SHA1 algorithm. However, this algorithm had recently been found to be insufficiently strong, and RIPE wanted to transition to the stronger RSA SHA2 algorithm.

But changing a signing algorithm without breaking the chain of trust that DNSSEC relies upon is not for the faint of heart. It is extremely complicated, as it requires signing the zones with two different algorithms, waiting for a critical period of time, publishing the second signing key, waiting again, and finally removing the old signing key from the parent zone. And if any one step is performed incorrectly, your domain could be wiped off the internet. Ouch.

At the time, our DNS Signer product was able to sign a zone with a single algorithm, but not with two, which is what is required to roll an algorithm without breaking the critical chain of trust. Our development team worked closely with RIPE throughout their well designed test process to ensure that the rollover would be successfully completed. And we all learned some important lessons on best practices when we hit an unexpected snag with other validating resolvers during testing that had to be worked through.

But thanks to RIPE’s pioneering efforts, Secure64 Signer customers can now roll their signing algorithms with confidence.[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_single_image image=”2540″ img_size=”500×700″ alignment=”center”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]

You can read more about RIPE’s experience with algorithm rollover at:

DNS Rollover

[/vc_column_text][/vc_column][/vc_row]

Developing a Framework to Improve Critical Infrastructure Cybersecurity

/in , , , /by

Here are thoughts from our CTO, Bill Worley PhD, on properly securing critical infrastructure in our highly connected world. They are particularly applicable with what we have seen in the last year with increased DDoS attacks focused on the DNS and compromised systems for the theft of intellectual property. Read more

DNSSEC Adoption is Slow for Government Agencies

/in , , , /by

Even though more than two years have passed since federal government agencies were required to support DNS Security Extensions (DNSSEC) on their web sites, only 57 percent of agencies have met these requirements. In other words, about 40 percent of federal agencies have not secured their domains to protect users from domain name hijacking and cache poisoning attacks.

As this Network World article explains, Read more

Google Now Supports DNSSEC

/in /by

Google announced this week that they have enabled Domain Name System Security Extensions (DNSSEC). This is essential for ensuring that DNS queries are directed to the real web site. With this in place Google is now checking the digital signatures on DNSSEC formatted messages. Currently 7% of the volume of all the queries Google handles use DNSSEC and the volume is expected to grow as more and more organizations implement DNSSEC to secure traffic to their sites. 

Without DNSSEC it is possible to hijack traffic from an internet resolver by fooling it to store a false IP Address in place of the real one. This is called cache poisoning. Requests directed to a site after the poisoning are instead directed to a fake site. Not a good thing if I am buying something or think I’m going to my bank or mortgage company.

Domain Name System Security Extensions is a set of IETF (Internet Engineering Task Force) standards outlined in RFCs 4033, 4034, and 4035. Its purpose is to create a way to verify the information that is stored on the thousands of DNS Resolvers around the world. With DNSSEC, Internet users can know with certainty that the DNS response received is the DNS response that was sent by the intended site, and it has not been altered in transit. DNSSEC eliminates threats from cache poisoning and pharming attacks. Without it, there is a much higher risk of fraud, loss of confidentiality, and identity theft. DNSSEC deployment is critical for financial institutions, government agencies, and security-conscious enterprises doing business on the Internet or securing internal networks. 

DNSSEC protects DNS clients (such as web browsers and mail clients) from forged DNS data. If an attacker attempts to alter any part of the DNS resolution process, then a DNSSEC aware client can detect the altered response. This allows the DNSSEC aware client to detect with certainty when this has happened. Not all browsers are DNSSEC aware. Chrome has supported this since version 14. On other browsers, an extension must be added to support DNSSEC. Some browser don’t yet support DNSSEC. 

ICANN tracks the implementation of DNSSEC by Top Level Domain (TLD) (ie .com or .org…) and reports that information on their site. They also have a great map that shows which countries have enabled DNSSEC on their country TLDs. 

Secure64 was the first company to offer a commercial application to support DNSSEC. We can assist in getting set up quickly to protect the traffic to crucial sites. For more information in implemented DNSSEC please visit our site.

DNSSEC Deployment Lags

/in , , , /by

DNSSEC has been slow to be accepted by commercial sites, leading a lag in DNSSEC deployment, even though it is the best solution to prevent the exposure to site hijacking. This type of hijacking is possible because of a major flaw in DNS that makes it possible for hackers to launch cache poisoning, found by security researcher Dan Kaminsky 5 years ago. Read more

Lack of DNSSEC Deployment on Financial Services Web Sites

/in , , , /by

It comes as a real surprise that one of the industries (financial services) that should be most interested in the security of their web sites has not implemented a key piece of protection, Domain Name System Security Extensions (DNSSEC). DNSSEC is a technology that was developed to add critically needed security to the domain name system. Without DNSSEC, internet users cannot be certain that they Read more

Four Vulnerabilities in Infrastructure Defense

/in , , , /by

“The basic underpinnings of the Internet — BGP, DNS, and SSL — we take for granted they were built in much friendlier times when friendly people wanted to communicate with friendly people. The Internet was built to be survivable, not trustable,” said John Pescatore, vice president and research fellow for Gartner Research. This quote was sited in an article in Darkreading by Kelly Jackson Higgins. Read more

DNS Diversity

/in , , , /by

Every DNS administrator knows that you need to configure at least two recursive or authoritative DNS servers so that you can still provide service in case one fails. Many administrators also know that these servers ideally should be located in different data centers and utilize different networks so that DNS service will not be interrupted in the event of a data center or network outage. Read more

FCC Recommends Code of Conduct for ISPs

/in , , , /by

In an earlier blog we mentioned the recommendations made by the CSRIC (Communications Security, Reliability and Interoperability Council), a Federal Advisory Committee for the Federal Communications Commission (FCC), to improve Internet safety. This is a set of industry-wide best practices for ISPs and other organizations that operate critical infrastructure. The voluntary best practices outlined in the recommendations are designed to address three main cyber-security issues facing commercial networks and the Internet: Read more

DNSSEC Adoption is Slow for Government Agencies

/in /by

Even though more than two years have passed since federal government agencies were required to support DNS Security Extensions (DNSSEC) on their web sites, only 57 percent of agencies have met these requirements. In other words, about 40 percent of federal agencies have not secured their domains to protect users from domain name hijacking and cache poisoning attacks. Read more