首页 > 代码库 > dns学习(二)

dns学习(二)

1.BIND的组成?
   * named守护进程–用来回答查询结果的
   * 去联系DNS分布式数据库的服务器用来解析主机查询的库例程
   * DNS的一些重要命令:nslookup,dig和host
 
2.名字服务器
   * 权威--一个区的正式代表
      * 主服务器:每个区都有的一个主名字服务器,保存着本区数据的正式拷贝。SA通过编辑这上面的数据文件来更改区数据。
      * 从服务器:每个区可以有多个从服务器(至少一个),它通过“区传送”操作从主服务器上获取它的数据。
      * 存根:类似于从服务器,不过不是必须的,它仅装载主服务器上的NS记录。
      * 非权威--从缓存中读取记录来回答查询,可能数据已过期
         * 高速缓存名字服务器:从一个文件中加载一些根服务器的地址,然后通过缓存由它解析的各个查询的回答来积累它的其余数据。它本身没有数据。
      * 递归--名字服务器要么是递归要么是不递归的。递归的含义是如果它不能回答你的查询,它将自己替你向上级进行查询,知道有结果(真实的结果或者错误的消息)。【等人家干完给本地】
      * 非递归--如果对于你的查询它能回答的,那么它将提供正确的响应,否则它将返回它所推荐的可能知道正确答案的其他域的权威性服务器。客户机必须准备接受并对这些推荐服务器进行操作。【本地继续自己干】
 3.bind服务器配置
      * 配置文件:named.conf
每条语句以分号结束。格式非常重要少一个空格或者少一个分号就会让你郁闷1小时:( ,每条语句以一个标示语句类型的关键词开始。
option语句:指定全局选项,在BIND8中大约有30个选项,9的选项超过50个。这里只介绍常用的。格式如下:
options{
option;
option;

};
version “string”; [服务器的真实版本号] #可以将它真实地版本号隐藏
directory “path”; [启动服务器的目录] #可以让named程序cd到这个目录(绝对路径)中。推荐将所有与BIND相关的配置文件(除了named.conf和resolv.conf)放在/var之下的子目录中。例如/var/named
notify yes | no; [yes]  #如果设为yes,并且named是一个或多个区的主服务器,那么每当区数据库有变化时,将自动通知相应区的从服务器。
recursion yes | no; [yes]  #指定named是否代表客户机查询其它名字服务器。
allow-recursion {address_match_list}; [所有主机] #可以结合上面的选项设置成对自身的客户机允许递归,但对外查询禁止递归
allow-query {address_match_list}; [所有主机]  #指定哪些主机(或网络)可以查询这台名字服务器。
allow-transfer {address_match_listh}; [所有主机]  #指定哪些主机(或网络)可以请求区数据的块传输。
blackhole {address_match_list}; [空]  #标示出您从不希望与之进行通信的服务器,named将不接受来自这些服务器的查询,也不会向他们询问答案。
acl语句:它必须是named.conf中的顶级语句。
acl acl_name{
address_match_list
};
其中,有4个列表是预先定义的:any,localnets,localhost,none
zone语句:是named.conf中的核心语句。将告诉named它具有权威性的区域。并为管理每个区设置适当的选项。zone语句格式根据named在(主服务器,从服务器)中所扮演的角色不同而不同。
4. 配置一个区的主服务器
zone “domain_name”{
type master;
file “path”;
allow-query {address_match_list};      [所有]
allow-transfer {address_match_list};   [所有]
allow-update {address_match_list};     [无]
ixfr-base “pat”;                       [domain_name.ixfr(仅版本8)]
};
5. BIND9中View(视图)的用法 
概述: 
这里摘抄BIND9手册中的一段话"视图是 BIND9 的强大的新功能, 允许名称服务器根据询问者的不同有区别的回答 DNS查询。特别是当运行拆分 DNS 设置而不需要运行多个服务器时特别有用。"手册中说得很明了,只是根据不同的来源DNS服务器做出不同的回应。 
 
 根据不同的源地址,目的地址,解析请求来判断该给客户提供什么样的解析
例授权视图为
view  data-idc-btte {
     match-clients {
          127.0.0.1/8;  #访问来源ip 
 gd; #由 acl 语句定义了的地址表列名
          key mykey; #语句定义了一个用于 TSIG的共享密匙
     }; 
     recursion yes; #使用递归查询
     server 10.0.0.11 { keys { mykey }; }; #主授权服务器
    zone "119.60.113.in-addr.arpa" IN {   ###权威域名管理,从域名服务器
     type slave;                             
     masters { 10.0.0.11; };  #其主是10.0.0.11
     file "slaves/view-idc-btte/zone-arpa-113.60.119";
     };
};
其中
"slaves/view-idc-btte/zone-arpa-113.60.119“ 为IPV4 的反向解析.
$ORIGIN .
$TTL 86400     ; 1 day
119.60.113.in-addr.arpa     IN SOA     ns1.3366.com. postmaster.3366.com. (
                    2012102621 ; serial
                    120        ; refresh (2 minutes)
                    60         ; retry (1 minute)
                    604800     ; expire (1 week)
                    360        ; minimum (6 minutes)
                    )
               NS     ns1.3366.com.
               NS     ns2.3366.com.
               NS     ns3.3366.com.
               NS     ns4.3366.com.
               NS     ns5.3366.com.
               NS     ns6.3366.com.
$ORIGIN 119.60.113.in-addr.arpa.
$TTL 180     ; 3 minutes
currentv          TXT     "arpa/183.60.189"
说明;
反向域名解析(也就是说 IP地址到主机名的翻译)通过in-addr.arpa域和PTR记录实现.。
in-addr.arpa 域入口可以作成最不重要到最重要(least-to-most)顺序,从左至右阅读。这与 IP
地址的通常顺序相反。这样,一台 IP地址为 10.1.2.3 的机器将会右对应的 in-addr.arpa 名称:
3.2.1.10.in-addr.arpa。这个名称应该具有一个 PTR资源记录,它的数据字段是主机名称或者
任意的多重 PTR 记录,如果主机右超过一个名字的话。
例如.在[example.com]域中:
 
$ORIGIN 2.1.10.in-addr.arpa
3 IN PTR foo.example.com.
 
注意:例子中的$ORIGIN行只给例子提供描述,在真实使用中不一定出现,在这出现仅仅
表明例子是域所列源相关的。