标签 DNS 下的文章

学习如何安装和配置 Designate,这是一个 OpenStack 的多租户 DNS 即服务(DNSaaS)。

Designate 是一个多租户的 DNS 即服务,它包括一个用于域名和记录管理的 REST API 和集成了 Neutron 的框架,并支持 Bind9。

DNSaaS 可以提供:

  • 一个管理区域和记录的干净利落的 REST API
  • 自动生成记录(集成 OpenStack)
  • 支持多个授权名字服务器
  • 可以托管多个项目/组织

 title=

这篇文章解释了如何在 CentOS 和 RHEL 上手动安装和配置 Designate 的最新版本,但是同样的配置也可以用在其它发行版上。

在 OpenStack 上安装 Designate

在我的 GitHub 仓库里,我已经放了 Ansible 的 bind 和 Designate 角色的示范设置。

这个设置假定 bing 服务是安装 OpenStack 控制器节点之外(即使你可以在本地安装 bind)。

1、在 OpenStack 控制节点上安装 Designate 和 bind 软件包:

# yum install openstack-designate-* bind bind-utils -y

2、创建 Designate 数据库和用户:

MariaDB [(none)]> CREATE DATABASE designate CHARACTER SET utf8 COLLATE utf8_general_ci;
       
MariaDB [(none)]> GRANT ALL PRIVILEGES ON designate.* TO \
'designate'@'localhost' IDENTIFIED BY 'rhlab123';

MariaDB [(none)]> GRANT ALL PRIVILEGES ON designate.* TO 'designate'@'%' \
IDENTIFIED BY 'rhlab123';

注意:bind 包必须安装在控制节点之外才能使 远程名字服务控制 Remote Name Daemon Control (RNDC)功能正常。

配置 bind(DNS 服务器)

1、生成 RNDC 文件:

rndc-confgen -a -k designate -c /etc/rndc.key -r /dev/urandom

cat <<EOF> etcrndc.conf
include "/etc/rndc.key";
options {
  default-key "designate";
  default-server {{ DNS_SERVER_IP }};
  default-port 953;
};
EOF

2、将下列配置添加到 named.conf

include "/etc/rndc.key"; 
controls {
  inet {{ DNS_SERVER_IP }} allow { localhost;{{ CONTROLLER_SERVER_IP }}; } keys { "designate"; };
};

option 节中,添加:

options {
  ...
  allow-new-zones yes;
  request-ixfr no;
  listen-on port 53 { any; };
  recursion no;
  allow-query { 127.0.0.1; {{ CONTROLLER_SERVER_IP }}; };
};

添加正确的权限:

chown named:named /etc/rndc.key
chown named:named /etc/rndc.conf
chmod 600 /etc/rndc.key
chown -v root:named /etc/named.conf
chmod g+w /var/named

# systemctl restart named
# setsebool named_write_master_zones 1

3、把 rndc.keyrndc.conf 推入 OpenStack 控制节点:

# scp -r /etc/rndc* {{ CONTROLLER_SERVER_IP }}:/etc/

创建 OpenStack Designate 服务和端点

输入:

# openstack user create --domain default --password-prompt designate
# openstack role add --project services --user designate admin
# openstack service create --name designate --description "DNS" dns

# openstack endpoint create --region RegionOne dns public http://{{ CONTROLLER_SERVER_IP }}:9001/
# openstack endpoint create --region RegionOne dns internal http://{{ CONTROLLER_SERVER_IP }}:9001/  
# openstack endpoint create --region RegionOne dns admin http://{{ CONTROLLER_SERVER_IP }}:9001/

配置 Designate 服务

1、编辑 /etc/designate/designate.conf

[service:api] 节配置 auth_strategy

[service:api]
listen = 0.0.0.0:9001
auth_strategy = keystone
api_base_uri = http://{{ CONTROLLER_SERVER_IP }}:9001/
enable_api_v2 = True
enabled_extensions_v2 = quotas, reports

[keystone_authtoken] 节配置下列选项:

[keystone_authtoken]
auth_type = password
username = designate
password = rhlab123
project_name = service
project_domain_name = Default
user_domain_name = Default
www_authenticate_uri = http://{{ CONTROLLER_SERVER_IP }}:5000/
auth_url = http://{{ CONTROLLER_SERVER_IP }}:5000/ 

[service:worker] 节,启用 worker 模型:

enabled = True
notify = True

[storage:sqlalchemy] 节,配置数据库访问:

[storage:sqlalchemy]
connection = mysql+pymysql://designate:rhlab123@{{ CONTROLLER_SERVER_IP }}/designate

填充 Designate 数据库:

# su -s /bin/sh -c "designate-manage database sync" designate

2、 创建 Designate 的 pools.yaml 文件(包含 target 和 bind 细节):

编辑 /etc/designate/pools.yaml

- name: default
  # The name is immutable. There will be no option to change the name after
  # creation and the only way will to change it will be to delete it
  # (and all zones associated with it) and recreate it.
  description: Default Pool

  attributes: {}

  # List out the NS records for zones hosted within this pool
  # This should be a record that is created outside of designate, that
  # points to the public IP of the controller node.
  ns_records:
    - hostname: {{Controller_FQDN}}. # Thisis mDNS
      priority: 1

  # List out the nameservers for this pool. These are the actual BIND servers.
  # We use these to verify changes have propagated to all nameservers.
  nameservers:
    - host: {{ DNS_SERVER_IP }}
      port: 53

  # List out the targets for this pool. For BIND there will be one
  # entry for each BIND server, as we have to run rndc command on each server
  targets:
    - type: bind9
      description: BIND9 Server 1

      # List out the designate-mdns servers from which BIND servers should
      # request zone transfers (AXFRs) from.
      # This should be the IP of the controller node.
      # If you have multiple controllers you can add multiple masters
      # by running designate-mdns on them, and adding them here.
      masters:
        - host: {{ CONTROLLER_SERVER_IP }}
          port: 5354

      # BIND Configuration options
      options:
        host: {{ DNS_SERVER_IP }}
        port: 53
        rndc_host: {{ DNS_SERVER_IP }}
        rndc_port: 953
        rndc_key_file: /etc/rndc.key
        rndc_config_file: /etc/rndc.conf

