1、名字解析介绍和DNS

1.1、名字解析介绍

当前TCP/IP网络中的设备之间进行通信，是利用和依赖于IP地址实现的。但数字形式的IP地址很难记忆的。当网络设备众多，想要记住每个设备的IP地址，可以说是”不可能完成的任务”。那么如何解决这一难题呢？

我们可以给每个网络设备起一个友好的名称，如：www.lijiach.com，这种由文字组成的名称，显而易见要更容易记忆。但是计算机不会理解这种名称的，我们可以利用一种名字解析服务将名称转化成（解析）成IP地址。从而我们就可以利用名称来直接访问网络中设备了。除此之外还有一个重要功能，利用名称解析服务可以实现主机和IP的解耦，即：当主机IP变化时，只需要修改名称服务即可，用户仍可以通过原有的名称进行访问而不受影响。

实现此服务的方法：

本地名称解析配置文件：hosts

Linux: /etc/hosts
windows: %WINDIR%/system32/drivers/etc/hosts

#格式
39.101.72.1  www.lijiach.com www

DNS：Domain Name System 域名系统,应用层协议,是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网，基于C/S架构，服务器端：53/udp, 53/tcp

BIND：Bekerley Internet Name Domain，由 ISC （www.isc.org）提供的DNS软件实现DNS域名结构

根域：全球根服务器节点
一级域名：Top Level Domain：tld
- 三类：组织域、国家域(.cn, .ca, .hk, .tw)、反向域
- com, edu, mil, gov, net, org, int,arpa
二级域名：lijiach.com
三级域名：www.lijiach.com
最多可达到127级域名

ICANN（The Internet Corporation for Assigned Names and Numbers）互联网名称与数字地址分配机构，负责在全球范围内对互联网通用顶级域名（gTLD）以及国家和地区顶级域名（ccTLD）系统的管理、以及根服务器系统的管理

1.2、DNS服务工作原理

1.3、DNS查询类型

递归查询
- 是指DNS服务器在收到用户发起的请求时，必须向用户返回一个准确的查询结果。如果DNS服务器本地没有存储与之对应的信息，则该服务器需要询问其他服务器，并将返回的查询结构提交给用户。
- 一般客户机和本地DNS服务器之间属于递归查询，即当客户机向DNS服务器发出请求后，若DNS服务器本身不能解析，则会向另外的DNS服务器发出查询请求，得到最终的肯定或否定的结果后转交给客户机。此查询的源和目标保持不变，为了查询结果只需要发起一次查询
- 递归算法：客户端向LocalDNS发起域名查询–>localDNS不知道域名对应的IP–>但它知道谁知道->他代为帮客户端去查找–>最后再返回最终结果
迭代查询
- 是指DNS服务器在收到用户发起的请求时，并不直接回复查询结果，而是告诉另一台DNS服务器的地址，用户再向这台DNS服务器提交请求，这样依次反复，直到返回查询结果。
- 一般情况下(有例外)本地的DNS服务器向其它DNS服务器的查询属于迭代查询,如：若对方不能返回权威的结果，则它会向下一个DNS服务器(参考前一个DNS服务器返回的结果)再次发起进行查询，直到返回查询的结果为止。此查询的源不变，但查询的目标不断变化,为查询结果一般需要发起多次查询。
- 迭代算法：客户端向LocalDNS发起域名查询–>localDNS不知道域名对应的IP–>但它知道谁知道并推荐客户端应该找谁–>客户端自己去找它
DNS缓存
- DNS缓存是将解析数据存储在靠近发起请求的客户端的位置，也可以说DNS数据是可以缓存在任意位置，最终目的是以此减少递归查询过程，可以更快的让用户获得请求结果。

1.4、名称服务器

Name Server，域内负责解析本域内的名称的DNS服务器

1.5、解析类型

FQDN –> IP 正向解析
IP –> FQDN 反向解析
正反向解析是两个不同的名称空间，是两棵不同的解析树

1.6、完整的查询请求经过的流程

Client –>hosts文件 –> Client DNS Service Local Cache –> DNS Server (recursion递归) –> DNS Server Cache –>DNS iteration(迭代) –> 根域名服务器–> 顶级域名服务器–>二级域名服务器…

2、DNS 服务相关概念和技术

2.1、DNS服务器的类型

