互联网是一个很大的地方。大量的协议和物理基础结构已经到位，使我们能够轻松使用它。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”。'是一样的。末尾的点在表示中可以省略，但内部所有分辨率都在末尾点就位的情况下发生。
DNS中的层次结构＃
网站域名＃
域名是互联网中的一个领域，拥有域名的实体对其拥有管理权-在DNS中为相应域名创建或更新资源记录。层次结构可以在域名中看到，并且可以可视化为树。wikipedia.org.是域名的示例。这等级制度域的数量从FQDN中的右标签到左标签降序。左侧的每个标签都指定了右侧域的一个子域。层次结构中的第一个域是根域（由点表示）。
com，org，in，io是根域下的一些子域。根域下的第一级域称为顶级域（TLD），并且独立于根域进行操作。TLD的子域可供互联网用户购买。例如wikipedia，TLD的子域org.必须在某个时间点已购买。
![4_0ZOKA[2JV2`F8X]]{X)P4.png](https://ucc.alicdn.com/pic/developer-ecology/a762da3c76b14cd38530f2b175421226.png "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。
一个域可能在其区域下仅包含几个子域，并为其他子域委派权限。
权威名称服务器＃
每个域都有至少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](https://ucc.alicdn.com/pic/developer-ecology/0a75677be5274ace9684eecdd2aa104f.png "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的基本工作原理。
