DNS基础
DNS(Domain Name System,域名系统),在Internet上作为域名与IP地址相互映射的一个分布式数据库,能够使用户更方便的使用域名访问互联网,而不用去记住只能被机器识别的IP地址。域名(FQDN)和IP地址之间的转换工作称为域名解析(或主机名解析)。
ICANN,全称Internet Corporation for Assigned Names and Numbers(互联网名称与数字地址分配机构),是一个非盈利性的国际组织,负责互联网协议(IP)地址的空间分配,协议标示符的指派,通用顶级域名 (gTLD)以及国家和地区顶级域名(ccTLD)系统的管理,以及根服务器系统的管理。官方网址是:http://www.icann.org
ICANN的作用:负责协调管理DNS各技术要素以确保普遍可解析性,使所有的互联网用户都能够找到有效的地址。它是通过监督互联网运作当中独特的技术标示符的分配以及顶级域名的授权来做到这点的。
hosts映射
早期,名字到地址的转换过程十分简单。每台计算机保存一个hosts文件,里面列出所有计算机名字和对应的IP地址,然后定期从一个维护此文件的站点更新里面的记录。当我们访问某个计算机名字时,先在hosts文件找到对应的IP,然后就可以建立连接。
随着网络规模的扩大,这种方法渐渐吃不消了。主要有以下三个原因:
- hosts文件变得非常大
- 主机名字会冲突
- 集中的维护站点会不堪重负
域名结构
通常 Internet 主机域名的一般结构为:主机名.三级域名.二级域名.顶级域名。 Internet 的顶级域名由 Internet网络协会域名注册查询负责网络地址分配的委员会进行登记和管理,它还为 Internet的每一台主机分配唯一的 IP 地址。全世界现有三个大的网络信息中心: 位于美国的 Inter-NIC,负责美国及其他地区; 位于荷兰的RIPE-NIC,负责欧洲地区;位于日本的APNIC,负责亚太地区
监听的端口
1 | 53/udp # 普通查询 |
DNS的功能
每个IP地址都可以有一个主机名,主机名由一个或多个字符串组成,字符串之间用小数点隔开。有了主机名,就不用死记硬背每台IP设备的IP地址,只要记住相对直观有意义的主机名就行了。这就是DNS协议所要完成的功能。
正反解析
- 正向解析:从域名到ip地址的解析过程
- 反向解析:从ip地址到域名的解析过程,反向解析一般用来进行服务器的身份验证
DNS查询
- 查询的优先级:本地hosts文件 => 本地缓存 => 本地DNS区域文件
- 分级查询:从根域开始,依次查询每一级域名的NS记录,直到查到最终的IP地址。DNS服务器根据域名的层级,进行分级查询。每一级域名都有自己的NS记录,NS记录指向该级域名的域名服务器。这些服务器知道下一级域名的各种记录。
- 递归查询:客户端向DNS服务器发送一次请求,DNS服务器逐级完成查询完成后直接返回结果。对于客户端来讲为递归查询,对于DNS服务器来讲是迭代查询。
- 迭代查询:客户端需要发起多次请求才可得到结果
默认情况下,DNS服务器使用递归方式来解析域名。递归的含义就是DNS服务器作为DNS客户端向其他DNS服务器查询此解析请求,直到获得解析结果,在此过程中,原客户端则等待DNS服务器的回复。
参考链接: http://blog.csdn.net/lycb_gz/article/details/11720247
DNS应答
- 权威应答
如果DNS服务器在自己的区域文件里找到了客户端需要查询的记录,就会返回一个权威性应答。如果DNS服务器最近被查找过该主机记录,就会在缓存里找到记录应答客户端。如果找不到主机的A记录,就会返回(RecordNotFound)应答――同样是权威性应答。 - 非权威应答
如果接到DNS查询请求的服务器不是指定域的名称服务器,则:首先查询其他DNS服务器直到找到,然后此服务器将找到的内容返回给客户端――非权威性应答。其次,推荐客户端到上一级DNS服务器找。―――非权威性应答。
DNS冗余
为保证服务的高可用性,DNS要求使用多台名称服务器冗余支持每个区域。某个区域的资源记录通过手动或自动方式更新到单个主名称服务器(称为主DNS服务器)上,主 DNS 服务器可以是一个或几个区域的权威名称服务器。
其它冗余名称服务器(称为辅 DNS 服务器)用作同一区域中主服务器的备份服务器,以防主服务器无法访问或宕机。辅 DNS服务器定期与主 DNS 服务器通讯,确保它的区域信息保持最新。如果不是最新信息,辅DNS服务器就会从主服务器获取最新区域数据文件的副本。这种将区域文件复制到多台名称服务器的过程称为区域复制。
服务器类型
- 主从服务器:主服务器数据修改,辅助服务器请求数据同步
- 缓存服务器
- 转发器
资源记录
- 为了将名字解析为IP地址,服务器查询它们的区(DNS数据库文件)。区中包含组成相关DNS域资源信息的资源记录(RR)。
- 某些资源记录不仅包括DNS域中服务器的信息,还可以用于定义域,即指定每台服务器授权了哪些域,这些资源记录就是SOA和NS资源记录。
- 数据库中的每一个条目称作是一个资源记录(Resource Record,RR),它是一个五元组,可以用以下格式表示:
1 | Domain_name Time_to_live Class Type Value |
名称 | TTL值(可选) | Internet | 资源记录类型 | 值 |
---|---|---|---|---|
NAME | TTL | IN | RRT | VALUE |
www.nettest.net | 600 | IN | A | 161.202.43.78 |
161.202.43.78 | 600 | IN | PTR | www.nettest.net |
资源记录及类型
①A记录:A记录也称为主机记录,是使用最广泛的DNS记录,A记录的基本作用就是说明一个域名对应的IP是多少, 它是域名和IP地址的对应关系,表现形式为 www.contoso.com 192.168.1.1 这就是一个A记录!A记录除了进行域名IP对应以外,还有一个高级用法,可以作为低成本的负载均衡的解决方案,比如说,www.contoso.com 可以创建多个A记录,对应多台物理服务器的IP地址,可以实现基本的流量均衡!)
②NS记录:NS记录和SOA记录是任何一个DNS区域都不可或缺的两条记录,NS记录也叫名称服务器记录,用于说明这个区域有哪些DNS服务器负责解析,SOA记录说明负责解析的DNS服务器中哪一个是主服务器。因此,任何一个DNS区域都不可能缺少这两条记录。NS记录,说明了在这个区域里,有多少个服务器来承担解析的任务
③SOA记录:NS记录说明了有多台服务器在进行解析,但哪一个才是主服务器呢,NS并没有说明,这个就要看SOA记录了,SOA名叫起始授权机构记录,SOA记录说明了在众多NS记录里那一台才是主要的服务器!
④MX记录:全称是邮件交换记录,在使用邮件服务器的时候,MX记录是无可或缺的,比如A用户向B用户发送一封邮件,那么他需要向DNS查询B的MX记录,DNS在定位到了B的MX记录后反馈给A用户,然后A用户把邮件投递到B用户的MX记录服务器里!
⑤Cname记录:又叫别名记录,我们可以这么理解,我们小的时候都会有一个小名,长大了都是学名,那么正规来说学名的符合公安系统的,那个小名只是我们的一个代名词而已,这也存在一个好处,就是比暴漏自己,比如一个网站 a.com
在发布的时候,他可以建立一个别名记录,把 b.com
发布出去,这样不容易被外在用户所察觉!达到隐藏自己的目的!
⑥SRV记录:SRV记录是服务器资源记录的缩写,SRV记录是DNS记录中的新鲜面孔,在RFC2052中才对SRV记录进行了定义,因此很多老版本的DNS服务器并不支持SRV记录。那么SRV记录有什么用呢?SRV记录的作用是说明一个服务器能够提供什么样的服务!SRV记录在微软的Active Directory中有着重要地位,大家知道在NT4时代域和DNS并没有太多关系。但从Win2000开始,域就离不开DNS的帮助了,为什么呢?因为域内的计算机要依赖DNS的SRV记录来定位域控制器!表现形式为:
1 | ldap._tcp.contoso.com 600 IN SRV 0 100 389 NS.contoso.com |
⑦PTR记录:PTR记录也被称为指针记录,PTR记录是A记录的逆向记录,作用是把IP地址解析为域名。由于我们在前面提到过,DNS的反向区域负责从IP到域名的解析,因此如果要创建PTR记录,必须在反向区域中创建。
Bind安装配置
Bind,全称是Berkeley Internet Name Domain(伯克利因特网名字域系统)。官方网址:http://www.isc.org/ 。它主要有3个版本:BIND 4,BIND 8,BIND9。
需求
已知域名 study.info
和 study.co
,IP地址 192.168.127.0/24
,要实现
主从权威名称服务器
1 | ns1.study.info 192.168.127.123 |
邮件服务器
1 | mail.study.co 192.168.127.125 |
网站服务器
1 | www.study.co 192.168.127.126 |
ftp服务器
1 | ftp.study.co 192.168.127.127 |
别名
1 | www2.study.co => www.study.co |
PTR
1 | 192.168.127.128 => www.study.co |
安装和文件说明
配置yum源,安装bind的rpm包
1 | rpm -qa | grep '^bind' |
文件说明
1 | /usr/sbin/named |
区域配置的语法结构
- 区域
1 | zone "ZONE NAME" IN { |
- 主区域
1 | file "区域数据文件"; |
- 从区域
1 | file "区域数据文件"; |
配置
在主机 192.168.127.123上进行配置
备份好原生配置文件
1 | cp /etc/named.conf{,.bak} |
编辑 /etc/named.conf
1 | options { |
创建区域文件 /var/named/zone.study.info
1 | $TTL 600 |
创建区域文件 /var/named/zone.study.co
1 | $TTL 600 |
创建区域文件 zone.192.168.127
1 | $TTL 600 |
对区域进行检查和文件权限,修改属主属组;重读配置文件进行测试
1 | chown /var/named/zone.study.* /var/named/zone.192.168.127 --reference='/etc/named.conf' |
使用 dig
命令进行测试
1 | dig @192.168.127.123 -t NS study.co |
如果在服务运行的过程中修改了配置文件,无需重新启动服务,使用 pkill
命令即可使服务重读配置文件
1 | pkill -1 named |
主从复制及区域传送
Bind 配置
从服务器(slave)192.168.127.164 bind配置,配置完成后进行主、从DNS日期时间同步
1 | setenforce disabled |
生成区域文件的工具: http://pgl.yoyo.org/adservers/bind-zone-file-creator.php
主 DNS 配置
在主 DNS 服务器 192.168.127.123 上修改 /etc/named.conf
1 | options { |
从 DNS 配置
在从 DNS 服务器上 192.168.127.124 上配置 /etc/named.conf
1 | options { |
区域传送测试
主从 DNS 服务器都重启进程,并查看日志是否传送成功
1 | systemctl restart named |
主服务器看到的日志信息
1 | Jul 18 17:09:39 study named[3249]: running |
从服务器看到的日志信息
1 | Jul 18 17:09:04 bogon named[21703]: zone study.info/IN: Transfer started. |
从服务器更新测试,修改主服务器区域文件,添加一条 N S记录并修改序列号;主服务器重启进程,测试从服务器是否正常同步
rndc远程控制
在主DNS生成 rndc
配置文件
1 | rndc-confgen -s 127.0.0.1 -r /dev/urandom > /etc/rndc |
文件 /etc/rndc
内容查看
1 | # Start of rndc.conf |
将开头的 key
覆盖到 /etc/rndc.conf
1 | awk '/# Start of rndc.conf/,/# End of rndc.conf/' /etc/rndc > /etc/rndc.conf |
修改 server IP
1 | # Start of rndc.conf |
将 #
开头的行写到 /etc/named.conf
文件中,并去掉部分注释。修改被控制机IP地址,以及allow,允许哪些IP来控制本机
1 | # Use with the following in named.conf, adjusting the allow list as needed: |
使用 rndc -c /etc/rndc.conf status
命令查看状态
1 | version: 9.9.4-RedHat-9.9.4-73.el7_6 <id:8f9657aa> |
其他命令
1 | rndc -c /etc/rndc.conf notify study.info # 手动通知区域 |
上面只是实现了本机 IP 控制本机,如果要使用其他主机来控制,需要拷贝 rndc
到控制机
1 | scp -P 22 192.168.127.123:/etc/rndc.conf /root/ |
子域授权
子域授权,在原有的域上再划分出一个小的区域并指定新 DNS 服务器。在这个小的区域中如果有客户端请求解析,则只需要找新的子 DNS 服务器。这样的做的好处可以减轻主 DNS 的压力,也有利于管理。这里只做正向区域的子域授权。
以子域 m.study.co.
为例,主 DNS 服务器IP还是之前的 192.168.127.123,子域DNS服务器地址是 192.168.127.130
主 DNS 服务器的配置,要在 /var/named/zone.study.co
添加子域资源记录并修改序列号,重新加载进程完成主从同步
1 | m IN NS ns1.m.study.co. |
子域服务器的配置,需要在子域 m.netpas.co.
服务器进行相关配置,启动服务
1 | yum -y install bind bind-utils |
修改 /etc/named.conf
并查看文件内容
1 | options { |
创建区域文件 /var/named/zone.m.study.co
1 | touch /var/named/zone.m.study.co |
写入内容
1 | $TTL 600 |
启动服务
1 | systemctl enable --now named |
主 DNS 服务器测试
1 | dig -t ns @192.168.127.123 m.study.co |
从 DNS 服务器测试
1 | dig @192.168.127.124 -t ns m.study.co |
子域DNS测试
1 | dig @192.168.127.130 www.study.co |
转发器
在DNS服务器的配置中,如果采用默认的配置,其实效率是较低的,因为默认情况下,我们所有的非权威解析都会被发送到根服务器进行迭代查询。如果采用转发,如将我们的DNS解析请求转发到一些公共DNS服务器上,由于公共DNS服务器上缓存了大量的解析,因此比原始的迭代查询快。全局转发能够实现对非权威解析(已缓存的除外)都转发到特定DNS服务器。
需要用到 forward
配置参数
1 | forward { only | first } |
上面子域DNS服务器解析主域的域名无法获取正常结果,需做转发配置。在子域DNS服务器 /etc/named.conf
的全局配置 options
字段加入以下两行
1 | forward only; |
如果仅设置 forwarders
,则在无法联系转发器时,就会尝试自己解析,即转发到根服务器迭代查询实现解析(如果配置有根zone)。
如果想服务器在联系不到转发器时不进行多余操作,则可以加上 forward only;
;这样如果联系不上转发器时,服务器将只查询权威解析和本地缓存的解析。
区域转发:从BIND9.1开始,引入一个新特新:转发区(forward zone ),及允许查询特定区域时,将其转发到指定DNS服务器上。
子域DNS服务器在修改配置后重启服务,并测试验证
1 | dig @192.168.127.130 www.study.co |
DNS视图
ACL的应用与配置
在 /etc/named.conf
的全局配置中,有 allow-query { 192.168.8.0/24; };
这样的一行定义允许为哪些些客户端进行递归查询。这里只允许了这一个IP段,如果是大型企业或者公网我们需要允许的客户端有上百个IP段时,这里会写很长而且如果在多个地方需要用到,则需写多次,配置麻烦且影响查看。因此引入ACL,可以实现集中定义,所有位置均可引用。ACL类似程序开发中的函数。例如:
1 | acl trust { |
视图 view
view 将不同IP地址段发来的查询响应到不同的DNS解析。例如需要对多个不同IP地址段进行配置,就需要明确这些IP地址段,这样View功能才会有效。注意一旦使用view,所有域都必须定义在 view。
智能DNS
智能DNS是域名服务在业界首创的智能解析服务。能自动判断访问者的IP地址并解析出对应的IP地址,使网通用户会访问到网通服务器,电信用户会访问到电信服务器。在 Bind 中可以使用 acl
和 view
实现智能DNS
创建 tel_ip、cnc_ip、cm_ip、crc_ip、edu、other 6个访问控制列表表示不同来源(电信,联通,移动,铁通,教育,其他,默认),以区域 study.co
为例,实现智能DNS
由于IP地址段数量较大,因此在 /var/named/
目录下创建目录 acl
存放不同来源的IP段。
1 | mkdir -pv /var/named/acl |
在 /var/named/acl/tel_ip.acl
创建针对电信IP的 acl
1 | acl tel_ip{ |
在 /var/named/acl/cnc_ip.acl
创建针对网通IP的 acl
1 | acl cnc_ip{ |
由于IP量比较大,上面只写了几个地址段仅供参考。实际情况需要写上百条,每个地址段占用一行,以分号结尾
针对这种数量比较大的情况,我们可以在 /etc/named.conf
使用 include
来处理,并添加与之对应的视图配置
1 | options { |
在 /var/named
下分别创建对应的区域文件(可拷贝),并将相关记录改成对应运营商的IP就完成了智能解析。
修改好配置重启服务后,使用 dig 命令在不同环境下进行测试,来验证效果。
当然,如果你的 zone
比较多的话,也可以像 acl
的处理方法一样分类并单独写一个文件,最后使用 include
配置在 /etc/named.conf
中即可
日志
Logging
bind中我们可以通过配置logging来记录日志信息,以便以后对服务器的分析及问题的跟踪。logging语句为域名服务器设定了一个多样性的logging选项。它的channel短语对应于输出方式、格式选项和分类级别,它的名称可以与category短语一起定义多样的日志信息。如果打开日志功能可能会降低dns的性能,因此不建议开启日志功能。
开启日志功能
只需要在option里面加入一个选项即可。man named.conf
1 | options { |
之后查看 /var/log/messages
就能看到日志信息;这样会浪费大量的空间。可以使用 catagory 日志系统,帮我们定制需要对哪些行为进行日志检测。
日志系统
bind的日志系统,提供了两个子系统,一个叫做channel,一个叫做category。
1 | catagory: 日志源(指的是产生日志的日志源,比如说有的是跟查询有关的,有的是跟区域传送相关的。)所以catagory可以让我们定义日志来源。 |
默认channel,下面是named 提前定义的四个通道,用于指定缺省的日志。
1 | channel "default_syslog" { |
default_debug 通道有特殊的性质:只有当服务器的debug级别非0的时候,它才产生输出。一般来说,它会在服务器的工作目录中写入 named.run
文件。因为安全原因,当在命令行选项中使用了 -u
参数后,只有当 named 使用了新的UID后,named.run
文件才会产生,以 root 身份启动和运行的 named 所产生的 debug 信息将会被丢弃。如果用户需要得到这些输出,则必须使用 -g
参数运行服务器,并重新将标准错误定向到一个文件中去。
一旦定义好一个通道,它就不能被重新定义。这样就不能修改内置的通道,但是可以通过把分类指向你已经定义的通道,来修改默认的日志记录。
示例
1 | logging { |
日志的设置和定义
1 | channel通道:作用主要定义日志输出的方式;在定义通道的语句里有哪些子语句: |
1 | category类别:定义了那些数据需要记录,即在日志里输出那些日志内容。哪一类的类别使用哪个或哪几个已经定义好的通道 |