填充 Designate 池:

su -s /bin/sh -c "designate-manage pool update" designate

3、启动 Designate 中心和 API 服务:

systemctl enable --now designate-central designate-api

4、验证 Designate 服务运行:

# openstack dns service list

+--------------+--------+-------+--------------+
| service_name | status | stats | capabilities |
+--------------+--------+-------+--------------+
| central      | UP     | -     | -            |
| api          | UP     | -     | -            |
| mdns         | UP     | -     | -            |
| worker       | UP     | -     | -            |
| producer     | UP     | -     | -            |
+--------------+--------+-------+--------------+

用外部 DNS 配置 OpenStack Neutron

1、为 Designate 服务配置 iptables:

# iptables -I INPUT -p tcp -m multiport --dports 9001 -m comment --comment "designate incoming" -j ACCEPT
       
# iptables -I INPUT -p tcp -m multiport --dports 5354 -m comment --comment "Designate mdns incoming" -j ACCEPT
       
# iptables -I INPUT -p tcp -m multiport --dports 53 -m comment --comment "bind incoming" -j ACCEPT
        
# iptables -I INPUT -p udp -m multiport --dports 53 -m comment --comment "bind/powerdns incoming" -j ACCEPT
       
# iptables -I INPUT -p tcp -m multiport --dports 953 -m comment --comment "rndc incoming - bind only" -j ACCEPT
       
# service iptables save; service iptables restart
# setsebool named_write_master_zones 1

2、 编辑 /etc/neutron/neutron.conf[default] 节:

external_dns_driver = designate

3、 在 /etc/neutron/neutron.conf 中添加 [designate] 节:

[designate]
url = http://{{ CONTROLLER_SERVER_IP }}:9001/v2 ## This end point of designate
auth_type = password
auth_url = http://{{ CONTROLLER_SERVER_IP }}:5000
username = designate
password = rhlab123
project_name = services
project_domain_name = Default
user_domain_name = Default
allow_reverse_dns_lookup = True
ipv4_ptr_zone_prefix_size = 24
ipv6_ptr_zone_prefix_size = 116 

4、编辑 neutron.confdns_domain

dns_domain = rhlab.dev.

重启:

# systemctl restart neutron-*

5、在 /etc/neutron/plugins/ml2/ml2_conf.ini 中的组成层 2(ML2)中添加 dns

extension_drivers=port_security,qos,dns

6、在 Designate 中添加区域:

# openstack zone create –[email protected] rhlab.dev.

rhlab.dev 区域中添加记录:

# openstack recordset create --record '192.168.1.230' --type A rhlab.dev. Test

Designate 现在就安装和配置好了。


via: https://opensource.com/article/19/4/getting-started-openstack-designate

作者:Amjad Yaseen 选题:lujun9972 译者:wxy 校对:wxy

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

如果你输入 dig 命令对 google.com 进行 DNS 查询,你会得到如下答复:

$ dig google.com

; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27120
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     194 IN  A   216.58.192.206

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep 21 16:14:48 CDT 2018
;; MSG SIZE rcvd: 55

这个输出一部分描述了你的问题(google.com 的 IP 地址是什么?),另一部分则详细描述了你收到的回答。在 答案区段 ANSWER SECTION 里,dig 为我们找到了一个包含五个字段的记录。从左数第四个字段 A 定义了这个记录的类型 —— 这是一个地址记录。在 A 的右边,第五个字段告知我们 google.com 的 IP 地址是 216.58.192.206。第二个字段,194 则代表这个记录的缓存时间是 194 秒。

那么,IN 字段告诉了我们什么呢?令人尴尬的是,在很长的一段时间里,我都认为这是一个介词。那时候我认为 DNS 记录大概是表达了“在 A 记录里,google.com 的 IP 地址是 216.58.192.206。”后来我才知道 IN 是 “internet” 的简写。IN 这一个部分告诉了我们这个记录分属的 类别 class

那么,除了 “internet” 之外,DNS 记录还会有什么别的类别吗?这究竟意味着什么?你怎么去搜寻一个不位于 internet 上的地址?看起来 IN 是唯一一个可能有意义的值。而且的确,如果你尝试去获得除了 IN 之外的,关于 google.com 的记录的话,DNS 服务器通常不能给出恰当的回应。以下就是我们尝试向 8.8.8.8(谷歌公共 DNS 服务器)询问在 HS 类别里 google.com 的 IP 地址。我们得到了状态为 SERVFAIL 的回复。

$ dig -c HS google.com

; <<>> DiG 9.10.6 <<>> -c HS google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31517
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.            HS  A

;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Sep 25 14:48:10 CDT 2018
;; MSG SIZE rcvd: 39

所以说,除了 IN 以外的类别没有得到广泛支持,但它们的确是存在的。除了 IN 之外,DNS 记录还有 HS(我们刚刚看到的)和 CH 这两个类别。HS 类是为一个叫做 Hesiod) 的系统预留的,它可以利用 DNS 来存储并让用户访问一些文本资料。它通常在本地环境中作为 LDAP 的替代品使用。而 CH 这个类别,则是为 Chaosnet 预留的。

