5月 192014

Everyone in the DNS community agrees that DNS’s security model is woefully outdated. Conceived at a time when there were fewer computers on the Internet than are housed by even today’s smallest data centers, DNS unfortunately has no strong protection against malicious parties hoping to exploit web users. What little protection it does offer is mostly derived from novel uses of non-security features (e.g., UDP source port and transaction ID randomization).

For more than 15 years, the IETF has been working on DNSSEC, a set of extensions to apply digital signatures to DNS. Millions of dollars in government grants and several reboots from scratch later, DNSSEC is just starting to see real world testing. And that testing is minimal — only about 400 of the more than 85,000,000 .com domains support DNSSEC, fewer than 20% of US government agencies met their mandated December 31, 2009 deadline for DNSSEC deployment, and only two of the thirteen root zone name servers is testing with even dummy DNSSEC data.

Aside from its lack of adoption, DNSSEC isn’t even a very satisfactory solution. It adds tremendous complexity to an already fragile protocol, significantly increases DNS traffic in size, encourages questionable security practices, and hamstrings many modern uses of DNS.


Continue reading »

5月 192014

DNSCurve is more like TLS for DNS servers, in comparison to DNSSEC, which is signed records. DNSCurve uses point-to-point cryptography to secure communication, while DNSSEC uses pre-calculated signatures to ensure the accuracy of the supplied records.

So we can summaraize it like this:
DNSSEC: Accurate Results
DNSCurve: Encrypted Traffic

Theoretically you can use traffic encryption to ensure accuracy, the way TLS does for websites. Except that it’s not really the encryption that’s ensuring your accuracy, is the authentication provided through the PKI. And there’s a set of critical problems with the basic DNSCurve PKI.

The first problem here is that with DNSCurve, each and every DNS server involved needs a private key, and since the key signature is encoded into the resolver’s address, then in the case of anycast DNS servers, each server needs the same private key. But even if they use different keys, you’re still trusting the local security where the DNS Server is installed. If the server is installed somewhere hostile, then the results can be compromised. This is not true with DNSSEC.

ICANN has stated that, in the case of the DNS Root zone servers, DNSCurve will not be implemented, ever. Many of the root servers operate in less-trusted locations, and the potential for abuse by local governments would be enormous. This is precisely why DNSSEC was designed such that signing happens outside the DNS server. DNS relies on a vast network of server which may not be individually trustworthy, so DNSSEC was designed such that the trust is based solely on the informationthey serve, not the honesty of the operator.

The second problem is that DNSCurve secures the public key by encoding it into the resolver name. But DNSSEC does not sign the resolver name. This means that DNSSEC (which is implemented in the root zone) cannot be used as a trust root for DNSCurve, because the one thing that DNSCurve requires to be accurate is in fact the very thing for which DNSSEC cannot ensure accuracy.

So essentially DNSCurve is pretty much a non-starter. While it can be used to guarantee the security of your communication with a single DNS resolver, there currently is no way of globally anchoring your trust in a way that could guarantee the accuracy of any results you retrieve.

Unless DNSCurve is re-designed to allow for trusted key distribution, it will have to remain a client-side security tool rather than a tool for ensuring the authenticity of DNS records.

Since DNSCurve is relatively new and was developed largely by djb in isolation, presumably these show-stopping issues were simple oversights on his part, and may be fixed at some future date. Though given Dr. Bernstein’s track record of maintaining his inventions, I wouldn’t hold my breath.

4月 212013

http://www.opendns.com/technology/dnscrypt/ 和 http://dnscrypt.org/

1. 获得trust anchor
trust anchor和根证书的意思类似。unbound-anchor 可以创建和更新 trust anchor。用下面的命令来下载和立即检查trust anchor的完整性,这个检查是使用 unbound-anchor 内建的 ICANN 证书进行的,如果不确认的话,还应检查它的完整性,包括 unbound-anchor -l 和检验源代码,不过源码包一般都经过校验,可以认为没有问题。

