Salesforce takes the multi-signer DNSSEC ball and runs with it
Extending DNS security protocol to multiple platforms takes root
A plan to expand the current DNSSEC security protocol to cover multiple DNS platforms has received the backing of Salesforce, with a first proof-of-concept implementation of the approach announced on Thursday.
Engineers from the CRM monster, and traffic management company NS1, claim to have a working REST API that allows them to pull in multiple public keys from different DNS providers and then sign and publish their own DNS records.
In other words, they have figured out a way to extend the somewhat rigid DNSSEC protocol to work more flexibly, and in particular to work with modern traffic management approaches such as geo-routing (where users are directed according to their physical location) and load balancing.
The companies claim this approach will remove one more barrier to widespread DNSSEC adoption by allowing companies to follow their existing traffic management approach while benefiting from the extra security that DNSSEC provides, such as limiting spoofing and cache-poisoning attacks.
The approach is being pushed by the Internet Engineering Task Force (IETF) and is currently on its third iteration. It is not a new standard per se, but rather a set of operational practices that will enable companies to work with different DNS providers' proprietary extensions without breaking DNSSEC. The idea is to present a workable solution that others can then follow.
"Multi-signer DNSSEC makes important strides in eliminating barriers to DNSSEC adoption by allowing for both redundancy and security without sacrificing the key proprietary features that ensure optimal performance," explained NS1 lead software engineer Jan Včelák.
"The strategy allows each DNS provider to use separate zone signing keys for the records they serve but all providers are required to agree on the total set of DNSSEC keys being used. This enables the successful validation of record authenticity between multiple DNS providers."
NS1 and Salesforce have worked with the open-source DNS system BIND to come up with a workable system. "Our REST API enables NS1 DNS to retrieve public keys used for signing and also allows publishing the final DNSKEY record set and its signatures,” Včelák explained.
"At the same time, we are building an open-source component that allows you to run NS1 and any common open-source DNS server (for example BIND) in the multi-signer DNSSEC configuration." He's written a longer blog post walking through the approach.
While it is certainly true that many companies use multiple DNS platforms – often as a backup to make sure they stay online if one provider fails – it's not clear how big a problem the lack of support for multiple DNS platform is for the broader adoption of DNSSEC.
Lead engineer at NS1 Shane Kerr told The Register that there are "companies that want to have multiple DNS vendors, to use advanced DNS features of each, and still provide DNSSEC-authenticated answers."
In that sense, this new approach "removes a show-stopper for organizations who want to adopt DNSSEC but did not feel that they could," he argues. He also notes it could be used by companies "who already use DNSSEC but want to use non-standard features of one or more of their DNS vendors that helps their business."
There are several companies like Cloudflare that already create dynamic DNS records, but Kerr says this approach is novel as it will be available for multiple platforms, "not just proprietary to a single vendor."
He's confident that it will pass IETF scrutiny, claiming that the idea has been received positively, especially since "it does not involve any protocol-level changes, and it solves a real problem."
He added: "We now have a proof-of-concept implementation in place. It may wait until a second implementation arrives, but that is not a requirement at the IETF. And since the document is clear and basically self-evident to DNSSEC experts, it seems unlikely that there will be any push-back."
Asked why NS1 and Saleforce are focusing on this approach, rather than pushing standards for things like load-balancing and geo-routing, Kerr notes: "Standardization takes a long time, and there is always a trade-off when standardizing in that it limits innovation. Even with standard approaches for advanced DNS features, there will always be a need for sharing signing responsibility for multiple DNS providers."
The DNSSEC protocol was first formally published back in 2005 but has had a painfully slow adoption. It got a boost in 2008 when security researcher Dan Kaminsky found a fundamental flaw in the DNS and recommended DNSSEC as the best available solution.
That led to the US government calling for the internet's root zone to be digitally signed by DNSSEC in 2009 but rollout still did not take off. In 2011, when the .com top-level domain finally got DNSSEC, everyone agreed we had hit a turning point. But we hadn't.
ICANN then required all new top-level domains to implement DNSSEC as part of the process before they could be added to the internet, and that prompted sufficient confidence in people that they started developing new secure protocols, like DANE, that worked on top of DNSSEC.
But take-up is still anemic thanks to the protocol's complexity and a perceived lack of urgency. Late last year, Cloudflare managed to get deployment down to a single click. Then in January this year, the US Department of Homeland Security put out an emergency directive telling everyone to get with the DNSSEC program as soon as possible thanks to a spate of new attacks on the DNS itself. The next month, DNS overseer ICANN did the same.
The bigger holdback
After all that, it's debatable whether the ability to use multiple DNS platforms is going to finally be the thing that tips people over into implementing DNSSEC. Besides, as several DNS experts told us, it's not the getting zones signed that is the biggest brake to widespread adoption of a more secure DNS; it's the validation of signed response.
The new approach pushed by Salesforce and NS1 would "remove an excuse for not signing zones" but without validation it's not going anywhere.
"DNSSEC is still too complicated for most non-specialist DNS operators to implement on-premises, even though the software tools (like BIND, PowerDNS and Knot) make it very easy sign the zones and keep them up to date," explained the chief innovation officer for registry CentralNic, Gavin Brown. "You still have to manually send your DS record information to the registry via the registrar, a process which is cumbersome and error-prone."
RIP Dyn Dynamic DNS :'( Oracle to end Dyn-asty by axing freshly gobbled services, shoving customers into its cloudREAD MORE
There is a protocol for automating the sending of records - which at the time was also hailed as lifting another barrier to DNSSEC - but that has also seen very low adoption.
Another DNS veteran told us "we saw that we would never get zones signed unless we start by getting all ISPs (including cell phone providers etc) to turn on validation. After validation was turned on, then it is easy to argue in favor of signing zones.
"In the US and elsewhere I have only seen discussions about signing the zones. I have tried and tried to get people that push for signed zones to instead push for validation to be turned on. But I have failed."
So while this new approach of making DNSSEC work with multiple platforms may work for some, and may just tip them over into implementation, it seems we still have a long way to go until a secure DNS become the norm. ®