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.

Tipping point?

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."

Long road

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."

In memoriam

RIP Dyn Dynamic DNS :'( Oracle to end Dyn-asty by axing freshly gobbled services, shoving customers into its cloud


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. ®

Broader topics

Other stories you might like

  • DigitalOcean sets sail for serverless seas with Functions feature
    Might be something for those who find AWS, Azure, GCP overly complex

    DigitalOcean dipped its toes in the serverless seas Tuesday with the launch of a Functions service it's positioning as a developer-friendly alternative to Amazon Web Services Lambda, Microsoft Azure Functions, and Google Cloud Functions.

    The platform enables developers to deploy blocks or snippets of code without concern for the underlying infrastructure, hence the name serverless. However, according to DigitalOcean Chief Product Officer Gabe Monroy, most serverless platforms are challenging to use and require developers to rewrite their apps for the new architecture. The ultimate goal being to structure, or restructure, an application into bits of code that only run when events occur, without having to provision servers and stand up and leave running a full stack.

    "Competing solutions are not doing a great job at meeting developers where they are with workloads that are already running today," Monroy told The Register.

    Continue reading
  • Patch now: Zoom chat messages can infect PCs, Macs, phones with malware
    Google Project Zero blows lid off bug involving that old chestnut: XML parsing

    Zoom has fixed a security flaw in its video-conferencing software that a miscreant could exploit with chat messages to potentially execute malicious code on a victim's device.

    The bug, tracked as CVE-2022-22787, received a CVSS severity score of 5.9 out of 10, making it a medium-severity vulnerability. It affects Zoom Client for Meetings running on Android, iOS, Linux, macOS and Windows systems before version 5.10.0, and users should download the latest version of the software to protect against this arbitrary remote-code-execution vulnerability.

    The upshot is that someone who can send you chat messages could cause your vulnerable Zoom client app to install malicious code, such as malware and spyware, from an arbitrary server. Exploiting this is a bit involved, so crooks may not jump on it, but you should still update your app.

    Continue reading
  • Google says it would release its photorealistic DALL-E 2 rival – but this AI is too prejudiced for you to use
    It has this weird habit of drawing stereotyped White people, team admit

    DALL·E 2 may have to cede its throne as the most impressive image-generating AI to Google, which has revealed its own text-to-image model called Imagen.

    Like OpenAI's DALL·E 2, Google's system outputs images of stuff based on written prompts from users. Ask it for a vulture flying off with a laptop in its claws and you'll perhaps get just that, all generated on the fly.

    A quick glance at Imagen's website shows off some of the pictures it's created (and Google has carefully curated), such as a blue jay perched on a pile of macarons, a robot couple enjoying wine in front of the Eiffel Tower, or Imagen's own name sprouting from a book. According to the team, "human raters exceedingly prefer Imagen over all other models in both image-text alignment and image fidelity," but they would say that, wouldn't they.

    Continue reading

Biting the hand that feeds IT © 1998–2022