百度对Register部分指控获美国法院批准
2010年7月23日 尚無評論
Archive
文章標籤 ‘DNS’
互联网域名系统(DNS)安全到达关键性里程碑
2010年6月19日 尚無評論
Web.com将承担百度的域名安全诉讼
2010年6月19日 尚無評論
.cn域名注册量从全球第二跌至第四 还将下跌
2010年6月17日 尚無評論
13台DNS根服务器升级 DNSSEC将改变互联网未来
2010年5月5日 尚無評論
5月5日，由ICANN，美国政府和Verisign领导的全球13台根域名服务器将会迎来DNSSEC（Domain Name System Security Extensions，域名系统安全扩展）升级，DNSSEC升级将会在反馈给互联网用户的DNS请求响应中插入数字签名，确保返回的域名地址是未经篡改 的。 DNSSEC是为阻止中间人攻击而设计的，利用中间人攻击，黑客可以劫持DNS请求，并返回一个假地址给请求方，这种攻击手段类似于正常的 DNS重定向，人们在不知不觉中被转到另一个URL。
据Melbourne IT首席战略官，ICANN董事Bruce Tonkin说，本次升级将会给那些毫无准备的网络管理员一个措手不及，响应标准DNS请求往往只有一个单一的数据包（UDP协议），大小一般不会超过 521字节，在某些较旧的网络设备中，比这个大的请求将会被出厂默认配置阻止掉，它会认为超过这个大小的数据包是异常的。
截至UTC 5月5日17:00点，所有发送给用户DNS解析器的DNSSEC签名的消息将会变大到2KB，是原来的4倍，但这么大的数据包可能会被许多网络设备拒绝 接收，因此这个响应消息很可能会通过TCP分成多个数据包进行发送。
Tonkin有点担心，虽然DNSSEC已经提上日程有一段时间了，但许多IT和网络管理员还没有测试他们的旧路由器和防火墙，如果不能处理更大的DNS 响应数据包就麻烦了。
他说：“企业网络中的设备可能会阻止比以往更大的DNS请求响应数据包”。
DNSSEC其实早在 2009年11月就在全球13台根服务器上准备好了，到目前为止，它只会导致许多旧网络设备载入网页略有延迟。
不是所有DNS根服务器都会响应每一个请求，用户机器上的DNS解析器会逐个请求这13台根服务器，直到返回一个满意的答复。当13台具有 DNSSEC签名功能的根服务器全部上线后，所有的响应不会抵达旧设备的企业网络，Tonkin希望大型ISP能解决这个问题，让家庭用户不受影响。
他说：“我不能保证所有ISP都准备好了，ISP会为你翻译DNS，但企业网络可能影响比较大，因为企业可能运行了自己的DNS服务器”。
从这个意义上来说，5月5日可与千年虫危机匹敌。Tonkin预计会有大量的组织遇到互联网接入问题，大量的网络管理员将会抓破头皮寻找问题的根源。
这个问题可能需要数天才能完全消除，晚上未关机的用户可能会访问到一些页面，那也仅仅是缓存中的内容。Tonkin建议网络管理员尽快运行一系列简单的测 试，确保他们的网络可以处理更大的DNS响应包。
【51CTO.com译稿，合作站点转载请注明原文译者和出处。】
原文：Warning: Why your Internet might fail on May 5 作者：Brett Winterford
免费顶级域名.cg注册免费一级域名.rw申请
2010年4月20日 尚無評論
先进入http://www.nic.cg/cgi-bin/search.pl
在这里输入 你要注册的youname.cg或者.
如果注册了，就会出现ALREADY TAKEN.几个红字
没注册就出现一个叫填 EMAIL的框
填入你的EMAIL
（注意，一般邮箱不能申请只有以@zj.com和@china.com.cn的邮箱可以申请， 自己试吧！）
然后进入下一页
Domain Name : xxx
Domain Country : .cg
You can also register the domain in the following country at once :
Is this domain to be delegated to
a Citizen/resident of the country ? No Yes (copy of passport will be required) If you already have registered a free domain, you must select ’No’. 就选NO
Organization registering the domain
Name Surname : 名字
Organization name : 组织
Street : 街道
City – Zip Code : 城市和邮编
Country : 国家选china
Telephone : 电话
Telefax : 传真号码
E-Mail Address : 电子邮件（这个要和刚才填的一样）
IMPORTANT: not the e-mail of the registrar but the Delegated Organization’s email address, so that we may have a direct contact with them. The registrar can use the billing e-mail address BUT NOT THIS ONE. This is a cause of rejection.
下面的基本上和上面填的一样，对照着填就行了
Billing Contact
Name Surname :
Organization name :
Street :
City – Zip Code :
Country :
Country :
Telephone :
Telefax :
E-Mail Address :
下面填DNS服务器信息，我用的是POWERDNS的
DNS Information
Primary DNS Host Name : dns-eu1.powerdns.net
Primary DNS IP Address : 213.244.168.217
Secondary DNS Host Name : dns-eu2.powerdns.net
Secondary DNS IP Address : 212.72.55.217
Please choose a password: 填密码
This password will allow you to login to our web site to view the status of your request, change contact information, dns etc… Password:
Re-enter Password: 再填一次密码
OK， 注册流程基本上到这就完毕了
到信箱看，有第一封系统发的信
会收到第二封信通知你是否成功
OVER
(编 辑：免费吧)
中国开通镜像服务器 域名解析不绕道美国
2008年12月19日 尚無評論
12 月19日消息,网通集团宣布,已与美国威瑞信(VeriSign)公司达成协议,将开通根域名中国镜像服务器,今后中国网民访问.com以及.net网站 时,域名解析将不再由设置在境外的域名服务器提供服务,长期以来在中国访问.com以及.net网站的安全性问题得到了保障,上网速度也将提升.网通集团 表示,已于12月14日与美国Verisign公司在北京举行签字仪式,正式开通互联网根域名中国镜像服务器.
由于此事的重要性,美国商务部古铁雷斯部长、中国商务部易小准副部长、信息产业部电信管理局韩夏副局长、Verisign公司约翰·多诺万副总裁、中国网通集团公司朱立军副总裁等共同出席了签约仪式,并启动了根域名服务器的开通.
解决了访问.com网站的安全问题
此次建立互联网根域名中国镜像服务器是在信息产业部的直接领导下,由中国网通集团公司与美国Verisign公司共同合作完成的.
据悉,以前,中国互联网网民访问.com、.net网站时,域名解析需由设置在中国境外的域名服务器提供服务.一直到去年,美国商务部还曾宣布,将坚持保 留对互联网域名根服务器(rootserver)的监控权,这一声明的隐含信息是:美国将继续掌握全球互联网的最终控制权.因此,有关网络信息安全问题再 次成为互联网业界的关注焦点.
信产部电信管理局和网通相关人士表示,此次开通根域名中国镜像服务器有非常重要的意义,解决了中国网民访问.com 、.net网站时,域名解析需由设置在中国境外的域名服务器提供服务的问题,使中国互联网的安全性和稳定性得到进一步保证;同时,将大大提高了中国境内互 联网用户连接相关网站的速度,有利于促进中国互联网的发展.
中国政府网率先启用”政务”专用中文域名
2008年12月7日 尚無評論
新闻来源:新华网
记者日前从中央编办政务和公益机构域名注册管理中心了解到，中国政府网已率先开始使用“中国政府网.政务”专用中文域名。
据了解，中国政府网还使用了“中国政府.政务”、“国务院.政务”、“国务院办公厅.政务”、“中央人民政府门户网站.政 务”等多个专用中文域名，网民今后就可以通过这些专用中文域名直接访问中央政府门户网站。 中 国政府网是我国最高级别的中央政府门户网站，是国务院和国务各部门，以及各省、自治区、直辖市人民政府在国际互联网上发布政府信息和提供在线服务的综合平 台。中国政府网专用中文域名的开通标志着我国政府网站域名规 范工作又迈上了一个新的台阶，对于进一步加强政府网站建设管理工作具有十分重要的意义。
在采访过程中，一些网民表示，以往我国政府网站在使用英文域名时很难做到非常规范，有的网站使用英文，有的使用汉语拼音，或者仅是几个字母的缩写，很难准确记忆，同时从域名上看也无法反映网站主办者的机构性质。
调查显示，我国的普通网民很少有人能够准确记忆10个以上的政府网站的英文域名，如何能使习惯于使用中文的我国网民用最直接的方式准确找到政府网站，政务专用中文域名的设立为此建立了一条绿色的通道。
另外，一些政府网站的管理者表示，“政务”、“公益”专用中文域名的设立和应用为政府网站在互联网中建立了一个明确的标识，便于网民准确识别，能够有效避免假冒网站所带来的社会危害，同时也对于保护政府部门和公益机构的合法权益具有十分重要的意义。
DNS漏洞 迫使互联网核心协议升级
2008年9月19日 1 則評論
DNS(Domain Name System,域名解析系统)的一些漏洞细节在Black Hat 2008大会发布之前已经泄露,让本身就不够安全的互联网更增添了恐慌和猜测.
正是基于目前互联网上曝出的DNS漏洞问题,ICANN(国际域名与IP地址管理机构)迫不得已在最近批准了一项符合公众利益的重要决定——.org域名 将率先转移为使用DNS安全扩展(DNSSEC)协议的顶级域名.开发周期长达11 年的DNSSEC协议,其创建目的就是为了解决原DNS协议中的漏洞问题,使之不再容易遭受攻击.
互联网的核心漏洞
DNS服务在互联网中扮演着极为重要的角色.简单地说,DNS就是互联网的核心,它作为可以将域名和IP地址相互映射的一个分布式数据库,能够使用户方便 地访问互联网,而不用去记住能被机器直接读取的IP数串.比如,用户只需要在浏览器中输入www.abc.com,而不需要记住长长的IP地址.不只浏览 网页需要DNS,E-mail和SSL证书同样需要DNS.
DNS的安全漏洞可能会导致“钓鱼”诈骗攻击.诈骗分子可以把人们引诱到假冒的银行和信用卡公司等商业网页,欺骗用户泄漏自己的账户号码、口令和其他信息.黑客还能利用这个安全漏洞把用户引导到其想让用户访问的网页,无论用户在网络浏览器上输入什么地址.
正因如此,DNS就像一块磁铁,吸引着那些试图对某个网站进行破坏性攻击的黑客.一旦DNS受到威胁,他们就可以随意改变互联网信息的流动方向,可以让一个合法的网站瞬间变成黑客手中的傀儡,对用户进行金融欺诈.
甚至有业内人士担忧地说:“该漏洞的危害性不容忽视,它涉及到整个互联网域名框架如何运行的问题.如果不及时修复这一漏洞,虽然互联网仍将存在,但那已不再是你想要的互联网了——届时,控制权将掌握在黑客手中.”
DNS自身的缺陷最早被发现于1990年,但一直没有相应的解决方法.而最新的“Cache投毒”方法则据称可以有效伪造DNS信息,利用DNS缓存服务器来达到劫持网站的目的.
虽然获取交易ID猜测和转介记录这两种DNS漏洞早已被业界熟知,尽管获取交易ID 的可能性在1/65535,但仍然给攻击者很大的几率让攻击成为可能.转介记录的安全问题与DNS服务器的性能也息息相关,比如某个站点的主域不仅仅有 abc.com的IP地址,而且还包括一些额外信息,因此只要攻击者在所谓的abc.com站点上拥有DNS服务器,就可以对请求做出响应.
这两种漏洞在很早以前就得到了解决,而且已经被网络运营商竭力修补.他们的解决方案就是抛弃任何与请求地址不相关的一切信息,比如输入搜狐的DNS地址http://61.135.179.166时,并不会访问搜狐的主页,而是出现报错页面,在策略上已经形成了范围保护.
Dan Kaminsky,曾在思科工作,现在就职于IOActive网络安全公司.10年来,他9次站在Black Hat大会上发言.现年29岁的Dan Kaminsky自称为DNS Geek(DNS极客),在今年年初时曾发现了DNS系统的一个严重漏洞,为了不让互联网遭受重创,他一直不肯透露漏洞细节.
还包括一些额外信息,因此只要攻击者在所谓的abc.com站点上拥有DNS服务器,就可以对请求做出响应.
这两种漏洞在很早以前就得到了解决,而且已经被网络运营商竭力修补.他们的解决方案就是抛弃任何与请求地址不相关的一切信息,比如输入搜狐的DNS地址http://61.135.179.166时,并不会访问搜狐的主页,而是出现报错页面,在策略上已经形成了范围保护.
为DNS打补丁
那么,Dan Kaminsky的新发现何以让安全业内人士恐慌呢?在2008年的Black Hat大会上,资深安全专家Dan Kaminsky向公众展示了DNS更为脆弱的一面.新发现的DNS漏洞引人注意之处就在于,它将交易ID猜测和转介记录以一种新方式进行了结合.当服务 器提出DNS请求时,它使用一个独特的交易ID来确定请求.这个特殊的交易ID使服务器可以验证响应,并且确保它们来自正确的搜索请求.
Dan Kaminsky表示:“这基本上就是黑客和合法服务器之间的一场竞赛,攻击者可以发送100个错误的响应,那么,1/65535的机率就可以提高到一个更有利的水平——1/655.”
幸运的是,Dan Kaminsky在过去几个月中,一直孜孜不倦地试图说服DNS服务器运营商,并在运营商的圈子中尽力传播这一消息.Dan Kaminsky说,他向运营商建议随机选择使用DNS源端口,这样可以消除现有DNS源端口的可预见性,并且用随机选择技术替代该性质.现在,攻击者不 仅仅需要猜测正确的交易ID,也需要猜测正确的充满答复的UDP端口.这将会带来一个更难于操作的成功率——1/163840000,使该攻击变得无效.
为了测试服务器中的漏洞,Dan Kaminsky还提供了一种简易的DNS检验工具(可以访问http://www.doxpara.com,用户可以检查各自的电脑是否存在该DNS漏 洞),发送大量查询到DNS检验服务器,然后对查询进行分析.据统计,世界上80%以上的DNS服务器都已经经过修补了,包括许多主要供应商使用的服务 器.
一些大型ISP,诸如澳洲电信、Optus(新加坡电信旗下子公司)、 Internode(澳大利亚宽带运营商)和iiNet(澳大利亚的互联网服务提供商)都表示,已经对DNS服务器安装了补丁.不过,还是有消息人士指 出,尽管众多安全机构再三叮嘱要及时修复该漏洞,但是还是有不少DNS管理员并没有真正修复这一漏洞.
iiNet网络工程师Mark Newton 说,由于那些小的ISP需要做大量工作来保障DNS服务器的正常运行,因而他们在修补DNS漏洞方面可能会比较滞后.另外,他们为了降低成本,还缺乏独立 分隔开的DNS服务器,所有的数据运行都整合在一台服务器当中,更容易遭受巨大风险.
拯救受困的DNS
虽然一些企业已经修补了其DNS服务器,但这并没有结束,仍然有很多工作需要完成.当用户在企业基础结构的使用范围内进行操作时,用户是受到保护的.但 是,这并不是用户惟一访问互联网的途径,用户还可能会出现在不同的商业ISP、酒店、咖啡馆、飞机场、火车站等具备Wi-Fi的场所,通过他们提供的 DNS服务,访问互联网,同样存在遭受DNS攻击的可能.
Dan Kaminsky建议,目前看上去用户还处于一种不设防的状态,最好的策略是确保员工使用VPN连接返回到企业基础设施,确保这种联网方式不使用分离的信 道,同时保证用户通过VPN获得DNS的正确配置,这样可以确保远程用户可以使用他们的企业DNS服务器,而不是依赖访问站点提供的那些服务器.
Dan Kaminsky揭露了DNS新漏洞,DNS服务器的缓存会被随意修改,即便是在防火墙后的主机也不能幸免,因此在更彻底的解决方案出台以前需要一些临时措施来修补由此造成的各类Bug.著名的信息安全博客Chaos提供了一些解决方案:
1.针对终端桌面用户,最好的办法是等待公司或ISP的工作人员修正问题,通过安装适当的补丁,消除DNS的这两种漏洞.
2.对于FreeBSD 用户,减轻这类问题影响的办法是在/etc/rc.conf中加入named_enable=”YES”,执行/etc/rc.d/named restart并在/etc/resolv.conf中将127.0.0.1配置为域名服务器.这样一来,黑客对缓存服务器的单点攻击,就变成了对所有桌 面系统的攻击行为,从而大大提高黑客的攻击成本.但缺点是,这样做意味着无法有效利用上游DNS的缓存.
3.如果是缓存DNS服务器的管理员,那么除了需要打补丁之外(如果你的系统中存在这个漏洞),还需要考虑部署DNSSEC.DNS协议的漏洞通过随机化查询端口和TXID只能部分缓解,而DNSSEC才是解决问题的根本.
4.如果是权威DNS服务器的管理员,那么事实上什么都做不了,因为缓存DNS服务器并不受DNS服务器管理员控制.唯一可以做的事情就只剩下为自己的权威域名配置DNSSEC了.遗憾的是,目前并不是所有的顶级域名以及域名注册服务提供商都支持DNSSEC.
发改委:2010年底前发展50万IPv6试商用用户
2008年8月22日 尚無評論
昨日,国家发改委在其网站上公布了下一代互联网业务试商用及设备产业化专项的通知.通知指出,为积极、稳妥推动我国下一代互联网业务应用和产业发展,按照中国下一代互联网示范工程总体安排,将组织实施下一代互联网业务试商用及设备产业化专项.通知强调,大力促进IPv6业务试商用,在2010年底前发展50万以上IPv6试商用用户,积极推进下一代互联网由试验向商用的转型,培育形成新的经济增长点,带动我国信息产业持续健康发展.
据 专家介绍,以IPv6为核心的下一代网络的出现,将引发全球的网络革命.IPv6也被称作下一代互联网协议,它是用来替代现行的IPv4协议的一种新的 IP协议.由于现行的IP地址资源有限,已不能满足用户的需求,因此国际互联网研究组织发布了新的主机标识方法,即IPv6.
发改委还在通知中指出,要实现关键设备产业化.配合新型技术及业务的应用和试商用,实现具有自主知识产权的下一代互联网关键设备的批量生产能力.
DNS漏洞攻击代码已经公布 危险迫在眉睫
2008年7月25日 尚無評論
Infoworld 报道,著名黑客HD Moore已经率先公布了可用代码.利用这段代码可以对DNS服务器进行投毒,将一条恶意纪录植入目标服务器,该服务器将随机发起域名查询,此时攻击者可以提供伪造的响应,将域名服务器中的纪录指向其特定站点.这个漏洞攻击可以默默的改变用户的升级服务下载恶意软件,IOActive研究者Dan Kaminsky很早发现漏洞并且无意中这周公布了漏洞使得开发出攻击代码.infoworld.com网站也提醒了这个攻击导致的网络钓鱼欺骗的问题.
通过这个网址http://metasploit.com/dev/trac/changeset/5579可以看到国外黑客发布的DNS漏洞攻击代码。
.org域名将首先使用DNS安全扩展协议
2008年7月23日 尚無評論
基于目前互联网爆出的DNS漏洞问题,ICANN近日批准了一项符合公众利益的重要决定,.org域名将首先转移为使用DNS安全扩展(DNSSEC)协议的顶级域名.
DNS自身的缺陷最早被发现于1990年,但是一直没有相关的问题解决方法,最新的“cache投毒”方法据称可以有效伪造DNS信息,利用DNS缓存服务器来达到劫持网站的目的.
DNSSEC 发展于1997年1月，开发周期长达11年，DNS安全扩展(DNSSEC)协议创建的目的是为了解决原DNS协议中的漏洞，使之不再 容易遭受攻击。不过因为DNSSEC会产生额外的数据开销而得不到普及。根据早期的协定，如果要使用DNSSEC，必须将之覆盖整个互联网。而且，有关隐 私和法律方面的疑虑涌现出来，使之无法获得普及。
不过，.org域名实际上并不是最需要考虑到域名，但是鉴于一些国家已经拥有了自己的顶级域名，这不是ICANN所能控制的，可以简单而 快速从 DNS转移到DNSSEC的顶级域名目前只有.org。不过如果ICANN可以控制全面的互联网访问权限，那么全部域名转移也不是不可能。至于ICANN 和美国政府是否可以值得信任，则是另外一个问题。
从.org域名的转移我们可以看到，尽管步伐缓慢，不过DNS将最终转移到DNSSEC上。
《连线》:DNS 漏洞细节被泄露,攻击即将开始
2008年7月23日 尚無評論
尽管 Dan Kaminsky 努力掩盖他所发现的 DNS 严重漏洞的细节，Matasano 安全公司的一个员工还是在他的博客上泄露了这些资料，虽然文章被立即删除，但已经有人拿到了这些资料，并发表在别的地方。Kaminsky 在他的博客上发表了一个紧急消息，赶快打补丁，别睡觉，使用 OpenDNS…
HD Moore，Metasploit 的作者说，黑客们正在加紧制作攻击工具，今天的晚些时候会有攻击出现。本月初，IOActive 的 Kaminsky 公布了 DNS 系统的一个非常严重的漏洞，该漏洞会导致攻击者轻松地伪造任何网站，银行网站，Google，Gmail 以及其它 Web 邮件网站。
Kaminsky 是在同多个 DNS 系统商共同开发安全补丁的时候发现了这个漏洞。Kaminsky 在记者会宣布了这个由多家厂商共同开发的 DNS 补丁，并呼吁 DNS 服务器所有者立即更新他们的系统。
但 Kaminsky 在宣布这个漏洞的时候，没有透露相关技术细节，以便 DNS 系统管理员知道其严重性，Kaminsky 承诺会在下月的 Las Vegas 黑帽安全大会上透露漏洞细节，在这之前，他给 DNS 系统管理员预留了一个月的时间升级系统。Kaminsky 同时恳求那些安全专家不要试图猜测漏洞的细节，但很多人将他的恳求当作一个挑战。
德国的安全专家 Halvar Flake 最先发表了漏洞细节，Kaminsky 曾被要求私下里公布细节，帮助那些系统管理员升级系统，同时，一些系统管理员以及安全专家指责 Kaminsky 是在拿那些过去的众所周知的 DNS 漏洞炒作。
Matasano 的创始人Thomas Ptacek 也曾置疑过 Kaminsky 的发现，然而当 Kaminsky 私下里向他透露过漏洞细节之后便不再出声。Ptacek 并没有参与漏洞细节的公布，但作为 Matasano 的创始人，他仍然发表了一个声明为这件事道歉。
Kaminsky 发现的 DNS 漏洞会让黑客在 10 秒之内发起一个“缓存毒药攻击”，使 DNS 服务器将用户引导到恶意网站。Kaminsky 说，这是一个非常严重的 Bug，会影响到任何网站，Kaminsky 不打算向 Matasano 追究到底细节到底是如何泄露的，但呼吁人们立即升级 DNS 系统。
本文国际来源：http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html
中文翻译：COMSHARP CMS
高达79.24%网民会选择注册“.中国”域名
2008年7月11日 尚無評論
“.中国”域名将启用极大的调动了2亿中国网民的互联网归属感和认同感.
近日,ICANN理事会通过一项重要决议,允许使用其他语言包括中文等作为互联网顶级域字符,“.中国”将于2009年写入全球根域名系统,成为首批新设的非拉丁语系字符顶级域之一.最新调查显示,高达79.24%的网民会选择注册“.中国”域名.而有业内人士却指出,近八成网民欲注册“.中国”域名对广大企业来说并不是好事.
●中国域名有利品牌文化传播 八成网民欲注册
这意味着,届时全球华人在浏览器地址栏不仅可以通过输入英文域名lenovo.com.cn,还将可以通过直接输入中国域名“联想.中国”在互联网上访问联想公司的网站.
网友冯健表示,中国网民这么多,完全可以借此机会向世界推广中国的文学、语言,意义深远;现在我们都是用英文输入,也应该让外国人来学学汉语,以后让世界也流行中文域名.
“外国人用外文域名,中国人用中文域名,不是很好吗?”一位腾讯威海网友如是表示.显然,中国域名将启用在网民中获得了巨大的认同,这在一项调查中得到充分证实.网易的最新调查显示,高达79.24%的网民会选择注册“.中国”域名.
●专家提醒:企业应及早行动 防范品牌遭遇“强娶”
近八成网民欲注册中国域名对广大企业来说并不是好事.
网络法律学者张樊指出,一个新域名后缀启用之后必然带来注册剧增问题.据了解,欧洲联盟的顶级代码“.eu”在向欧盟居民开放注册后,就吸引了大批民众集中注册.据欧盟委员会统计,在注册开放后100分钟内注册人数高达30万,仅当天便有数十万个人用户提交了注册申请.
张樊认为,“.中国”域名的类似情况可能会更突出,因为它允许将更多的中文商标直接注册成域名.据介绍,对于国内企业来说,绝大部分企业商标用的是中文,过去由于无法直接将其商标注册成域名,极大阻碍了企业品牌在互联网上的传播.
如今,中国域名的启用将给企事业单位的网络品牌传播带来一种全新的体验.相比之下,更多国人能够记住的是企事业单位的中文品牌,而非英文商标.如在十三亿国人中,“海信”的知名度要比“Hisense”高得多.
由于“.中国”域名与“.com”、“.cn”结尾的域名一样,遵循“先注先得”的国际惯例,因此同样具有稀缺性与唯一性的特点.网舟咨询总经理翟文军表示,具有唯一性的域名存在着被他人或竞争对手提前注册的可能性,从而产生企业网络资源和品牌边缘化,因此企业要提高域名品牌意识,加强自身资源保护.
《北京晨报》消息
DNS爆漏洞 可致黑客控制网络
2008年7月9日 尚無評論
计算机行业巨头正在忙于修复互联网基础中的一个安全漏洞。这个安全漏洞能够让黑客控制互联网通信。
主要软件和硬件厂商几个月来一直在秘密研制本周二发布的这个软件“补丁”以修复这个漏洞。这个安全漏洞存在于计算机被路由到网页地址的方式中。Securosis公司分析师Rich Mogul在媒体电话会议上说,这是整个互联网地址解析方案工作方式的一个非常基本的问题。你拥有这个互联网,但是,它不是你预期的那样的互联网。黑客会控制一切。
这个安全漏洞可能导致“钓鱼”诈骗攻击。诈骗分子可以把人们引诱到假冒的银行和信用卡公司等商业网页,欺骗人们泄漏自己的账户号码、口令和其它信息。黑客还能够利用这个安全漏洞把用户引导到他要用户访问的网页,无论用户在网络浏览器上输入什么地址。
IOActive公司的安全研究人员Dan Kaminsky在6个月前发现了这个域名系统安全漏洞,并且立即联系微软、Sun和思科等行业巨头合作制定一个解决方案。
Kaminsky说,人们应该担心这个问题。但是,他们不必恐慌。我们已经给你许多时间测试和使用这个补丁。以前还从来没有这种规模的修复安全漏洞的事情。
Kaminsky建立了一个网页,网址是http://www.doxpara.com/。人们可以在那里查看自己的计算机是否存DNS安全漏洞。
IPv6
2008年1月12日 尚無評論
IPv6是Internet Protocol Version 6的缩写，其中Internet Protocol译为“互联网协议”。
IPv6是IETF（互联网工程任务组，Internet Engineering Task Force）设计的用于替代现行版本IP协议（IPv4）的下一代IP协议。
目前的全球因特网所采用的协议族是TCP/IP协议族。IP是TCP/IP协议族中网络层的协议，是TCP/IP协议族的核心协议。
目前IP协议的版本号是4（简称为IPv4），它的下一个版本就是IPv6。IPv6正处在不断发展和完善的过程中，它在不久的将来将取代目前被广泛使用的IPv4。
目前我们使用的第二代互联网IPV4技术，核心技术属于美国。它的最大问题是网络地址资源有限，从理论上讲，IPV4技术可使用的IP地址有43亿个，其中北美占有3/4，约30亿个，而人口最多的亚洲只有不到4亿个，中国只有3千多万个，只相当于美国麻省理工学院的数量。地址不足，严重地制约了我国及其他国家互联网的应用和发展。
随着电子技术及网络技术的发展，计算机网络将进入人们的日常生活，可能身边的每一样东西都需要连入全球因特网。但是与IPv4一样，IPv6一样会造成大量的IP地址浪费。准确的说，使用IPv6的网络并没有2^128-1个能充分利用的地址。首先，要实现IP地址的自动配置，局域网所使用的子网的前缀必须等于64，但是很少有一个局域网能容纳2^64个网络终端；其次，由于IPv6的地址分配必须遵循聚类的原则，地址的浪费在所难免。
但是，如果说IPV4实现的只是人机对话，而IPV6则扩展到任意事物之间的对话，它不仅可以为人类服务，还将服务于众多硬件设备，如家用电器、传感器、远程照相机、汽车等，它将是无时不在，无处不在的深入社会每个角落的真正的宽带网。而且它所带来的经济效益将非常巨大。
当然，IPv6并非十全十美、一劳永逸，不可能解决所有问题。IPv6只能在发展中不断完善，也不可能在一夜之间发生，过渡需要时间和成本，但从长远看，IPv6有利于互联网的持续和长久发展。 目前，国际互联网组织已经决定成立两个专门工作组，制定相应的国际标准。
与IPV4相比，IPV6具有以下几个优势：
一，IPv6具有更大的地址空间。IPv4中规定IP地址长度为32，即有2^32-1（符号^表示升幂，下同）个地址；而IPv6中IP地址的长度为128，即有2^128-1个地址。
二，IPv6使用更小的路由表。IPv6的地址分配一开始就遵循聚类（Aggregation）的原则，这使得路由器能在路由表中用一条记录（Entry）表示一片子网，大大减小了路由器中路由表的长度，提高了路由器转发数据包的速度。
三，IPv6增加了增强的组播（Multicast）支持以及对流的支持（Flow Control），这使得网络上的多媒体应用有了长足发展的机会，为服务质量（QoS，Quality of Service）控制提供了良好的网络平台。
四，IPv6加入了对自动配置（Auto Configuration）的支持。这是对DHCP协议的改进和扩展，使得网络（尤其是局域网）的管理更加方便和快捷。
五，IPv6具有更高的安全性。在使用IPv6网络中用户可以对网络层的数据进行加密并对IP报文进行校验，极大的增强了网络的安全性。
IPv6包由IPv6包头（40字节固定长度）、扩展包头和上层协议数据单元三部分组成。
IPv6包扩展包头中的分段包头（下文详述）中指名了IPv6包的分段情况。其中不可分段部分包括：IPv6包头、Hop-by-Hop选项包头、目的地选项包头（适用于中转路由器）和路由包头；可分段部分包括：认证包头、ESP协议包头、目的地选项包头（适用于最终目的地）和上层协议数据单元。但是需要注意的是，在IPv6中，只有源节点才能对负载进行分段，并且IPv6超大包不能使用该项服务。
IPv6包头长度固定为40字节，去掉了IPv4中一切可选项，只包括8个必要的字段，因此尽管IPv6地址长度为IPv4的四倍，IPv6包头长度仅为IPv4包头长度的两倍。
其中的各个字段分别为：
Version（版本号）：4位，IP协议版本号，值= 6。
Traffice Class（通信类别）：8位，指示IPv6数据流通信类别或优先级。功能类似于IPv4的服务类型（TOS）字段。
Flow Label（流标记）：20位，IPv6新增字段，标记需要IPv6路由器特殊处理的数据流。该字段用于某些对连接的服务质量有特殊要求的通信，诸如音频或视频等实时数据传输。在IPv6中，同一信源和信宿之间可以有多种不同的数据流，彼此之间以非“0”流标记区分。如果不要求路由器做特殊处理，则该字段值置为“0”。
Payload Length（负载长度）：16位负载长度。负载长度包括扩展头和上层PDU，16位最多可表示65，535字节负载长度。超过这一字节数的负载，该字段值置为“0”，使用扩展头逐个跳段（Hop-by-Hop）选项中的巨量负载（Jumbo Payload）选项。
Next Header（下一包头）：8位，识别紧跟IPv6头后的包头类型，如扩展头（有的话）或某个传输层协议头（诸如TCP，UDP或着ICMPv6）。
Hop Limit（跳段数限制）：8位，类似于IPv4的TTL（生命期）字段。与IPv4用时间来限定包的生命期不同，IPv6用包在路由器之间的转发次数来限定包的生命期。包每经过一次转发，该字段减1，减到0时就把这个包丢弃。
Source Address（源地址）：128位，发送方主机地址。
Destination Address（目的地址）：128位，在大多数情况下，目的地址即信宿地址。但如果存在路由扩展头的话，目的地址可能是发送方路由表中下一个路由器接口。
IPv6包头设计中对原IPv4包头所做的一项重要改进就是将所有可选字段移出IPv6包头，置于扩展头中。由于除Hop-by-Hop选项扩展头外，其他扩展头不受中转路由器检查或处理，这样就能提高路由器处理包含选项的IPv6分组的性能。
通常，一个典型的IPv6包，没有扩展头。仅当需要路由器或目的节点做某些特殊处理时，才由发送方添加一个或多个扩展头。与IPv4不同，IPv6扩展头长度任意，不受40字节限制，以便于日后扩充新增选项，这一特征加上选项的处理方式使得IPv6选项能得以真正的利用。 但是为了提高处理选项头和传输层协议的性能，扩展头总是8字节长度的整数倍。
目前，RFC 2460中定义了以下6个IPv6扩展头：Hop-by-Hop（逐个跳段）选项包头、目的地选项包头、路由包头、分段包头、认证包头和ESP协议包头：
（一）Hop-by-Hop选项包头包含分组传送过程中，每个路由器都必须检查和处理的特殊参数选项。其中的选项描述一个分组的某些特性或用于提供填充。这些选项有：
Pad1选项（选项类型为0），填充单字节。
PadN选项（选项类型为1），填充2个以上字节。
Jumbo Payload选项（选项类型为194），用于传送超大分组。使用Jumbo Payload选项，分组有效载荷长度最大可达4,294,967,295字节。负载长度超过65,535字节的IPv6包称为“超大包”。
路由器警告选项（选项类型为5），提醒路由器分组内容需要做特殊处理。路由器警告选项用于组播收听者发现和RSVP（资源预定）协议。
（二）目的地选项包头指名需要被中间目的地或最终目的地检查的信息。有两种用法：
如果存在路由扩展头，则每一个中转路由器都要处理这些选项。
如果没有路由扩展头，则只有最终目的节点需要处理这些选项。
（三）路由包头
类似于IPv4的松散源路由。IPv6的源节点可以利用路由扩展包头指定一个松散源路由，即分组从信源到信宿需要经过的中转路由器列表。
（四）分段包头
提供分段和重装服务。当分组大于链路最大传输单元（MTU）时，源节点负责对分组进行分段，并在分段扩展包头中提供重装信息。
（五）认证包头
提供数据源认证、数据完整性检查和反重播保护。认证包头不提供数据加密服务，需要加密服务的数据包，可以结合使用ESP协议。
（六）ESP协议包头
提供加密服务。
上层数据单元即PDU，全称为Protocol Data Unit。
PDU由传输头及其负载（如ICMPv6消息、或UDP消息等）组成。而IPv6包有效负载则包括IPv6扩展头和PDU，通常所能允许的最大字节数为65535字节，大于该字节数的负载可通过使用扩展头中的Jumbo Payload（见上文）选项进行发送。
IPv6即将进入根服务器 离我们已经很近
2008年1月4日 尚無評論
ICANN/IANA将在2008年2月4日为服务于IPv6地址的4个根服务器添加AAAA记录.这意味着2月4日以后，两组独立的IPv6主机将开始服务于全世界而无需依赖任何IPv4的基础设施.IPv6离我们已经越来越近了。
去年年底，ICANN/IANA发出了一个简短的信息，他们将在2008年2月4日为服务于IPv6地址的4个根服务器添加AAAA记录.
ICANN主要负责全球域名，IANA分配网络号码，这意味着2月4日以后，两组独立的IPv6主机将开始服务于全世界而无需依赖任何IPv4的基础设施.接下来的工作是让分布于全球的DNS服务器识别并对IPv6的解析提供支持，IPv6到DNS系统的转换已经最大限度地被设计为兼容现有DNS系统，目前大多数现代的DNS软件都能够接收足够长（大于512字节）的解析数据包.
如果你工作在对IPv6有需求的部门，请注意您的防火墙不能拦截大于512字节的DNS数据包和TCP DNS请求，如果您还在运行旧版DNS软件，这可能是一个升级的好时机.
当然在短时间内，IPv6发展的规模可以忽略不计.
DNS and BIND
2007年12月29日 尚無評論
我转载的评价：
本书是介绍bind和dns的权威书籍，由于市面上介绍bind和dns的书比较少，所以本书的
份量也就更重了。本书从dns的基本概念到dns的实现程序bind都作了详细的介绍。如果
你是dns的维护人员，应该通读这本书。如果你想了解一下dns的概念和bind程序的基本
应用，这本书也提供的大量的相关知识。不同层次的人员可根据自已的实际情况选读相关章
节。由于我应用dns只是在局域网内做一下名字解析，应用较浅，所以我只挑了个别章节看
了一下，没有深入dns的高级部份，所以读书笔记也就只包含这部分的内容了。
第一章 背景
dns是针对ARPnet的特殊问题发展起来的，在整个20世纪70年代，ARPnet还是一个
有几百台主机的很小很友好的网络。仅仅需要一个名为HOSTS.TXT的文件就能容纳所有需
要了解的主机信息。该文件由SRI(Stanford Research Institute的前身)的网络信息中心
（Network Information Center NIC)负责维护，并从一台主机SRI-NIC上分发到整个网络。
ARPnet的管理员通常定期通过电子邮件的方式将他们的变更通知SRI，同时还定期ftp到
sri-nic，以获取最新的HOSTS文件。但随着ARPnet的增长，这种方法行不通了。流量和负
载使SRI的线路不堪重负；名字冲突，造成网络混乱；在不断扩张的网络上要维护文件的
一致性变得越来越难。关键问题是HOSTS文件的结构不是很好，最终导至了hosts文件的
失败和落伍。
ARPnet的管理者们开始投入研究，为HOSTS.TXT文件寻求继任者。Paul Mockapetris，
当时在南加州大学的信息科学所，负责设计新系统的体系架构。1984年，他发布了描述DNS
的RFC882和RFC883。后来它们被RFC1034和RFC1035所取代，也就是目前的DNS规范。
目前，还有很其它RFC补充RFC1034和RFC1035的内容，它们描述了DNS的安全问题，
实现问题，管理问题等。
DNS 简述
实际上，DNS是一个分布式数据库，它允许对整个数据库的各个部份进行本地控制；同时
整个网络也能通过客户-服务器方式访问每个部份的数据。借助备份和缓存机制，DNS将具
有强壮性和足够的性能。DNS的数据库结构同unix文件系统的结构非常相似，就像一棵倒
着的树。
第二章 DNS是如何工作的
介绍了DNS的工作原理，一些功能和名词。
第三章 如何开始工作
获是bind软件
选择一个域名
第四章 建立BIND
建立区数据，包括正向解析文件（名字到地址的映射），反向解析文件（地址到名字的映射）。
每个网络都有包含它自已的反向映射数据文件。名字服务器用named.conf配置文件把所有
的区数据文件绑定在一起。
区数据文件
区数据文件中的大部份条目被称为DNS资源记录。DNS查找是不区分大小写的，但大写是
被系统保留的，建议用小写。资源记录必须从一行的第一列开始。在DNS RFC中，表示资
源的记录是按特定顺序排列的，但这不是必须的。顺序如下：
SOA记录 指示该区的权威
NS记录 列出该区的一个名字服务器
A 名字到地址的映射
PTR 地址到名字的映射
CNAME 规范名字（相对于别名而言）
注释是以“；”号开始的
设置区默认的TTL值。
在8.2版本前，SOA记录中最后一个字段设置区默认的TTL值。在8.2版出来前，公布了
RFC2308,将SOA记录中最后一个字段的含义改为了“否定缓存TTL”，它的意思是一个远
程名字服务器能将区的否定响应缓存多长时间，否定响应是报告某个域名或某个域名的某个
数据类型不存。8.2版及后继版中用$TTL控制语句。名字服务器在查询响应中提供这个值，
允许其它服务器将数据在缓存中存放TTL所指定的时间。如果数据不是经常变动的，可以
考虑把它的值设为几天，1周大概是使之有意义的最大值。1小时会引起不必要的DNS流量。
如：$TTL 3h
SOA记录
表示对于该区数据而言，这个名字服务器是最好的信息来源。根据这个SOA记录，我们的
名字服务器就享有对该区的权威。
movie.edu IN SOA terminator.movie.edu. al.robocop.movie.edu. (
1 ;序列号
3h ;3小时后刷新
1h ;1小时后重试
1w ;1周后期满
1h) ;否定缓存TTL为1小时
IN 代表Internet类
terminator.movie.edu. 代表主名字服务器
al.robocop.movie.edu. 把第一个点号换成@,代表邮件地址，对电脑没意义，只对人有意义
在反解文件的头几行也添加类似的SOA记录。在这些文件中把movie.edu改为
249.249.192.in-addr.arpa
NS记录
在文件中添加的下一条记录是NS记录。这些记录表明区movie.edu有两个名字服务器。这
些名字服务器运行在主机terminator.movie.edu and wormhole.movie.edu上。
movie.edu IN NS terminator.movie.edu
movie.edu IN NS wormhole.movie.edu
同SOA记录一样，也在反解文件中添加记录
地址和别名记录
接下来创建名字到地址的映射
；主机地址
localhost.movie.edu. IN A 127.0.0.1
robocop.movie.edu. IN A 192.249.249.2
terminator.movie.edu. IN A 192.249.249.3
misery.movie.edu. IN A 192.249.253.2
;
;多宿主主机
wormhole.movie.edu. IN A 192.249.249.1
wormhole.movie.edu. IN A 192.249.253.1
;
;别名
bigt.movie.edu. IN CNAME terminator.movie.edu.
wh.movie.edu. IN CNAME wormhole.movie.edu.
wh249.movie.edu IN A 192.249.249.1
wh253.movie.edu IN A 192.249.253.1
像bigt.movie.edu这样的别名不能出现在资源记录的右边。换名话说，在资源记录的数据部
份总是要使用规范名（terminator.movie.edu）。
如果一台主机是多宿主的（具表不止一个网络接口），让每个接口对应一个唯一的别名，再
为这个别名创建一个地址（A）记录，为每个对所有地址都通用的别名创建一个CNAME记
录。能否在所有情况下都使用地址记录而不用CNAME记录呢？大部份程序是可以的，但
sendmail会有问题。sendmail通常用规范名替换邮件首部中所有使用的别名，只有当邮件首
部中的名字有相关的CNAME记录时才进行这种规范化。如果你的别名没有对应的CNAME
记录，你的SENDMAIL就必须知道你的主机所有可能为外界所知的别名，这就要求你对
SENDMAIL进行一些额外的调整。
PTR记录
创建地址到名字的映射，使用PTR资源记录
1.249.249.192.in-addr.arpa. IN PTR wormhole.movie.edu.
2.249.249.192.in-addr.arpa. IN PTR robocop.movie.edu.
3.249.249.192.in-addr.arpa. IN PTR terminator.movie.edu.
对于192.249.253/24也创建类似的数据。
需要设置回送网络的正反解文件。如果没有则查找127.0.0.1就会失败。
根线索（root hint）数据。从ftp.rs.internic.net里上载。
建立BIND配置文件
从版本4到版本8，BIND配置文件的语法变化非常大，版本8到版本9没有变化。可以通
过运行named-bootconf程序把版本4的配置文件转换成版本8的文件。这个程序随BIND源
码一起发布。
h2n工具是一个PERL脚本，用来把HOSTS文件转换成区数据文件。
运行名字服务器
#named
设置本地域名，这样可以直接查找主机名而不用加上域名。有两种方法设置：hostname or
/etc/resolv.conf。在resolv.conf的第一行加入domain movie.edu。或者在terminator主机上
把hostname设置为terminator.movie.edu。不要在名字后加点号。
用远程的名字服务器来查找你的区中的域名,把本地域名作为第一个参数，远程名字服务器
作为第二个参数。如果失败，可能是你的区还没有向你的父名字服务器注册。需与父域管理
员联系，检查区授权。
# nslookup carrie getekeeper.dec.com
运行辅名字服务器
需要再建立一个名字服务器以增强DNS的健壮性。以便分担负荷和容错。在named.conf文
件中定义是主还是辅服务器。主要区别是主名字服务器从区数据文件中读取数据，辅服务器
是通过网络从其它的名字服务器装载数据的，这个过程称为“区传送”（zone transfer）。
建立
在辅名字服务器建立区数据文件目录（/etc/named），并把named.conf,named.root,db.127.0.0
这三个文件拷贝过来。修改配置文件，把域的master改为slave,然后添加一个带主服务器ip
地址的masters行。例如：
zone “movie.edu” in {
type master;
file “db.movie.edu”;
};
改为
zone “movie.edu” in {
type slave;
file”bak.movie.edu”; 如果不想在辅名字服务器上保存区数据文件的备份，可以删除这
行。
masters {192.249.249.3};
};
SOA值
序列号：格式为yyyymmddnn，nn代表这一天是第几次修改。在每次更新了你的区数据后
不要忘了增加序列号的值。辅名字服务器通过比较这个序列号是否加载一份新的区数据拷
贝。
refresh（刷新）：告诉该区的辅名字服务器相隔多久检查该区的数据是否是最新的。
retry（重试）：如果辅名字服务器超过刷新间隔时间后无法访问主服务器，那么它就开始隔
一段时间重试连接一次。这个时间通常比刷新时间短，但也不一定非要这样。
expire（过期或期满）：如果在期满时间内辅名字服务器还不能和主服务器连接上，辅名字服
务器就使用这个我失效。这就意味着辅名字服务器将停止关于该区的回答，因为这些区数据
太旧了，没有用了。设置时间要比刷新和重试时间长很多，以周为单位是较合理的。
否定缓存TTL（生存期）：这个值对来自这个区的权威名字服务器的否定响应都适用。
新版的bind的时间设置灵活了很多，以前只接收以秒为单位（一周有608400秒）。现在可
以用h（小时）,d（天）,w（周）表示。
RFC1537建议顶级名字服务器采用以下值：
refresh 24h
retry 2h
expire 30d
否定缓存ttl 4d
新版8，9改变了区数据传播的方式，轮询的特性还在，但增加了当区数据改变后进行通知
的功能，在15分钟之内通知辅名字服务器，要加载该区的一份新的拷贝了。
多个主服务器
可配置最多十个主名字服务器，以分号分隔。辅名字服务器会依序尝试每个IP地址对应的
主服务器。一直到收到回答为止。但从8.2以后，辅服务器会查询所有的主服务器，从具有
最高序列号的服务器那里传送区数据。
第五章 DNS与电子邮件
DNS与主机表相比的一个优势在于支持高级邮件路由。当邮件收发器只用HOSTS文件工作
时，所能做的最多也就是试着把邮件直接发送到主机的IP地址，如果失败，要么延迟发送，
过一会再重试，要么就将邮件退回给发送者。dns提供一种机制，能为邮件的发送者指定备
份主机，它还允许一台主机为别的主机承担邮件处理任务。
DNS用一种资源类型来实现增强的邮件路由，那就是MX记录。它为一个域名指定一个邮
件交换器。它是一台主机，负责处理或转发该域名的邮件。还定义了一个优先级值，它决定
了邮件收发器使用它们顺序，优值小的先使用。
peets.mpk.ca.us. IN MX 10 relay.hp.com 指定relay.hp.com是peets.mpk.ca.us的邮件交
换器，优先级是10
第六章 配置主机
reslov.conf中有五个命令可你使用，domain,search,nameserver,sortlist,options。
domain定义本地域名，从第一行开始，后跟一个空格，然后是本地域名，本地域名后面不
要有点号。
例如：domain movie.ecu
LOCALDOMAIN环境变量也可以设置每个用户的本地域名。
建议使用hostname设置。
search指令
search corp.hp.com paloalto.hp.com hp.com
解析器会首先搜索corp.hp.com，然后是paloalto.hp.com，再是这两个域的父域hp.com。
nameserver指令
默认地，解析器首先查找本地上的名字服务器，也可以通过该指令指示解析器去使用其它主
机的域名服务器。
nameserver 15.32.17.2
nameserver 15.32.17.3 （可指定多个服务器）
注意：在多个nameserver的情况下不要使用回送地址。
sortlist指令
当查询收到的响应包括多个地址时，该设置允许你选择更希望使用的子网和网络。
sortlist 128.32.42.0/255.255.255.0 最多可指定十个优先的子网和网络。
options指令
options debug 设置RES_DEBUG,在标准输出上产生大量调试数据。前提是在编译BIND时
定义了DEBUG参数。
options ndots:2 如果域名参数中的点号大于或等于这个值，那么解析器会在使用搜索列表
之前，先查找这个域名。如果你相信你的用户更有可能输入部份域名而需要使用搜索列表时，
你可以增加这个值。
8.2版引入以下选项
options attempts:2 允许你指定在放弃之前向resolv.conf文件中每个名字服务器发送查询的
次数。
options timeout:2 指定每个对resolv.conf文件中名字服务器的查询的初始超时时间。默认为
5，最大为30。对第二轮以及接下来的几轮查询，解析器会把初始超时时间加倍。再除以
resolv.conf中文件服务器的数量。
options rotate 使你的解析器能使用resolv.conf文件中所有的名字服务器。从而分散负载。默
认只要第一台服务器正常，解析器是不会去查询其它服务器。
options no-check-names 关掉解析器的名字检查功能，默认是打开的。它检查响应的域名是
否合法。
如果你想指定多个选项，可以把它们写成一行：
options attempts:4 timeout:2 ndots:2
第七章 维护BIND
BIND9与8一样，也用controls来决定服务器如何监听控制信息的。
controls {
inet * allow {any;} keys {“rndc-key”}
};
这决定了rndc用户要用什么加密密钥来验证身份才能给服务器发送控制信息。如果没有指
定keys，服务器启动时会出错
key “rndc-key” {
algorithm hmac-md5;
secret “xxxxx”;
};
为安全起见，使用包括文件：
include “/etc/rndc.key”。唯一支持的算法是HMAC-MD5。
要使用rndc，你需要创建一个rndc.conf文件告诉rndc要用哪个认证密钥。而哪些名字服务
器要使用它们。
options {
default-server localhost;
default-key “rndc-key”;
};
key “rndc-key” {
algrithm hmac-md5;
secert “xxxxx”;
};
更新区数据文件，两种方法，手工 或 h2n。
重新开始一个SOA序列号。改变主服务器序列号，重启，停止辅服务器，删除所有备份区
数据文件。因为备份文件被删除，所以辅服务器就会加载一个新的区数据文件，这个区数据
文件就是最新的。
TXT
xxx IN TXT “this is a test” 限制2K字符串数据
RP 负责人邮件地址
robocop IN RP root.movie.edu
组织文件
当域大的时候，区数据文件就会越来越多，有两个命令可以帮助我们组这些文件:
$ORIGIN 改变一个区数据文件的起点
$INCLUDE 在当前区数据文件中插入一个新文件
改变系统文件的位置，主要是从安全角度考虑。
options {pid-file “server1.pid”;} 改变PID的文件名，可以在一台主机上运行两个名字服务
器。
options {named-xfer “/HOME/….”;} 在9版中没有这个文件。
options {dump-file “/home/yangjing/named/named_dump.db”;} 服务器转储数据库
options {statistics-file “/home/yangjing/named/named.stats”;} 服务器统计数据
日志
有七个级别,允许存在文件中或伸用syslog日志系统。
critical
error
warning
notice
info
debug [level] dns服务器特有
dynamic dns服务器特有
语法如下：
logging {
[ channel channel_name {
( file path_name
[ versions ( number | unlimited ]
[ size size_spec ]
| syslog ( kern | user | mail | daemon | auth | syslog | lpr |
news | uucp | cron | authpriv | ftp |
local0 | local1 | local2 | local3 |
local4 | local5 | local6 | local7
| null ;
[ severity ( critical | error | warning | notice |
info | debug [ level ] | dynamic ; ]
[ print-category yes_or_no; ]
[ print-severity yes_or_no; ]
[ print-time yes_or_no; ]
}; ]
[ category category_name {
channel_name; [ channel_name; ... ]
}; ]
…
};
example:
logging {
channel my_syslog {
syslog daemon;
severity info;
};
channel my_file {
file “my_named.log” versions 3 size 10k;
severity dynamic;
print-category yes; 在日志中输出附加信息：消息类别，严重性，时间。
print-severity yes;
print-time yes;
};
category default {unll;}; 如果对于某个类别你没有指定任何通道，那么就会把这些消息发
送到default类所分配的通道中。
category statistics {my_syslog;my_file;};
category queries {my_file;};
};
要记录这些日志，还要再打开名字服务器的调试功能。
#rndc trace
versions 3 文件版本，会保存file，file.0,file.1,file.2，如果不设置将有99个版本。在服务
器启动和重新加载时将file.1-file.2,file.0-file.1,file-file.0。
size 10k 文件的大小限制。
default_stderr通道可把信息写到服务器的stderr中。
null通道可以用来丢弃不想要的信息。
bind9类别
general 包括所有未明确分类的信息。
client 处理客户端请求
config 配置文件分析和处理
database 数据库相关信息
dnssec 处理DNSSEC签名响应
lame-servers 发现错误授权
network 网络操作
notify 异步区变动通知
queries 查询日志
resolver 名字解析，包括对来自解析器的递归查询的处理
security 认可/非认可的请求
update 动态更新事件
xfer-in 从远程名字服务器到本地服务器的区传送
xfer-out 从本地到远程的区传送
第八章 扩展你的域
第九章 担当父域
第十章 高级特性
新版BIND8.1.2 9.10有大量的新特性，其中最突出的是支持DNS动态更新，异步区变动通
知（NOTIFY)，以及增量区传送。
地址匹配列表和ACL
acl name {address_match_list;}; 定义一个列表，以后可用name引用
acl “hp-net” {192.168.1.192/26;};
有四个预定义的列表：none，没有任何IP地址；any，所有IP地址；localhost，本地主机的
任一IP地址；localnets，本地主机任一网络接口所在的网络。
第十一章 安全
限制查询 allow-query{}
防止未授权的区传送 allow-transfer{}
以最小权限运行bind，-u 以该用户运行， -g 以该组运行，-t 使用chroot()转到的目录。
使用chroot步骤见书例子。
第十二章 nslookup and dig
各大网站域名服务器测评
2007年11月9日 尚無評論
1、 Sina.com.cn
http://www.dnsstuff.com/tools/dnsreport.ch?domain=sina.com.cn
Parent
INFO NS records at parent serversYour NS records at the parent servers are: ns2.sina.com.cn. [61.172.201.254 ] [TTL=21600] [CN]
ns3.sina.com.cn . [202.108.44.55] [TTL=21600] [CN]
ns1.sina.com.cn. [202.106.184.166] [TTL=21600] [CN]
[These were obtained from cns.cernet.net]
NS INFO Nameservers versions Your nameservers have the following versions: 61.172.201.254: No version info available (refused).
202.108.44.55: No version info available (refused).
202.106.184.166: No version info available (refused).
SOA
WARN SOA Serial NumberWARNING: Your SOA serial number is: 5. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.
WARN SOA MINIMUM TTL valueWARNING: Your SOA MINIMUM TTL is : 600 seconds. This seems low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.
规范等级：中
http://www.dnsstuff.com/tools/dnsreport.ch?domain=sina.com
Parent
INFO NS records at parent serversYour NS records at the parent servers are: ns1.sina.com.cn. [ 202.106.184.166 (NO GLUE)] [CN]
ns2.sina.com.cn. [61.172.201.254 (NO GLUE)] [CN]
ns3.sina.com.cn. [202.108.44.55 (NO GLUE)] [CN]
[These were obtained from l.gtld-servers.net]
WARN Glue at parent nameservers
WARNING. The parent servers (I checked with l.gtld-servers.net.) are not providing glue for all your nameservers. This means that they are supplying the NS records ( host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause incompatibilities with some non-RFC-compliant programs. This is perfectly acceptable behavior per the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of ” ns1.example.org” for the domain “example.com“). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain.
NS
WARN Nameservers on separate class C’s
WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.
INFO Nameservers versionsYour nameservers have the following versions: 202.106.184.166: No version info available (refused).
61.172.201.254 : No version info available (refused).
202.108.44.55: No version info available (refused).
WARN Nameservers on separate class C’s
WARNING: We cannot test to see if your nameservers are all on the same Class C (technically, /24) range, because the root servers are not sending glue. We plan to add such a test later, but today you will have to manually check to make sure that they are on separate Class C ranges. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.
SOA WARN SOA MNAME Check
WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: sina.com. . However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.
WARN SOA REFRESH value
WARNING: Your SOA REFRESH interval is : 900 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.
WARN SOA MINIMUM TTL value
WARNING: Your SOA MINIMUM TTL is : 300 seconds. This seems low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.
规范等级：低
2、 sohu.com
http://www.dnsstuff.com/tools/dnsreport.ch?domain=sohu.com
Parent
INFONS records at parent serversYour NS records at the parent servers are:dns.sohu.com. [61.135.131.86] [TTL=172800] [CN]
ns1.sohu.com. [61.135.131.1] [TTL=172800] [CN]
ns3.sohu.com. [220.181.26.168] [TTL=172800] [CN]
[These were obtained from a.gtld-servers.net]
NS
WARN Single Point of Failure
WARNING: Although you have at least 2 NS records, and they appear to point to different physical servers, it appears that they block the ICMP packets used as part of our test, which means that they may share the same firewall. If they share the same firewall, this results in a single point of failure, which could cause all your DNS servers to be unreachable.
INFO Nameservers versionsYour nameservers have the following versions:61.135.131.86: ” ”
61.135.131.1: ” ”
220.181.26.168: ” ”
SOA
FAILSOA MINIMUM TTL value
WARNING: Your SOA MINIMUM TTL is : 60 seconds. This seems very low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.
规范等级：高
3、163.com
http://www.dnsstuff.com/tools/dnsreport.ch?domain=163.com
Parent
INFO NS records at parent serversYour NS records at the parent servers are:ns.nease.net. [202.106.185.75] [TTL=172800] [CN]
ns3.nease.net. [220.181.28.3] [TTL=172800] [CN]
[These were obtained from a.gtld-servers.net ]
NS
INFO Nameservers versions Your nameservers have the following versions: 202.106.185.75: “9.2.3″
220.181.28.3: “9.2.3″
SOA
FAILNS agreement on SOA Serial #
ERROR: Your nameservers disagree as to which version of your DNS is the latest (20011937 versus 20011938). This is OK if you have just made a change recently, and your secondary DNS servers haven’t yet received the new information from the master. I will continue the report, assuming that 20011938 is the correct serial #. The serial numbers reported by each DNS server are:
202.106.185.75: 20011938
220.181.28.3: 20011937
WARN SOA Serial Number
WARNING: Your SOA serial number is: 20011938. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.
规范等级：中
http://www.dnsstuff.com/tools/dnsreport.ch?domain=nease.net
Parent
INFO NS records at parent serversYour NS records at the parent servers are: ns.nease.net. [202.106.185.75] [TTL=172800] [CN]
ns3.nease.net. [220.181.28.3] [TTL=172800] [CN]
[These were obtained from j.gtld-servers.net]
NS
INFO Nameservers versions Your nameservers have the following versions: 202.106.185.75: “9.2.3″
220.181.28.3: “9.2.3″
SOA
WARN SOA Serial Number
WARNING: Your SOA serial number is: 991160. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where ‘nn’ is the revision. For example, if you are making the 3rd change on 02 May 2006, you would use 2006050203. This number must be incremented every time you make a DNS change.
WARN SOA EXPIRE value
WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.
规范等级：中
4、 tom.com
http://www.dnsstuff.com/tools/dnsreport.ch?domain=tom.com
Parent
INFO NS records at parent serversYour NS records at the parent servers are: brown.hutchcity.com. [202.45.84.67] [TTL=172800] [HK]
edns.wyith.net. [202.181.240.44] [TTL=172800] [HK]
ns1.tom.com. [61.135.159.46] [TTL=172800] [CN]
ns2.tom.com. [61.135.159.47] [TTL=172800] [CN]
[These were obtained from f.gtld-servers.net ]
NS
FAILOpen DNS servers
ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn’t happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are: Server 202.45.84.67 reports that it will do recursive lookups. [ test] Server 202.181.240.44 reports that it will do recursive lookups. [ test] Server 61.135.159.46 reports that it will do recursive lookups. [ test] Server 61.135.159.47 reports that it will do recursive lookups. [test] See this page for info on closing open DNS servers.
FAIL Lame nameservers
ERROR: You have one or more lame nameservers. These are nameservers that do NOT answer authoritatively for your domain. This is bad; for example, these nameservers may never get updated. The following nameservers are lame:
202.45.84.67
FAIL Missing nameservers 2
ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are:
brown.hutchcity.com.
edns.wyith.net.
WARN All nameservers report identical NS records
WARNING: Your nameservers report somewhat different answers for your NS records (varying TTL, for example).
INFO Nameservers versions Your nameservers have the following versions: 202.45.84.67: “8.3.4-REL”
202.181.240.44: “4.9.6-REL”
61.135.159.46: “TOM.COM DNS Server 2.00″
61.135.159.47 : “TOM.COM DNS Server 2.00″
规范等级：低
5、qq.com
http://www.dnsstuff.com/tools/dnsreport.ch?domain=qq.com
Parent
INFO NS records at parent serversYour NS records at the parent servers are:dns1.imok.net. [219.133.40.202] [TTL=172800] [CN]
dns2.imok.net. [61.152.100.5] [TTL=172800] [CN]
[These were obtained from e.gtld-servers.net ]
NS
WARN Single Point of Failure
WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.
INFO Nameservers versions Your nameservers have the following versions: 219.133.40.202: “9.3.2″
61.152.100.5: “9.3.0rc4″
SOA
WARN SOA MNAME Check
WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: qq.com.. However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.
WARN SOA REFRESH value
WARNING: Your SOA REFRESH interval is : 300 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.
WARN SOA EXPIRE value
WARNING: Your SOA EXPIRE time is : 86400 seconds. This seems a bit low. You should consider increasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.
规范等级：低
http://www.dnsstuff.com/tools/dnsreport.ch?domain=imok.net
Parent
INFO NS records at parent serversYour NS records at the parent servers are:dns1.imok.net. [219.133.40.202] [TTL=172800] [CN]
dns2.imok.net. [61.152.100.5] [TTL=172800] [CN]
[These were obtained from j.gtld-servers.net ]
NS
WARN Single Point of Failure
WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.
INFO Nameservers versions Your nameservers have the following versions: 219.133.40.202: “9.3.2″
61.152.100.5: “9.3.0rc4″
SOA
WARN SOA MNAME Check
WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: imok.net. . However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing.
WARN SOA REFRESH value
WARNING: Your SOA REFRESH interval is : 360 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.
WARN SOA EXPIRE value
WARNING: Your SOA EXPIRE time is : 3600000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.
规范等级：低
6、 baidu.com
http://www.dnsstuff.com/tools/dnsreport.ch?domain=baidu.com
Parent
INFONS records at parent serversYour NS records at the parent servers are:dns.baidu.com. [202.108.250.228] [TTL=172800] [CN]
ns2.baidu.com. [202.108.249.147] [TTL=172800] [CN]
ns3.baidu.com. [220.181.27.61] [TTL=172800] [CN]
ns4.baidu.com. [220.181.27.62] [TTL=172800] [CN]
[These were obtained from m.gtld-servers.net]
NS
FAIL Missing (stealth) nameservers
FAIL: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNS Report will not query these servers, so you need to be very careful that they are working properly. ns1.baidu.com.
This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example).
WARN TCP Allowed
WARNING: One or more of your DNS servers does not accept TCP connections. Although rarely used, TCP connections are occasionally used instead of UDP connections. When firewalls block the TCP DNS connections, it can cause hard-to-diagnose problems. The problem servers are: 202.108.249.147: Error [No response to TCP packets].
220.181.27.61: Error [No response to TCP packets]. 220.181.27.62: Error [No response to TCP packets].
WARN Single Point of Failure
WARNING: Although you have at least 2 NS records, there is a chance that they may both point to the same server (one of our two tests shows them being different, the other is unsure; it appears that there are one or more firewall(s) that intercept and alter DNS packets (some versions of Linux reportedly have a built-in firewall that does this, too)), which would result in a single point of failure. You are required to have at least 2 nameservers per RFC 1035 section 2.2.
INFO Nameservers versions Your nameservers have the following versions: 202.108.250.228: “diy by bind”
202.108.249.147: “9.2.1 ”
220.181.27.61: “9.2.1″
220.181.27.62: “9.2.1″
FAIL Stealth NS record leakage
Your DNS servers leak stealth information in non-NS requests:
Stealth nameservers are leaked [ns1.baidu.com.]!This can cause some serious problems (especially if there is a TTL discrepancy). If you must have stealth NS records (NS records listed at the authoritative DNS servers, but not the parent DNS servers), you should make sure that your DNS server does not leak the stealth NS records in response to other queries.
SOA
WARN SOA REFRESH value
WARNING: Your SOA REFRESH interval is : 300 seconds. This seems low. You should consider increasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). A value that is too low will unncessarily increase Internet traffic.
WARN SOA EXPIRE value
WARNING: Your SOA EXPIRE time is : 2592000 seconds. This seems a bit high. You should consider decreasing this value to about 1209600 to 2419200 seconds (2 to 4 weeks). RFC1912 suggests 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can’t reach the primary nameserver.
规范等级：中
7、 google.com
http://www.dnsstuff.com/tools/dnsreport.ch?domain=google.com
Parent
INFO NS records at parent servers Your NS records at the parent servers are: ns1.google.com. [216.239.32.10] [TTL=172800] [US]
ns2.google.com. [216.239.34.10 ] [TTL=172800] [US]
ns3.google.com. [ 216.239.36.10] [TTL=172800] [US]
ns4.google.com . [216.239.38.10] [TTL=172800] [US]
[These were obtained from k.gtld-servers.net]
NS
INFO Nameservers versions Your nameservers have the following versions: 216.239.32.10: No version info available (refused).
216.239.34.10: No version info available (refused).
216.239.36.10: No version info available (refused).
216.239.38.10: No version info available (refused).
SOA
FAILSOA MINIMUM TTL value
WARNING: Your SOA MINIMUM TTL is : 60 seconds. This seems very low (unless you are just about to update your DNS). You should consider increasing this value to somewhere between 3600 and 10800. RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.
规范等级：中