DNS&&BIND

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

我们知道，当我们访问互联网上的资源时，都需要具有一个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：分配域名的机构，任何人想自己构建网站并且需要通过域名来访问，那么就需要到这个机构去注册域名，各地都会有相关的注册机构，各种手续办完之后，就可以在全世界范围内访问记得域名了（可能会等一段时间：机构录入信息和各地服务器更新学习都需要时间）；

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

格式： 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

猜你喜欢