关于dns:DNS-服务的运行详解

135次阅读

共计 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 解析中查问和响应的流程。

  1. 客户端 A 为域 en.wikipedia.org 寻找具备 IP 地址的 Type 资源记录，该客户端创立 DNS 查问并将其发送到配置的 DNS 服务器。
  2. 要查找 en.wikipedia.orgDNS 服务器的 IP 地址，必须首先找到该域的名称服务器。为了找到该名称服务器，DNS 服务器从其域名服务器首先与 DNS 服务器一起存储的根域开始，开始从右向左一次解析一个标签的域名。接下来的一行将是org. 它查问根域的权威名称服务器之一，以询问的名称服务器。org.请留神，它首先搜寻名称服务器，因为它们领有该域的所有信息。
  3. 查问的名称服务器将后果返回到 DNS 服务器。
  4. DNS 服务器接下来向域名服务器之一查问 org. 域，以申请以下域名服务器的域名服务器：wikipedia.org
  5. 查问的名称服务器将适合的后果返回到 DNS 服务器。
  6. 最初，DNS 服务器查问 wikipedia.org 名称服务器，询问以下内容的类型 A 记录：en.wikipedia.org
  7. 查问的名称服务器以类型 A 资源记录来响应 DNS 服务器。
  8. 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
2021-04-08
 0
关于dns:深入理解DNS解析过程
关于dns:使用DNSLOG配置mysql的securefilepriv参数
关于http:数据在网络中如何传输图解-HTTP-协议
关于dns:理解-DNS-缓存