DNS&&BIND

时间 2019-11-22

原文原文链接

DNS：Domain Name Server，应用层协议，属于C/S架构，使用tcp和udp(经常使用)的53号端口;web

咱们知道，当咱们访问互联网上的资源时，都须要具备一个IP地址，可是咱们要访问的资源有不少，咱们是没法记住各个资源的IP地址的，因此咱们有个解决办法就是使用主机名来对应IP地址，由于人类对于记忆名字仍是比较拿手的，那么问题又来了，仍是数量的问题，当名字不少时咱们仍是没法记住，因此又有一个解决办法出现了，那就是把名字和IP地址都记录在文件中，须要访问资源的时候，让计算机本身查找文件来实现访问资源；那么问题又出现了，仍是数量的问题，当计算机不算多的时候使用文件记录还能够，可是互联网上那么多主机，仅仅使用一个文件来记录，当计算机查找IP地址时的速度可想而知有多么慢，而且网络上的主机名是随时都会修改，增长和删除的，咱们也没法实时的到最新的对应关系，因此dns服务就出现了，它能够解决如今互联网主机不断增多已经没法使用hosts文件来记录主机名的情况；数据库

咱们把这些数据都放在服务器上是为了方便而且但愿它能够增长速度，可是把这些数据单纯的放在服务器上，而后去查找真的会节省时间吗，答案是否认的，没准还会浪费时间那，由于多了一步交互的过程；因此为了加速，其实在服务器启动时就已经对本地的全部名字和地址的对应关系分别作了hash，而且把它放在内存中，当有客户端来请求数据时，直接比对hash值，不一样则响应回答，发送最新的对应关系数据，而且在hash后获得的都是16进制数，服务器会对它们作分类处理，好比首个字符相同则存在一块儿，这样的话在查找时只需在16个字符中查找便可，而后再分层往下查找，因此会节省不少时间，由于是在内存中，中因此会更快；又该可是了，互联网上的主机真的是多的没法查清啊，因此咱们使用一台或者一个群组来管理这些主机名和ip的对应关系是不现实的，所以就想出了一个解决办法，把主机名的命名名称分层，每一个服务器之管理本身下一层的域名；<==分布式查找缓存

tcp：面向链接的协议，稳定；安全

udp：无链接的协议，速度快；服务器

当主机想要经过主机名来访问网络资源时，首先会调用一个底层的库文件，这个文件会扮演成客户端，根据本地事先配置的dns服务器地址，到这台服务器去请求主机名对应的IP地址，待服务器返回IP地址后，就能够经过这个IP地址来访问资源了；这一步对于访问资源实际上是多余的，很浪费时间，因此咱们就想让它越快越好，所以选择了udp协议；网络

BIND：Bekerlay Internat Name Domain架构

IANA：分配域名的机构，任何人想本身构建网站而且须要经过域名来访问，那么就须要到这个机构去注册域名，各地都会有相关的注册机构，各类手续办完以后，就能够在全世界范围内访问记得域名了（可能会等一段时间：机构录入信息和各地服务器更新学习都须要时间）；dom

本地名称解析配置文件：/etc/hosts，主机名找IP地址tcp

格式： IP地址主机名分布式

例子： 192.168.203.129 www.chen.com

DNS树状结构：namespace

DNS树状结构：最上层为根(.)，下面有不少顶级域名(com,org,net等)，之下还有二级域名(通常企业或我的注册的域名就属于二级域名)；

Top Level Domain：tld

组织域：com，edu，mil，gov，net，int等；

国家域：cn，iq，hk等；

反向域

DNS查询类型：

递归查询：把请求发送给别人，让它去代替本身查询，而后等待结果便可，通常主机经过本身的服务器查询就是递归；

迭代查询：一步一步的按级查找，不是必定会直接获得结果，可能会通过屡次查找，通常服务器帮主机查找就是迭代；

名称服务器：域内负责解析本域名内的名称的主机；域只是一个概念上的区域，它须要一个或一组主机来实现它，那个它就是名称服务器，通常使用"ns"命名；

