皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

Linux DNS 查询剖析(第二部分)

Linux DNS 查询剖析 – 第一部分 中,我介绍了:

  • nsswitch
  • /etc/hosts
  • /etc/resolv.conf
  • ping 与 host 查询方式对比

并且发现大多数程序选择要查询的 DNS 服务器时会参考 /etc/resolv.conf 配置文件。

这种方式在 Linux 上比较普遍1。虽然我使用了特定的发行版 Ubuntu,但背后的原理与 Debian 甚至是那些基于 CentOS 的发行版有相通的地方;当然,与更低或更高的 Ubuntu 版本相比,差异还是存在的。

也就是说,接下来,你主机上的行为很可能与我描述的不一致。

在第二部分中,我将介绍 resolv.conf 的更新机制、systemctl restart networking 命令的运行机制 ,以及 dhclient 是如何参与其中。

1) 手动更新 /etc/resolv.conf

我们知道 /etc/resolv.conf (有极大的可能性)被用到,故你自然可以通过该文件增加一个 nameserver,那么主机也将会(与已有的 nameserver 一起)使用新加入的 nameserver 吧?

你可以尝试如下:

  1. $ echo nameserver 10.10.10.10 >> /etc/resolv.conf

看上去新的 nameserver 已经加入:

  1. # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  2. #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  3. nameserver 10.0.2.3
  4. search home
  5. nameserver 10.10.10.10

但主机网络服务重启后问题出现了:

  1. $ systemctl restart networking
  2. $ cat /etc/resolv.conf
  3. # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  4. #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  5. nameserver 10.0.2.3
  6. search home

我们的 10.10.10.10nameserver 不见了!

在上一篇文章中我们忽略了这一点,本文进行补充说明。

2) resolvconf

你在 /etc/resolv.conf 文件中看到 generated by resolvconf 词组了吧?这就是我们的线索。

如果深入研究 systemctl restart networking 命令,你会发现它做了很多事情,结束时调用了 /etc/network/if-up.d/000resolvconf 脚本。在该脚本中,可以发现一次对 resolvconf 命令的调用:

  1. /sbin/resolvconf -a "${IFACE}.${ADDRFAM}"

稍微研究一下 man 手册,发现-a 参数允许我们:

  1. Add or overwrite the record IFACE.PROG then run the update scripts
  2. if updating is enabled.

(增加或覆盖 IFACE.PROG 记录,如果开启更新选项,则运行更新脚本)

故而也许我们可以直接调用该命令增加 namserver

  1. echo 'nameserver 10.10.10.10' | /sbin/resolvconf -a enp0s8.inet

测试表明确实可以!

  1. $ cat /etc/resolv.conf  | grep nameserver
  2. nameserver 10.0.2.3
  3. nameserver 10.10.10.10

是否已经找到答案,这就是 /etc/resolv.conf 更新的逻辑?调用 resolvconfnameserver 添加到某个地方的数据库,然后(“如果配置了更新”,先不管具体什么含义)更新 resolv.conf 文件。

并非如此。

  1. systemctl restart networking
  2. root@linuxdns1:/etc# cat /etc/resolv.conf
  3. # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  4. #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  5. nameserver 10.0.2.3
  6. search home

呃!(网络服务重启后)新增的 nameserver 再次消失了。

可见,systemctl restart networking 不仅仅运行了 resolvconf,还在其它地方获取 nameserver 信息。具体是哪里呢?

3) ifup/ifdown

继续深入研究 systemctl restart networking,发现它完成了一系列工作:

  1. cat /lib/systemd/system/networking.service
  2. [...]
  3. [Service]
  4. Type=oneshot
  5. EnvironmentFile=-/etc/default/networking
  6. ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle'
  7. ExecStart=/sbin/ifup -a --read-environment
  8. ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
  9. [...]

首先,网络服务的重启实质是运行一个单触发oneshot的脚本,脚本包含如下命令:

  1. /sbin/ifdown -a --read-environment --exclude=lo
  2. /bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle'
  3. /sbin/ifup -a --read-environment

第一行使用 ifdown 关闭全部的网络接口,但本地回环local, lo接口除外。2

(LCTT 译注:其实这是因为很快就又启动了接口,间隔的时间没有超过 TCP 连接的超时时间,有人在评论中也做了类似回复)

第二行用于确认系统已经完成关闭网络接口相关的全部工作,以便下一步使用 ifup 启动接口。这也让我们了解到,网络服务实质运行的就是 ifdownifup

