Linux运维实战之DNS基础
Posted python运维自动化之路
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux运维实战之DNS基础相关的知识，希望对你有一定的参考价值。
DNS服务作为网络的一种基础架构，在网络中有举足轻重的地位。它担负着整个网络用户计算机的名称解析工作。没有正确的名称解析，服务器就无法识别各客户机。我们日常进行的浏览网页等上网活动，无一例外都在使用DNS服务。本次博文我们就来谈谈DNS的基本知识。
【本次博文的主要内容】
- DNS服务器的组成
- DNS域名称空间
- DNS服务器的工作原理
- DNS的名称解析库及资源记录
一、DNS服务器的组成：
【DNS是什么】：
由网络知识可知：两台主机之间相互通信依靠的是IP地址，而数字对我们人类来说难以记忆，所以我们人类喜欢用友好的名称（如：www.magedu.com）来定位诸如网络上的Web服务器这样的计算机。但计算机是用数字地址在网络上通信的。由此，如果用友好的名称该如何实现在网络上主机间的通信呢？DNS技术应运而生。
DNS：（Domain Name Service）域名服务，是一种组织成层次结构的计算机和网络服务命名系统，用于实现名称解析（hostname<-->IP）。其中通过计算机名解析出ip地址的叫做正向解析，通过ip地址解析出计算机名的叫做反向解析。DNS服务监听在主机的TCP/UDP的53号端口。
说到这里，我来问大家一个问题哈：www.sina.com 这是一个主机名还是域名？
【答】：这是一个主机名哈，sina.com才是域名。
【DNS服务器的组成】
一个典型的DNS服务包含4个部分，如下图所示：
1、DNS域名称空间：它指定用于组织名称的域的层次结构
2、资源记录（RR）：它将DNS域名映射到特定类型的资源信息，以供在名称空间中注册或解析名称时使用。在Linux系统中，通常“名称解析库（文本文件，位于/var/named/）”中的每一行称作一个资源记录。
3、DNS服务器：它存储和应答资源记录的名称查询
4、DNS客户端（解析程序）：它查询从服务器来的搜索及将名称解析为查询中指定的资源记录类型。
【DNS服务器的类型】
缓存DNS服务器：不包含域名数据库文件，它每次将从域名服务器得到的查询结果返回给客户端，并在本地将以缓存，供下次查询使用。
主DNS服务器(master): 数据库更新由管理员手动完成
辅助DNS服务器(slave)：数据库更新从主服务器或其它辅助DNS服务器那里完成
二、DNS域名称空间：
DNS域名空间是一种层次化的结构，这种层次化的结构我们已经不是第一次遇到了哈，以前的博文就说过，层次化结构有利于将复杂的问题简单化，能够大大简化查找的复杂度（例如：OSI参考模型是层次化的、IP地址结构是层次化的、Linux文件系统的结构也是层次化的）。
【组织DNS域名称空间】
DNS域名称空间的组织如下图所示：
整个DNS域名空间呈倒立的树状结构分布，被称为“域树”。
根域：最上面是根域名 dot，全球13台根域服务器（a.root-server.net~m.root-server.net），没有一台在中国。
Tips：根域服务器的地址、位置、IP
- A INTERNIC.NET（美国，弗吉尼亚州） 198.41.0.4
- B 美国信息科学研究所（美国，加利弗尼亚州） 128.9.0.107
- C PSINet公司（美国，弗吉尼亚州） 192.33.4.12
- D 马里兰大学（美国马里兰州） 128.8.10.90
- E 美国航空航天管理局（美国加利弗尼亚州） 192.203.230.10
- F 因特网软件联盟（美国加利弗尼亚州） 192.5.5.241
- G 美国国防部网络信息中心（美国弗吉尼亚州） 192.112.36.4
- H 美国陆军研究所（美国马里兰州） 128.63.2.53
- I Autonomica公司（瑞典，斯德哥尔摩） 192.36.148.17
- J VeriSign公司（美国，弗吉尼亚州） 192.58.128.30
- K RIPE NCC（英国，伦敦） 193.0.14.129
- L IANA（美国，弗吉尼亚州） 198.32.64.12
- M WIDE Project（日本，东京） 202.12.27.33
顶级域：由两三个字母组成的名称，用于指示国家（地区）或使用名称的单位的类型。如：
组织域：.net, .com, .org, .mil, .edu, .gov, .cc, .mobi
国家域：.jp, .tw, .hk, .iq, .ir, .cn, .uk, .us
二级域：在Internet上使用而注册到个人或单位的长度可变的名称。这些名称始终基于相应的顶级域，这取决于单位的类型或使用名称所在的地理位置。如：
sina.com.是由Internet DNS域名注册人员注册到新浪公司的二级域名
子域：单位可创建的其他名称，这些名称从已注册的二级域名中派生。包括为扩大单位名称的DNS树添加的名称，并将其分为部门或地理位置。如：
sports.sina.com.是新浪网体育版块的子域
重点理解：子域授权
授权是自上而下的，也就是说，上级知道下级的存在并知道下级的主DNS服务器地址（上级的名称解析库中有一条下级域的NS记录和主机A记录），而下级并不知道上级的存在，因此下级需要从根域开始查找。
举例说明：
如下图所示，nwtraders.com域下有3个子域，现在假设主机server1想要与子域east.nwtraders.com下的某台主机通信，DNS查询的过程是怎样的呢？它首先把请求发送到主持本区域的DNS服务器，主持本区域的DNS服务器查询自己的名称解析库发现主机server1发送的查询请求的区域并不归自己负责，那它必然要向外迭代哈，此时它首先要找根域，然后层层迭代以至找到最终答案。注意，它并不知道south.nwtraders.com域和nwtraders.com的存在，因此它不能通过south.nwtraders.com域直接找到答案。
*反向域：IP-->FQDN
【注】：两个名词解释
（1）完全限定域名（FQDN）：如上图所示，server1.sales.south.nwtraders.com.即为完全限定域名（类似于在日常生活中，南京市玄武区珠江路80号的张三），FQDN保证网络中的计算机名不会重名。
（2）主机名：如上图所示，server1是主机名（类似于人名，张三）
三、DNS的工作原理：
1、DNS服务器的名称查询原理：
【DNS服务器的解析过程】
DNS解析原理及过程：
说明：服务器之间的箭头上的数字均显示DNS查询事件的次序，字母则表示事件查询请求的类型。
DNS的查询过程按两部分进行：
（1）名称查询从客户端计算机开始（客户端浏览器中键入www.magedu.com），并传送至解析程序（即DNS客户端程序）进行解析
（2）不能就地解析查询时，可根据需要查询DNS服务器来解析名称
查询流程详解：
（1）客户端浏览器中键入www.magedu.com发出查询请求，浏览器将调用本地stub resolver解析器（存根解析器）去本地(/etc/hosts)查询有没有相关的记录，有则返回结果
（2）本地hosts没有查到，则查找本地DNS解析器缓存，如果查到则直接返回，完成域名解析。
（3）如果hosts与本地DNS解析器缓存都没查询到，则查询TCP/IP参数中设置的首选DNS服务器（即本地DNS服务器），此服务器收到查询请求时首先检查是否是自己负责的区域，如果是则返回权威应答给客户机，完成域名解析。
（4）如果要查询的域名，不由本地DNS服务器区域解析，但该DNS服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
（5）如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（没有设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责 .com域的这台服务器。这台负责 .com域的服务器收到请求后，如果自己无法解析，它就会找一个管理 .com域的下一级DNS服务器地址(magedu.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找magedu.com域服务器，重复上面的动作进行查询，直至找到www.magedu.com主机。
（6）如果用的是转发模式（设置转发器），此DNS服务器就会把请求转发至上一级ISP DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
注：从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是迭代查询。
【两种查询方法详解】：
（1）递归查询：客户端得到结果要么成功，要么失败。(本地客户端和DNS服务直接交互，被请求的DNS服务器必须给出最终答案)
（2）迭代查询：服务器以相关参考性应答返回本地DNS。(DNS服务与DNS服务交互，得到的是参考答案)
总结：本地客户端向本地域名服务器查询请求时，查询类型为：一次递归，多次迭代。
【根提示功能】
一般情况下，DNS服务器之间的查询方式都是迭代查询。如上图所示，如果要查询www.microsoft.com（microsoft.com域不是本地DNS负责的区域），那么本地DNS就需要向外迭代查询（迭代查询从根域开始，如此，本地DNS就必须知道根域的IP地址）。根提示的功能可以让本地DNS服务器查询根域DNS服务器。
在Linux系统中，安装好了bind服务，会自动创建全球13台根服务器的解析库文件，保存在/var/named/named.ca文件中：
[[email protected] ~]# cat /var/named/named.ca #named.ca保存根域的解析库信息 ; <<>> DiG 9.5.0b2 <<>> +bufsize=1200 +norec NS . @a.root-servers.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34420 ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:7fd::1 L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35 ;; Query time: 147 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Mon Feb 18 13:29:18 2008 ;; MSG SIZE rcvd: 615
2、DNS服务器的反向查询原理
在大部分DNS查询中，客户端一般执行正向查询，正向查询是基于存储在地址（A）资源记录中的另一台计算机的DNS名称来搜索IP地址等信息。DNS也提供反向查询过程，允许客户端在名称查询期间使用已知的IP地址查询计算机名。反向查询采取问答形式进行，例如”您能告诉我使用IP地址192.168.1.20的计算机的DNS名称吗？“
DNS在最初设计上并不支持反向查询。支持反向查询过程可能存在一个问题，即DNS名称空间如何组织和索引名称，IP地址如何分配，这些方面都有差别。为了解决这个问题，在DNS标准中采用了一种叫”线索追踪的机制“，即定义了特殊域”in-addr.arpa“,并保留在Internet DNS名称空间中。为了创建名称空间，in-addr.arpa域中的子域是按照带句点十进制编号的IP地址的相反顺序构造的，且采用与正向解析完全不同的解析库。因此，创建in-addr.arpa域树的时候，IP地址八位字节的顺序必须倒置，并且定义一种新的资源记录类型”PTR“。
3、区域传送原理
【为什么需要区域传送】
DNS辅助服务器是一种容错设计，考虑的是一旦DNS主服务器出现故障或因负载太重无法及时响应客户机请求，辅助服务器将挺身而出为主服务器排忧解难。辅助服务器的区域数据都是从主服务器复制而来，因此辅助服务器的数据都是只读的，当然，如果有必要，我们可以很轻松地把辅助服务器升级为主服务器。辅助服务器从主服务器复制区域数据的过程叫“区域传送”。区域传送使用TCP的53号端口。
【区域传送的类型】
（1）完全区域传送（AXFR）
（2）增量区域传送（IXFR）
【区域传送原理】
（1）在新的配置过程中，目标服务器会向配置为区域源的主要DNS服务器发送初始“所有区域”传送（AXFR）的请求；
（2）主（源）服务器作出响应，并将此区域完全传送到辅助（目标）服务器；
该区域发送给请求传送的目标服务器，通过启动SOA资源记录的属性中的“序列号”字段建立的版本一起传送。SOA RR也包含一个以秒为单位的状态刷新间隔（默认设置是900秒或15分钟），指出目标服务器下一次应该在何时请求使用源服务器来续订该区域
（3）刷新间隔到期时，目标服务器使用SOA查询来请求从源服务器续订此区域；
（4）源服务器应答其SOA记录的查询。该响应包括该区域在源服务器中的当前状态的序列号。
（5）目标服务器检查响应中的SOA记录的序列号并确定怎样续订该区域；
如果SOA响应中的序列号等于其当前的本地序列号，那么区域在两个服务器中都相同，并且不需要区域传送。然后，目标服务器根据来自源服务器的SOA响应中的该字段值重新设置其刷新间隔来续订该区域。
如果SOA响应中的序列号比其当前本地序列号要高，则可以确定此区域已更新并需要区域传送。
（6）如果这个目标服务器推断此区域已经更改，则它会把IXFR查询发送至源服务器，其中包括此区域的SOA记录中序列号的当前本地值。
（7）源服务器通过区域的递增传送或完全传送做出响应。
如果源服务器支持增量传送，则通过IXFR做出应答，否则通过AXFR做出应答。
四、DNS的名称解析库及资源记录：
【问题引入】
当客户端发起一个DNS查询请求时，DNS服务器如何解析该查询请求呢？
答：类似于日常生活中查询人口，假设要查询南京市玄武区有没有一个叫张三的人那该怎么做呢？最直接有效的方法是到当地派出所查看相应的户口簿哈。同理，DNS服务器要解析客户端发来的查询请求，则必须要有相应的名称解析库。
下面详细总结下与DNS名称解析相关的基本知识。
【名称解析】：
以主机名为搜索码，在DNS解析数据库中查找对应的IP地址的过程；
在本地通过hosts文件来解析：
类Unix系统中：/etc/hosts
windows系统中：%windir%\system32\drivers\etc\hosts
【DNS解析类型】
正向解析：FQDN-->IP
反向解析: IP --> FQDN
【DNS的名称解析库】
在Linux系统中，DNS的名称解析库通常是一个文本文件（只能包含资源记录和宏定义)，通常保存在/var/named/目录下。其中文本文件的每一行称作一个资源记录。
每一个名称解析库称作”区域（zone）“
说明：区域（zone）与域之间的差异
区域zone是一个物理概念，一个区域就是一个DNS解析库
域是一个逻辑概念，一个域对应一个DNS域名称空间
正向解析与反向解析采用的是不同的解析库，一个配置了正向解析库和反向解析库的DNS意味着其包含了两个区域（正向zone和反向zone）
【资源记录】
1、资源记录有类型：
FQDN-->IPv4: A (Address)
FQDN-->IPv6: AAAA
Domain-->DNS Server：NS (Name Server)
Domain-->Master DNS: SOA (Start Of Authority), 起始授权记录（用于明确说明一个域内的主DNS服务器是哪个，必须是名称解析库中的第一条记录）
FQDN-->FQDN: CNAME (Canonical Name)
IP-->FQDN: PTR (pointer)
Domain-->Mail Server: MX (Mail eXchanger), 有优先级：0-99，数字越小级别越高
注：SOA记录定义了一个域内的主DNS是谁？主辅DNS服务器之间如何同步（即如何进行区域传送）
正向解析不能有PTR记录
反向解析不能有A记录，也不需要MX记录
对于互联网上的邮件服务器来说，PTR记录是必须的（为什么？因为如果只能正向解析而不能反向解析，那么大多邮件服务器会把其作为垃圾邮件来处理）
理解MX记录：我们的电子邮箱地址一般都是“用户名@域名”，例如[email protected]，然而我们的邮件一般都是发送到某个主机而不是域，那么发到哪个主机呢？DNS查询邮件地址@后面的域名所对应的MX记录来确定。因此，DNS可以有多个（通过主辅来区别），MX也可以有多个（通过优先级来区别）。
2、资源记录的格式：
name [ttl] class type value
说明：
name(名字)]: name字段表示该记录所描述的实体(通常是主机或者一个域)。如果几个连续的记录涉及同一个实体的话，那么则第一条之后可以省略，利用@来代替这个name字段。
[ttl]字段：TTL(time to live (存活时间)),默认字段以秒为单位指定时间长度，在指定的时间内，数据项可被缓存并且仍被认为是有效的。TTL必须位于该区域数据文件的第一行，默认可省
class：class指定网络类型：默认类型为IN，IN(指Internet)、HS(Hesiod:本地使用的目录服务)、CH(供域名服务器内部用来标示自己)
type：资源记录类型
value: 资源记录的值（具体解释见后面介绍）
3、各资源记录类型其“名称”有要求：
SOA: zone
NS: zone
A, AAAA: FQDN
CNAME: FQDN
PTR: ReverseIP.in-addr.arpa.
MX: zone
4、各资源记录类型其“value”有要求：
SOA: 主DNS服务器的FQDN
NS: 对应DNS服务器的FQDN
A,AAAA：IP
CNAME：FQDN
PTR：FQDN
MX: Mail Server FQDN
【举例说明各资源记录的格式】
SOA记录：
magedu.com 600 IN SOA dns.magedu.com. admin.magedu.com. ( #也可以用@表示当前域magedu.com
2014101701 #序列号, serial number，每次更改配置值是都要在原来的基础上加上1，表示有更新
2H
20M
7D
5H )
NS记录：
magedu.com 600 IN NS dns.magedu.com.
主机A记录：
dns.magedu.com. 600 IN A 10.0.0.1
别名记录：
ftp.magedu.com. 600 IN CNAME www
邮件记录：
magedu.com 600 IN MX 20 mailserver1.magedu.com.
PTR记录：
1.0.0.10.in-addr.arpa 600 IN PTR dns.magedu.com.
所有资源记录中，SOA记录的格式最特别，下面详细阐述之：
SOA有两种写法：
写法一：
SOA： zone [TTL] IN FQDN admin_mailbox ( 2013081201 ;序列号, serial number，每次更改配置值是都要在原来的基础上加上1，表示有更新 2h ;刷新时间, refresh time, 通知(notify): 只通知给本区域解析库文件中定义NS记录的所有主机； 5m ;重试时间, retry time 7d ;过期时间, expire time 1d ;否定答案的ttl )
写法二：
SOA： @ [TTL] IN FQDN admin_mailbox ( 2013081201 ;序列号, serial number 2h ;刷新时间, refresh time, 通知(notify): 只通知给本区域解析库文件中定义NS记录的所有主机； 5m ;重试时间, retry time 7d ;过期时间, expire time 1d ;否定答案的ttl )
注：[email protected] --> nsadmin.magedu.com. ;管理员邮箱在此种写法下的写法（注意最后一个点不能省略）
以上是关于Linux运维实战之DNS基础的主要内容，如果未能解决你的问题，请参考以下文章
20170804L08-03老男孩Linux实战运维培训-Lamp系列之-http服务重要基础概念讲解