標籤彙整: DNS

IPv6

 IPv6Internet Protocol Version 6的缩写,其中Internet Protocol译为“互联网协议”。
  IPv6是IETF(互联网工程任务组,Internet Engineering Task Force)设计的用于替代现行版本IP协议(IPv4)的下一代IP协议。
  目前的全球因特网所采用的协议族是TCP/IP协议族。IPTCP/IP协议族中网络层的协议,是TCP/IP协议族的核心协议。
  目前IP协议的版本号是4(简称为IPv4),它的下一个版本就是IPv6IPv6正处在不断发展和完善的过程中,它在不久的将来将取代目前被广泛使用的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即将进入根服务器 离我们已经很近

 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

转载的评价:
本书是介绍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

各大网站域名服务器测评

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.

规范等级:中

Sina.com

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.

规范等级:高

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

规范等级:中

nease.net

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″

规范等级:低

5qq.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.

规范等级:低

Imok.net

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.

规范等级:中

http://blog.pcstars.tk/2007/11/blog-post_09.html