Govt mandate aids DNSSEC uptake

Registrar reluctance to sign keys and lack of government as well as peer pressure are some factors why enterprises are not paying due attention to DNSSEC adoption, experts say.
Written by Tyler Thia, Contributor
A clarification was made to this story. Read below for details.

Domain Name System Security Extensions (DNSSEC) are not widely adopted for a variety of reasons, such as lack of cooperation from registrars and lack of pressure from governments to ensure that the industry adopts the more secure protocol, experts said.

Akamai's chief security officer Andy Ellis told ZDNet Asia in interview that registrars have not "made it easy" for end users to integrate DNSSEC as they are not prepared to do any signing of the public keys required for the authentication of requests.

"Without signings from the root all the way down to domain name, DNSSEC is mostly useless. So that's the first problem--as an infrastructure we haven't really stood up and said DNSSEC is important and we're committed to make it work," Ellis explained.

DNSSEC introduces security at the infrastructure level, encrypting DNS records using cryptographic signatures. The protocol has been established for years, but came into the spotlight again three years ago when security researcher Dan Kaminsky identified a fundamental flaw in the DNS. At that time, Cambridge University security expert Richard Clayton said the use of the encrypted protocol is one way to mediate the security loophole.

Another challenge stems from the client resolver issue, where most users are still relying on Internet service providers (ISPs) to authenticate the keys. Ellis said most of the attacks against domain name servers happen between the client and the ISP, which is "not secured in most cases today".

"Until the client browsers are actually pushing DNS, I think a lot of companies will look at that and say that's not an interesting problem to solve."

Cost is also a hindrance to widespread adoption of DNSSEC. Ellis said that because DNS is the "ugly part" of the system that does not earn revenue for businesses, IT departments are not compelled to spend money to improve the systems. Organizations are "happy" as long as the systems are running, he noted.

However, Nigel Houghton, head mentalist of Sourcefire's SF VRT Department of Intelligence Excellence, told ZDNet Asia in an e-mail that other issues such as ownership of top-level domain root keys and the misnomer that DNSSEC is difficult to deploy outweigh cost concerns.

He singled out "zone enumeration" as another concern, as DNSSEC requires a list of names in a zone be disclosed, which run contrary to typical DNS security best practices.

"The workaround for this was to implement a split-horizon DNS structure when using DNSSEC. This makes the implementation somewhat more cumbersome and leads to the 'it's difficult to deploy' idea," Houghton said.

Govt regulation necessary
Akamai, said Ellis, noticed the lack of motivation in getting authentication keys signed, and decided to plug the gap by introducing a service where they take over the signing, just so that corporate entities can comply with the government mandate, if any.

The U.S. government, for instance, has "mandated" that organizations hosting .gov domains have to turn on DNSSEC, but only a handful are "doing the signings" of authentication keys, he revealed.

Ellis attributed this reluctance to operational challenge--IT departments are "not used" to handling key authorization, and will differ that for as long as possible.

Unfortunately, these signing of keys can be delayed, and even halted with no significant consequences, hence there is little motivation or push factor for companies or agencies to act, unless they are pressured to do so, he said.

"I think you will have people who will wait until the very end [to turn on DNSSEC]," Ellis noted. "Why should they incur [implementation] cost until it is absolutely necessary?".

Pressure has to come from governments, Ellis stated, explaining this would be similar to what the United States has initiated. For example, Singapore can issue a ruling that requires all businesses who wish to host on .sg to adopt DNSSEC, otherwise the domain may be revoked.

Realistically, however, it would take a couple of years before such a development can actually take place, he said.

Chester Wisniewski, senior security advisor at Sophos, suggested in an e-mail that the best way to encourage the adoption of DNSSEC is to put in an expiry date after which the client's name becomes "parked". This means that domain names would stop resolving, or cease to work, until the problem is fixed.

But while such a measure would pressure those "who simply 'don't care' that the rest of us do care and we need everyone to participate to succeed", he doubted it would be adopted.

"The cost of [DNSSEC] implementation is insignificant and if large domain name server providers like GoDaddy.com and Verisign were to offer hosted name servers that include DNSSEC by default, it would help jumpstart the transition," Wsiniewski noted.

No viable alternatives to DNSSEC
When quizzed on the alternatives to DNSSEC, Akamai's Ellis noted that "DNSCurve" had been proposed by mathematician and professor Daniel J. Bernstein. It uses techniques from elliptic curve cryptography to give a vast decrease in computational time over the RSA public-key algorithm used by DNSSEC, and uses the existing DNS hierarchy to propagate trust by embedding public keys into specially formatted DNS records.

The problem with the technique, however, is that it did not "support some interesting things which are needed", and does not allow bit caching, which means it is unable to provide good protection against attacks, said Ellis. Also, the DNSCurve would be inefficient in shielding the wide array of domain records emerging from the adoption of IPv6, he added.

According to Wisniewski, there are no alternatives to addressing insecurities in the DNS system. Users of open iFi systems, he warned, are likely to suffer the greatest risk of getting "infected" should a network be compromised.

Sourcefire's Houghton also reiterated: " Since DNS is a core requirement, there is no feasible alternative other than securing DNS [itself]."

Clarification: Sourcefire has clarified that its comments should be attributed to Nigel Houghton, head mentalist of the company's SF VRT Department of Intelligence Excellence. The article has been updated.
Editorial standards