如今,大家都在使用 TCP/IP 协议族。这两种协议(TCP 及 UDP)是绝大部分电脑远程连接采用的协议。不过我觉得,从互联网的垃圾堆里翻出了一个布满灰尘,绝迹已久,被人们遗忘的系统,也是一件令人愉悦的事情。那么,Chaosnet 是什么?为什么它像恐龙一样,走上了毁灭的道路呢?

在 MIT 的机房里

Chaosnet 是在 1970 年代,由 MIT 人工智能实验室的研究员们研发的。它是一个宏伟目标的一部分 —— 设计并制造一个能比其他通用电脑更高效率运行 Lisp 代码的机器。

Lisp 是 MIT 教授 John McCarthy 的造物,他亦是人工智能领域的先驱者。在 1960 年发布的一篇论文中,他首次描述了 Lisp 这个语言。在 1962 年,Lisp 的编译器和解释器诞生了。Lisp 引入了非常多的新特性,这些特性在现在看来是每一门编程语言不可或缺的一部分。它是第一门拥有垃圾回收器的语言,是第一个有 REPL(Read-eval-print-loop:交互式解析器)的语言,也是第一个支持动态类型的语言。在人工智能领域工作的程序员们都十分喜爱这门语言,比如说,大名鼎鼎的 SHRDLU 就是用它写的。这个程序允许人们使用自然语言,向机器下达挪动玩具方块这样的命令。

Lisp 的缺点是它太慢了。跟其它语言相比,Lisp 需要使用两倍的时间来执行相同的操作。因为 Lisp 在运行中仍会检查变量类型,而不仅是编译过程中。在 MIT 的 IBM 7090 上,它的垃圾回收器也需要长达一秒钟的时间来执行。 1 这个性能问题急需解决,因为 AI 研究者们试图搭建类似 SHRDLU 的应用。他们需要程序与使用者进行实时互动。因此,在 1970 年代的晚期,MIT 人工智能实验室的研究员们决定去建造一个能更高效运行 Lisp 的机器来解决这个问题。这些“Lisp 机器”们拥有更大的存储和更精简的指令集,更加适合 Lisp。类型检查由专门的电路完成,因此在 Lisp 运行速度的提升上达成了质的飞跃。跟那时流行的计算机系统不同,这些机器并不支持分时,整台电脑的资源都用来运行一个单独的 Lisp 程序。每一个用户都会得到他自己单独的 CPU。MIT 的 Lisp 机器小组 Lisp Machine Group 在一个备忘录里提到,这些功能是如何让 Lisp 运行变得更简单的:

Lisp 机器是个人电脑。这意味着处理器和主内存并不是分时复用的,每个人都能得到单独属于自己的处理器和内存。这个个人运算系统由许多处理器组成,每个处理器都有它们自己的内存和虚拟内存。当一个用户登录时,他就会被分配一个处理器,在他的登录期间这个处理器是独属于他的。当他登出,这个处理器就会重新可用,等待被分配给下一个用户。通过采取这种方法,当前用户就不用和其他用户竞争内存的使用,他经常使用的内存页也能保存在处理器核心里,因此页面换出的情况被显著降低了。这个 Lisp 机器解决了分时 Lisp 机器的一个基本问题。 2

这个 Lisp 机器跟我们认知的现代个人电脑有很大的不同。该小组原本希望今后用户不用直接面对 Lisp 机器,而是面对终端。那些终端会与位于别处的 Lisp 机器进行连接。虽然每个用户都有自己专属的处理器,但那些处理器在工作时会发出很大的噪音,因此它们最好是位于机房,而不是放在本应安静的办公室里。 3 这些处理器会通过一个“完全分布式控制”的高速本地网络共享访问一个文件系统和设备,例如打印机。 4 这个网络的名字就是 Chaosnet。

Chaosnet 既是硬件标准也是软件协议。它的硬件标准与以太网类似,事实上 Chaosnet 软件协议是运行在以太网之上的。这个软件协议在网络层和传输层之间交互,它并不像 TCP/IP,而总是控制着本地网络。Lisp 机器小组的一个成员 David Moon 写的另一个备忘录中提到,Chaosnet “目前并不打算为低速链接、高信噪链接、多路径、长距离链接做特别的优化。” 5 他们专注于打造一个在小型网络里表现极佳的协议。

因为 Chaosnet 连接在 Lisp 处理器和文件系统之间,所以速度十分重要。网络延迟会严重拖慢一些像打开文本文档这种简单操作的速度,为了提高速度,Chaosnet 结合了在 Network Control Program网络控制程序中使用的一些改进方法,随后的 Arpanet 项目中也使用了这些方法。据 Moon 所说,“为了突破诸如在 Arpanet 中发现的速率瓶颈,很有必要采纳新的设计。目前来看,瓶颈在于由多个链接分享控制链接,而且在下一个信息发送之前,我们需要知道本次信息已经送达。” 6 Chaosnet 协议族的批量 ACK 包跟当今 TCP 的差不多,它减少了 1/3 到一半的需要传输的包的数量。

因为绝大多数 Lisp 机器使用较短的单线进行连接,所以 Chaosnet 可以使用较为简单的路由算法。Moon 在 Chaosnet 路由方案中写道“预计要适配的网络架构十分简单,很少有多个路径,而且每个节点之间的距离很短。所以我认为没有必要进行复杂的方案设计。” 7 因为 Chaosnet 采用的算法十分简单,所以实现它也很容易。与之对比明显,其实现程序据说只有 Arpanet 网络控制程序的一半。 8

