23---DNS & BIND

来源：互联网发布：分享wifi的软件编辑：程序博客网时间：2024/05/16 04:10

2017.05.26 修正SOA的描述 & 补充主从同步中NS记录作用 & 排版

============

DNS 基本信息

DNS 服务使用 TCP 和 UDP 的 53 端口

FQDN（Fully Qualified Domain Name），就是按标准写的域名

域是一个逻辑概念，就像 IP 地址一样，它也是分级的。IP 分为ABC类，然后下面分子网，子网下面才是主机。域的分级也差不多，级结构如下，父域的DNS 服务器只保存直接子域的信息，而不保存间接子域的信息。一般来讲，子域的 DNS 服务器不保存父域的信息（使用区域转发时，可能会在子域中含有父域的信息）。要了解域，得找到一种弹性的感觉，即. 是一个域cn. 也是一个域 edu.cn. 也是一个域，只不过是大小不同罢了。

==============

DNS 查询流程

下面描述下 www.xidian.edu.cn 的查询过程，以对 DNS 的查询有个感性的认识，我的便携机的 DNS 信息如下（为 DHCP 指派）

[root@os6 ~]# cat /etc/resolv.conf

; generated by /sbin/dhclient-script

search cau.edu.cn freeland

nameserver 202.112.170.14

nameserver 202.112.170.10

nameserver 202.205.81.2

hosts 文件--->本地 DNS Cache--->本地 DNS Server 去DNS体系去找，图中 202.112.170.10 就是一台本地 DNS

PC 对本地 DNS 的查询属于递归查询，一定要等到最终结果（不管是肯定结果还是否定结果）。

本地 DNS 到 DNS 体系中查找属于迭代查询，一级一级挨个儿查询。讲得细一点就是本地 DNS 在本地找不到www.xidian.edu.cn 这个域名的时候，就去 DNS 体系去查。先找根服务器，根服务器一看是 cn. 结尾的域名就告诉 202.112.170.10 去找管 cn. 的服务器，当查询来到管 cn. 这个域的 DNS 服务器时，它一看是要查询的 name 属于 edu.cn. 这个子域，就告诉 202.112.170.10 去找管 edu.cn. 的服务器，同样管理 edu.cn. 这个域的服务器会告诉 202.112.170.10 去找管理 xidian.edu.cn. 这个域的服务器，当查询到达管理 xidian.edu.cn. 的服务器的时候，该服务器一看，这个要查询的 name 归我管啊，于是查询自己的解析库文件把结果返回给 202.112.170.10 上级让查询者去找自己的下一级服务器，我们就称之为上级对下级做了子域授权（后文详细介绍其配置）

上图中黑线匡可以理解为DNS服务器，而框内的内容，即 {.} {cn.} {edu.cn.} {xidian.edu.cn.} 代表的是DNS服务器负责管理的域的名称，而非DNS服务器的主机名。一台DNS服务器可能负责多个域的管理（如西安教育网的 DNS 不只管理 xidian.edu.cn. 还要管理 nwpu.edu.cn 等高校），一个域也可以被多个服务器管理（如根域就被13台根服务器管理）

加了 +trace 可以让查询从根服务器开始，这里做了两次，对比看下：

[root@os6 ~]# dig -t A www.xidian.edu.cn +trace

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> -t A www.xidian.edu.cn +trace

;; global options: +cmd

. 63251 IN NS j.root-servers.net.

. 63251 IN NS l.root-servers.net.

. 63251 IN NS e.root-servers.net.

. 63251 IN NS k.root-servers.net.

. 63251 IN NS a.root-servers.net.

. 63251 IN NS i.root-servers.net.

. 63251 IN NS c.root-servers.net.

. 63251 IN NS g.root-servers.net.

. 63251 IN NS m.root-servers.net.

. 63251 IN NS f.root-servers.net.

. 63251 IN NS b.root-servers.net.

. 63251 IN NS h.root-servers.net.

. 63251 IN NS d.root-servers.net.

;; Received 492 bytes from202.112.170.10#53(202.112.170.10) in 58 ms // 202.112.170.10北京海淀教育网

cn. 172800 IN NS d.dns.cn.

cn. 172800 IN NS c.dns.cn.

cn. 172800 IN NS e.dns.cn.

