DNS 服务相关概念 （一）

DNS 服务相关概念 （一）
DNS: Domain Name Service

例如： www.magedu.com ( 这是一个【主机名| FQDN】，而我们通常把它称为域名这是不准确的~)
FQDN: Full Qualified Domain Name (完全合格域名，或完全限定域名)




那什么才算是一个域名呢：magedue.com 才是一个域名。我们知道网络通讯在某一时刻一定是一对一
的通讯（说白了：就是主机与主机之间的通讯），而域名它代表的是一个范围。

DNS: 又称为名称解析或名称转换。 Name Resolving (为会什么把它称之名称解析呢，这是有原因的)。
通常我们所说的解析一般都会涉及数据查询的过程，而这些数据一般都存放在某个数据库当中。
例如：/etc/passwd这个文件它其实也就是一个数据库，而且很规范，我们知道passwd 这个文件
中的每一行都是由7个字段组成，并且分别代表不同的含义。比方说：第1个字段，表示用户名
第3个字段，表示用户UID，等等，在用户名和UID之间形成了一一对应的关系。我们再回顾
一下之前学习的NSSwitch 是干什么用的啊~ ，NSSwitch就是负责：当某用户输入某个用户名时把
这个用户名转换成对应的UID，我们也可以认为是把用户名解析为UID)

1、 那么DNS是用来解析什么的呢~？
DNS 主要是负责把: FQDN <--- (解析为) ---> IP地址
因此我们需要一个数据库来存放 FQDN 和IP 地址的对应关系。
比如： 172.16 .0.1 www.magedu.com.
172.16.0.2 mail.magedu.com.
172.16.0.3 ftp.magedu.com

2、此外将端口号和对应的服务建立关联关系，也认为是名称解析：
比如： 80 WEB服务443 HTTPS服务21 FTP服务22 SSH服务23 Telnet服务 25 SMTP服务 161 SNMP服务 因此除了上面提到的这2种，要实现名称解析或名称转换的机制还有很多，所以为了有一个统一的框架我们
的NSSwitch 就出现了。
NSSwitch 就是实现为多种需要实现名称解析的机制，提供名称解析的平台的。

在互联网诞生之初，由于互联网上的主机数量非常少，通常使用一个名为“hosts”的文件来记录主机名与
IP地址之间的对应关系，并完成主机名到IP地址的解析。但使用这种方式有一个弱点，hosts 文件需要及
时的更新，而最初是采用手动的方式来更新的，而且更新也十的麻烦，随着互联网上主机数量的增加，最
终，使用host的方式已经不能满足日常的 需要了~，而且随着加入互联网的主机数量急剧的增加，但是每
个人都随便给自己的主机取个名字（设定一个IP）,那么很显然主机之间的通讯就越来越困难了。因此所谓
名称地址管理机构（IANA）就在此时诞生了~ ，这个机构在美国，是由美国人创立的。但是由于IANA 具
美国官方的背景，而且人们后来也意识到 DNS已经成了一种互联网资源，而且是一种基础性互联网资源，因
此不应该为美国政府所维护。而且大家也不放心，所以后来人们把这种名称分配的功能交给一个民间组织来
管理，这个民间组织就是 ICANN

IANA: TheInternet Assigned Numbers Authority 互联网名称分配机构
ICANN: The Internet Corporation for Assigned Names and Numbers）互联网名称与数字地址分配机构

从此由ICANN来负责维护 IP地址、和主机名之间的对应关系。于是ICANN维护了一个数据库，在这个数据库中
记录了每一台主机的【 IP 与主机名】对应关系。

名称解析管理方式，由最初的集中式数据库 ----> 到---->分布式数据库
名称解析还可以理解为 IP地址与主机名对应关系的查询

TLD : Top Level Domain 顶级域
组织域：.com 、.org、.net、.cc
国家域：.cn、.tw、.hk、.iq、.jp 反向域：IP-->FQDN
说明：为什么会出现一个反向域呢~？其实DNS刚刚诞生的时候只能支持从FQDN --->到---> IP地址的解析。
后来借助于一种特殊的机制（指针的机制）才实现从IP地址--->到--->FQDN的解析。因此我们的正向和反向
解析是2个不同的数据库。

正反解析：从FQDN --->到---> IP地址
反向解析：从IP地址--->到--->FQDN




我们以下图为例来说明名称解析（查询）的整个过程：




例如：当ST1这台主机发起一个查询（查询www.magedu.com. 这台主机）。
第1种情形： 在ibm 这个域中没有NS服务器（域名服务器）
因为这个域中没有NS服务器，ST1会把查询请求直接发送给根（.）

第2种情形： 在ibm 这个域中有一台NS服务器（域名服务器）
ST1把查询请求发送给NS服务器，由NS服务来完成查询过程，并返回查询结果给ST1

NS服务器诞生的由来：
我们知道ibm 这个域里面可能有成千上万台客户端主机，每台主机都有可能查询 www.magedu.com.这台主机。
我们以ST1为例，当查询完成后ST1会把查询的结果保存在自己的缓存当中，当再次发起同样的请求时，直接读取
缓存当中的内容就行了，这样加快了查询的速度，并且还减少了对带宽资源的占用。但是ST1缓存里面的内容ibm
这个域当中的其它主机并不能使用(读取)，因为我们需要把查询结果缓存在一个公共的地方，让ibm这个域里机
的所有主机都能读取，NS服务器正是在这种背景下诞生的。

