互联网是一个很大的地方。大量的协议和物理基础结构已经到位，使我们能够轻松使用它。DNS是一个巨大的话题。在本文中，我将介绍有关DNS及其组成部分的基本知识，并探讨DNS解析的实际应用。

DNS的目的＃

连接到互联网的每个设备都有一个分配给它的IP地址。该设备可以托管大量服务，互联网上的任何人都可以通过使用其IP地址连接到该设备来访问。例如，Wikipedia已使其网站可访问IP地址103.102.166.224（该IP地址可能与您不同），但是记住一长串数字以方便我联系它并不方便。Pffff。

这将立即限制访问Internet上所有很酷的内容。wikipedia.org代替IP地址将更容易使用。我们宁愿有某种机制可以为我们记住这些映射。因此，就像电话中的联系人列表一样，DNS（域名系统的缩写）维护着一堆有关服务器名称（或更确切地说是域名）的信息，每当您打开任何网站时，Web浏览器都会无提示地查询这些信息。

从技术上讲，DNS是一个分布式的分层数据库通过与该数据库进行交互（插入和检索信息）的机制在互联网上传播。DNS中的信息存储为资源记录（RR），这实际上是域名和某些数据之间的映射。一些资源记录类型为：

A ：将域名映射到IPv4地址。
AAAA ：映射到IPv6地址。
CNAME ：映射到域名的别名。
NS ：使用授权的域名服务器映射域名。
SOA ：指定域的区域的开始。

对于IP而言，拥有更多资源的资源记录对于将层次结构引入DNS并简化域名管理非常重要。在服务器的IP地址被更改的情况下，DNS还通过保持相同的服务器名称来带来可访问性的一致性。

DNS是互联网的关键结构，众所周知，如果没有DNS，DNS将会崩溃。

URL的细分＃

在开始之前，让我们先了解一个URL并弄清楚DNS解析URL的哪一部分。考虑以下URL

https://www.youtube.com/watch?v=dQw4w9WgXcQ

建立连接后，“ https”是用于与Web服务通信的协议。
“ www.youtube.com ”是代表托管Web服务的设备的域名，需要解析为IP地址。也称为完全合格域名（FQDN）。
'watch？v = dQw4w9WgXcQ'是我们要在Web服务中访问的资源或页面。

FQDN字符串由用单点分隔的标签组成。传统上，FQDN以代表根域的点结束。“ www.youtube.com ”和“ www.youtube.com”。'是一样的。末尾的点在表示中可以省略，但内部所有分辨率都在末尾点就位的情况下发生。

$PY$GTS%@5_4%{TJJ`N1${T8.png$

DNS中的层次结构＃

网站域名＃

域名是互联网中的一个领域，拥有域名的实体对其拥有管理权-在DNS中为相应域名创建或更新资源记录。层次结构可以在域名中看到，并且可以可视化为树。wikipedia.org.是域名的示例。这等级制度域的数量从FQDN中的右标签到左标签降序。左侧的每个标签都指定了右侧域的一个子域。层次结构中的第一个域是根域（由点表示）。

com，org，in，io是根域下的一些子域。根域下的第一级域称为顶级域（TLD），并且独立于根域进行操作。TLD的子域可供互联网用户购买。例如wikipedia，TLD的子域org.必须在某个时间点已购买。

$4_0ZOKA[2JV2`F8X]]{X)P4.png$

com，org，in是根域的子域。
youtube，duckduckgo是com或com.域的子域。
www，music是youtube.com或youtube.com.域的子域。

拥有域名权限可以将其映射到某些网络设备（可能正在运行某些网络服务）的IP地址或创建子域。域所有者甚至可以选择将子域的权限委派给其他实体。例如，如果Google觉得可以，那么它可以出售域名music.youtube.com并将域名的全部权限委派给买方。这是顶级域名（TLD）在出售子域名时通常会做的事情。

区域＃

区域是一组子域，其中包括域所有者对域进行完全控制的域本身。根区域仅具有根域。管理根区域的ICANN组织有权创建更多的TLD（可能是子域），就像过去一样。

根域的子域com，org是从在权威方面根域完全独立的。这意味着，如果在com域下添加任何新的子域，则根域不会受到任何影响，因为该com域不在其管辖范围之内。facebook.com在单独的区域中。域apps.facebook.com和与developers.facebook.com处于同一区域facebook.com。如果facebook.com要添加新服务（例如直播电视），他们可以tv.facebook.com在同一区域中进行设置，而无需打扰父域com。

