当前TCP/IP网络中的设备之间进行通信，是利用和依赖于IP地址实现的．但数字形式的IP地址是很难记忆的．当网络设备众多，想要记住每个设备的IP地址，可以说是"不可能完成的任务".那么如何解决这一难题呢?我们可以给每个网络设备起一个友好的名称,如:www.kobe.org,这种由文字组成的名称,显而易见更要容易记忆.但是计算机不会理解这种名称的,我们可以利用一种名字解析服务将名称转化成(解析)成IP地址.从而我们就可以利用名称来直接访问网络中设备了,除此之外还有一个重要功能,利用名称解析服务可以实现主机和IP的解耦,即:当主机IP变化时,只需要修改名称服务即可,用户仍可以通过原有的名称进行访问而不受影响.
实现此服务的方法是多样的.如下面所述:
本地名称解析配置文件:hosts
- 根域
- 一级(顶级)域名:Top Level Domain:tld
三类:组织域,国家域(.cn,.ca,.hk,.tw),反向域
com,edu,mil,gov,net,org,int,arpa - 二级域名:magedu.com
- 三级域名:study.magedu.com
- 最多可达到127级域名
- 递归查询:一般客户机和本地DNS服务器之间属于递归查询,即当客户机向DNS服务器发出请求后,若DNS服务器本身不能解析,则会向另外的DNS服务器发出查询请求,得到最终的肯定或否定的结果后转交给客户机.此查询的源和目标保持不变,为了查询结果只需要发起一次查询
- 迭代查询:一般情况下(有例外)本地的DNS服务器向其它DNS服务器的查询属于迭代查询,如:若对方不能返回权威的结果,则它会向下一个DNS服务器(参考前一个DNS服务器返回的结果)再次发起进行查询,直到返回查询的结果为止.此查询的源不变,但查询的目标不断变化,查询结果一般需要发起多次查询
范例:whois 查询域名信息
Name Server,域内负责解析本域内的名称的DNS服务器
IPv4的根服务器:全球共13个负责解析根域的DNS服务器,美国10个,荷兰1个,瑞典1个,日本1个
IPv6的根服务器:全球共25个,中国1主3从,美国1主2从
- FQDN --> IP 正向解析
- IP --> FQDN 反向解析
注意:正反向解析是两个不同的名称空间,是两颗不同的解析树
范例:在windos上查询dns
- 主DNS服务器
- 从DNS服务器
- 缓存DNS服务器(转发器)
2.1.1 主DNS服务器
管理和维护所负责解析的域内解析库的服务器
2.1.2 从DNS服务器
从主服务器或从服务器"复制"(区域传输)解析库副本
- 序列号:解析库版本号,主服务器解析库变化时,其序列递增
- 刷新时间间隔:从服务器从主服务器请求同步解析的时间间隔
- 重试时间间隔:从服务器请求同步失败时,再次尝试时间间隔
- 过期时长:从服务器联系不到主服务器时,多久后停止服务
- 通知机制:主服务器解析库发生变化时,会主动通知从服务器
- 完全传输:传输整个解析库
- 增量传输:传输解析库变化的那部分内容
- 正向:FQDN(Fully Qualified Domain Name完全合格的域名) --> IP
- 反向:IP --> FQDN
- 正向区域
- 反向区域
- 肯定答案:存在对应的查询结果
- 否定答案:请求的条目不存在等原因导致无法返回结果
- 权威答案:直接由存有此查询结果的DNS服务器(权威服务器)返回的答案
- 非权威答案:由其它非权威服务器返回的查询答案
区域解析库:由众多资源记录RR(Resource Record)组成
记录类型:SOA,A,AAAA,PTR,NS,CNAME,MX,TXT
- SOA:Start Of Authority,起始授权记录.一个区域解析库有且仅有一个SOA记录,必须位于解析库的第一条记录
- A:internet Address,作用,FQDN --> IP
- AAAA:FQDN --> IPv6
- PTR:PoinTeR,IP --> PTR
- NS:Name Server,专用于标记当前区域的DNS服务器
- CNAME:Canonical Name,别名记录
- MX:Mail eXchanger,邮件交换器
- TXT:对域名进行标识和说明的一种方式,一般做验证记录时会使用此项,如:SPF(反垃圾邮件记录),https验证等,如下示例:
2.6.1 资源记录定义
注意:
1.TTL可从全局继承
2.使用"@"符号可用于引用当前区域的名字
3.同一个名字可以通过多条记录定义多个不同的值;此时DNS服务器会以轮询方式响应
4.同一个值也可能有多个不同的定义名字;通过多个不同的名字指向同一个值进行定义;此仅表示通过不同的名字可以找到同一个主机
2.6.2 SOA记录
name:当前区域的名字,例如"magedu.org."
value:有多部分组成
注意:
1.当前区域的主DNS服务器的FQDN,也可以使用当前区域的名字
2.当前区域管理员的邮箱地址;但地址中不能使用@符号,一般用.替换
例如:admin.magedu.org
3.主从服务区域传输相关定义以及否定的答案的统一的TTL
范例:
2.6.3 NS记录
name:当前区域的名字
value:当前区域的某DNS服务器的名字,例如:ns.magedu.org.
注意:
1.相邻的两个资源记录的name相同时,后续的可省略
2.对NS记录而言,任何一个ns记录后面的服务器名字,都应该在后续有一个A记录
3.一个区域可以有多个NS记录
范例:
2.6.4 MX记录
name:当前区域的名字
value:当前区域的某邮件服务器(smtp服务器)的主机名
注意:
1.一个区域内,MX记录可由多个;但每个记录的value之前应该有一个数字(0-99),表示此服务器的优先级;数字越小,优先级越高
2.对MX记录而言,任何一个MX记录后面的服务器名字,都应该在后续有一个A记录
范例:
2.6.5 A记录
name:某主机的FQDN,例如:www.magedu.org.
value:主机名对应主机的IP地址
避免用户写错名称时给错误答案,可通过泛域名解析进行解析至某特定地址
范例:
2.6.6 AAAA记录
name:FQDN
value:IPv6
2.6.7 PTR记录
name:IP,有特定格式,把IP地址反过来写,1.2.3.4,要写作4.3.2.1;而有特定后缀:in-addr.arpa,所以完整写法为:4.3.2.1.in-addr.arpa.
value:FQDN
注意:网络地址及后缀可省略;主机地址依然需要反着写
例如:
2.6.8 CNAME别名记录
name:别名的FQDN
value:真正名字的FQDN
例如:
每个域的名称服务器,都是通过其上级名称服务器在解析库进行授权,类似根域授权tld
glue record:粘合记录,父域授权子域的记录
范例:
DNS服务器软件:bind,powerdns,dnsmasq,unbound,coredns
yum list all bind*
- bind:服务器
- bind-utils:客户端
- bind-libs:相关库
- biind-chroot:安全包,将dns相关文件放至/var/named/chroot/
范例:安装bind软件
- BIND主程序:/usr/sbin/named
- 服务脚本和Unit名称:/etc/rc.d/init.d/named,/usr/lib/systemd/system/named.service
- 主配置文件:/etc/named.conf,/etc/named.rfc1912.zones,/etc/rndc.key
- 管理工具:/usr/sbin/rndc:remote name domain controller,默认与bind安装在同一主机,且只能通过127.0.0.1连接named进程,提供辅助性的管理功能;953/tcp
- 解析库文件:/var/named/ZONE_NAME.ZONE
注意:
(1)一台物理服务器可同时为多个区域提供解析
(2)必须要有根区域文件;named.ca
(3)应该有两个(如果包括ipv6的,应该更多)实现localhost和本地回环地址的解析库
- 全局配置:options {};
- 日志子系统配置:logging {};
- 区域定义:本机能够为哪些zone进行解析,就要定义哪些zone
zone “ZONE_NAME” IN {};
注意: - 任何服务程序如果期望其能够通过网络被其它主机访问,至少应该监听在一个能与外部主机通信的IP地址上
- 缓存名称服务器的配置:监听外部地址即可
- dnssec:建议关闭dnssec,设为no
1.在主配置文件中定义区域
2.定义区域解析库文件
内容包括:
- 宏定义
- 资源定义
范例:区域数据库
范例:抓包观察查询结果
4.5.1 dig命令
dig只用于测试dns系统,不会查询hosts文件进行解析
命令格式:
范例:
4.5.2 host命令
命令格式:
范例:
4.5.3 nslookup命令
nslookup 可以支持交互和非交互式两种方式进行
命令格式:
交互式模式:
nslookup>
server IP:指明使用哪个DNS server进行查询
set q=RR_TYPE:指明查询的资源记录类型
NAME:要查询的名称
4.5.4 rndc命令
利用rndc工具可以实现管理DNS功能
rndc 监听端口:953/tcp
命令格式:
4.6.1 实验目的
4.6.2 环境要求
4.6.3 前提准备
4.6.4 实现步骤
4.6.4.1 在DNS服务器端安装bind
4.6.4.2 修改bind配置文件
4.6.4.3 DNS区域数据库文件
4.6.4.4 检查配置文件和数据库文件格式，并启动服务
4.6.4.5 实现WEB服务
4.6.4.6 在客户端实现测试
4.6.4.7 扩展
动态更新：可以通过远程更新区域数据库的资源记录
实现动态更新，需要在指定的zone语句块中：
allow-update { any; };
范例：
chmod 770 /var/named
setsebool -P named_write_master_zones on #此命令必须要开启SELinux服务
nsupdate
>server 127.0.0.1
>zone kobe.local
>update add ftp.kobe.local 88888 IN A 8.8.8.8
>send
>update delete www.kobe.local A
>send
#测试
dig ftp.kobe.local @127.0.0.1
ls -l /var/named/kobe.local.zone.jnl
cat /var/named/kobe.local.zone
反向区域：即将IP反向解析为FQDN
区域名称：网络地址反写.in-addr.arpa.
示例：
172.16.100. --> 100.16.172.in-addr.arpa.
(1)定义区域
zone “ZONE_NAME” IN {
type {master|slave|forward};
file “网络地址.zone”
};
(2)定义区域解析库文件
注意：不需要MX，以PTR记录为主
范例：
$TTL 1D
$ORIGIN 16.172.in-addr.arpa.
@ IN SOA ns1.kobe.local. admin.kobe.local. (
1
1H
5M
7D
1D )
IN NS ns1.kobe.local.
1.2 IN PTR www.kobe.local.
3.4 IN PTR mx1.kobe.local.
只有一台主DNS服务器，存在单点失败的问题，可以建立主DNS服务器的备份服务器，即从服务器来实现DNS服务器的容错机制。从服务器可以自动和主服务器进行单向的数据同步，从而和主DNS服务器一样，也可以对外提供查询服务，但从服务器不提供数据更新服务。
1.应该为一台独立的名称服务器
2.主服务器的区域解析库文件中必须有一条NS记录指向从服务器
3.从服务器只需要定义区域，而无需提供解析库文件；解析库文件应该放置于/var/named/slaves目录中
4.主服务器得允许从服务器作区域传送
5.主从服务器时间应该同步，可通过ntp进行
6.bind程序的版本应该保持一致；否则，应该从高，主低
格式：
zone “ZONE_NAME” IN {
type slave;
file “slaves/ZONE_NAME.zone”;
};
6.3.1 实验目的
6.3.2 环境要求
6.3.3 前提准备
6.3.4 实现步骤
6.3.4.1 主DNS服务器端配置(参看前面案例)
6.3.4.2 从DNS服务器配置
6.3.4.3 客户端测试主从DNS服务架构
将子域委派给其它主机管理，实现分布式DNS数据库
正向解析区域子域方法
范例：
shanghai.kobe.local. IN NS ns1.ops.kobe.local.
shanghai.kobe.local. IN NS ns2.ops.kobe.local.
shenzhen.kobe.local. IN NS ns1.shenzhen.kobe.local.
shenzhen.kobe.local. IN NS ns2.shenzhen.kobe.local.
ns1.shanghai.kobe.local. IN A 1.1.1.1
ns2.shanghai.kobe.local. IN A 1.1.1.2
ns1.shenzhen.kobe.local. IN A 1.1.1.3
ns2.shenzhen.kobe.local. IN A 1.1.1.4
7.2.1 实验目的
7.2.2 环境要求
7.2.3 前提准备
7.2.4 实现步骤
7.2.4.1 在父域DNS服务器上实现主kobe.local域的主DNS服务
7.2.4.2 实现子域的DNS服务器
7.2.4.3 在父域和子域的web服务器上安装httpd服务
7.2.4.4 客户端测试
利用DNS转发，可以将用户的DNS请求，转发至指定DNS服务器，而非默认的根DNS服务器，并将指定服务器查询的返回结果进行缓存，提高效率。
注意：
1.被转发的服务器需要能够为请求者做递归，否则转发请求不予进行
2.在全局配置块中，关闭dnssec功能
dnssec-enable no;
dnssec-validation no;
8.2.1 全局转发：
对非本机所负责解析区域的请求，全转发给指定的服务器
在全局配置块中实现：
options {
forward first|only;
forwarders { ip; };
};
8.2.2 特定区域转发
仅转发对特定的区域的请求，比全局转发优先级高
zone “ZONE_NAME” IN {
type forward;
forward first|only;
forwarders { ip; };
};
first：先转发至指定的DNS服务器，如果无法解析查询请求，则本服务器再去根服务器查询
only：先转发至指定的DNS服务器，如果无法解析查询请求，则本服务器将不再去根服务器查询