根服务器：世界上有13组根服务器；

解析类型：

正向解析：FQDN→Ip

反向解析：Ip→FQDN

正反向各须要一个解析库来分别负责本地域名的正反和反向解析；

FQDN：彻底合格域名；

例子：www.chen.com.

查找过程：自顶向下查找；

好比查找www.chen.com 这个主机时，首先会去寻找根(.)，跟一看不是本身直接管理的主机，可是是属于本身管理的com域中的主机，因此就将com域的信息发给客户端，客户端再去com域找，com域发现是本身管理的主机，就将www主机的IP地址返回给客户端，客户端就能够链接www.chen.com了；

详细过程：

Client→hosts文件→DNS Server：Local Cache→DNS Server(recursion递归)→Server Cache→iteration(迭代)→自顶向下查找过程；

客户端首先会检查hosts文件，若是没有则会检查本地缓存，如若尚未则会到事先设置的主dns服务器查询，服务器首先会检查本身的缓存，如若没有才会去迭代查询，最后将结果返回给客户端；

DNS服务器的类型：

主DNS服务器：维护所负责解析的域内解析库服务器，解析库由管理员维护，可使手动的也可使用软件；

辅助(从)DNS服务器：从主DNS服务器或其余的从DNS服务器那里"复制"(区域传送)一份解析库文件；

主从服务器须要保持数据的统一，故从服务会按期到主服务器那里更新数据；主从之间根据序列号的大小来标识数据的新旧；

序列号：解析库的版本，主服务器解析库内容发生改变，序列号增大(越大越新)；

刷新时间间隔：从服务器从主服务器那里请求同步解析库的时间间隔；

重试时间间隔：从服务器从主服务器那里请求同步解析库失败时，再次尝试的时间间隔；

过时时长：从服务器始终联系不到主服务器时，多久放弃从服务器角色，中止提供服务(不会抢占成为主服务器)；

区域传送：

全量传送：传送整个解析库数据；

增量传送：仅传送解析库变化的那部分数据；

缓存DNS服务器：没有在互联网上注册域名，只是让客户端将它当作DNS服务器，当客户端请求解析时，它会去请求真正提供DNS解析服务的服务器帮它解析，而后将DNS服务器返回的结果保存一份在本身的本地缓存中，而后再发送给客户端；这样能够减轻公网带宽的负担；提供的是递归查询；

转发器

子域受权：每一个域的名称服务器，都是经过其上级名称服务器在解析库中进行受权的；

chen.com. 受权过程：

相似根域受权tld：

.com. IN NS ns1.com.

.com. IN NS ns2.com.

ns1.com. IN A 9.9.9.9

ns2.com. IN A 10.10.10.10

chen.com.在.com(9.9.9.9)的名称服务器上的解析库中添加资源记录；

chen.com. IN NS ns1.chen.com.

chen.com. IN NS ns2.chen.com.

ns1.chen.com. IN A 6.6.6.1

ns2.chen.com. IN A 6.6.6.2

chen.com.(6.6.6.1)本地设置；

chen.com. IN NS ns1.chen.com.

ns1.chen.com. IN A 6.6.6.1

www.chen.com. IN A 3.3.3.1

域名注册：

中国代理商：万网，新网；

外国代理商：godaddy

BIND的安装配置：

dns服务：程序包名；bind，程序名：named；

程序包：

bind：主程序；

bind-libs：band和相关命令使用的函数库；

bind-utils：客户端查找主机名的相关命令；(host,dig,nslookup)

bind-chroot：将bind主程序的根目录限制到/var/named/chroot

Note：测试环境能够不装，生产环境建议安装；

bind：

服务脚本：/etc/rc.d/init.d/named

主配置文件：/etc/named.conf,/etc/named.rfc1912.zones,/etc/rndc.key

全局配置：options { }

日志子系统配置：logging { }