文档中没有找到 --read-environment 参数的说明,该参数为 systemctl 正常工作所需。很多人以文档不完善为由不喜欢 systemctl

很好。那么 ifup (和其成对出现的 ifdown) 到底做了哪些工作呢?长话短说,它运行了 /etc/network/if-pre-up.d//etc/network/if-up.d/ 目录下的全部脚本;期间,这些脚本也可能会调用另外的脚本,依此类推。

其中一件工作就是运行了 dhclient,但我还不完全确定具体的机理,也许 udev 参与其中。

4) dhclient

dhclient 是一个程序,用于与 DHCP 服务器协商对应网络接口应该使用的 IP 地址的详细信息。同时,它也可以获取可用的 DNS 服务器并将其替换到 /etc/resolv.conf 中。

让我们开始跟踪并模拟它的行为,但仅在我实验虚拟机的 enp0s3 接口上。事先已经删除 /etc/resolv.conf 文件中的 nameserver 配置:

  1. $ sed -i '/nameserver.*/d' /run/resolvconf/resolv.conf
  2. $ cat /etc/resolv.conf | grep nameserver
  3. $ dhclient -r enp0s3 && dhclient -v enp0s3
  4. Killed old client process
  5. Internet Systems Consortium DHCP Client 4.3.3
  6. Copyright 2004-2015 Internet Systems Consortium.
  7. All rights reserved.
  8. For info, please visit https://www.isc.org/software/dhcp/
  9. Listening on LPF/enp0s8/08:00:27:1c:85:19
  10. Sending on   LPF/enp0s8/08:00:27:1c:85:19
  11. Sending on   Socket/fallback
  12. DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 3 (xid=0xf2f2513e)
  13. DHCPREQUEST of 172.28.128.3 on enp0s8 to 255.255.255.255 port 67 (xid=0x3e51f2f2)
  14. DHCPOFFER of 172.28.128.3 from 172.28.128.2
  15. DHCPACK of 172.28.128.3 from 172.28.128.2
  16. bound to 172.28.128.3 -- renewal in 519 seconds.
  17. $ cat /etc/resolv.conf | grep nameserver
  18. nameserver 10.0.2.3

可见这就是 nameserver 的来源。

但稍等一下,命令中的 /run/resolvconf/resolv.conf 是哪个文件,不应该是 /etc/resolv.conf 吗?

事实上,/etc/resolv.conf 并不一定只是一个普通文本文件。

在我的虚拟机上,它是一个软链接,指向位于 /run/resolvconf 目录下的“真实文件”。这也暗示了我们,该文件是在系统启动时生成的;同时,这也是该文件注释告诉我们不要直接修改该文件的原因。

(LCTT 译注:在 CentOS 7 中,没有 resolvconf 命令,/etc/resolv.conf 也不是软链接)

假如上面命令中 sed 命令直接处理 /etc/resolv.conf 文件,效果是不同的,会有警告消息告知待操作的文件不能是软链接(sed -i 无法很好的处理软链接,它只会创建一个新文件)。

(LCTT 译注:CentOS 7 测试时,sed -i 命令操作软链接并没有警告,但确实创建了新文件取代软链接)

如果你继续深入查看配置文件 /etc/dhcp/dhclient.confsupersede 部分,你会发现 dhclient 可以覆盖 DHCP 提供的 DNS 服务器。

Linux DNS 查询剖析(第二部分)

(大致)准确的关系图


第二部分的结束语

第二部分到此结束。信不信由你,这是一个某种程度上简化的流程版本,但我尽量保留重要和值得了解的部分,让你不会感到无趣。大部分内容都是围绕实际脚本的运行展开的。

但我们的工作还没有结束,在第三部分,我们会介绍这些之上的更多层次。

让我们简要列出我们已经介绍过的内容:

  • nsswitch
  • /etc/hosts
  • /etc/resolv.conf
  • /run/resolvconf/resolv.conf
  • systemd 和网络服务
  • ifup 和 ifdown
  • dhclient
  • resolvconf

  1. 事实上,这是相对于 POSIX 标准的,故不限于 Linux (我从上一篇文章的一条极好的回复中了解到这一点) 
  2. 我不明白为何这没有导致我例子中的 vagrant 会话中断 (有谁明白吗?)。 

via: https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-lookup-part-ii/

作者:ZWISCHENZUGS
译者:pinewall
校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

编译自:https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-lookup-part-ii/ 作者: Zwischenzugs
原创:LCTT https://linux.cn/article-9949-1.html 译者: Andy Song