3月 112015
 

利用域名解析服务器不验证请求源的弱点,DNS放大攻击在过去几年非常流行。攻击者伪装成攻击目标域名向全世界数以百万计的域名解析服务器发送查询请求,域名服务器返回的数据要远大于请求的数据,导致目标遭受了放大数十倍的DDoS攻击。被利用的域名服务器因此每天会收到大量的恶意请求,它也不断的遭受较小规模的DDoS攻击。防止此类攻击的一种方法是实现DNSSEC,验证DNS请求源的身份。但旧的DNS基础架构很难改变。
现在,提供防御DDoS攻击服务的Cloudflare推出了虚拟DNS服务,为域名解析服务器提供基于云端的DNS查询和缓存代理服务,由CloudFlare验证请求源的身份。

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.

Details

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.

1月 082014
 

前段时间尝试用PostgreSQL 作为BIND9的后端数据存储玩玩,发现真不错,需要的Postgresql数据库表结构简单,查询效率高、及时生效。SOA记录也是一条语句,但发送邮件需要的TXT记录出现了问题,按照SPF格式写入了以下TXT记录:“v=spf1 ip4:60.166.118.xxx include:xuplus.com -all”,结果使用nslookup查询出来的情况竟然是这样的: Continue reading »

8月 212013
 

从2011年年中开始,一些较大的域名注册商提供的免费DNS在国内基本上都被盯上了,时不时就给你掐断几条,前阵子也是因为这个原因换掉了域名的DNS。虽然现在免费DNS服务有很多,但选择起来也不是每方面都能很好的顾及到。

如使用国外的,优点是使用方便不用验证这验证那的,服务也相对靠谱,但弊端也很明显容易被墙,而使用国内的,长期看来备案这关是免不了的。所以如何选择大家还是先自己衡量清楚后再去设置,千万不要短时间频繁的修改DNS,免得网站长时间出现无法访问的情况。

下面介绍一些国内外比较有名的免费DNS服务提供商。 Continue reading »

6月 242013
 

Google
8.8.8.8
8.8.4.4
备注:推荐,没有DNS劫持,全球Anycast,节点超多

CNNIC
1.2.4.8
210.2.4.8
备注:也采用Anycast技术,目前4个节点;CNNIC之前也推出过210.2.1.1和210.2.2.2,ip也很好记,但不知什么时候静悄悄的就不能访问了。http://www.sdns.cn

114DNS
114.114.114.114
114.114.115.115
备注:南京信风推出,是曾为中国电信、中国联通两个省约 2000 万宽带用户提供备份服务的超大型 DNS 系统。也采用Anycast技术。

OpenDNS
208.67.222.222
208.67.220.220
备注:全球Anycast,无DNS劫持。

以上都是ipv4的DNS server,如果需要ipv6双栈支持的,请点此链接:
支持IPV6的双栈DNS服务器
https://www.icocean.com/blog/?p=1971

6月 212013
 

现如今互联网蓬勃发展,截止2011年12月,全球上网人数达到19亿。IPv4仅能提供约2.5亿个IP地址。ADSL和NAT等分时和子网技术可以有效缓解这个问题,方便了全球用户使用网络。同时,因为不能每个人甚至每个设备都拥有一个IP地址,使得个人对外提供互联网服务难度加大,网络IP地址经常变化,也使得定位用户特征变得困难,难以给用户推送个性化的内容。在此背景下,1990年开始,互联网工程任务小组开始制定互联网的下一代协议,即IPv6,它提供了理论上虽然有限,实际使用中几乎无穷的IP地址。

目前的智能解析技术可以对IP地址进行划分,并展示个性化的内容。比如按照ISP线路、联通、电信;或者地域,比如山东省、广东省等。如前所述,由于NAT和ADSL技术的大规模使用,达到更精确的线路划分实际上比较困难。最精确的划分只到城市级别,已然错误百出,变化频繁,遑论单个IP级别的划分。 Continue reading »