什么是 DNS 服务器、解析器和存根解析器?

Tim*_*Tim 10 dns terminology systemd-resolved

https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Description

此外,systemd-resolved 在本地环回接口上的 IP 地址 127.0.0.53 上提供本地 DNS 存根侦听器。直接发出 DNS 请求、绕过任何本地 API 的程序可能会被定向到这个存根,以便将它们连接到 systemd-resolved。

我该如何理解`/etc/resolv.conf` 的格式?

DNS 服务器和解析器(“存根解析器”)可以不同,您可以将 DNS 请求传递给 127.0.0.53,后者将它们传递给您的路由器以获得实际的 DNS(例如,它可以处理本地主机但传递对远程主机的请求以获得完整的 DNS) )。

什么是 DNS 服务器、解析器和存根解析器?

我也听说过两种 DNS 服务器(一种叫做“解析器”,另一种我忘记了)。这两种是什么意思?

Jde*_*eBP 12

人们经常弄错的令人困惑的名字。

RFC 1034的术语中,有“解析器”和“名称服务器”。“解析器”描述用户程序用来访问“名称服务器”的整个子系统,而不考虑任何特定的体系结构。这是一个子系统,它以RFC 1034 § 5.3.3 中描述的方式向一个或多个“名称服务器”查询它们发布的数据,并将这些数据拼凑成查询应用程序的最终答案。“解析器”是执行查询解析整体子系统。

RFC 理论上允许,因为它不打算以 Unix 为中心,所有查询解析机制都可能以某种形式的共享子系统形式运行,这些子系统在每个单独的应用程序中运行。

在 RFC 1034 术语中,“存根解析器”是 Unix 和 Linux 世界中通常使用的:一个在应用程序进程中运行的相当笨拙的 DNS 客户端库,将相同的 DNS/UDP 和 DNS/TCP 协议与运行的外部程序对话作为另一个过程,它实际上通过进行后端事务并从它们构建前端响应来完成查询解析的繁重工作。

“解析器”是一个如此令人困惑的术语,经常与 RFC 背道而驰,几年前我开始使用从 HTTP 借来的术语向人们解释 DNS:代理服务器内容服务器和链接到应用程序的客户端库

  • 您应用程序中的DNS 客户端库几乎总是来自 ISC 的 BIND DNS 客户端库。Unix 和 Linux 系统上的大多数 C 库都包含 BIND DNS 客户端库。但是,存在其他几个 DNS 客户端库,并且少数应用程序使用它们。

    DNS 客户端库以进一步阅读中描述的方式进行名称限定并找出要与之通信的 DNS 代理服务器。

  • 在此特定设置中,初始DNS 代理服务器systemd-resolved侦听 127.0.0.53。

    执行此角色的其他 Unix 和 Linux 软件包括 Daniel J. Bernstein 的dnscacheunbounddnsmasq、PowerDNS Recursor、MaraDNS Recursor(“Deadwood”)等等。

    我个人在每台侦听 127.0.0.1 的机器上都有一个已修改dnscache的本地实例(可以继承其侦听套接字),这也是 BIND DNS 客户端库期望代理 DNS 服务器所在的默认位置,在没有明确的情况下配置。

  • systemd-resolved与其他代理 DNS 服务器交谈,这些服务器很可能与更进一步的代理服务器交谈,沿着链转发查询,直到查询到达解析代理服务器。
  • 默认情况下,作为 systemd 人员运送东西,除非构建二进制包的人或本地系统管理员对其进行更改,否则解析代理 DNS 服务器将是由谷歌运行的服务器,作为谷歌公共 DNS 的一部分,并且会有一个长度为 1的转发代理 DNS 服务器链。
  • 如果系统管理员配置systemd-resolved为使用其他代理 DNS 服务器而不是 Google 的,则链条会更长。此类配置的示例包括(按从最佳到最坏的粗略顺序)在 LAN 上使用本地解析代理 DNS 服务器、使用在 LAN 边缘的路由器/网关中运行的代理 DNS 服务器,或使用互联网上的第三方代理 DNS 服务器。
  • 链远端的解析代理 DNS 服务器完成查询解析的繁重工作,根据需要查询世界各地的内容 DNS 服务器,将数据拼接在一起形成最终答案,然后沿着链返回。将 DNS 服务器(包括systemd-resolved在该链的近端)代理到应用程序中的 DNS 客户端库。

相比之下,在 RFC 1034 术语中,这里的“解析器”实际上是一个巨大的黑匣子,包含 BIND DNS 客户端库systemd-resolved和 Google 公共 DNS,因为 RFC 将其定义为一侧具有“用户程序”,并且内容 DNS 服务器(“直接”提供参考和数据库信息)。人们经常会误用这个术语,有时是因为他们将 RFC 1034 架构中立的“解析器”概念误解为与单个 Unix 或 Linux 服务器程序相同,但事实并非如此。HTTP 术语没有巨大的黑匣子。

进一步阅读

  • 另外,关于命名,IETF DNSOP 工作组现已制作了此 RFC,其中提供了在处理 DNS 内容时可以使用的词汇:https://tools.ietf.org/html/rfc8499。特别参见第 6 节:“存根解析器”、“递归名称服务器”、“权威服务器”和“转发器”。 (3认同)

小智 5

只要涉及到 systemd-resolved,“stub-resolver”就不会自行完成所有 DNS 解析(即它不连接到根 DNS 服务器 -> tld/gtld 名称服务器 -> 权威名称服务器)。相反,它连接到其他解析器(通常通过网络接口配置进行配置。例如 8.8.8.8 或 1.1.1.1 或由 ISP 提供)进行名称解析。

其目的是,每个程序/客户端不必直接查询解析器,而是可以查询存根解析器,该存根解析器可以缓存结果以加快整体名称解析过程。还有一些额外的好处。

它之所以被称为存根,是因为它有点像解析器,但从技术上讲它不是解析器,因为它缺乏它的所有功能。