区域定义；本机可以为哪些zone提供解析，就要定义哪些zone；

zone "ZONE_NAME.zone" IN { }

注意：任何服务程序若是指望其可以经过网络被其余主机访问，至少应该监听在一个能与外部主机通讯的ip地址上

解析库文件：/var/named/ZONE_NAME.zone

注意：

1.一台物理服务器可同时为多个区域提供解析；

2.必需要有根区域文件；

3.应该有两个实现localhost和本地回环地址的解析库，用来联系本身；

rndc：remote name domain controller，默认与bind安装在同一主机，且只能经过127.0.0.1来链接named进程；提供辅助性的管理功能；使用953/tcp

缓存名称服务器的配置：

监听外部地址便可；

dnssec：与dns的安全有关，对dns服务解析时的每个解析包文都要加数字签名，作校验，但配置麻烦；测试环境建议关闭，在配置文件中便可关闭 "dnssec-enable no"；

主zone DNS名称服务器：

正向解析：

1.在主配置文件中定义区域；/etc/named.conf：

options {

listen-on port 53 { 192.168.10.20; 127.0.0.1; };

// listen-on-v6 port 53 { ::1; };

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

memstatistics-file "/var/named/data/named_mem_stats.txt";

allow-query { any; };

recursion yes;

// dnssec-enable yes;

// dnssec-validation yes;

/* Path to ISC DLV key */

bindkeys-file "/etc/named.iscdlv.key";

managed-keys-directory "/var/named/dynamic";

};

/etc/named.rfc1912.zones：

zone "chen.com" IN {

type master ;

file "chen.com.zone" ;

};

zone "10.168.192.in-addr.arpa" IN {

type master ;

file "10.168.192.in-addr.arpa.zone" ;

};

2.定义区域解析库文件；/var/named/chen.com.zone

宏定义:

$TTL 时间(s)

$ORIGIN 域名(chen.com.)

资源记录:

/var/named/chen.com.zone ：

$TTL 86400

@(代指区域) IN SOA na1.chen.com.(区域名或者主dns服务器名) admin.chen.com.(管理员邮箱地址) (

2018103001 序列号

1H 更新时间

5M 失败后重连时间

7H 失效时间

1D 缓存时间 )

chen.com.(与上一条内容相同，则能够省略) IN NS ns1.chen.com.

chen.com. IN NS ns2.chen.com.

chen.com. IN MX 10 mail.chen.com.

ns1 IN A 192.168.10.20

ns2.chen.com. IN A 192.168.10.1

mail IN A 192.168.10.20

www.chen.com. IN A 192.168.10.20

web.chen.com. IN CNAME www.chen.com.

反向解析：

区域名称：网络地址反写.in-addr.arpa.

192.168.10. →10.168.192.in-addr.arpa.

定义区域：

zone "ZONE_NAME" IN {

type {master|slave|forward};

file "网络地址.zone" ;

};

区域解析库文件：

不须要A,AAAA,MX等记录，以NS及PTR为主；

/var/named/10.168.192.in-addr.arpa.zone ：

$TTL 86400

10.168.192.in-addr.arpa. IN SOA ns1.chen.com. admin.chen.com. (

2018103001

10M

1D )

10.168.192.in-addr.arpa. IN NS ns1.chen.com.

10.168.192.in-addr.arpa. IN NS ns2.chen.com.

20 IN PTR ns1.chen.com.

1 IN PTR ns2.chen.com.

20 IN PTR mail.chen.com.

20 IN PTR www.chen.com.

检查配置文件语法是否有错：

named-checkconf [区域配置文件]

named-checkzone ：检查解析库文件语法是否正确；

例如：named-checkzone "chen.com" /var/named/chen.com.zone

Note：最后须要修改区域文件的权限(640)，属主为root，属组为named；

从zone DNS名称服务器：

定义从区域正向解析：

zone "chen.com" IN {

type slave;

masters { MASTRT_IP; };

file "slaves/chen.com.zone";

};