Chaosnet 的另一个特性是,它的地址只有 16 位,是 IPv4 地址的一半。所以这也意味着 Chaosnet 只能在局域网里工作。Chaosnet 也不会去使用端口号;当一个进程试图连接另一个机器上的另外一个进程时,需要首先初始化连接,获取一个特定的目标“ 联系名称 contact name ”。这个联系名称一般是某个特定服务的名字。比方说,一个主机试图使用 TELNET 作为联系名称,连接另一个主机。我认为它的工作方式在实践中有点类似于 TCP,因为有些非常著名的服务也会拥有联系名称,比如运行在 80 端口上的 HTTP 服务。

在 1986 年,RFC 973 通过了将 Chaosnet DNS 类别加入域名解析系统的决议。它替代了一个早先出现的类别 CSNETCSNET 是为了支持一个名叫 计算机科学网络 Computer Science Network 而被制造出来的协议。我并不知道为什么 Chaosnet 能被域名解析系统另眼相待。很多别的协议族也有资格加入 DNS,但是却被忽略了。比如 DNS 的主要架构师之一 Paul Mockapetris 提到说在他原本的构想里, 施乐 Xerox 的网络协议应该被包括在 DNS 里。 9 但是它并没有被加入。Chaosnet 被加入的原因大概是因为 Arpanet 项目和互联网的早期工作,有很多都在麻省剑桥的博尔特·贝拉尼克—纽曼公司,他们的雇员和 MIT 大多有紧密的联系。在这一小撮致力于发展计算机网络人中,Chaosnet 这个协议应该较为有名。

Chaosnet 随着 Lisp 机器的衰落渐渐变得不那么流行。尽管在一小段时间内 Lisp 机器有实际的商业产品 —— Symbolics 和 Lisp Machines Inc 在 80 年代售卖了这些机器。但它们很快被更便宜的微型计算机替代。这些计算机没有特殊制造的回路,但也可以快速运行 Lisp。Chaosnet 被制造出来的目的之一是解决一些 Apernet 协议的原始设计缺陷,但现在 TCP/IP 协议族同样能够解决这些问题了。

壳中幽灵

非常不幸的是,在互联网中留存的关于 Chaosnet 的资料不多。RFC 675 —— TCP/IP 的初稿于 1974 年发布,而 Chasnet 于 1975 年开始开发。 10 但 TCP/IP 最终征服了整个互联网世界,Chaosnet 则被宣布技术性死亡。尽管 Chaosnet 有可能影响了接下来 TCP/IP 的发展,可我并没有找到能够支持这个猜测的证据。

唯一一个可见的 Chaosnet 残留就是 DNS 的 CH 类。这个事实让我着迷。CH 类别是那被遗忘的幽魂 —— 在 TCP/IP 广泛部署中存在的一个替代协议 Chaosnet 的最后栖身之地。至少对于我来说,这件事情是十分让人激动。它告诉我关于 Chaosnet 的最后一丝痕迹,仍然藏在我们日常使用的网络基础架构之中。DNS 的 CH 类别是有趣的数码考古学遗迹。但它同时也是活生生的标识,提醒着我们互联网并非天生完整成型的,TCP/IP 不是唯一一个能够让计算机们交流的协议。“万维网”也远远不是我们这全球交流系统所能有的,最酷的名字。


  1. LISP 1.5 Programmer’s Manual, The Computation Center and Research Laboratory of Electronics, 90, accessed September 30, 2018, http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf
  2. Lisp Machine Progress Report (Artificial Intelligence Memo 444), MIT Artificial Intelligence Laboratory, August, 1977, 3, accessed September 30, 2018, https://dspace.mit.edu/bitstream/handle/1721.1/5751/AIM-444.pdf.
  3. Lisp Machine Progress Report (Artificial Intelligence Memo 444), 4.
  4. 同上
  5. Chaosnet (Artificial Intelligence Memo 628), MIT Artificial Intelligence Laboratory, June, 1981, 1, accessed September 30, 2018, https://dspace.mit.edu/bitstream/handle/1721.1/6353/AIM-628.pdf.
  6. 同上
  7. Chaosnet (Artificial Intelligence Memo 628), 16.
  8. Chaosnet (Artificial Intelligence Memo 628), 9.
  9. Paul Mockapetris and Kevin Dunlap, “The Design of the Domain Name System,” Computer Communication Review 18, no. 4 (August 1988): 3, accessed September 30, 2018, http://www.cs.cornell.edu/people/egs/615/mockapetris.pdf.
  10. Chaosnet (Artificial Intelligence Memo 628), 1.

via: https://twobithistory.org/2018/09/30/chaosnet.html

作者:Two-Bit History 选题:lujun9972 译者:acyanbird 校对:wxy

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

关于 DNS 和根证书你需要了解的内容。

由于最近发生的一些事件,我们(Privacy Today 组织)感到有必要写一篇关于此事的短文。它适用于所有读者,因此它将保持简单 —— 技术细节可能会在稍后的文章发布。

什么是 DNS,为什么它与你有关?

DNS 的意思是 域名系统 Domain Name System ,你每天都会接触到它。每当你的 Web 浏览器或任何其他应用程序连接到互联网时,它就很可能会使用域名。简单来说,域名就是你键入的地址:例如 duckduckgo.com。你的计算机需要知道它所导向的地方,会向 DNS 解析器寻求帮助。而它将返回类似 176.34.155.23 这样的 IP —— 这就是连接时所需要知道的公开网络地址。 此过程称为 DNS 查找。

这对你的隐私、安全以及你的自由都有一定的影响:

隐私

由于你要求解析器获取域名的 IP,因此它会确切地知道你正在访问哪些站点,并且由于“物联网”(通常缩写为 IoT),甚至它还知道你在家中使用的是哪个设备。