cn. 172800 IN NS ns.cernet.net.

cn. 172800 IN NS a.dns.cn.

cn. 172800 IN NS b.dns.cn.

;; Received 298 bytes from192.112.36.4#53(192.112.36.4) in 52 ms // 美国

edu.cn. 172800 IN NS ns2.cernet.net.

edu.cn. 172800 IN NS dns2.edu.cn.

edu.cn. 172800 IN NS dns.edu.cn.

edu.cn. 172800 IN NS deneb.dfn.de.

edu.cn. 172800 IN NS ns2.cuhk.hk.

;; Received 183 bytes from203.119.25.1#53(203.119.25.1) in 252 ms // 北京海淀 CNNIC

XIDIAN.edu.cn. 172800 IN NS NS2.XIDIAN.EDU.CN.

XIDIAN.edu.cn. 172800 IN NS NS1.XIDIAN.EDU.CN.

;; Received 131 bytes from202.112.0.13#53(202.112.0.13) in 37 ms // 北京海淀教育网

www.xidian.edu.cn. 3600 IN A 61.150.43.92

xidian.edu.cn. 3600 IN NS ns2.xidian.edu.cn.

xidian.edu.cn. 3600 IN NS ns1.xidian.edu.cn.

;; Received 119 bytes from61.150.43.66#53(61.150.43.66) in 25 ms // 陕西西安电信

[root@os6 ~]# dig -t A www.xidian.edu.cn +trace

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> -t A www.xidian.edu.cn +trace

;; global options: +cmd

. 63081 IN NS c.root-servers.net.

. 63081 IN NS h.root-servers.net.

. 63081 IN NS m.root-servers.net.

. 63081 IN NS i.root-servers.net.

. 63081 IN NS a.root-servers.net.

. 63081 IN NS g.root-servers.net.

. 63081 IN NS k.root-servers.net.

. 63081 IN NS e.root-servers.net.

. 63081 IN NS f.root-servers.net.

. 63081 IN NS d.root-servers.net.

. 63081 IN NS j.root-servers.net.

. 63081 IN NS l.root-servers.net.

. 63081 IN NS b.root-servers.net.

;; Received 492 bytes from202.112.170.10#53(202.112.170.10) in 59 ms // 202.112.170.10 北京海淀教育网

cn. 172800 IN NS a.dns.cn.

cn. 172800 IN NS c.dns.cn.

cn. 172800 IN NS ns.cernet.net.

cn. 172800 IN NS d.dns.cn.

cn. 172800 IN NS e.dns.cn.

cn. 172800 IN NS b.dns.cn.

;; Received 298 bytes from2001:500:2f::f#53(2001:500:2f::f) in 28 ms // 应该是美国

edu.cn. 172800 IN NS dns2.edu.cn.

edu.cn. 172800 IN NS deneb.dfn.de.

edu.cn. 172800 IN NS dns.edu.cn.

edu.cn. 172800 IN NS ns2.cuhk.hk.

edu.cn. 172800 IN NS ns2.cernet.net.

;; Received 183 bytes from203.119.26.1#53(203.119.26.1) in 43 ms // 北京海淀 CNNIC

XIDIAN.edu.cn. 172800 IN NS NS1.XIDIAN.EDU.CN.

XIDIAN.edu.cn. 172800 IN NS NS2.XIDIAN.EDU.CN.

;; Received 131 bytes from101.4.126.99#53(101.4.126.99) in 39 ms // 北京海淀教育网

www.xidian.edu.cn. 3600 IN A 202.117.112.26

xidian.edu.cn. 3600 IN NS ns1.xidian.edu.cn.

xidian.edu.cn. 3600 IN NS ns2.xidian.edu.cn.

;; Received 119 bytes from202.117.112.3#53(202.117.112.3) in 19 ms // 陕西西安教育网

===============

BIND 配置文件

在介绍各种概念之前先来了解下 BIND 的配置文件，一般来讲手动编译安装的 BIND 是没有配置文件的，需要自己手动添加。通过 RPM 方式安装的 BIND 会自动带有配置文件，接下来我们就来介绍下几个较为重要的配置文件。

/etc/named.conf

bind 主配置文件

/etc/named.rfc1912.zones

定义了 zone 和 zone 所引用的资源解析库文件，该配置文件被 include 到 named.conf 中