$_LRLCEZYKBS8Q{F@TD%%WUY.png$

一个域可能在其区域下仅包含几个子域，并为其他子域委派权限。

权威名称服务器＃

每个域都有至少2个（用于冗余）与它们相关联的专用权威名称服务器。这些名称服务器维护并提供域及其子域的资源记录。如果查询域名，则最终将由其权威的名称服务器提供服务。

权威名称服务器是DNS的重要组成部分，因为它们形成了要查询域名解析的分布式层次数据库的节点。它们使DNS得以分发，因为每个域名可以具有自己的名称服务器，并且不绑定到单个中央数据库。

管理员可以根据自己的选择配置名称服务器。大型组织可以维护自己的权威名称服务器，以管理其域专有的资源记录。但是，在其他域之间共享其权威名称服务器的域名是很常见的。换句话说，许多单独的，不相关的域名可能正在使用共享名称服务器。

行动中的DNS解析＃

DNS解析由DNS客户端启动，以寻求域名的某些信息（例如IP地址）。它创建一个DNS查询，并将其发送到DNS服务器，然后DNS服务器为DNS客户端解析该查询。当我们连接到Internet时，我们的网络配置将保留由我们的ISP提供的默认DNS服务器。我们甚至可以使用我们选择的DNS服务器。8.8.8.8是Google提供的一种非常流行，易于记忆的DNS服务器。

下图演示了DNS解析中查询和响应的流程。

YF1}(5BYR]RQ8IR5$NH(VT7.png 客户端A为域en.wikipedia.org寻找具有IP地址的Type资源记录，该客户端创建DNS查询并将其发送到配置的DNS服务器。

要查找en.wikipedia.orgDNS服务器的IP地址，必须首先找到该域的名称服务器。为了找到该名称服务器，DNS服务器从其域名服务器首先与DNS服务器一起存储的根域开始，开始从右向左一次解析一个标签的域名。接下来的一行将是org.它查询根域的权威名称服务器之一，以询问的名称服务器。org.请注意，它首先搜索名称服务器，因为它们拥有该域的所有信息。
查询的名称服务器将结果返回到DNS服务器。
DNS服务器接下来向域名服务器之一查询org.域，以请求以下域名服务器的域名服务器：wikipedia.org
查询的名称服务器将合适的结果返回到DNS服务器。
最后，DNS服务器查询wikipedia.org名称服务器，询问以下内容的类型A记录：en.wikipedia.org
查询的名称服务器以类型A资源记录来响应DNS服务器。
DNS服务器将此结果答复给提出查询的DNS客户端。

为了使名称服务器免于重复查询的负担，DNS服务器实现了高速缓存机制，并且仅在名称服务器中按层次结构查询名称服务器（如果它们在其高速缓存中没有客户端请求的资源记录）。为了解释DNS解析及其所有组成部分，以上插图未考虑缓存。如果DNS服务器和Namerserver没有所需的信息，它们将以适当的答案进行答复。

使用DiG的示例＃

在阅读完所有内容后，这是一段有趣的时光，您可以看到这一切并进行验证。我已经将DNS服务器设置为，208.67.222.222并且将使用dig实用程序在bash shell中执行几个DNS查询。

1.简单的挖掘查询＃

dig期望将域名作为参数，并且默认情况下将查询A类资源记录。下面是命令dig www.reddit.com及其输出。

neeraj@mrm:~$ dig www.reddit.com
; <<>> DiG 9.16.1-Ubuntu <<>> www.reddit.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16713
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.reddit.com.            IN    A
;; ANSWER SECTION:
www.reddit.com.        254    IN    CNAME    reddit.map.fastly.net.
reddit.map.fastly.net.    30    IN    A    151.101.65.140
reddit.map.fastly.net.    30    IN    A    151.101.129.140
reddit.map.fastly.net.    30    IN    A    151.101.193.140
reddit.map.fastly.net.    30    IN    A    151.101.1.140
;; Query time: 84 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Tue Sep 01 00:16:04 IST 2020
;; MSG SIZE  rcvd: 142

输出说明：

上面输出的以下片段列出了DiG版本，发出的查询以及传递给dig的一些命令行选项。

; <<>> DiG 9.16.1-Ubuntu <<>> www.reddit.com
;; global options: +cmd

接下来是有关DNS标头的一些信息，例如标志，部分。

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16713
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

然后将查询发给DNS服务器。问题部分下的列格式为域名，DNS类，资源记录的类型。这里IN是指DNS类“ Internet”。

;; QUESTION SECTION:
;www.reddit.com.            IN    A

在“问题”部分之后是“答案”，“权限”和“其他”部分形式的响应。在此示例中，我们仅具有“答案”部分，在该部分中，我们接收CNAME到所查询域的Type资源记录而不是Type A，这可能是因为A该域的Type资源记录不存在，而这是DNS服务器相对于查询所找到的。 CNAME基本上这样指定别名，www.reddit.com.并且reddit.map.fastly.net.是同一事物的两个不同名称。域名后的数字是主机可以缓存资源记录的秒数。在CNAME我们拥有“类型”A资源记录之后，reddit.map.fastly.net.这给了我们4个IP地址，我们可以使用这些IP地址进行访问www.reddit.com.

;; ANSWER SECTION:
www.reddit.com.        254    IN    CNAME    reddit.map.fastly.net.
reddit.map.fastly.net.    30    IN    A    151.101.65.140
reddit.map.fastly.net.    30    IN    A    151.101.129.140
reddit.map.fastly.net.    30    IN    A    151.101.193.140
reddit.map.fastly.net.    30    IN    A    151.101.1.140

最后，我们对整个操作有一些统计。操作所需的时间，查询的DNS服务器等。

;; Query time: 84 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Tue Sep 01 00:16:04 IST 2020
;; MSG SIZE  rcvd: 142

2.更多 `CNAME`＃

您可能知道甚至可以从打开Facebook www.fb.com。让我们看看发生了什么事。我鼓励您仔细阅读输出内容。

neeraj@mrm:~$ dig www.fb.com
; <<>> DiG 9.16.1-Ubuntu <<>> www.fb.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29969
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.fb.com.            IN    A
;; ANSWER SECTION:
www.fb.com.        6569    IN    CNAME    www.facebook.com.
www.facebook.com.    668    IN    CNAME    star-mini.c10r.facebook.com.
star-mini.c10r.facebook.com. 60    IN    A    157.240.198.35
;; Query time: 112 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sun Sep 06 23:47:27 IST 2020
;; MSG SIZE  rcvd: 111

啊! 因此，在“答案”部分中，我们可以看到它 www.facebook.com只是的别名www.fb.com。

我们甚至可以通过在域名之后放置“类型”来直接查询特定的资源记录。

neeraj@mrm:~$ dig www.fb.com CNAME
; <<>> DiG 9.16.1-Ubuntu <<>> www.fb.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37259
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.fb.com.            IN    CNAME
;; ANSWER SECTION:
www.fb.com.        570    IN    CNAME    www.facebook.com.
;; Query time: 68 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sun Sep 06 23:48:17 IST 2020
;; MSG SIZE  rcvd: 66

3.完整的DNS解析＃

Dig实用程序具有一个有趣的标志+trace，它可以模拟DNS服务器如何解析查询。Dig会从根域开始迭代解析查询中的域名。您甚至可以将其与上图进行比较。最后，我们得到了结果-的别名www.duckduckgo.com.以及与别名相关联的Type A资源记录。要求您检查输出。使用该+trace标志时，输出仅包含响应，并且在响应的每个部分的底部都有已答复或被查询的DNS服务器的FQDN。

现在忽略NSEC3和RRSIG资源记录。

neeraj@mrm:~$ dig www.duckduckgo.com  +trace
; <<>> DiG 9.16.1-Ubuntu <<>> www.duckduckgo.com +trace
;; global options: +cmd
.            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.
.            518400    IN    NS    m.root-servers.net.
.            518400    IN    RRSIG    NS 8 0 518400 20200919050000 20200906040000 46594 . shcVsOdL/w+sH9xm8cdCgjCgu2feO/b5J7HAg8SdyHa1pzh/VSO+PL6N kLac2uYQZ//3bkPjPa1lRdBUTQvFfYWKRKz385NldCl1CSBMc5rpjyx3 qPgz21JVmV7BWzfehqduOhAQ0tk0+wahbcjEW3IfDydfpR+NXBh+DQg/ GSTZoXlfQ3UubGPdzIX9ihyRVwWe/dM5xc3ooLi/exPcNSm2exdpgHHY VsIWarQapYGFIbdrsNstevhrRp91ClfLm88ZwPEtjVjPoW3T7yffsC/O 7YNRc9q7g59srKAKaUHhjXx01HaXG/3SGKrsnQRgfTP6t8Tmdu/0fFGI erH7AQ==
;; Received 525 bytes from 208.67.222.222#53(208.67.222.222) in 59 ms
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            86400    IN    DS    30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.            86400    IN    RRSIG    DS 8 1 86400 20200919050000 20200906040000 46594 . RQNHtH2zX1hOpuchqw/ZFwRgDQU6oIvSNtUIWq2vnKKKmi0GL1eOJSPX zkEVq2vhSAjpfwqruMzSEL+fa4el1lA9ufC7lfOzONAIsvasPEyMxqDB qA8KxfdJNbBClA6iDiFvqP5zzNlgD2npNDIy4moxfhoM6bHqRYvBNqFC Sthsd3lA2rGcGJ0sbXYUaSSkqTABb+d8MqUifls5UHkGboWIs9hgTySZ oMnygnwolMJjE74xipQTD+FinBiUcfyRhe6BD/bO2JOkC6HyKRqfacBE 1xvGp7GGXJJ4DF8RY+rNuhWZrzx/U4yBThKHTZipaAwnLx1/MAy7wPLo 78bgug==
;; Received 1178 bytes from 198.97.190.53#53(h.root-servers.net) in 63 ms
duckduckgo.com.        172800    IN    NS    dns1.p05.nsone.net.
duckduckgo.com.        172800    IN    NS    dns2.p05.nsone.net.
duckduckgo.com.        172800    IN    NS    dns3.p05.nsone.net.
duckduckgo.com.        172800    IN    NS    dns4.p05.nsone.net.
duckduckgo.com.        172800    IN    NS    ns04.quack-dns.com.
duckduckgo.com.        172800    IN    NS    ns03.quack-dns.com.
duckduckgo.com.        172800    IN    NS    ns02.quack-dns.com.
duckduckgo.com.        172800    IN    NS    ns01.quack-dns.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200910044132 20200903033132 24966 com. K6VW6C0oC+auVPTbHxy4vSc4em0hAvhlzBiLRTqiO+axNGK71dwVKNVP Kzp7ltUjiuPvNtA0FxvwR8OwN57WXO7tR7tQWaWeE7+VhqPQMYuYa6dT 3HMFHa9udTCFyG5qdOZeYCPmfOon6un4IijrJ+yyDV817BGOvRfPsmUj fpENyGNckI0m/gNJ5ZfxECSTtxEJkMOjuHlIm7ETJ+qmow==
BN1FJS0UO0RMBT477B345GNU6A9CFODA.com. 86400 IN NSEC3 1 1 0 - BN1FSPPU7UST4HCP0ADMG9U117OMTH0V NS DS RRSIG
BN1FJS0UO0RMBT477B345GNU6A9CFODA.com. 86400 IN RRSIG NSEC3 8 2 86400 20200911053325 20200904042325 24966 com. Ec2/Sko4MmcDqenrDWRbHPk1NBc2fvkqPUmjTw2YZCgUI/Okj1QBytgt TgHK3zrpMUW6hBwyCdn3ewa6lt3FgOvCSY33/t9SgQDLz5cbqaOk+kYV ZYXtv5H3OdyK22vbO5SPvXMssMHhYbKqU+2M3IM7WN8PuQJ/BdpOQ4qG sbYgG19C3KDoYM0U5oMsvFmBIMzEPJR+BJ/f+1lqYvZ9qQ==
;; Received 947 bytes from 192.48.79.30#53(j.gtld-servers.net) in 199 ms
www.duckduckgo.com.    86400    IN    CNAME    duckduckgo.com.
duckduckgo.com.        200    IN    A    40.81.94.43
;; Received 77 bytes from 148.163.196.65#53(ns02.quack-dns.com) in 187 ms

输出说明：

Dig首先向DNS服务器询问根域的名称服务器。
h.root-servers.net然后，查询根domain（）的名称服务器之一以获取com.名称服务器。
然后com.域名服务器h.root-servers.net中查询的域名服务器duckduckgo.com.和挖掘得到所要求的响应。
最后，ns02.quack-dns.com名称服务器用CNAME和A键入资源记录进行回复。如果您在CNAME此处注意到资源记录，则无需www.在前面添加duckduckgo.com访问网站。

瞧！我希望本文能帮助您了解DNS的基本工作原理。

DNS 服务的运行详解

DNS的目的＃

URL的细分＃

DNS中的层次结构＃

网站域名＃

区域＃

权威名称服务器＃

行动中的DNS解析＃

使用DiG的示例＃

1.简单的挖掘查询＃

2.更多 `CNAME`＃

3.完整的DNS解析＃

DNS软件服务

热门文章

最新文章

相关产品

相关课程

相关电子书

相关实验场景

推荐镜像

DNS 服务的运行详解

DNS的目的＃

URL的细分＃

DNS中的层次结构＃

网站域名＃

区域＃

权威名称服务器＃

行动中的DNS解析＃

使用DiG的示例＃

1.简单的挖掘查询＃

2.更多 CNAME＃

3.完整的DNS解析＃

DNS软件服务

热门文章

最新文章

相关产品

相关课程

相关电子书

相关实验场景

推荐镜像

2.更多 `CNAME`＃