安全

你可以相信解析器返回的 IP 是正确的。有一些检查措施可以确保如此,在正常情况下这一般不是问题。但这些可能措施会被破坏,这就是写作本文的原因。如果返回的 IP 不正确,你可能会被欺骗引向了恶意的第三方 —— 甚至你都不会注意到任何差异。在这种情况下,你的隐私会受到更大的危害,因为不仅会被跟踪你访问了什么网站,甚至你访问的内容也会被跟踪。第三方可以准确地看到你正在查看的内容,收集你输入的个人信息(例如密码)等等。你的整个身份可以轻松接管。

自由

审查通常是通过 DNS 实施的。这不是最有效的方法,但它非常普遍。即使在西方国家,它也经常被公司和政府使用。他们使用与潜在攻击者相同的方法;当你查询 IP 地址时,他们不会返回正确的 IP。他们可以表现得就好像某个域名不存在,或完全将访问指向别处。

DNS 查询的方式

由你的 ISP 提供的第三方 DNS 解析器

大多数人都在使用由其互联网接入提供商(ISP)提供的第三方解析器。当你连接调制解调器时(LCTT 译注:或宽带路由器),这些 DNS 解析器就会被自动取出,而你可能从来没注意过它。

你自己选择的第三方 DNS 解析器

如果你已经知道 DNS 意味着什么,那么你可能会决定使用你选择的另一个 DNS 解析器。这可能会改善这种情况,因为它使你的 ISP 更难以跟踪你,并且你可以避免某些形式的审查。尽管追踪和审查仍然是可能的,但这种方法并没有被广泛使用。

你自己(本地)的 DNS 解析器

你可以自己动手,避免使用别人的 DNS 解析器的一些危险。如果你对此感兴趣,请告诉我们。

根证书

什么是根证书?

每当你访问以 https 开头的网站时,你都会使用它发送的证书与之通信。它使你的浏览器能够加密通信并确保没有人可以窥探。这就是为什么每个人都被告知在登录网站时要注意 https(而不是 http)。证书本身仅用于验证是否为某个域所生成。以及:

这就是根证书的来源。可以其视为一个更高的级别,用来确保其下的级别是正确的。它验证发送给你的证书是否已由证书颁发机构授权。此权限确保创建证书的人实际上是真正的运营者。

这也被称为信任链。默认情况下,你的操作系统包含一组这些根证书,以确保该信任链的存在。

滥用

我们现在知道:

  • DNS 解析器在你发送域名时向你发送 IP 地址
  • 证书允许加密你的通信,并验证它们是否为你访问的域生成
  • 根证书验证该证书是否合法,并且是由真实站点运营者创建的

怎么会被滥用呢?

  • 如前所述,恶意 DNS 解析器可能会向你发送错误的 IP 以进行审查。它们还可以将你导向完全不同的网站。
  • 这个网站可以向你发送假的证书。
  • 恶意的根证书可以“验证”此假证书。

对你来说,这个网站看起来绝对没问题;它在网址中有 https,如果你点击它,它会说已经通过验证。就像你了解到的一样,对吗?不对!

它现在可以接收你要发送给原站点的所有通信。这会绕过想要避免被滥用而创建的检查。你不会收到错误消息,你的浏览器也不会发觉。

而你所有的数据都会受到损害!

结论

风险

  • 使用恶意 DNS 解析器总是会损害你的隐私,但只要你注意 https,你的安全性就不会受到损害。
  • 使用恶意 DNS 解析程序和恶意根证书,你的隐私和安全性将完全受到损害。

可以采取的动作

不要安装第三方根证书!只有非常少的例外情况才需要这样做,并且它们都不适用于一般最终用户。

不要被那些“广告拦截”、“军事级安全”或类似的东西营销噱头所吸引。有一些方法可以自行使用 DNS 解析器来增强你的隐私,但安装第三方根证书永远不会有意义。你正在将自己置身于陷阱之中。

实际看看

警告

有位友好的系统管理员提供了一个现场演示,你可以实时看到自己。这是真事。

千万不要输入私人数据!之后务必删除证书和该 DNS!

如果你不知道如何操作,那就不要安装它。虽然我们相信我们的朋友,但你不要随便安装随机和未知的第三方根证书。

实际演示

链接在这里:http://https-interception.info.tm/

  • 设置所提供的 DNS 解析器
  • 安装所提供的根证书
  • 访问 https://paypal.com 并输入随机登录数据
  • 你的数据将显示在该网站上

延伸信息

如果你对更多技术细节感兴趣,请告诉我们。如果有足够多感兴趣的人,我们可能会写一篇文章,但是目前最重要的部分是分享基础知识,这样你就可以做出明智的决定,而不会因为营销和欺诈而陷入陷阱。请随时提出对你很关注的其他主题。

这篇文章来自 Privacy Today 频道Privacy Today 是一个关于隐私、开源、自由哲学等所有事物的组织!

所有内容均根据 CC BY-NC-SA 4.0 获得许可。(署名 - 非商业性使用 - 共享 4.0 国际)。


via: https://lushka.al/dns-and-certificates/

作者:Anxhelo Lushka 选题:lujun9972 译者:wxy 校对:wxy

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

Linux DNS 查询剖析(第一部分)Linux DNS 查询剖析(第二部分)Linux DNS 查询剖析(第三部分) 中,我们已经介绍了以下内容:

  • nsswitch
  • /etc/hosts
  • /etc/resolv.conf
  • pinghost 查询方式的对比
  • systemd 和对应的 networking 服务
  • ifupifdown
  • dhclient
  • resolvconf
  • NetworkManager
  • dnsmasq