主DNS服务器
- 管理和维护所负责解析的域内解析库的服务器
从DNS服务器
- 从主服务器或从服务器”复制”（区域传输）解析库副本
  - 序列号：解析库版本号，主服务器解析库变化时，其序列递增
  - 刷新时间间隔：从服务器从主服务器请求同步解析的时间间隔
  - 重试时间间隔：从服务器请求同步失败时，再次尝试时间间隔
  - 过期时长：从服务器联系不到主服务器时，多久后停止服务
  - 通知机制：主服务器解析库发生变化时，会主动通知从服务器
缓存DNS服务器（转发器）

2.2、区域传输

完全传输：传送整个解析库
增量传输：传递解析库变化的那部分内容

2.3、解析形式

正向：FQDN（ Fully Qualified Domain Name） –> IP
反向：IP –> FQDN

2.4、负责本地域名的正向和反向解析库

正向区域
反向区域

2.5、解析答案

肯定答案：存在对应的查询结果
否定答案：请求的条目不存在等原因导致无法返回结果
权威答案：直接由存有此查询结果的DNS服务器（权威服务器）返回的答案
非权威答案：由其它非权威服务器返回的查询答案

2.6、各种资源记录

区域解析库：由众多资源记录RR(Resource Record)组成
记录类型：A, AAAA, PTR, SOA, NS, CNAME, MX

SOA：Start Of Authority，起始授权记录；一个区域解析库有且仅能有一个SOA记录，必须位于解
析库的第一条记录
A：internet Address，作用，FQDN –> IP
AAAA：FQDN –> IPv6
PTR：PoinTeR，IP –> FQDN
NS：Name Server，专用于标明当前区域的DNS服务器
CNAME ： Canonical Name，别名记录
MX：Mail eXchanger，邮件交换器
TXT：对域名进行标识和说明的一种方式，一般做验证记录时会使用此项，如：SPF（反垃圾邮件）记录，https验证等

# 资源记录定义的
name [TTL] IN rr_type value

1. TTL可从全局继承
2. 使用 "@" 符号可用于引用当前区域的域名
3. 同一个名字可以通过多条记录定义多个不同的值；此时DNS服务器会以轮询方式响应
4. 同一值也可能有多个不同的定义名字；通过多个不同的名字指向同一个值进行定义；此仅表示通
过多个不同的名字可以找到同一个主机

# SOA记录
name: 当前区域的名字，例如"lijiach.com."
value: 有多部分组成

1. 当前区域的主DNS服务器的FQDN，也可以使用当前区域的名字，只是注释功能，可以不需要配置对应的NS记录和A记录
2. 当前区域管理员的邮箱地址；但地址中不能使用@符号，一般用.替换，例如：admin.lijiach.com
3. 主从服务区域传输相关定义以及否定的答案的统一的TTL

# 范例
lijiach.com.      86400    IN    SOA ns.lijiach.com. nsadmin.lijiach.com. (
              2022102201 ;序列号
              2H         ;刷新时间
              10M ;重试时间
              1W ;过期时间
              1D ;否定答案的TTL值
              )

# NS记录
name：当前区域的名字
value：当前区域的某DNS服务器的名字，例如: ns.lijiach.com.

1. 相邻的两个资源记录的name相同时，后续的可省略
2. 对NS记录而言，任何一个ns记录后面的服务器名字，都应该在后续有一个A记录
3. 一个区域可以有多个NS记录

# 范例
lijiach.com. IN NS ns1.lijiach.com.
lijiach.com. IN NS ns2.lijiach.com.

# MX记录
name: 当前区域的名字
value: 当前区域的某邮件服务器(smtp服务器)的主机名

1. 一个区域内，MX记录可有多个；但每个记录的value之前应该有一个数字(0-99)，表示此服务器的优先级；数字越小优先级越高
2. 对MX记录而言，任何一个MX记录后面的服务器名字，都应该在后续有一个A记录

# 范例
lijiach.com. IN MX 10   mx1.lijiach.com.
             IN MX 20   mx2.lijiach.com.
mx1             A  192.168.1.100
mx2             A  192.168.1.200

# A记录
# A记录是将一个主机名（全称域名FQDN）和一个IP地址关联起来。这也是大多数客户端程序默认的查询类型。
name: 某主机的FQDN，例如：www.lijiach.com.
value: 主机名对应主机的IP地址

# 避免用户写错名称时给错误答案，可通过泛域名解析进行解析至某特定地址

# 范例
www.lijiach.com.         IN   A  1.1.1.1
www.lijiach.com.         IN   A  2.2.2.2
mx1.lijiach.com.         IN   A  3.3.3.3
mx2.lijiach.com.         IN   A  4.4.4.4
$GENERATE 1-254 HOST$    IN   A  1.2.3.$
*.lijiach.com.           IN   A  5.5.5.5
lijiach.com.             IN   A  6.6.6.6