$ sudo -u unbound unbound-anchor -a "/var/lib/unbound/root.key"

当然如果root.key的路径指定错误了,就会有提示。比如我一开始在 Continue reading »

10月 122011

DNS安全扩展(DNSSEC),是由IETF提供的一系列DNS安全认证的机制(可参考RFC2535)。引入DNS SEC技术是为了防范在 DNS 中发现的一些无法避免的漏洞,攻击者可以利用这些漏洞劫持这一使用名称在 互联网 上搜寻某个人或某个站点的过程。这种攻击的目的是取得对会话的控制以实施某种操作,例如使用户进入劫持者自己设立的欺骗性网站,以便收集用户的帐户和密码。

本文描述的如何在你的Linux(Ubuntu)和Mac系统上启用DNSSec支持,防止域名劫持。通过安装和配置开源 DNS服务软件unbound,就可以在本地启用DNSSec的支持。 Continue reading »

10月 122011

Posted on May 11, 2010 by Duan Haixin


那些山寨版的Root Server仍然可以继续“行骗”,只要ISP仍然控制着路由。如果Resolver 也配置了DNSSec,这些山寨版的root server可能要露出马脚了。

当然,国内可以控制域名服务器,让国内的resolver不使用 DNSSec。然而,他们控制不了国外的resolver。



10月 122011

Posted on May 16, 2011 by Duan Haixin



1  DNSSEC的背景和目的

域名系统(Domain Name System,DNS)是一些“Too simple, Too Naive”的互联网先驱者设计的,它象互联网的其他协议或系统一样,在一个可信的、纯净的环境里运行得很好。但是今天的互联网环境异常复杂,充斥着各种 欺诈、攻击,DNS协议的脆弱性也就浮出水面。对DNS的攻击可能导致互联网大面积的瘫痪,这种事件在国内外都屡见不鲜。

尽管DNS的安全问题一直被互联网研究和工程领域广为关注,但是有一种普遍存在的攻击却始终没有解决,即DNS的欺骗和缓存污染问题。DNS安全扩 展(DNS Security Extension, 即DNSSEC)主要是为了解决这一问题而提出的(尽管它还有其他用途)。因此,在介绍DNSSEC的原理之前有必要简单介绍DNS欺骗和缓存污染攻击的 原理。

1.1   DNS欺骗攻击和缓存污染

用户在用域名(www.example.com)访问某一个网站时,用户的计算机一般会通过一个域名解析服务器(Resolver Server,也称递归服务器(Recursive Server))把域名转换成IP地址。解析服务器一般需要通过查询根域名服务器(root)、顶级域名服务器(TLD)、 权威域名服务器(Authoritative Name Server),通过递归查询的方式最终获得目标服务器的IP地址,然后交给用户的计算机。如图1所示。

图1 DNS域名欺骗和缓存污染攻击

对于上述任何一个请求(1,2,3,4)过程,攻击者都可以假冒应答方(根、顶级域、权威域、或解析服务器)给请求方发送一个伪造的响应,其中包含 一个错误的IP地址。发送请求的用户计算机或者解析服务器很傻、很天真地接受了伪造的应答,导致用户无法访问正常网站,甚至可以把重定向到一个伪造的网站 上去。由于正常的DNS解析使用UDP协议而不是TCP协议,伪造DNS的响应报文比较容易;如果攻击者可以监听上述过程中的任何一个通信链路,这种攻击 就易如反掌。 Continue reading »

11月 122010

狗爹目前支持.org, .eu, .biz 和 .us域名的DNSSEC安全扩展. com 和 net域名估计还要再等等啊,至少是2011年下半年了.

by GoDaddy Employee JacqueM on August 17th, 2010

We currently support DNSSEC for .org, .eu, .biz., and .us domain name extensions. The registry for .com and .net, VeriSign (R), doesn’t support DNSSEC for these extensions yet, but they’re working on it. As soon as they make DNSSEC possible for .com and .net, we plan to be right there with them to support it!