在第四部分中,我将介绍容器如何完成 DNS 查询。你想的没错,也不是那么简单。

1) Docker 和 DNS

Linux DNS 查询剖析(第三部分) 中,我们介绍了 dnsmasq,其工作方式如下:将 DNS 查询指向到 localhost 地址 127.0.0.1,同时启动一个进程监听 53 端口并处理查询请求。

在按上述方式配置 DNS 的主机上,如果运行了一个 Docker 容器,容器内的 /etc/resolv.conf 文件会是怎样的呢?

我们来动手试验一下吧。

按照默认 Docker 创建流程,可以看到如下的默认输出:

$  docker run  ubuntu cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

search home
nameserver 8.8.8.8
nameserver 8.8.4.4

奇怪!

地址 8.8.8.88.8.4.4 从何而来呢?

当我思考容器内的 /etc/resolv.conf 配置时,我的第一反应是继承主机的 /etc/resolv.conf。但只要稍微进一步分析,就会发现这样并不总是有效的。

如果在主机上配置了 dnsmasq,那么 /etc/resolv.conf 文件总会指向 127.0.0.1 这个 回环地址 loopback address 。如果这个地址被容器继承,容器会在其本身的 网络上下文 networking context 中使用;由于容器内并没有运行(在 127.0.0.1 地址的)DNS 服务器,因此 DNS 查询都会失败。

“有了!”你可能有了新主意:将 主机的 的 IP 地址用作 DNS 服务器地址,其中这个 IP 地址可以从容器的 默认路由 default route 中获取:

root@79a95170e679:/# ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2

使用主机 IP 地址真的可行吗?

从默认路由中,我们可以找到主机的 IP 地址 172.17.0.1,进而可以通过手动指定 DNS 服务器的方式进行测试(你也可以更新 /etc/resolv.conf 文件并使用 ping 进行测试;但我觉得这里很适合介绍新的 dig 工具及其 @ 参数,后者用于指定需要查询的 DNS 服务器地址):

root@79a95170e679:/# dig @172.17.0.1 google.com | grep -A1 ANSWER.SECTION
;; ANSWER SECTION:
google.com.             112     IN      A       172.217.23.14

但是还有一个问题,这种方式仅适用于主机配置了 dnsmasq 的情况;如果主机没有配置 dnsmasq,主机上并不存在用于查询的 DNS 服务器。

在这个问题上,Docker 的解决方案是忽略所有可能的复杂情况,即无论主机中使用什么 DNS 服务器,容器内都使用 Google 的 DNS 服务器 8.8.8.88.8.4.4 完成 DNS 查询。

我的经历:在 2013 年,我遇到了使用 Docker 以来的第一个问题,与 Docker 的这种 DNS 解决方案密切相关。我们公司的网络屏蔽了 8.8.8.88.8.4.4,导致容器无法解析域名。

这就是 Docker 容器的情况,但对于包括 Kubernetes 在内的容器 编排引擎 orchestrators ,情况又有些不同。

2) Kubernetes 和 DNS

在 Kubernetes 中,最小部署单元是 pod;它是一组相互协作的容器,共享 IP 地址(和其它资源)。

Kubernetes 面临的一个额外的挑战是,将 Kubernetes 服务请求(例如,myservice.kubernetes.io)通过对应的 解析器 resolver ,转发到具体服务地址对应的 内网地址 private network 。这里提到的服务地址被称为归属于“ 集群域 cluster domain ”。集群域可由管理员配置,根据配置可以是 cluster.localmyorg.badger 等。

在 Kubernetes 中,你可以为 pod 指定如下四种 pod 内 DNS 查询的方式。

Default

在这种(名称容易让人误解)的方式中,pod 与其所在的主机采用相同的 DNS 查询路径,与前面介绍的主机 DNS 查询一致。我们说这种方式的名称容易让人误解,因为该方式并不是默认选项!ClusterFirst 才是默认选项。

如果你希望覆盖 /etc/resolv.conf 中的条目,你可以添加到 kubelet 的配置中。

ClusterFirst

ClusterFirst 方式中,遇到 DNS 查询请求会做有选择的转发。根据配置的不同,有以下两种方式:

第一种方式配置相对古老但更简明,即采用一个规则:如果请求的域名不是集群域的子域,那么将其转发到 pod 所在的主机。

第二种方式相对新一些,你可以在内部 DNS 中配置选择性转发。

下面给出示例配置并从 Kubernetes 文档中选取一张图说明流程:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"acme.local": ["1.2.3.4"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]

stubDomains 条目中,可以为特定域名指定特定的 DNS 服务器;而 upstreamNameservers 条目则给出,待查询域名不是集群域子域情况下用到的 DNS 服务器。

这是通过在一个 pod 中运行我们熟知的 dnsmasq 实现的。

kubedns

剩下两种选项都比较小众:

ClusterFirstWithHostNet

适用于 pod 使用主机网络的情况,例如绕开 Docker 网络配置,直接使用与 pod 对应主机相同的网络。

None

None 意味着不改变 DNS,但强制要求你在 pod 规范文件 specification dnsConfig 条目中指定 DNS 配置。

CoreDNS 即将到来

除了上面提到的那些,一旦 CoreDNS 取代 Kubernetes 中的 kube-dns,情况还会发生变化。CoreDNS 相比 kube-dns 具有可配置性更高、效率更高等优势。

如果想了解更多,参考这里

如果你对 OpenShift 的网络感兴趣,我曾写过一篇文章可供你参考。但文章中 OpenShift 的版本是 3.6,可能有些过时。

第四部分总结