定义从服务器反向解析：

zone "10.168.192.in-addr.arpa" IN {

type slave;

masters { MASTER_IP; };

file "slaves/10.168.192.in-addr.arpa.zone

通常咱们修改DNS配置的时候都是修改主服务器，不会修改从服务器，因此咱们但愿传送过来的文件，dns服务使用的用户named对它具备读写权限，默认named用户或组对/var/named/目录没有写权限，可是对/var/named/slaves/目录具备读写权限，因此通常默认会将文件放在这个目录中，不然没法从主服务器传输配置文件到从服务器；

咱们上面说过从服务器会定时到主服务器那里同步解析库文件的数据，而且当主服务器修改之后还会主动通知从服务器来作同步，那么是怎么通知的那，其实很简单，就是在主服务器的区域配置文件中要设置从服务器的NS和A的记录，让主服务器能够找到从服务器便可；

主从复制：

1.主从都应该是一台独立的服务器；

2.主服务器的区域解析库文件中必须有一条NS记录是指向从服务器的；

3.从服务器只需定义区域，无需提供解析库文件；解析库文件应该放置于/var/named/slaves/目录中；

4.主服务器容许从服务器作区域传送，通常这个是须要管理员作限制的，只容许从服务器作传送，其余的都应该被禁止；

5.主从服务器时间应该同步，能够经过使用ntp进行同步；

6.bind程序的版本应该保持一致，若是不一致，从应该比主新；

由于正反域都是独立的区域，因此能够独立设置；所以正反、主从服务器可使用多个主机，例如A为正主，B为反主，C为正从，D为反从；若是是三个dns主机，一主两从，可使两个主机是同一个主机的从，也可使一个主机是另外一个从的从；

测试命令：dig，nslookup，host

dig：DNS lookup utility

dig用于测试dns系统，所以不会查询hosts文件；

dig [-t type] name [@server] [query options]

选项：

-x IP_ADDR：反向解析；

-t type：A,PTR,SOA,MX等；

+[no]trace：跟踪解析过程；

+[no]recurse：进行递归解析；

模拟全量区域传送：

dig -t axfr zone_name @server_ipaddr

nslookup：query Internet name servers interactively

nslookup [options] [FQDN] [server]

交互式模式：

nslookup>

server IP：指明使用哪一个DNS server进行查询；

set type=any：列出全部正解信息；

set q=RR_TYPE：指明查询的资源记录类型；

host：DNS lookup utility

host [-a] FQDN [server]

选项：

-a：列出该主机全部相关信息；

-l：列出该domain所管理的全部主机名对应的数据；

-t type：A，PTR，SOA，MX等；

rndc：name server control utility

当dns服务启动时rndc也会跟着启动，它就像服务器同样监听在953端口，咱们能够经过客户端键入rndc命令来管理dns服务；可是默认状况下rndc不容许远程使用，只能够在本地使用；由于若是rndc出现bug被不良人利用岂不是完蛋了；

COMMAND：

reload：重载主配置文件和区域解析库文件；

重载意义重大啊，别看咱们在学习测试时每每随意就从新启动服务，可是在生产环境中服务不是随便就可以重启的，不然可能会形成在成巨大的损失，可能会被炒呦！切记！！！

reload zone：重载区域解析库文件；

retransfer zone：手动启动其他传送过程，且无论序列号是否增长；

notify zone：从新对区域传送发通知；

reconfig：重载主配置文件；

querylog：开启或关闭查询日志；

通常状况处于关闭状态，除非是出现问题时，排错时才建议启动；为了确保突发证况下日志文件不丢失，通常日志都是同步写入的，这样的话就会加大内存与磁盘的I/O，增长服务器负载，因此建议关闭；

trace：递增debug级别；

trace LEVEL：直接设置debug级别；

能够经过rndc-h来查看选项帮助；

本身定义受权子域：分布式数据库；

正向解析区域子域受权：

在上一级服务器中须要定义子区域：

stk.chen.com. IN NS ns1.stk.chen.com.

stk.chen.com. IN NS ns2.stk.chen.com.

ns1.stk.chen.com. IN A 192.168.20.1

ns2.stk.chen.com. IN A 192.168.20.2

在子域中配置主机名：

stk.chen.com. IN NS ns1.stk.chen.com.

stk.chen.com. IN NS ns2.stk.chen.com.

ns1.stk.chen.com. IN A 192.168.20.1

ns2.stk.chen.com. IN A 192.168.20.2

www.stk.chen.com. IN A 192.168.20.10

ftp.stk.chen.com. IN A 192.168.20.20

定义转发服务器：

注意：被要求转发的服务器须要可以为请求者作递归，不然转发请求不予进行；

转发的意义：

咱们假设一种状况，在chen.com.域中有stk.chen.com.这个子域；当子域中www这个主机想访问父域chen.com.中的www主机时，若是不设置转发，则子域中www主机会直接找根来解析父域中的www主机；这是很不合理的，因此咱们在这种状况下就须要设置转发功能；父域查找子域中的主机时就不须要，由于父域是知道子域服务器的位置的；

所有转发：凡是非本机所负责解析的请求，都转交给指定服务器，请求他代为查询，在主配置文件的options中定义；

options {

...

forward {first|only};

forwarders { IP };

}；

first：表示当客户端请求的主机解析不是本身所管理的，就转发给指定服务器，若是他没有返回解析结果，就本身找根去解析；递归不成就迭代；

only：表示当客户端请求的主机解析不是本身所管理的，就转发给指定服务器，哪怕他不给解析，也不作处理，就像把本身的但愿放到了别人的手里；仅递归；

区域转发：仅转发对特定的区域的请求至指定服务器，在区域配置文件中定义；

zone "ZONE_NAME" IN {

type forward;

forward {first|only};

forwarders { IP; };

};

Note：使用yum安装的dnssec是启用的，因此作转发服务器的时候可能会很差使，建议关闭(学习测试环境中)；

dnssec-enable no;

dnssec-validation no;

BIND中基础的与安全相关的配置：

acl：将一个或多个主机归并为一个集合，并经过一个统一的名称调用；

acl ACL_NAME {

IP;

NET/prelen; ==>192.168.10.0/24;

…;

};

bind有四个内置的acl：能够直接调用的；

none：没有主机；

any：任意主机；

local：本机：

localnet：本机的IP同掩码运算后获得的网络地址；

注意：只能先定义，后使用；所以，其通常定义在配置文件中options的前面；

访问控制的指令(能够在options中设置，也能够在zone中)：

allow-query { }；：容许作查询的主机；相似设置白名单；通常是any；

allow-transfer { }；：容许区域传送的主机；白名单；

allow-recursion { };：容许递归的主机；白名单；

allow-update { };：容许更新区域数据库中的内容；通常不容许经过其余服务更新，好比使用DHCP更新，每次重启服务或从新开机时ip地址可能会有变更而致使错误，建议不容许任何人更新=>"none"；

BIND view(视图)：自上而下检查

视图的做用是：能够根据不一样用户访问同一域名时所处的位置不一样而指定不一样的服务器为其解析(经过指定不一样的解析库文件来实现)；

一个bind服务器能够定义多个view，每一个view能够定义一个或多个zone；

每一个view用来匹配一组客户端；

多个view内可能须要对同一个区域解析，可是用不一样的区域解析库文件；

view VIEW_NAME {

…

match-clients { }; 匹配的客户端；

};

能够经过view来实现仅对本身本地管理的客户端进行递归，来自其余的客户端不予递归；

Note：1.一旦使用了view，全部的zone都只能定义在view中；(包括".")

2.仅有必要在匹配到容许递归请求的客户所在view中定义根区域；

3.客户端请求到达时，是自上而下检查每一个view所服务的客户端列表的(像优先被匹配的应该放在上面)；

智能DNS提供商：

dnspod，dns.la