共计 9793 个字符，预计需要花费 25 分钟才能阅读完成。
互联网是一个很大的中央。大量的协定和物理根底构造曾经到位，使咱们可能轻松应用它。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. 必须在某个工夫点已购买。
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 解析中查问和响应的流程。
- 客户端
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 的根本工作原理。