/var/named/xxx

资源解析库，建议以 .zone 结尾其属主属组分别为root：named

/etc/named.conf 文件内容如下：

options { <--- 全局配置

listen-on port 53 { 192.168.10.131; }; <--- 监听的 port 和 IP

// 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; }; <--- 允许哪些主机查询，此处的 any 是 BIND 的内置 acl 之一（acl 相关部分见下文）

recursion yes; <--- 是否递归查询，即如果本地解析不了某条目，是否去 DNS 体系迭代查询后再返回结果

dnssec-enable no; <--- 建议配置为 no

dnssec-validation no; <---- 建议配置为 no

/* Path to ISC DLV key */

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

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

};

logging { <---日志相关

channel default_debug {

file "data/named.run";

severity dynamic;

};

zone "." IN { <--- 注意到 . 没有被放到 /etc/named.rfc1919.zones 中（其实放到 zones 文件中也ok），而是直接放到了主配置文件中。

type hint;

file "named.ca"; <--- 对应根 zone 的资源解析库，13台根DNS的信息存于此

};

include "/etc/named.rfc1912.zones"; <--- zones 文件被 include 到主配置文件中，zone 的定义也可以直接放到该主配置文件中，但是显得混乱，所以分开放到 zones 文件中

include "/etc/named.root.key";

/etc/named.rfc1912.zones 文件内容如下：

zone "ZONE_NAME" IN {

type {master|slave|hint|forward}; <--- 其中 hint 只给根区域用

file "ZONEFILE.zone"; <---- 建议以 .zone 结尾，也只是建议

};

zone "dezhou.shandong.com" IN { <--- 正向解析区域的定义

type master; <--- 正向解析区域的类型

file "dezhou.shandong.com";

};

zone "1.0.0.127.in-addr.arpa" IN { <--- 反向解析区域的定义

type master;

file "named.loopback";

allow-update { none; }; <--- 允许谁来更新解析库，从安全角度考虑，建议禁止，即设置为 none；即仅仅手动更新

};

先说下什么是 zone（区域），zone 其实和域有某种对应，比如根服务器上面肯定定义了 cn 这个 zone，并在资源解析库中定义了哪个或哪些子域 DNS 服务器可以解析这个域，然后让查询者去做迭代查询。顶级域服务器，如管理 .cn 这个顶级域的服务器，上面肯定定义了edu.cn 这个zone，然后让查询者去找它的子域DNS去做解析。所以说 zone 可以认为是域这种抽象划分的一种具体体现。

区域解析可以分为正向解析和反向解析，正向解析就是 FQDN ---> IP 的解析，反向解析就是 IP ---> FQDN 的解析。举个例子，如果我们要解析www.xiaoqiang.com 和 ftp.xiaoqiang.com 这两个 FQDN，可能就需要建立 xiaoqiang.com 这个zone，然后在指定资源解析库中写入这两台主机的 IP，资源解析库的格式下面会讲到。

这里重点关注下反向解析（也许以后不常用），我们知道 IP 地址的结构是从左到右逐渐范围逐渐缩小的，ABC类-->子网网络号-->主机在子网的编号；但是我们 zone 的名字的结构是和 FQDN 一样从右往左逐渐缩小范围的，最右边是根域，次右是顶级域，然后是二级域，向左越来越小。所以做反向解析时，IP 地址的 “IP域”（暂且这么称呼吧）要倒过来写，以符合从右往左范围依次减小的规范，同时以.in-addr.arpa 结尾，如对于 11.22.33.0/24 这个 IP 段，我们组要构造33.22.11.in-addr.arpa 这个zone 来实现反向解析。

--- 思考下，一个zone是否可以有多个资源解析库文件？且如果解析库文件内容冲突，怎么办？

必要的zone：

1. hint 即记录 . 的 zone，当该 DNS 上找不到需要的信息时去 DNS 体系去找（从根开始），这个 hint zone 就记录了根 DNS 的信息。

2. 本域的zone，这里就是 xiaoqiang.edu.cn. 这个zone，这个很好理解。

/var/named/xxx 资源解析库文件的格式如下（FQDN 必须以点结尾，正如我们定位某文件时文件名以 / 开头）：

name [TTL] IN rr_type value

-----description-----

name 要解析的 FQDN（正向解析）或 IP（反向解析）, @ 表示引用当前区域的名字

TTL 解析结果在查询者内存中的老化时间，每个条目都有自己的值，可选的，不写就继承全局

IN 关键字

rr_type 资源类型，取值 { SOA | NS | CNAME | A | AAAA | PTR | MX }

value 要反馈给查询者的解析结果（可能不是一步到位，查询可能需要 N 步）

-----example-----

$TTL 1D

$ORIGIN dezhou.shandong.com. <--- FQDN 的一部分，和下面的 name 字段共同组成 FQDN(FQDN 必须以.结尾)

注意：ORIGIN 应该和 zone 的名字保持一致，测试发现，当ORIGIN的范围小于（名字长于）zone名字时，报错 SOA record not at top of zone

@ IN SOA ns1.dezhou.shandong.com xiaoyu.shandong.com (

20170520

10M

1D)

NS ns1

NS ns2

ns1 IN A 1.1.1.1

ns2 IN A 1.1.1.2

www IN A 1.1.1.3

ftp IN A 1.1.1.3

* IN A 1.1.1.3 //泛域名解析，避免用户写错名称时给错误答案，可通过泛域名解析至某特定地址。网上有人提泛域名解析有风险，找时间研究下。

资源解析库中每一条解析记录被称之为 Resource Record，简称 RR

同一个 name 可以有多条资源记录（轮询？），除第一条需要完整写出外，后续的记录可以从rr_type字段开始写起，前面的字段可以省略。

同一个 value 也可以被多个 name 引用，如上例中 www 和 ftp 两个 FQDN 在同一台主机上部署。

资源记录类型有：

SOA --> Start Of Authority 起始授权记录，一个区域解析库有且仅能有一个SOA记录，且位于解析库的第一条；主要用于主从同步。

name 值为要查询域的名字

value 值为：

当前区域的名字（通常写为@）而非本台DNS的FQDN（因为若写为FQDN如ns1，那区域间同步之后在从服务器上也是ns1，这样不好。）

当前区域管理员的邮箱地址，但地址中不能使用@符号，一般用.替代，如果有.则用\代替

（20170520; 资源解析库的序列号，从服务器凭借此号完成 DNS 同步

2H; 刷新时间，从服务器从主服务器请求解析库的时间间隔，如 2 小时

10M; 重试时间，刷新失败后间隔多长时间再次尝试请求刷新，小于刷新时长，否则无意义

1W; 过期时间，从服务器始终联系不到主服务器时，多久放弃从服务器角色，停止DNS服务

1D; 否定答案的TTL值，即返回“查无此项”保持多久）

NS --> Name Server，

name 值为要查询域的名字

value 值为当前区域的DNS服务器（master 和 slave），NS 记录后都应该有对应的 A 记录，否则就是耍流氓

MX --> Mail eXchanger 标明当前域内实现邮件交换的主机

name 值为当前区域的名字

value 值为当前区域的某邮件服务器（smtp）的主机名，value之前有一个0-99的数字，表示此服务器的优先级（越小越高）

对MX记录而言，任何一个NS记录后面的服务器名字都应该在其后有一个A记录；

CNAME --> Canonical Name 别名记录

A --> FQDN-->IP v4

AAAA --> FQDN-->IPv6

PTR --> Pointer 作用 IP-->FQDN

语法检查工具：

named-checkconf 检查主配置文件是否有语法错误

named-checkzone "zone名字“ "zone文件" 检查某个区域解析资源库文件中的zone区域是否有语法错误

=========

子域授权

所谓子域授权就是在上级域DNS服务器上配置一个 NS 记录和 A 记录，让查询者去它的下一级域DNS服务器上继续查询，比如根服务器会让查询者去顶级域名服务器查询，根服务器也仅记录了顶级域名服务器的信息。顶级域名服务器会让查询者去二级域名服务器查询，因为顶级域名服务器也仅仅记录了二级域名服务器的信息。二级推给三级，三级推给四级，这样传递下去，只有最后的DNS服务器真正记录记录主机信息，它才是真正的劳动者。

举个配置子域授权的例子：

如果我们办了一所私立大学，想申请一个域，比如 xiaoqiang.edu.cn，并在这个域里面架设 www 服务器和 ftp 服务器，那外界如何访问这些服务器呢？

方案之一是我们自己架设 DNS 服务器（或者使用别人的，同理），管理 xiaoqiang.edu.cn. 这个域，然后将其纳入公网 DNS 体系。首先在管理edu.cn. 这个域的DNS服务器上加上指向我们自己搭建的 DNS 服务器的条目（NS 记录和 A 记录），然后在我们自己架设的 DNS 服务器上配置www.xiaoqiang.edu.cn. 和 ftp.xiaoqiang.edu.cn. 这两个主机名及其 IP 信息（A 记录），这样来访者就会找到我们这台管理 xiaoqiang.edu.cn. 这个域的DNS服务器上并查询并得到 www 主机和 ftp 主机的 IP 地址。

另一个方案是，申请在管理 edu.cn. 的服务器上直接加上指向 www.xiaoqiang.edu.cn 和 ftp.xiaoqiang.edu.cn 的条目（后面这种跨级了，当然如果够牛掰在管理 cn. 的服务器上添加www.xiaoqiang.edu.cn 也不是问题，技术上应该不是问题，但这么干就乱了）。

配置实例

192.168.10.129 作为上级域名服务器，管理 shandong.com. 这个域

---------------- /etc/named.rfc1912.zones 的配置 ----------------

zone "shandong.com" IN { <--- 顺便说下，这就是正向解析zone

type master;

file "shandong.com.zone";

};

---------------- /var/named/shandong.com.zone 的配置 ----------------

$TTL 1D

$ORIGIN shandong.com.

@ IN SOA ns1.shandong.com xiaoyu.shandong.com (

20170520

1D)

NS ns1

NS ns2

ns1 IN A 192.168.10.129

ns2 IN A 192.168.10.133

www IN A 111.111.111.111

ftp IN A 222.222.222.222

dezhou IN NS ns1.dezhou <--- 当解收到解析子域的查询时，告知查询者找下一级DNS处理

NS ns2.dezhou

$ORIGIN dezhou.shandong.com.

ns1 IN A 192.168.10.130

ns2 IN A 192.168.10.131

###############################################################

192.168.10.130 作为子域域名服务器，管理 dezhou.shandong.com. 这个域

---------------- /etc/named.rfc1912.zones 的配置 ----------------

zone "dezhou.shandong.com" IN {

type master;

file "dezhou.shandong.com"; <--- zone 文件只是建议以 .zone 结尾，不是强制

};

---------------- /var/named/dezhou.shandong.com 的配置 ----------------

$TTL 1D

$ORIGIN dezhou.shandong.com.

@ IN SOA ns1.dezhou.shandong.com xiaoyu.shandong.com (

20170520

10M

1D)

NS ns1

NS ns2

ns1 IN A 192.168.10.130

ns2 IN A 192.168.10.131

www IN A 11.11.11.22

ftp IN A 22.22.22.22

一台 IP 为192.168.10.128 的 linux 便携机执行，dig -t A www.dezhou.shandong.com @192.168.10.129 +norecurse

最终通过自己的迭代得到结果，dig 的 +norecurse 就是不递归。如果不写@，则交给/etc/resolv.conf 中使用的nameserver解析

===========

转发服务器

对于某次查询的 FQDN 不在本DNS负责解析的域，如果本DNS使能了递归（也就是自己没有就去找，找到后把结果给返回给查询者），一般来说都是去找 DNS 体系并从根开始问起。其实我们也可以不去找根，而是转发给某DNS服务器B，这里要求 DNS服务器B应该允许做递归（当然本DNS也需要允许递归，否则怎么发给DNS B呢），因为这次的查询可能也不属于B所管理的域。一个应用就是当子域接收到某主机对父域的请求时，可以转给父域DNS，这种情况下子域 DNS 就是转发服务器，它的 type 就是forward

转发分为两种：全部转发和区域转发

全部转发：非本机负责的域的全部解析请求，统统转发给某服务器，而非根。全部转发在/etc/named.conf 中的 options 中设置。

options {

forward {first|only}; // first 是转发给某服务器，如果该服务器拒绝递归，则找根；only就是和该服务器死磕，不给肯定解析就认为失败；

forwarders { xxx; }; // xxx 是要转发给的服务器地址（集）

}

区域转发：非本机负责的某特定区域的全部解析请求，转发给某服务器，而非根。区域转发定义在 named.rfc1912.zones 中

zone "aaa.bbb.com" IN {

type forward;

forward {first|only}; // 对于父域解析请求且转发给父域DNS，一般就是only了。因为如果父域DNS给不出肯定解析，找根也没用啊。

forwarders{ xxx; };

}

区域转发和全局转发都开启的话，先去匹配区域转发，匹配不到再去找全局转发服务器。区域转发，一般来讲是转给父域（当然其他与也可以）。

感觉全部转发没有什么用啊，可以自己直接去找根，为什么要做转发呢？上网查找全部转发的应用场景

配置实例

192.168.10.129 作为上级域名服务器，管理 shandong.com. 这个域

---------------- /etc/named.rfc1912.zones 的配置 ----------------参考上面的实例

---------------- /var/named/shandong.com.zone 的配置 ----------------参考上面的实例

###############################################################

192.168.10.130 作为子域域名服务器，管理 dezhou.shandong.com. 这个域

---------------- /etc/named.rfc1912.zones 的配置 ----------------

zone "dezhou.shandong.com" IN {

type master;

file "dezhou.shandong.com";

};

zone "shandong.com" IN {

type forward;

forward only;

forwarders { 192.168.10.129; };

};

一台 IP 为192.168.10.128 的 linux 便携机执行， dig -t A ftp.shandong.com @192.168.10.130

最终通过.130的转发得到最终结果（来自.129）

=====================

区域传送 & 主从 DNS

(要实现主从同步时候，需要在从DNS上关闭 SeLinux 否则不让 named 进程写文件到磁盘；同时注意防火墙的设置)

如果某 DNS（如：192.168.10.130）上有个 dezhou.shandong.com 这个zone，我们在可访问该DNS的便携机上执行 dig -t axfr dezhou.shandong.com @192.168.10.130 可以获得该 zone 的所有配置信息。在DNS获得一份某个zone的解析库信息的动作，这叫做区域传送。BIND 默认是对来自所有设备的请求都允许这种区域传送。当然我们可以在zone中控制是否允许，对谁允许，如下例所示，就是对任何主机都不允许区域传送。none 可以替换成其他的 acl 列表，acl 列表会在下文中讲到。

zone "dezhou.shandong.com" IN {

type master;

file "dezhou.shandong.com";

allow-transfer { none; };

};

基于区域传送，才有了主从 DNS 的同步。

master & slave 是在 zone 粒度来讲的，对于一个 zone 只有一个 master，但可以有多个 slave。某服务器对 zone-01 来说是 master 可能对于 zone-02 来说就是 slave。

前面的例子讲的大部分都是作为 master 的情况，当然还有上面讲的 forward ，那么现在看看如何配置 slave 服务器。slave 服务器配置比较简单，仅仅配置 zone 名称即可（与 mater 上的zone名称一致），无需配置资源解析库。如下例在 /etc/named.rfc1912.zones 中定义一个 slave 的 zone

//例子中主服务器 192.168.10.130 ，从服务器 192.168.10.131

zone "dezhou.shandong.com" IN { <--- zone 名称一定是在master 上存在的

type slave; <--- 类型一定是 slave

masters { 192.168.10.130; }; <--- masters 的地址

file "slaves/dezhou.shandong.com.slave"; <--- 同步回来的资源解析库放置位置及文件名。/etc/named/slaves 对named要有写权限。

};

要完成主从同步（也就是区域传送），除了要配置 slave 外，还需要对 master 进行配置，主要关注两点：

1. 主服务器允许区域传送，默认是允许的；

2. 主服务器上要同步的zone的资源解析库文件中要有从服务器的NS记录和A记录

----- /etc/named.rfc1912.zones-----

zone "dezhou.shandong.com" IN {

type master;

file "dezhou.shandong.com";

// allow-transfer { none; }; <--- 对从服务器允许区域传送，最好只对从服务器允许，对其他主机不允许

};

----- /var/named/dezhou.shandong.com -----

$TTL 1D

$ORIGIN dezhou.shandong.com.

@ IN SOA ns1.dezhou.shandong.com xiaoyu.shandong.com (

2017052005

10M

1D)

NS ns1

NS ns2 <--- 一定要有从服务器的 NS 记录（主服务器的资源记录改变后通知哪些从服务器，可以由此得到）

ns1 IN A 192.168.10.130

ns2 IN A 192.168.10.131 <--- 一定要有从服务器的 A 记录

www IN A 11.11.11.22

ftp IN A 22.22.22.33

一般来讲，修改主服务器上的资源解析库后需要手动更改序列号（通常是+1），然后使用 rndc reload 命令重新载入资源解析库。这时候主服务器就会发送notification给从服务器，从服务器会来主服务器拿更新后的资源解析库，这就完成了同步。当主服务器更新完资源解析库且rndc reload后，可在主从服务器上分别查看日志，即 tail /var/log/messages 对比看下以帮助理解同步过程。

===================

acl 及访问控制命令

acl

其实就是主机和网段的集合（只是一个集合而已），先定义后使用，一般定义在 /etc/named.conf 中 options 前面，如：

acl my_slave {

1.1.1.1;

2.2.2.0/24;

};

BIND 的 4 个内置 acl ---> none ; any ; local （本机IP）; localnet（本机所在网段）

访问控制命令 <--- 放在options中是全局生效，放在zone中是局部生效。通常配合acl使用，也可以单独写IP，多个IP用分号隔开

allow-query { xxx; }; //控制查询，默认是 any

allow-transfer { xxx; }; //控制区域传送，一般来讲只允许从服务器从本机做区域传送

allow-recursion { xxx; }; // 一般来讲只为内部主机做递归

allow-update { xxx; }; // 允许谁来更新解析库，从安全角度考虑，建议禁止，即设置为 none

===========

view (视图)

DNS的查询可以做到精细化管理，即把请求用户划分为不同的用户群，每个用户群分配不同的view，对于同一个FQDN，不同 view 下的用户查询，反馈的结果可以做到不一样。各种 zone 分布在不同的 view下，具体来说就是有些 zone 仅分布在某些 view 下开放给特定用户查询；有些相同（名字）的 zone 也可以开放给不同的 view 用户，但是 zone 下的资源解析库文件不同（这是常见的场景）。view 外不在定义 zone，根也会根据需要放到某些view下。view 定义在 /etc/named.rfc1912.zones 中，如下例：

view VIP01 {

match-clients { xxx; }; <--- xxx 一般是acl，用以给 view圈定用户

allow-recursive { yyy; }; <--- yyy 应该是 xxx 的子集

zone "dezhou.shandong.com" IN {

type master;

file "dezhou.shandong.com";

allow-transfer { none; };

};

查询请求到达时，将按 view 从上到下匹配 IP，然后在匹配到的 view 中查询 FQDN。

===============

配置工具 rndc

rndc 是 BIND 的配置工具，使用语法为： rndc COMMAND

监听在953端口，接收命令来控制named进程的行为，通常情况下只允许本机连接953端口

COMMAND:

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

reload zone 只重载zone解析库文件

reconfig 只重载主配置文件

retransfer zone 手动启动区域传送过程，而不管序列号是否更新（增加）

notify zone 手动对区域传送发通知

querylog 开启或关闭查询日志 //通常关闭，因为日志会及时同步到磁盘，影响IO

trace # 设定debug级别，默认为0

flush 清空缓存

status 状态查询

==========

测试工具

dig <--- 被设计用来测试DNS

dig [-t type] name [@serverIP]

查询选项（放在命令最后）

+[no]trace 跟踪整个跟踪过程

+[no]recurse 进行递归解析（服务器端要支持）

dig -t axfr zone_name @server //全量传送，获得server的全量信息

dig -x IP @server 反向解析

host -t A www.baidu.com 202.112.170.14

--------------

nslookup <--- 通常以交互式方式使用

> server IP //指明使用哪个DNS server 相当于dig中的@

> set q=A //查询类型

然后直接给出要查询的name

=====补充反向解析实例=====

-----/etc/named.rfc1912.zones-----

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

type master;

file "named.boss";

allow-update { none; };

};

-----/etc/named/named.boss-----

$TTL 1D

@ IN SOA @ rname.invalid. (

0 ; serial

1D ; refresh

1H ; retry

1W ; expire

3H ) ; minimum

NS ns1

ns1 A 11.22.33.44

78 PTR www.bosshuang.com.

阅读全文

1 0