第四部分到此结束,其中我们介绍了:

  • Docker DNS 查询
  • Kubernetes DNS 查询
  • 选择性转发(子域不转发)
  • kube-dns

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

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

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

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

  • nsswitch
  • /etc/hosts
  • /etc/resolv.conf
  • pinghost 查询方式的对比

而在 Linux DNS 查询剖析(第二部分),我们介绍了:

  • systemd 和对应的 networking 服务
  • ifupifdown
  • dhclient
  • resolvconf

剖析进展如下:

linux-dns-2 (2)

(大致)准确的关系图

很可惜,故事还没有结束,还有不少东西也会影响 DNS 查询。在第三部分中,我将介绍 NetworkManagerdnsmasq,简要说明它们如何影响 DNS 查询。

1) NetworkManager

在第二部分已经提到,我们现在介绍的内容已经偏离 POSIX 标准,涉及的 DNS 解析管理部分在各个发行版上形式并不统一。

在我使用的发行版 (Ubuntu)中,有一个名为 NetworkManager 可用 available 服务,它通常作为一些其它软件包的依赖被安装。它实际上是 RedHat 在 2004 年开发的一个服务,用于帮助你管理网络接口。

它与 DNS 查询有什么关系呢?让我们安装这个服务并找出答案:

$ apt-get install -y network-manager

对于 Ubuntu,在软件包安装后,你可以发现一个新的配置文件:

$ cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq

[ifupdown]
managed=false

看到 dns=dnsmasq 了吧?这意味着 NetworkManager 将使用 dnsmasq 管理主机上的 DNS。

2) dnsmasq

dnsmasq 程序是我们很熟悉的程序:只是 /etc/resolv.conf 之上的又一个间接层。

理论上,dnsmasq 有多种用途,但主要被用作 DNS 缓存服务器,缓存到其它 DNS 服务器的请求。dnsmasq 在本地所有网络接口上监听 53 端口(标准的 DNS 端口)。

那么 dnsmasq 运行在哪里呢?NetworkManager 的运行情况如下:

$ ps -ef | grep NetworkManager
root     15048     1  0 16:39 ?        00:00:00 /usr/sbin/NetworkManager --no-daemon

但并没有找到 dnsmasq 相关的进程:

$ ps -ef | grep dnsmasq
$

令人迷惑的是,虽然 dnsmasq 被配置用于管理 DNS,但其实并没有安装在系统上!因而,你需要自己安装它。

安装之前,让我们查看一下 /etc/resolv.conf 文件的内容:

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

可见,并没有被 NetworkManager 修改。

如果安装 dnsmasq

$ apt-get install -y dnsmasq

然后启动运行 dnsmasq

$ ps -ef | grep dnsmasq
dnsmasq  15286     1  0 16:54 ?        00:00:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -r /var/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

然后,/etc/resolv.conf 文件内容又改变了!

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

运行 netstat 命令,可以看出 dnsmasq 在所有网络接口上监听 53 端口:

$ netstat -nlp4
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address     Foreign Address State   PID/Program name
tcp        0      0 127.0.0.1:53      0.0.0.0:*       LISTEN  15286/dnsmasq 
tcp        0      0 10.0.2.15:53      0.0.0.0:*       LISTEN  15286/dnsmasq
tcp        0      0 172.28.128.11:53  0.0.0.0:*       LISTEN  15286/dnsmasq
tcp        0      0 0.0.0.0:22        0.0.0.0:*       LISTEN  1237/sshd
udp        0      0 127.0.0.1:53      0.0.0.0:*               15286/dnsmasq
udp        0      0 10.0.2.15:53      0.0.0.0:*               15286/dnsmasq  
udp        0      0 172.28.128.11:53  0.0.0.0:*               15286/dnsmasq  
udp        0      0 0.0.0.0:68        0.0.0.0:*               10758/dhclient
udp        0      0 0.0.0.0:68        0.0.0.0:*               10530/dhclient
udp        0      0 0.0.0.0:68        0.0.0.0:*               10185/dhclient

3) 分析 dnsmasq

在目前的情况下,所有的 DNS 查询都会使用 127.0.0.1:53 这个 DNS 服务器,下一步会发生什么呢?

我再次查看 /var/run 目录,可以发现一个线索:resolvconf 目录下 resolv.conf 文件中的配置也相应变更,变更为 dnsmasq 对应的 DNS 服务器:

$ cat /var/run/resolvconf/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search home

同时,出现了一个新的 dnsmasq 目录,也包含一个 resolv.conf 文件:

$ cat /run/dnsmasq/resolv.conf
nameserver 10.0.2.2

(LCTT 译注:这里依次提到了 /var/run/run,使用 Ubuntu 16.04 LTS 验证发现,/var/run 其实是指向 /run/ 的软链接)

该文件包含我们从 DHCP 获取的 nameserver

虽然可以推导出这个结论,但如何查看具体的调用逻辑呢?

4) 调试 dnsmasq

我经常思考 dnsmasq (在整个过程中)的功能定位。幸运的是,如果你将 /etc/dnsmasq.conf 中的一行做如下调整,你可以获取大量 dnsmasq 状态的信息:

#log-queries

修改为:

log-queries

然后重启 dnsmasq

接下来,只要运行一个简单的命令:

$ ping -c1 bbc.co.uk

你就可以在 /var/log/syslog 中找到类似的内容(其中 [...] 表示行首内容与上一行相同):