查询的过程（查询www.magedu.com.）分2个部分：
1. ST1 向NS服务器发送查询请求，NS会把这个请求提交给根，根说你可以去找.com
然后NS向.com提交查询请求，.com说你可以去找magedu, 于是NS向magedu
提交查询请求，magedu说我这里确实有一台名为www.magedu.com.的主机，它的
IP 也有。于是最终NS服务获得了查询的结果。所以我们不难看出以上这个查询过程是
一个迭代的过程，整个过程当中NS服务器发送多次查询请求。
2. 当NS服务器把查询的结果返回给ST1 时，整个查询的过程就结束了。在整个过程当中
ST1只发送了1次查询请求。所以相当来说ST1向NS服务器发送查询请求的过程是一
个递归的过程，很明显ST1只管从NS那里获取查询的结果，至于NS查询的过程是怎么样
ST1是不管的。
3. 如何理解名称解析管理方式，“分布式数据库”模型。




以中国为例，对上图来进行阐述。中国是一个大的区域，区域的代表是中国国主席。我们知道中国划分了很多个行政区，为什么这么划分？我们知道中国有34个省级行政区其中包括（4个直辖市、23个省、5个自治区、2个特别行政区），而且每个省又下辖多个市县，有如此多子的区域，如果都由某一个人（国家主席）来管理，其难度是可想而知的。即使不忙死也累死了。 那么有没办法解决呢？我们引入领导人负责制。 什么是领导人负责制？我们把中国这个大的区域划分为若干个小的区域（34个行政区）每一个区域指定一个代表（省长）来负责管理。我们的 .com、.net、.org 就是从根里面划分出来的小的区域，每个小区域我们为其指定一个NS服务器。.com、.net、.org下面还可以继续划分多个子区域。在每个小区域的NS服务器中维护了一个数据库用于记录其下的所有的子区域，以及每个子区域的NS 服务器的名称及其子区域的NS服务器的IP地址。子区域的NS 服务器的名称： 等同于省长的名字子区域的NS服务器的IP地址： 等同于省长的电话号码 其实上面的意思很好理解，我们只有知道了某个省的省长姓什么叫什么名字，他的电话号码，这样我们才能找到他。在名称解析时也是同样的道理，只有知道了小区域中某个
子区域的NS服务器的名称和IP地址，才能告诉查询提交的那一方你要查询的主机在哪里可以找到。比如：根收到来自，ibm这个域中的NS服务器的查询请求时， 根会告诉ibm这个域中的NS服务器www.magedu.com.这个主机我并不知道在哪里可以找到，但是.com在哪里我是知道的。根于是查询自己的数据库并找出有关.com 的记录信息，并把这些信息反馈给ibm这个域中的NS服务器 由此一来ibm这个域中的NS服务器就会去找 .com、当.com中的NS服务器收到来处ibm这域中的NS服务器的查询请求时，.com中的NS服务器会告诉.ibm中的NS服务器www.magedu.com这个主机我并不知道在哪里可以找到，但是magedu 在哪里我是知道的。于是.com中的NS服务器查询自己的数据库并找出有关maedu的记录信息，并反馈给.ibm中的NS服务器。

最后ibm这个域中的NS服务器就会去找magedu, 当magedu中的NS服务器收到来处ibm这域中的NS服务器的查询请求时, magedu中的NS服务器会查询自己的数据库发现其下确实有一台名为www.magedu.com 的主机。于是magedu中的NS服务器反把有关这台主机记录信息反馈给ibm这个域中的NS服务器。
我们对下图来进行一些更深入的讲解。 如图中所示，我们知道 .com 它是什么~ 。.com 代表一个范围，代表一个区域，我们需要为这个区域指定一个负责管理的人员，一个区域里可能有 www 、 ftp、ns这样众多的主机存，因为我们需要从中指定一个来负责管理这个区域。所以在根的数据库中每2行对应一条记录。比如： 第1行： .com (域的名称是什么？) —> NS.com( .com这个域由谁来管理？)第2行： NS.com (管理者名称是什么) —>IP (管理者对应的IP地址是什么？)




4. 其实每个域都有一个NS服务器，NS服务器不仅仅是响应域内部主机的的查询请求，还 经常用于处理域外部主机发送过来的查询请求。

什么是非权威答案、什么权威答案？
1. NS返回给ST1的查询结果是一个非权威答案。这又是为什么呢，那权威答案又在哪里？ 我们知道NS服务器从magedu获取查询结果，只是某一时刻的状态信息，比如在那一 刻www.magedu.com. 这台主机的IP地址是58.250.4.48 (联通)，但是下一刻这台 主机的IP地址就被管员改成了58.250.4.50 那么很显然NS缓存中的内容就不准确了，要 想得到准确的答案只有找magedu . 因此NS服务器缓存中的内容是一个非权威答案。所 以非权威答案都是有可能都会过期的，并产生错误。那怎么办呢？magedu这个域中的NS 服务器向ibm域中的NS服务器反馈查询结果时，可以设定这个结果在查询提交方的缓存中 能保留多长时间。在设定的这个时间段里查询提交方缓存的这个条目才是有效的。一旦超出 设定的时就必须重新发起查询请求。由此就出现了一个新的定义TTL 2. 我们的权威答案谁知道呢，magedu知道。

查询的分类： 1. 接受域内主机（本地主机）的查询请求（递归） 2. 接受外部主机的的查询请求：请求权威答案 (而权威答案的结果有2种) 第1种：返回肯定答案 并且有TTL值 第2种：返回否定答案 并且有TTL值 3. 接受外部主机的的查询请求：请求非权威答案 我们假设当ST1发送查询请求的时候（查询www.magedu.com.），它没有把查询请求 发送给本域内的NS.ibm.com.这台服务器，而是把查询请求发送给了 NS.kernel.org. 这台服务器,那么对于NS.kernel.org. 来说，它返回的是一个非权威的答案。