DNS:Domain Name Service , 域名服务器, 应用层协议(属于资源子网),C/S,udp/53、tcp/53。是一种概念模型。
BIND:DNS在互联网上的具体实现。
DNS
DNS的发展:
随着互联网上的主机越来越多,基于ip通信要记住的ip地址越来越多,人类对名称比对数字敏感,所以基于名称通信就比较方便了。
要想使用名字进行通信,就必须向IANA(数字名称分配机构)申请。为了避免名字重复,一个名字只能分给一台主机。
解析:以一个字段为关键字,去找另一个字段的值。
本地名称解析文件:/etc/hosts
在网络上的主机不多时,只需要在本地维护好这个文件就行,当有新的主机加入时,就更新这个文件
随着互联网上的主机越来越多时,更新这个文件就越来越难了。
为此,IANA提供了一台ftp服务器,任何主机向IANA申请名字后,它就把申请结果保存在此服务器上,在这个服务器上维护着一个公共的hosts文件。每一个服务器的管理员没有必要手动的更新本地的hosts文件,需要时只需在ftp服务器上下载文件更新至本地即可。(可以根据自身情况做一个定时任务,每隔多长时间去更新一次)
当网络上的主机变得很多很多,这种方法就不太好了,因为每次更新会很慢,而且每次的解析也会很慢。
这时IANA也不再去更新这个ftp服务器上的hosts文件,其他服务器本地也没有必要去更新本地hosts的文件(本地的hosts文件依然存在,这是传统的解析方式)
IANA又建了一个服务器,该服务器上保存着每个已注册的名字和ip的对应关系。这时候任何一个主机和其他主机要想通信,在通信之前又多了一步。
当本地浏览器想通过主机名访问某个web服务时,输入域名回车后,浏览器看到我们输入的是一个域名,他会调用本地的一个底层的库文件,这个库文件先扮演成客户端,去找一个在本地被配置成dns服务器的主机,把请求扔给它,(基于udp:这一步不是真正通信要完成的一步,所以我们期望这一步用的时间越短越好,这也是为什么采用udp的方式进行通信。),告诉它我现在要访问名某主机,请告诉我该主机的IP地址,dns服务器查找本地的数据库,并把查找结果扔给请求服务器,这样请求者就是知道了主机名对应的IP地址是什么,接下来封装通信报文与另一台主机进行通信。(在浏览器输入域名------>浏览器调用本地库文件----->库文件扮演成客户端去访问本地的dns服务器)
这样有人就问了,一个主机查找本地的解析文件慢,难道放在服务器上就不满了吗?
所以服务器采用了这样一种机制。
在服务启动时,他会将本地所有的名字和地址hash化后保存在内存中,这样性能就好的多。而且进行了hash化后检索起来就会很快了。
但是还是架不住网上的服务器越来越多啊!最后就采用这种倒树形结构哦,访问时自下而上访问。
(摘自:https://blog.youkuaiyun.com/lycb_gz/article/details/11720247)
递归查询:查询请求者只需发出一次查询请求就能得到最终结果。“递归解析”(或叫“递归查询”,其实意思是一样的)是最常见,也是默认的解析方式。在这种解析方式中,如果客户端配置的本地名称服务器不能解析的话,则后面的查询全由本地名称服务器代替DNS客户端进行查询,直到本地名称服务器从权威名称服务器得到了正确的解析结果,然后由本地名称服务器告诉DNS客户端查询的结果。
(1)客户端向本机配置的本地名称服务器(在此仅以首选DNS服务器为例进行介绍,所配置其它备用DNS服务器的解析流程完全一样)发出DNS域名查询请求。
(2)本地名称服务器收到请求后,先查询本地的缓存,如果有该域名的记录项,则本地名称服务器就直接把查询的结果返回给客户端;如果本地缓存中没有该域名的记录,则本地名称服务器再以DNS客户端的角色发送与前面一样的DNS域名查询请求发给根名称服务器。
(3)根名称服务器收到DNS请求后,把所查询得到的所请求的DNS域名中顶级域名所对应的顶级名称服务器地址返回给本地名称服务器。
(4)本地名称服务器根据根名称服务器所返回的顶级名称服务器地址,向对应的顶级名称服务器发送与前面一样的DNS域名查询请求。
(5)对应的顶级名称服务器在收到DNS查询请求后,也是先查询自己的缓存,如果有所请求的DNS域名的记录项,则相接把对应的记录项返回给本地名称服务器,然后再由本地名称服务器返回给DNS客户端,否则向本地名称服务器返回所请求的DNS域名中的二级域名所对应的二级名称服务器地址
然后本地名称服务器继续按照前面介绍的方法一次次地向三级、四级名称服务器查询,直到最终的对应域名所在区域的权威名称服务器返回到最终的记录给本地名称服务器。然后再由本地名称服务器返回给DNS客户,同时本地名称服务器会缓存本次查询得到的记录项。
迭代解析:DNS 服务器另外一种查询方式为迭代查询,DNS 服务器会向客户机提供其他能够解析查询请求的DNS 服务器地址,当客户机发送查询请求时,DNS 服务器并不直接回复查询结果,而是告诉客户机另一台DNS 服务器地址,客户机再向这台DNS 服务器提交请求,依次循环直到返回查询的结果为止。
(1)客户端向本机配置的本地名称服务器(在此仅以首先DNS服务器为例进行介绍,其它备用DNS服务器的解析流程完全一样)发出DNS域名查询请求
(2)本地名称服务器收到请求后,先查询本地的缓存,如果有该域名的记录项,则本地名称服务器就直接把查询的结果返回给客户端;如果本地缓存中没有该域名的记录,则向DNS客户端返回一条DNS应答报文,报文中会给出一些参考信息,如本地名称服务器上的根名称服务器地址等。
(3)DNS客户端在收到本地名称服务器的应答报文后,会根据其中的根名称服务器地址信息,向对应的根名称服务器再次发出与前面一样的DNS查询请求报文。
(4)根名称服务器在收到DNS查询请求报文后,通过查询自己的DNS数据库得到请求DNS域名中顶级域名所对应的顶级名称服务器信息,然后以一条DNS应答报文返回给DNS客户端。
(5)DNS客户端根据来自根名称服务器应答报文中的对应顶级名称服务器地址信息,向该顶级名称服务器发出与前面一样的DNS查询请求报文。
(6)顶级名称服务器在收到DNS查询请求后,先查询自己的缓存,如果有所请求的DNS域名的记录项,则相接把对应的记录项返回给DNS客户端,否则通过查询后把对应域名中二级域名所对应的二级名称服务器地址信息以一条DNS应答报文返回给DNS客户端。
然后DNS客户端继续按照前面介绍的方法一次次地向三级、四级名称服务器查询,直到最终的权威名称服务器返回到最终的记录。
解析类型:
Name -------> IP
IP -------> Name
注意:正反解析是两个不同的名称空间,是两棵不同的解析树
DNS服务器的类型:
主DNS服务器:维护所负责解析的域内解析库服务器;
辅DNS服务器:从主DNS服务器或其它的从DNS服务器那里“复制“(区域传送)一份解析库;
序列号:解析库的版本号;前提:主服务器解析库内容发生变化,其序列递增。(从服务器和主服务器的序列号本开是一致的,从服务器通过序列号来判断主服务器是否发生变化)
刷新时间间隔:从服务器向主服务器请求同步的时间间隔;
重式时间间隔:从服务器从主服务器请求同步解析库失败后,再次尝试的时间间隔;
过期时长:从服务器始终联系不到主服务器时,多久之后放弃从服务器角度,停止提供服务。
“通知“机制:主服务器数据改变后它会通知从服务器:我的数据发生改变了,你快点过来同步数据(即使还没到下一次刷新时间)
缓存DNS服务器:接收互联网用户请求,不负责解析任何域,只提供代理解析工作,并将解析的结果存在本地,实现缓存功能
主从之间的数据同步方式:区域传送
区域传送:
全量传送:传送整个解析库
增量传送:传送解析库变化的那部分。
主服务器和从服务器同时提供服务,当第一台服务器解析不到不会去找第二台服务器,而是去找根,如果还是解析不到,则报错。只有当第一台服务器坏了才去找第二台服务器。
Domain:
正向:FQDN -----> IP
反向:IP -----> FQDN
**各需要一个解析库来分别负责本地域名的正向和反向解析:**正向区域,反向区域
提到即有正向又有反向,提到区域则只有正向或反向。
FQDN :Full Qualified Domain Name ,完全合格域名 例如:www.wtt.com.
一次完整的查询请求的流程:
Client -----> hosts文件 -----> DNS Service -----> Local Cache ----> DNS Server ------ Server Cache -----> iteration(迭代)—>
解析答案:
肯定答案:
否定答案:请求的条目不存在等原因导致无法返回结果;
权威答案:所查询的域名的结果是由负责解析这个域的DNS服务器所返回的答案。
非权威答案: 在缓存中查询的结果。
客户端向dns服务器请求解析mail.magedu.com,假设权威服务器告没有此结果,客户端不死心,一次一次的问,dns服务器不断要解析这种请求然后响应这种的答案一遍有一遍,所以否定答案也需要做缓存。
所以否定答案做同一缓存,请求的任何一个条目本地没有的都叫否定,否定也应该有一个时长,因为现在没有不代表以后也没有。
#BIND
**区域解析库:**由众多RR组成
资源记录: Resource Record,RR
记录类型:A,PTR,SOA,NS,CNAME,MX,AAAA
SOA:Start Of Authority ,起始授权记录: 一个区域解析库有且只能由一个SOA库,并且出现在第一条(用来说明当前的区域解析库为哪个区域所用,由谁负责)
A:internet Address,作用:FQDN ---> IP
AAAA:FQON -- IPV6
PTR:PoinTeR , IP –> FQDN
NS:Name Server,用来标明当前区域的DNS服务器
CNAME:Canonical Name,别名记录
MX:Mail eXchanger , 邮件交换器
资源记录定义的格式:
语法:name [TTL] IN rr_type value
注意:(1)TTL可从全局继承
(2)@可用于引用当前区域的名字
(3)同一个名字可以通过多条记录定义多个不同的值;此时DNS服务器以轮询方式响应
(4)同一个值也可能有多个不同的定义名字,通过多个不同的名字指向同一值进行定义,此时仅表示可以通过不同的名字找到同一个主机而已
SOA:
name:当前区域的名字,例如:“magedu.com.”;
value: 由多部分组成
(1)当前区域的主dns服务器的FQDN,也可以使用当前区域的名字
(2)当前区域管理员的邮箱地址:但地址中不能使用@符号,一般用”.”替换,例如将linuxedu@magedu.com 替换为 linuxedu.magedu.com;
(3)(主从服务器协调属性的定义,及否定答案的统一TTL)主从服务器协调属性:例如序列号,刷新时间间隔,重试时间间隔,过期时长
示例:
magedu.com 86400 IN SOA ns.magedu.com. nsadmin.magedu.com. (
2015042201 ;序列号
2H ;刷新时间
10M ;重试时间
1W ;过期时间
1D ;否定答案的TTL值
)
NS:
name:当前区域的名字
value:当前区域的某dns服务器的名字。例如ns.magedu.com. :
注意:(1)一个区域可以有多个NS记录
(2)相邻的两个资源记录的name相同时,可省略
(3)对NS而言,任何一个ns记录后面的服务器的名字,都应该在后续有一个A记录
例如 :
magedu.com. IN NS ns1.magedu.com.
magedu.com. IN NS ns2.magedu.com.
MX:
name:当前区域的名字
value:当前区域的某个邮件服务器(smtp服务器)的主机名;
一个区域内,MX记录可以有多个,value之前应该有一个数字(0~99),表示此服务器的优先级;数字越小,优先级越高
注意:(1)对于MX记录而言,任何一个MX记录后面的服务器名字,都应该在后续有一个A记录;
例如:
magedu.com. IN MX 10 mx1.magedu.com.
IN MX 20 mx2.magedu.com.
A:
name:某主机的FQNN,例如:www.magedu.com.
value :主机名对应的IP地址
例如1:
此时,以轮询方式响应
www.magedu.com. IN A 1.1.1.1
www.magedu.com. IN A 1.1.1.2
例如2:
仅表示可以通过不同的名字找到同一个主机而已
mx1.magedu.com. IN A 1.1.1.3
mx2.magedu.com. IN A 1.1.1.3
【注意】
*.magedu.com. IN A 1.1.1.4
避免用户写错名称时给错误答案,可通过泛域名进行解析至某特定地址;
magedu.com. IN A 1.1.1.4
有的用户在访问时不指定www,也可以访问
AAAA:
name:FQDN
value:Ipv6
PTR:
name:IP,有特定格式,把IP地址反过来写,1.2.3.4,要写做4.3.2.1;而有特定后缀:in-addr.arpa.,所以完整写法为:4.3.2.1.in-addr.arpa.
value:FQDN
例如:
4.3.2.1.in-addr.arpa. IN PTR www.magedu.com
CNAME:
name:别名的FQDN
value:真名字的FQDN
例如
web.magedu.com. IN CNAME www.magedu.com.
子域授权: 每个域的名称服务器都是由上级名称服务在解析库中授权:
比如根域授权给tld(顶级域):
.com. IN NS ns1.com.
.com IN NS ns2.com.
ns1.com. IN A 2.2.2.1
ns2.com. IN A 2.2.2.2
例如:我们要想使用magedu.com.这个域名,在.com的名称服务器的解析库中添加资源记录:
magedu.com. IN NS ns1.magedu.com.
magedu.com. IN NS ns2.magedu.com.
magedu.com. IN NS ns3.magedu.com.
ns1.magedu.com IN A 3.3.3.1
ns2.magedu.com IN A 3.3.3.1
ns3.magedu.com IN A 3.3.3.1
**BIND安装配置: **
dns服务:程序包名bind,服务名named
程序包:
bind
bind-libs
bind-utils
chroot :将某服务圈禁在某个范围中
bind-chroot :/var/named/chroot/
bind:
服务脚本:/etc/rc.d/init.d/named
主配置文件:/etc/named.conf
子配置文件:/etc/named.rfc1912.zones
/etc/rndc.key
解析库文件:/var/named/ZONE_NAME.ZONE
【注意】
(1)一台物理服务器可同时为多台区域提供解析;
(2)必须要有根区域文件 /var/named/named.ca
(3)应该有两个(如果包括ipv6的应该更多)实现localhost和本地回环地址的解析库;named.localhost named.loopback
(4)rndc: remote name domain controller,默认与bind装在一起,且只能通过127.0.0.1来连接named进程,提供辅助性的管理功能,端口:953/tcp
主配置文件:
全局配置:option{}
日志子系统配置:logging{}
区域定义:本机能够为哪些zone进行解析,就要定义哪些zone;
zone “ZONE_NAME”IN {}
注意:任何服务程序如果期望其能通过网络被其他主机访问,至少监听在一个能与外部主机进行通信的ip地址上;
缓存名称服务器的配置:
监听外部地址即可
dnssec :建议测试时关闭dnssec;
主dns名称服务器:
(1) 在主配置文件中定义区域:
zone “ZONE_NAME” IN{
type {master|slave|hint|forward};
file “ZONE_NAME.zone”;
};
(2) 定义区域解析库文件
出现的内容:
宏定义:
资源记录:
测试记录:
dig的使用:
dig [-t type] name [@SERVER] [query options]
dig用于测试dns系统,因此,不会查询hosts文件进项解析
查询选项:
+[no]trace:跟踪解析过程 迭代
+[no]recures: 进行递归解析
测试反向解析:
dig –x IP @server
模拟区域全量传送:
dig -t axfs ...
否定答案:
缓存时间在SOA定义了
为了避免出现否定回答,可定义通用解析:
host命令:
host [-t type] name [SERVER]
nslookup命令:
交互模式:
nslookup>
server IP: 指明使用哪个DNS server进项查询;
set q=RR_TYPE:指明查询的资源记录类型;
NAME:要查询的名称;
反向区域:
区域名称:网络地址反写.in-addr.arpa.
172.16.100. ------> 100.16.172.in-addr.arpa.
(1)定义区域
zone “ZONE_NAME” IN {
type {master|slave|forward};
file “网络地址.zone”
};
(3) 区域解析库文件
注意:不需要MX和A,AAAA记录,以PTR记录为主;
主从复制:
1、 从服务器应该是一台独立的名称服务器,否则就没有任何意义了
2、 主服务器的区域解析库文件中必须有一条NS记录是指向从服务器的
3、 从服务器只需要定义区域,而无需提供解析库文件:解析库文件应该放到/var/named/slaves/目录中
4、 主服务器应该允许从服务器过来进行区域传送
5、 主从服务器时间应该同步,可通过ntp进行
6、 bind程序版本应该保持一致,否则应该从高主低
定义从区域的方法
zone “ZONE_NAME”IN {
type slave;
master { MASTER_IP; };
file “slaves/ZONE_NAME.zone”;
};
主服务器的解析文件发生改变通过更改序列号向从服务发出通知。
r ndc:
rndc 客户端命令-----》rndc服务端(tcp/953)
而rndc服务端能与本机上的named建立某种关联,所以客户主机就可以远程控制服务端得named
但如果rndc出现一些漏洞,客户端就很容易获得窝们主机上的信息,所以不安全,所以一般我们都是把rndc客户端和服务端装在同一台主机上,自己控制自己
rndc 命令
命令:
reload:重载配置文件和区域文件
reload zone:重载区域解析库文件
retransfer zone:手动启动区域传送过程,而不管序列号的增加
notify zone:重新对区域传送发通知
reconfig:重载主配置文件
querylog:开启或关闭查询日志(一般都会关掉)
trace:递增debug级别(一般不开启 即:0)
trace level:指定使用得级别
bind的高阶应用
DNS sand Bind(3)
子域授权:分布式数据库
正向解析区域的子域授权方法:
定义一个子区域:
ops.magedu.com. IN NS ns1.ops.magedu.com.
ops.magedu.com. IN NS ns2.ops.magedu.com.
ns1.ops.magedu.com. IN A 1.1.1.1
ns2.ops.magedu.com. IN A 1.1.1.2
fin.magedu.com. IN NS ns1.fin.magedu.com.
fin.magedu.com. IN NS ns2.fin.magedu.com.
ns1.fin .magedu.com . IN A 1.1.1.3
ns2.fin.magedu.com. IN A 1.1.1.4
ops的父域magedu应该在.c om上有授权 ,否则无法在网上获得授权
子域如果解析父域的名称服务器,子域是不知道父域在哪的,所以它会去找根(需要访问互联网),这时就有点走绕路的感觉了,所以我们此时就定义了区域转发这个东西,来明确说明当自己不负责的时候转发给哪台服务器来实现。
定义转发服务器:
注意:被转发的服务器需要能够为请求者做递归,否则,转发请求不予进行。
1、 全局转发(全部转发):凡是非本机所负责解析的区域的请求,通通转发给指定的服务器
Options {
forward
forwarders
}
2、 区域转发:仅转发对特定区域的请求至某服务器;
zone “ZONE_NAME” IN {
type forward;
forward {first|only}
forwarders
}
需要关掉dnssec 功能:
dnssec-enable no;
dnssec-validation no;
first:当转发服务器没有响应时,自己去找根。(先递归,再迭代)
only:当转发服务器没有响应时,不管。
递归:客户端发出查询,如果本地名称服务器无结果,由本地名称服务器将请求转发给根,根再将顶级域名称服务器的位置发给本地名称服务器,本地名称服务器将二级域得dns名称服务器的位置给本地名称服务器。。。。。。最终找到权威名称服务器,,然后权威名称服务器向本地名称服务器转发最终结果,本地名称服务器收到结果后向客户端发送答案
迭代:
客户端向本地名称服务器发出查询请求,未果,则本地名称服务器会将根名称服务器的位置发给客户端,
客户端找根,根将顶级域发给客户端
。。。
客户端找权威名称服务器,权威名称服务器将结果发给客户端
当有客户端向父域发出找父域的子域的,父域明确知道子域在哪,因为自己的dns的解析文件中已经有了明确的记载,所以不需要层层找根
allow-query::允许查询dns的客户端的地址年,默认本地,注释掉表示所
父域:
有
子域:
测试:norecurse
全局转发:
区域转发
只把对magedu.com这个域的请求转发给172.17.100.11
全局转发和区域转发都被启用的情况下,能够被区域转发的就以区域转发为准。
bind中基础的安全相关的配置:
acl:把一个或多个主机归并为一个集合,并通过一个统一的名称调用
acl acl_name{
ip;
ip;
net/prelen;
};
bind有四个内置的acl:
none:没有一个主机
any:任意主机
local:主机
localnet:本机的ip同掩码运算后得到的网络地址
注意:acl只能先定义,后使用;因此,其一般定义在配置文件中options的前面;
例子:
acl mynet{
172.16.0.0/16
}
访问控制的指令:
allow-query {}:允许查询的主机,白名单
allow-transfer {}:允许区域传送的主机,白名单
allow-recursion {}:允许递归的主机,通常定义在全局中(options)
allow-uodate {}:允许更新区域数据库的内容