Jul  3 19:56:07 ubuntu-xenial dnsmasq[15372]: query[A] bbc.co.uk from 127.0.0.1
[...] forwarded bbc.co.uk to 10.0.2.2
[...] reply bbc.co.uk is 151.101.192.81
[...] reply bbc.co.uk is 151.101.0.81
[...] reply bbc.co.uk is 151.101.64.81
[...] reply bbc.co.uk is 151.101.128.81
[...] query[PTR] 81.192.101.151.in-addr.arpa from 127.0.0.1
[...] forwarded 81.192.101.151.in-addr.arpa to 10.0.2.2
[...] reply 151.101.192.81 is NXDOMAIN

可以清晰看出 dnsmasq 收到的查询、查询被转发到了哪里以及收到的回复。

如果查询被缓存命中(或者说,本地的查询结果还在 存活时间 time-to-live TTL 内,并未过期),日志显示如下:

[...] query[A] bbc.co.uk from 127.0.0.1
[...] cached bbc.co.uk is 151.101.64.81
[...] cached bbc.co.uk is 151.101.128.81
[...] cached bbc.co.uk is 151.101.192.81
[...] cached bbc.co.uk is 151.101.0.81
[...] query[PTR] 81.64.101.151.in-addr.arpa from 127.0.0.1

如果你想了解缓存中有哪些记录,可以向 dnsmasq 进程 id 发送 USR1 信号,这样 dnsmasq 会将缓存记录导出并写入到相同的日志文件中:

$ kill -SIGUSR1 $(cat /run/dnsmasq/dnsmasq.pid)

(LCTT 译注:原文中命令执行报错,已变更成最接近且符合作者意图的命令)

导出记录对应如下输出:

Jul  3 15:08:08 ubuntu-xenial dnsmasq[15697]: time 1530630488
[...] cache size 150, 0/5 cache insertions re-used unexpired cache entries.
[...] queries forwarded 2, queries answered locally 0
[...] queries for authoritative zones 0
[...] server 10.0.2.2#53: queries sent 2, retried or failed 0
[...] Host             Address         Flags      Expires
[...] linuxdns1        172.28.128.8    4FRI   H
[...] ip6-localhost    ::1             6FRI   H
[...] ip6-allhosts     ff02::3         6FRI   H
[...] ip6-localnet     fe00::          6FRI   H
[...] ip6-mcastprefix  ff00::          6FRI   H
[...] ip6-loopback     :               6F I   H
[...] ip6-allnodes     ff02:           6FRI   H
[...] bbc.co.uk        151.101.64.81   4F         Tue Jul  3 15:11:41 2018
[...] bbc.co.uk        151.101.192.81  4F         Tue Jul  3 15:11:41 2018
[...] bbc.co.uk        151.101.0.81    4F         Tue Jul  3 15:11:41 2018
[...] bbc.co.uk        151.101.128.81  4F         Tue Jul  3 15:11:41 2018
[...]                  151.101.64.81   4 R  NX    Tue Jul  3 15:34:17 2018
[...] localhost        127.0.0.1       4FRI   H
[...] <Root>           19036   8   2   SF I
[...] ip6-allrouters   ff02::2         6FRI   H

在上面的输出中,我猜测(并不确认,? 代表我比较无根据的猜测)如下:

  • 4 代表 IPv4
  • 6 代表 IPv6
  • H 代表从 /etc/hosts 中读取 IP 地址
  • I ? “永生”的 DNS 记录 ? (例如,没有设置存活时间数值 ?)
  • F
  • R
  • S
  • N
  • X

(LCTT 译注:查看 dnsmasq 的源代码 cache.c 可知,4 代表 IPV46 代表 IPV6C 代表 CNAMES 代表 DNSSECF 代表 FORWARDR 代表 REVERSEI 代表 IMMORTALN 代表 NEGX 代表 NXDOMAINH 代表 HOSTS。更具体的含义需要查看代码或相关文档)

dnsmasq 的替代品

NetworkManager 配置中的 dns 字段并不是只能使用 dnsmasq,可选项包括 nonedefaultunbounddnssec-triggered 等。使用 none 时,NetworkManager 不会改动 /etc/resolv.conf;使用 default 时,NetworkManager 会根据当前的 活跃连接 active connections 更新 resolv.conf;使用 unbound 时,NetworkManager 会与 unbound 服务通信;dnssec-triggered 与 DNS 安全相关,不在本文讨论范围。

第三部分总结

第三部分到此结束,其中我们介绍了 NetworkManager 服务及其 dns=dnsmasq 的配置。

下面简要罗列一下我们已经介绍过的全部内容:

  • nsswitch
  • /etc/hosts
  • /etc/resolv.conf
  • /run/resolvconf/resolv.conf
  • systemd 及对应的 networking 服务
  • ifupifdown
  • dhclient
  • resolvconf
  • NetworkManager
  • dnsmasq

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

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

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

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

  • nsswitch
  • /etc/hosts
  • /etc/resolv.conf
  • pinghost 查询方式对比

并且发现大多数程序选择要查询的 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 吧?

你可以尝试如下:

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

看上去新的 nameserver 已经加入:

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

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

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

我们的 10.10.10.10nameserver 不见了!

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

2) resolvconf

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

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

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

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

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

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

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

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

测试表明确实可以!

$ cat /etc/resolv.conf&nbsp; | grep nameserver
nameserver 10.0.2.3
nameserver 10.10.10.10

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

并非如此。

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

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

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

3) ifup/ifdown

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

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

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

/sbin/ifdown -a --read-environment --exclude=lo
/bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle'
/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 配置:

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

$ cat /etc/resolv.conf | grep nameserver
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-2 (2)

(大致)准确的关系图


第二部分的结束语

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

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

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

  • nsswitch
  • /etc/hosts
  • /etc/resolv.conf
  • /run/resolvconf/resolv.conf
  • systemd 和网络服务
  • ifupifdown
  • 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中国 荣誉推出