# 如果有和DNS的IP相同的多个同名的A记录，优先返回DNS的本机IP

# 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.lijiach.com.

# 如1.2.3为网络地址，可简写成：
4 IN PTR www.lijiach.com.

# CNAME别名记录
name: 别名的FQDN
value: 真正名字的FQDN

2.7、子域授权

每个域的名称服务器，都是通过其上级名称服务器在解析库进行授权，类似根域授权tld。

glue record：粘合记录，父域授权子域的记录。

# 范例
.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
#lijiach.com. 在.com的名称服务器上，解析库中添加资源记录
lijiach.com.       IN   NS   ns1.lijiach.com.
lijiach.com.       IN   NS   ns2.lijiach.com.
lijiach.com.       IN   NS   ns3.lijiach.com.
ns1.lijiach.com.   IN   A    3.3.3.1
ns2.lijiach.com.   IN   A    3.3.3.2
ns3.lijiach.com.   IN   A    3.3.3.3

2.8、互联网域名

域名注册
- 代理商：万网，新网，godaddy
注册完成以后，想自己用专用服务来解析
- 管理后台：把NS记录指向的服务器名称，和A记录指向的服务器地址

2.9、whois

# whois 查询域名信息
[root@centos79-base01 ~]# yum install -y whois

[root@centos79-base01 ~]# whois lijiach.com
   Domain Name: LIJIACH.COM
   Registry Domain ID: 2730192818_DOMAIN_COM-VRSN
   Registrar WHOIS Server: grs-whois.hichina.com
   Registrar URL: http://wanwang.aliyun.com
   Updated Date: 2022-10-06T10:16:33Z
   Creation Date: 2022-10-06T10:11:20Z
   Registry Expiry Date: 2032-10-06T10:11:20Z
   Registrar: Alibaba Cloud Computing Ltd. d/b/a HiChina (www.net.cn)
   Registrar IANA ID: 1599
   Registrar Abuse Contact Email: DomainAbuse@service.aliyun.com
   Registrar Abuse Contact Phone: +86.95187
   Domain Status: ok https://icann.org/epp#ok
   Name Server: DNS21.HICHINA.COM
   Name Server: DNS22.HICHINA.COM
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2022-11-13T07:48:09Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar.  Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability.  VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.

2.10、HttpDNS

HttpDNS 定义

HttpDNS是使用HTTP协议向DNS服务器的80端口进行请求，代替传统的DNS协议向DNS服务器的53端口进行请求。也就是使用Http协议去进行DNS解析请求，DNS服务器返回的解析结果（域名对应的服务
器IP），直接向该IP发起对应的API服务请求，代替使用域名。

HttpDNS工作原理

HttpDNS的原理主要有两步
- 客户端直接访问HttpDNS接口，获取业务在域名配置管理系统上配置的访问延迟最优的IP。（基于容灾考虑，还是保留次选使用运营商LocalDNS解析域名的方式）
- 客户端向获取到的IP后就向直接往此IP发送业务协议请求。以Http请求为例，通过在header中指定host字段，向HttpDNS返回的IP发送标准的Http请求即可。

HttpDNS优势

从原理上来讲，HttpDNS只是将域名解析的协议由DNS协议换成了Http协议，并不复杂。但是这一微小的转换，却带来了很多的收益。
- A、根治域名解析异常：由于绕过了运营商的LocalDNS，用户解析域名的请求通过Http协议直接透传到了HttpDNS服务器IP上，用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰。
- B、调度精准：HttpDNS能直接获取到用户IP，通过结合IP地址库以及测速系统，可以保证将用户引导的访问最快的IDC节点上。
- C、实现成本低廉：接入HttpDNS的业务仅需要对客户端接入层做少量改造，无需用户手机进行root或越狱；而且由于Http协议请求构造非常简单，兼容各版本的移动操作系统更不成问题；另外HttpDNS的后端配置完全复用现有权威DNS配置，管理成本也非常低。总而言之，就是以最小的改造成本，解决了业务遭受域名解析异常的问题，并满足业务精确流量调度的需求。
- D、扩展性强：HttpDNS提供可靠的域名解析服务，业务可将自有调度逻辑与HttpDNS返回结果结合，实现更精细化的流量调度。比如指定版本的客户端连接请求的IP地址，指定网络类型的用户连接指定的IP地址等。