标签 DNS 下的文章

我经常与虚拟机集群打交道(文1、文2、文3、文4、文5、文6),因此最终花费了大量时间试图掌握 DNS 查询的工作原理。遇到问题时,我只是不求甚解的使用 StackOverflow 上的“解决方案”,而不知道它们为什么有时工作,有时不工作。

最终我对此感到了厌倦,决定一并找出所有问题的原因。我没有在网上找到完整的指南,我问过一些同事,他们不知所以然(或许是问题太具体了)。

既然如此,我开始自己写这样的手册。

结果发现,“Linux 执行一次 DNS 查询”这句话的背后有相当多的工作。

linux-dns-0

“究竟有多难呢?”

本系列文章试图将 Linux 主机上程序获取(域名对应的) IP 地址的过程及期间涉及的组件进行分块剖析。如果不理解这些块的协同工作方式,调试解决 dnsmasq、vagrant landrush 和 resolvconf 等相关的问题会让人感到眼花缭乱。

同时这也是一份有价值的说明,指出原本很简单的东西是如何随着时间的推移变得相当复杂。在弄清楚 DNS 查询的原理的过程中,我了解了大量不同的技术及其发展历程。

我甚至编写了一些自动化脚本,可以让我在虚拟机中进行实验。欢迎读者参与贡献或勘误。

请注意,本系列主题并不是“DNS 工作原理”,而是与查询 Linux 主机配置的真实 DNS 服务器(这里假设查询了一台 DNS 服务器,但后面你会看到有时并不需要)相关的内容,以及如何确定使用哪个查询结果,或者如何使用其它方式确定 IP 地址。

1) 其实并没有名为“DNS 查询”的系统调用

linux-dns-1

工作方式并非如此

首先要了解的一点是,Linux 上并没有一个单独的方法可以完成 DNS 查询工作;没有一个有这样的明确接口的核心 系统调用 system call 。

不过,有一个标准 C 库函数调用 getaddrinfo,不少程序使用了该调用;但不是所有程序或应用都使用该调用!

让我们看一下两个简单的标准程序:ping 和 host:

root@linuxdns1:~# ping -c1 bbc.co.uk | head -1
PING bbc.co.uk (151.101.192.81) 56(84) bytes of data.
root@linuxdns1:~# host bbc.co.uk | head -1
bbc.co.uk has address 151.101.192.81

对于同一个域名,两个程序得到的 IP 地址是相同的;那么它们是使用同样的方法得到结果的吧?

事实并非如此。

下面文件给出了我主机上 ping 对应的 DNS 相关的系统调用:

root@linuxdns1:~# strace -e trace=open -f ping -c1 google.com
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 4
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 4
open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 4
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
open("/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 4
open("/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 4
PING google.com (216.58.204.46) 56(84) bytes of data.
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
64 bytes from lhr25s12-in-f14.1e100.net (216.58.204.46): icmp_seq=1 ttl=63 time=13.0 ms
[...]

下面是 host 对应的系统调用:

$ strace -e trace=open -f host google.com
[...]
[pid  9869] open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libdst.cat", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  9869] open("/usr/share/locale/en/libdst.cat", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  9869] open("/usr/share/locale/en/LC_MESSAGES/libdst.cat", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  9869] open("/usr/lib/ssl/openssl.cnf", O_RDONLY) = 6
[pid  9869] open("/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so", O_RDONLY|O_CLOEXEC) = 6[pid  9869] open("/etc/resolv.conf", O_RDONLY) = 6
google.com has address 216.58.204.46
[...]

可以看出 ping 打开了 nsswitch.conf 文件,但 host 没有;但两个程序都打开了 /etc/resolv.conf 文件。

下面我们依次查看这两个 .conf 扩展名的文件。

2) NSSwitch 与 /etc/nsswitch.conf

我们已经确认应用可以自主决定选用哪个 DNS 服务器。很多应用(例如 ping)通过配置文件 /etc/nsswitch.conf (根据具体实现 1 )参考 NSSwitch 完成选择。

NSSwitch 不仅用于 DNS 查询,例如,还用于密码与用户信息查询。

NSSwitch 最初是 Solaris OS 的一部分,可以让应用无需硬编码查询所需的文件或服务,而是在其它集中式的、无需应用开发人员管理的配置文件中找到。

下面是我的 nsswitch.conf:

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files
hosts: files dns myhostname
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       nis

我们需要关注的是 hosts 行。我们知道 ping 用到 nsswitch.conf 文件,那么我们修改这个文件(的 hosts 行),看看能够如何影响 ping。

修改 nsswitch.conf, hosts 行仅保留 files

如果你修改 nsswitch.conf,将 hosts 行仅保留 files:

hosts: files

此时, ping 无法获取 google.com 对应的 IP 地址:

$ ping -c1 google.com
ping: unknown host google.com

但 localhost 的解析不受影响:

$ ping -c1 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.039 ms

此外,host 命令正常返回:

$ host google.com
google.com has address 216.58.206.110

毕竟如我们之前看到的那样,host 不受 nsswitch.conf 影响。

修改 nsswitch.conf, hosts 行仅保留 dns

如果你修改 nsswitch.conf,将 hosts 行仅保留 dns:

hosts: dns

此时,google.com 的解析恢复正常:

$ ping -c1 google.com
PING google.com (216.58.198.174) 56(84) bytes of data.
64 bytes from lhr25s10-in-f174.1e100.net (216.58.198.174): icmp_seq=1 ttl=63 time=8.01 ms

但 localhost 无法解析:

$ ping -c1 localhost
ping: unknown host localhost

下图给出默认 NSSwitch 中 hosts 行对应的查询逻辑:

linux-dns-2 (1)

我的 hosts: 配置是 nsswitch.conf 给出的默认值

3) /etc/resolv.conf

我们已经知道 host 和 ping 都使用 /etc/resolv.conf 文件。

下面给出我主机的 /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

先忽略前两行,后面我们会回过头来看这部分(它们很重要,但你还需要一些知识储备)。

其中 nameserver 行指定了查询用到的 DNS 服务器。

如果将该行注释掉:

#nameserver 10.0.2.3

再次运行:

$ ping -c1 google.com
ping: unknown host google.com

解析失败了,这是因为没有可用的名字服务器 2 。

该文件中还可以使用其它选项。例如,你可以在 resolv.conf 文件中增加如下行:

search com

然后执行 ping google (不写 .com)

$ ping google
PING google.com (216.58.204.14) 56(84) bytes of data.

程序会自动为你尝试 .com 域。

第一部分总结

第一部分到此结束,下一部分我们会了解 resolv.conf 文件是如何创建和更新的。

下面总结第一部分涵盖的内容:

  • 操作系统中并不存在“DNS 查询”这个系统调用
  • 不同程序可能采用不同的策略获取名字对应的 IP 地址

    • 例如, ping 使用 nsswitch,后者进而使用(或可以使用) /etc/hosts、/etc/resolv.conf 以及主机名得到解析结果
  • /etc/resolv.conf 用于决定:

    • 查询什么地址(LCTT 译注:这里可能指 search 带来的影响)
    • 使用什么 DNS 服务器执行查询

如果你曾认为 DNS 查询很复杂,请跟随这个系列学习吧。


  1. ping 实现的变种之多令人惊叹。我 不 希望在这里讨论过多。 ↩
  2. 另一个需要注意的地方: host 在没有指定 nameserver 的情况下会尝试 127.0.0.1:53。 ↩

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

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

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

DNS 轮询将多个服务器映射到同一个主机名,并没有为这里展示的魔法做更多的工作。

如果你的后端服务器是由多台服务器构成的,比如集群化或者镜像的 Web 或者文件服务器,通过负载均衡器提供了单一的入口点。业务繁忙的大型电商在高端负载均衡器上花费了大量的资金,用它来执行各种各样的任务:代理、缓存、状况检查、SSL 处理、可配置的优先级、流量整形等很多任务。

但是你并不需要做那么多工作的负载均衡器。你需要的是一个跨服务器分发负载的简单方法,它能够提供故障切换,并且不太在意它是否高效和完美。DNS 轮询和使用轮询的子域委派是实现这个目标的两种简单方法。

DNS 轮询是将多台服务器映射到同一个主机名上,当用户访问 foo.example.com 时多台服务器都可用于处理它们的请求,使用的就是这种方式。

当你有多个子域或者你的服务器在地理上比较分散时,使用轮询的子域委派就比较有用。你有一个主域名服务器,而子域有它们自己的域名服务器。你的主域名服务器将所有的到子域的请求指向到它们自己的域名服务器上。这将提升响应时间,因为 DNS 协议会自动查找最快的链路。

DNS 轮询

轮询和 旅鸫鸟 robins 没有任何关系,据我相熟的图书管理员说,它最初是一个法语短语,ruban rond、或者 round ribbon。很久以前,法国政府官员以不分级的圆形、波浪线、或者直线形状来在请愿书上签字,以盖住原来的发起人。

DNS 轮询也是不分级的,简单配置一个服务器列表,然后将请求转到每个服务器上。它并不做真正的负载均衡,因为它根本就不测量负载,也没有状况检查,因此如果一个服务器宕机,请求仍然会发送到那个宕机的服务器上。它的优点就是简单。如果你有一个小的文件或者 Web 服务器集群,想通过一个简单的方法在它们之间分散负载,那么 DNS 轮询很适合你。

你所做的全部配置就是创建多条 A 或者 AAAA 记录,映射多台服务器到单个的主机名。这个 BIND 示例同时使用了 IPv4 和 IPv6 私有地址类:

fileserv.example.com. IN A 172.16.10.10
fileserv.example.com. IN A 172.16.10.11
fileserv.example.com. IN A 172.16.10.12

fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::10
fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::11
fileserv.example.com. IN AAAA fd02:faea:f561:8fa0:1::12

Dnsmasq 在 /etc/hosts 文件中保存 A 和 AAAA 记录:

172.16.1.10 fileserv fileserv.example.com
172.16.1.11 fileserv fileserv.example.com
172.16.1.12 fileserv fileserv.example.com
fd02:faea:f561:8fa0:1::10 fileserv fileserv.example.com
fd02:faea:f561:8fa0:1::11 fileserv fileserv.example.com
fd02:faea:f561:8fa0:1::12 fileserv fileserv.example.com

请注意这些示例都是很简化的,解析完全合格域名有多种方法,因此,关于如何配置 DNS 请自行学习。

使用 dig 命令去检查你的配置能否按预期工作。将 ns.example.com 替换为你的域名服务器:

$ dig @ns.example.com fileserv A fileserv AAA

它将同时显示出 IPv4 和 IPv6 的轮询记录。

子域委派和轮询

子域委派结合轮询要做的配置会更多,但是这样有一些好处。当你有多个子域或者地理位置比较分散的服务器时,就应该去使用它。它的响应时间更快,并且宕机的服务器不会去响应,因此客户端不会因为等待回复而被挂住。一个短的 TTL,比如 60 秒,就能帮你做到。

这种方法需要多台域名服务器。在最简化的场景中,你需要一台主域名服务器和两个子域,每个子域都有它们自己的域名服务器。在子域服务器上配置你的轮询记录,然后在你的主域名服务器上配置委派。

在主域名服务器上的 BIND 中,你至少需要两个额外的配置,一个区声明以及在区数据文件中的 A/AAAA 记录。主域名服务器中的委派应该像如下的内容:

ns1.sub.example.com. IN A 172.16.1.20
ns1.sub.example.com. IN AAAA fd02:faea:f561:8fa0:1::20
ns2.sub.example.com. IN A 172.16.1.21
ns2.sub.example.com. IN AAA fd02:faea:f561:8fa0:1::21

sub.example.com. IN NS ns1.sub.example.com.
sub.example.com. IN NS ns2.sub.example.com.

接下来的每台子域服务器上有它们自己的区文件。在这里它的关键点是每个服务器去返回它自己的 IP 地址。在 named.conf 中的区声明,所有的服务上都是一样的:

zone "sub.example.com" {
    type master;
    file "db.sub.example.com";
};

然后数据文件也是相同的,除了那个 A/AAAA 记录使用的是各个服务器自己的 IP 地址。SOA 记录都指向到主域名服务器:

; first subdomain name server
$ORIGIN sub.example.com.
$TTL 60
sub.example.com  IN SOA ns1.example.com. admin.example.com. (
        2018123456      ; serial
        3H              ; refresh
        15              ; retry
        3600000         ; expire
)

sub.example.com. IN NS ns1.sub.example.com.
sub.example.com. IN A  172.16.1.20
ns1.sub.example.com.  IN AAAA  fd02:faea:f561:8fa0:1::20
; second subdomain name server
$ORIGIN sub.example.com.
$TTL 60
sub.example.com  IN SOA ns1.example.com. admin.example.com. (
        2018234567      ; serial
        3H              ; refresh
        15              ; retry
        3600000         ; expire
)

sub.example.com. IN NS ns1.sub.example.com.
sub.example.com. IN A  172.16.1.21
ns2.sub.example.com.  IN AAAA  fd02:faea:f561:8fa0:1::21

接下来生成子域服务器上的轮询记录,方法和前面一样。现在你已经有了多个域名服务器来处理到你的子域的请求。再说一次,BIND 是很复杂的,做同一件事情它有多种方法,因此,给你留的家庭作业是找出适合你使用的最佳配置方法。

在 Dnsmasq 中做子域委派很容易。在你的主域名服务器上的 dnsmasq.conf 文件中添加如下的行,去指向到子域的域名服务器:

server=/sub.example.com/172.16.1.20
server=/sub.example.com/172.16.1.21
server=/sub.example.com/fd02:faea:f561:8fa0:1::20
server=/sub.example.com/fd02:faea:f561:8fa0:1::21

然后在子域的域名服务器上的 /etc/hosts 中配置轮询。

获取配置方法的详细内容和帮助,请参考这些资源:

通过来自 Linux 基金会和 edX 的免费课程 "Linux 入门" 学习更多 Linux 的知识。


via: https://www.linux.com/learn/intro-to-linux/2018/3/simple-load-balancing-dns-linux

作者:CARLA SCHRODER 译者:qhwdw 校对:wxy

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

许多人熟知并热爱 Dnsmasq,并在他们的本地域名服务上使用它。今天我们将介绍进阶配置文件管理、如何测试你的配置、一些基础的安全知识、DNS 泛域名、快速 DNS 配置,以及其他一些技巧与窍门。下个星期我们将继续详细讲解如何配置 DNS 和 DHCP。

测试配置

当你测试新的配置的时候,你应该从命令行运行 Dnsmasq,而不是使用守护进程。下面的例子演示了如何不用守护进程运行它,同时显示指令的输出并保留运行日志:

# dnsmasq --no-daemon --log-queries
dnsmasq: started, version 2.75 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt
 DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack
 ipset auth DNSSEC loop-detect inotify
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 192.168.0.1#53
dnsmasq: read /etc/hosts - 9 addresses

在这个小例子中你能看到许多有用的信息,包括版本、编译参数、系统名字服务文件,以及它的监听地址。可以使用 Ctrl+C 停止进程。在默认情况下,Dnsmasq 没有自己的日志文件,所以日志会被记录到 /var/log 目录下的多个地方。你可以使用经典的 grep 来找到 Dnsmasq 的日志文件。下面这条指令会递归式地搜索 /var/log,在每个匹配的文件名之后显示匹配的行号,并忽略 /var/log/dist-upgrade 里的内容:

# grep -ir --exclude-dir=dist-upgrade dnsmasq /var/log/

使用 grep --exclude-dir= 时有一个有趣的小陷阱需要注意:不要使用完整路径,而应该只写目录名称。

你可以使用如下的命令行参数来让 Dnsmasq 使用你指定的文件作为它专属的日志文件:

# dnsmasq --no-daemon --log-queries --log-facility=/var/log/dnsmasq.log

或者在你的 Dnsmasq 配置文件中加上 log-facility=/var/log/dnsmasq.log。

配置文件

Dnsmasq 的配置文件位于 /etc/dnsmasq.conf。你的 Linux 发行版也可能会使用 /etc/default/dnsmasq、/etc/dnsmasq.d/,或者 /etc/dnsmasq.d-available/(不,我们不能统一标准,因为这违反了 Linux 七嘴八舌秘密议会 Linux Cat Herd Ruling Cabal 的旨意)。你有很多自由来随意安置你的配置文件。

/etc/dnsmasq.conf 是德高望重的老大。Dnsmasq 在启动时会最先读取它。/etc/dnsmasq.conf 可以使用 conf-file= 选项来调用其他的配置文件,例如 conf-file=/etc/dnsmasqextrastuff.conf,或使用 conf-dir= 选项来调用目录下的所有文件,例如 conf-dir=/etc/dnsmasq.d。

每当你对配置文件进行了修改,你都必须重启 Dnsmasq。

你也可以根据扩展名来包含或忽略配置文件。星号表示包含,不加星号表示排除:

conf-dir=/etc/dnsmasq.d/, *.conf, *.foo
conf-dir=/etc/dnsmasq.d, .old, .bak, .tmp

你可以用 --addn-hosts= 选项来把你的主机配置分布在多个文件中。

Dnsmasq 包含了一个语法检查器:

$ dnsmasq --test
dnsmasq: syntax check OK.

实用配置

永远加入这几行:

domain-needed
bogus-priv

它们可以避免含有格式出错的域名或私有 IP 地址的数据包离开你的网络。

让你的名字服务只使用 Dnsmasq,而不去使用 /etc/resolv.conf 或任何其他的名字服务文件:

no-resolv

使用其他的域名服务器。第一个例子是只对于某一个域名使用不同的域名服务器。第二个和第三个例子是 OpenDNS 公用服务器:

server=/fooxample.com/192.168.0.1
server=208.67.222.222
server=208.67.220.220

你也可以将某些域名限制为只能本地解析,但不影响其他域名。这些被限制的域名只能从 /etc/hosts 或 DHCP 解析:

local=/mehxample.com/
local=/fooxample.com/

限制 Dnsmasq 监听的网络接口:

interface=eth0
interface=wlan1

Dnsmasq 在默认设置下会读取并使用 /etc/hosts。这是一个又快又好的配置大量域名的方法,并且 /etc/hosts 只需要和 Dnsmasq 在同一台电脑上。你还可以让这个过程再快一些,可以在 /etc/hosts 文件中只写主机名,然后用 Dnsmasq 来添加域名。/etc/hosts 看上去是这样的:

127.0.0.1 localhost
192.168.0.1 host2
192.168.0.2 host3
192.168.0.3 host4

然后把下面这几行写入 dnsmasq.conf(当然,要换成你自己的域名):

expand-hosts
domain=mehxample.com

Dnsmasq 会自动把这些主机名扩展为完整的域名,比如 host2 会变为 host2.mehxample.com。

DNS 泛域名

一般来说,使用 DNS 泛域名不是一个好习惯,因为它们太容易被误用了。但它们有时会很有用,比如在你的局域网的严密保护之下的时候。一个例子是使用 DNS 泛域名会让 Kubernetes 集群变得容易管理许多,除非你喜欢给你成百上千的应用写 DNS 记录。假设你的 Kubernetes 域名是 mehxample.com,那么下面这行配置可以让 Dnsmasq 解析所有对 mehxample.com 的请求:

address=/mehxample.com/192.168.0.5

这里使用的地址是你的集群的公网 IP 地址。这会响应对 mehxample.com 的所有主机名和子域名的请求,除非请求的目标地址已经在 DHCP 或者 /etc/hosts 中配置过。

下星期我们将探索更多的管理 DNS 和 DHCP 的细节,包括对不同的子网络使用不同的设置,以及提供权威域名服务器。

更多参考


via: https://www.linux.com/learn/intro-to-linux/2018/2/advanced-dnsmasq-tips-and-tricks

作者:CARLA SCHRODER 译者:yixunx 校对:wxy

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

今天,我们很高兴地宣布我们最近几周做的新功能。它是 Whois 聚合工具,现在可以在 DNSTrails 上获得。

在过去,查找一个域名的所有者会花费很多时间,因为大部分时间你都需要把域名翻译为一个 IP 地址,以便找到同一个人拥有的其他域名。

使用老的方法,在得到你想要的域名列表之前,你在一个工具和另外一个工具的一日又一日的研究和交叉比较结果中经常会花费数个小时。

感谢这个新工具和我们的智能 WHOIS 数据库,现在你可以搜索任何域名,并获得组织或个人注册的域名的完整列表,并在几秒钟内获得准确的结果。

我如何使用 Whois 聚合功能?

第一步:打开 DNSTrails.com

第二步:搜索任何域名,比如:godaddy.com

第三步:在得到域名的结果后,如下所见,定位下面的 Whois 信息:

Domain name search results

第四步:你会看到那里有有关域名的电话和电子邮箱地址。

第五步:点击右边的链接,你会轻松地找到用相同电话和邮箱注册的域名。

All domain names by the same owner

如果你正在调查互联网上任何个人的域名所有权,这意味着即使域名甚至没有指向注册服务商的 IP,如果他们使用相同的电话和邮件地址,我们仍然可以发现其他域名。

想知道一个人拥有的其他域名么?亲自试试 DNStrails 的 WHOIS 聚合功能或者使用我们的 API 访问。


via: https://securitytrails.com/blog/find-every-domain-someone-owns

作者:SECURITYTRAILS TEAM 译者:geekpi 校对:wxy

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

构建一个健壮的系统需要为故障而设计。作为 GitHub 的网站可靠性工程师(SRE),我们一直在寻求通过冗余来帮助缓解问题,今天将讨论最近我们所做的工作,以便支持你通过 DNS 来查找我们的服务器。

大型 DNS 提供商在其服务中构建了多级冗余,出现导致中断的问题时,可以采取措施来减轻其影响。最佳选择之一是把你的 区域 zone 的权威服务分割到多个服务提供商中。启用 分割权威 split authority 很简单,你只需在域名注册商配置两套或多套你区域的名称服务器,然后 DNS 请求将分割到整个列表中。但是,你必须在多个提供商之间对这些区域的记录保持同步,并且,根据具体情况这可能要么设置复杂,要么是完全手动的过程。

$ dig NS github.com. @a.gtld-servers.net.

...

;; QUESTION SECTION:
;github.com.            IN  NS

;; AUTHORITY SECTION:
github.com.     172800  IN  NS  ns4.p16.dynect.net.
github.com.     172800  IN  NS  ns-520.awsdns-01.net.
github.com.     172800  IN  NS  ns1.p16.dynect.net.
github.com.     172800  IN  NS  ns3.p16.dynect.net.
github.com.     172800  IN  NS  ns-421.awsdns-52.com.
github.com.     172800  IN  NS  ns-1283.awsdns-32.org.
github.com.     172800  IN  NS  ns2.p16.dynect.net.
github.com.     172800  IN  NS  ns-1707.awsdns-21.co.uk.

...

上面的查询是向 TLD 名称服务器 询问 github.com. 的 NS 记录。它返回了在我们在域名注册商中配置的值,在本例中,一共有两个 DNS 服务提供商,每个四条记录。如果其中一个提供商发生中断,那么其它的仍有希望可以服务请求。我们在各个地方同步记录,并且可以安全地修改它们,而不必担心数据陈旧或状态不正确。

完整地配置分割权威的最后一部分是在两个 DNS 服务提供商中将所有名称服务器作为顶层 NS 记录添加到区域的根中。

$ dig NS github.com. @ns1.p16.dynect.net.

...

;; QUESTION SECTION:
;github.com.            IN  NS

;; ANSWER SECTION:
github.com.     551 IN  NS  ns1.p16.dynect.net.
github.com.     551 IN  NS  ns2.p16.dynect.net.
github.com.     551 IN  NS  ns-520.awsdns-01.net.
github.com.     551 IN  NS  ns3.p16.dynect.net.
github.com.     551 IN  NS  ns-421.awsdns-52.com.
github.com.     551 IN  NS  ns4.p16.dynect.net.
github.com.     551 IN  NS  ns-1283.awsdns-32.org.
github.com.     551 IN  NS  ns-1707.awsdns-21.co.uk.

在 GitHub,我们有几十个区域和数千条记录,而大多数这些区域并没有关键到需要冗余,因此我们只需要处理一部分。我们希望有能够在多个 DNS 服务提供商中保持这些记录同步的方案,并且更一般地管理内部和外部的所有 DNS 记录。所以今天我们宣布了 OctoDNS。

octoDNS logo

配置

OctoDNS 能够让我们重新打造我们的 DNS 工作流程。我们的区域和记录存储在 Git 仓库的配置文件中。对它们的变更使用 GitHub 流,并像个站点一样用分支部署。我们甚至可以做个 “空” 部署来预览哪些记录将在变更中修改。配置文件是 yaml 字典,每个区域一个,它的顶层的键名是记录名称,键值是 ttl、类型和类型特定的数据。例如,当包含在区域文件 github.com.yaml 中时,以下配置将创建 octodns.github.com. 的 A 记录。

octodns:
  type: A
  values:
    - 1.2.3.4
    - 1.2.3.5

配置的第二部分将记录数据的源映射到 DNS 服务提供商。下面的代码片段告诉 OctoDNS 从 config 提供程序加载区域 github.com,并将其结果同步到 dyn 和 route53。

zones:
  github.com.:
    sources:
      - config
    targets:
      - dyn
      - route53

同步

一旦我们的配置完成,OctoDNS 就可以评估当前的状态,并建立一个计划,其中列出将需要将目标状态与源相匹配的一组更改。在下面的例子中,octodns.github.com 是一个新的记录,所以所需的操作是在两者中创建记录。

$ octodns-sync --config-file=./config/production.yaml
...
********************************************************************************
* github.com.
********************************************************************************
* route53 (Route53Provider)
*   Create <ARecord A 60, octodns.github.com., [u'1.2.3.4', '1.2.3.5']>
*   Summary: Creates=1, Updates=0, Deletes=0, Existing Records=0
* dyn (DynProvider)
*   Create <ARecord A 60, octodns.github.com., [u'1.2.3.4', '1.2.3.5']>
*   Summary: Creates=1, Updates=0, Deletes=0, Existing Records=0
********************************************************************************
...

默认情况下 octodns-sync 处于模拟运行模式,因此不会采取任何行动。一旦我们审阅了变更,并对它们感到满意,我们可以添加 `--doit' 标志并再次运行命令。OctoDNS 将继续它的处理流程,这一次将在 Route53 和 Dynect 中进行必要的更改,以便创建新的记录。

$ octodns-sync --config-file=./config/production.yaml --doit
...

此刻,在两个 DNS 服务提供商里我们有了相同的数据记录,并可以轻松地分割我们的 DNS 请求给它们,并知道它们将提供准确的结果。当我们直接运行上面的 OctoDNS 命令时,我们的内部工作流程依赖于部署脚本和 chatops。你可以在 README 的工作流程部分中找到更多信息。

总结

我们认为大多数网站可以从分割权威中受益,并且希望用 OctoDNS,其中最大的障碍已被扫除。即使对分割权威不感兴趣,OctoDNS 仍然值得一看,因为它将基础设施即代码的好处带给了 DNS。

想帮助 GitHub SRE 团队解决有趣的问题吗?我们很乐意加入我们。在这里申请。


via: https://githubengineering.com/enabling-split-authority-dns-with-octodns/

作者:Ross McFarland 译者:geekpi 校对:wxy

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

在 GitHub,我们最近从头改进了 DNS。这包括了我们如何与外部 DNS 提供商交互以及我们如何在内部向我们的主机提供记录。为此,我们必须设计和构建一个新的 DNS 基础设施,它可以随着 GitHub 的增长扩展并跨越多个数据中心。

以前,GitHub 的 DNS 基础设施相当简单直接。它包括每台服务器上本地的、只具备转发功能的 DNS 缓存服务器,以及一对被所有这些主机使用的缓存服务器和权威服务器主机。这些主机在内部网络以及公共互联网上都可用。我们在缓存守护程序中配置了 区域 zone 存根 stub ,以在本地进行查询,而不是在互联网上进行递归。我们还在我们的 DNS 提供商处设置了 NS 记录,它们将特定的内部 域 domain 指向这对主机的公共 IP,以便我们网络外部的查询。

这个配置使用了很多年,但它并非没有缺点。许多程序对于解析 DNS 查询非常敏感,我们遇到的任何性能或可用性问题在最好的情况下也会导致服务排队和性能降级,而最坏情况下客户会遭遇服务中断。配置和代码的更改可能会导致查询率发生大幅度的意外变化。因此超出这两台主机的扩展成为了一个问题。由于这些主机的网络配置,如果我们只是继续添加 IP 和主机的话存在一些本身的问题。在试图解决和补救这些问题的同时,由于缺乏测量指标和可见性,老旧的系统难以识别问题的原因。在许多情况下,我们使用 tcpdump 来识别有问题的流量和查询。另一个问题是在公共 DNS 服务器上运行,我们处于泄露内部网络信息的风险之下。因此,我们决定建立更好的东西,并开始确定我们对新系统的要求。

我们着手设计一个新的 DNS 基础设施,以改善上述包括扩展和可见性在内的运维问题,并引入了一些额外的需求。我们希望通过外部 DNS 提供商继续运行我们的公共 DNS 域,因此我们构建的系统需要与供应商无关。此外,我们希望该系统能够服务于我们的内部和外部域,这意味着内部域仅在我们的内部网络上可用,除非另有特别配置,而外部域也不用离开我们的内部网络就可解析。我们希望新的 DNS 架构不但可以基于部署的工作流进行更改,并可以通过我们的仓库和配置系统使用 API 自动更改 DNS 记录。新系统不能有任何外部依赖,太依赖于 DNS 功能将会陷入级联故障,这包括连接到其他数据中心和其中可能有的 DNS 服务。我们的旧系统将缓存服务器和权威服务器在同一台主机上混合使用。我们想转到具有独立角色的分层设计。最后,我们希望系统能够支持多数据中心环境,无论是 EC2 还是裸机。

实现

为了构建这个系统,我们确定了三类主机: 缓存主机 cache 、 边缘主机 edge 和 权威主机 authority 。缓存主机作为 递归解析器 recursive resolver 和 DNS “路由器” 缓存来自边缘层的响应。边缘层运行 DNS 权威守护程序,用于响应缓存层对 DNS 区域 zone 的请求,其被配置为来自权威层的 区域传输 zone transfer 。权威层作为隐藏的 DNS 主服务器 master ,作为 DNS 数据的规范来源,为来自边缘主机的 区域传输 zone transfer 提供服务,并提供用于创建、修改或删除记录的 HTTP API。

在我们的新配置中,缓存主机存在于每个数据中心中,这意味着应用主机不需要穿过数据中心边界来检索记录。缓存主机被配置为将 区域 zone 映射到其 地域 region 内的边缘主机,以便将我们的内部 区域 zone 路由到我们自己的主机。未明确配置的任何 区域 zone 将通过互联网递归解析。

边缘主机是地域性的主机,存在我们的网络边缘 PoP( 存在点 Point of Presence )内。我们的 PoP 有一个或多个依赖于它们进行外部连接的数据中心,没有 PoP 数据中心将无法访问互联网,互联网也无法访问它们。边缘主机对所有的权威主机执行 区域传输 zone transfer ,无论它们存在什么 地域 region 或 位置 location ,并将这些区域存在本地的磁盘上。

我们的权威主机也是地域性的主机,只包含适用于其所在 地域 region 的 区域 zone 。我们的仓库和配置系统决定一个 区域 zone 存放在哪个 地域性权威主机 regional authority ,并通过 HTTP API 服务来创建和删除记录。 OctoDNS 将区域映射到地域性权威主机,并使用相同的 API 创建静态记录,以及确保动态源处于同步状态。对于外部域 (如 github.com),我们有另外一个单独的权威主机,以允许我们可以在连接中断期间查询我们的外部域。所有记录都存储在 MySQL 中。

可运维性

迁移到更现代的 DNS 基础设施的巨大好处是可观察性。我们的旧 DNS 系统几乎没有指标,只有有限的日志。决定使用哪些 DNS 服务器的一个重要因素是它们所产生的指标的广度和深度。我们最终用 Unbound 作为缓存主机,NSD 作为边缘主机,PowerDNS 作为权威主机,所有这些都已在比 GitHub 大得多的 DNS 基础架构中得到了证实。

当在我们的裸机数据中心运行时,缓存通过私有的 任播 anycast IP 访问,从而使之可以到达最近的可用缓存主机。缓存主机已经以机架感知的方式部署,在它们之间提供了一定程度的平衡负载,并且与一些电源和网络故障模式相隔离。当缓存主机出现故障时,通常将用其进行 DNS 查询的服务器现在将自动路由到下一个最接近的缓存主机,以保持低延迟并提供对某些故障模式的容错。任播允许我们扩展单个 IP 地址后面的缓存数量,这与先前的配置不同,使得我们能够按 DNS 需求量运行尽可能多的缓存主机。

无论地域或位置如何,边缘主机使用权威层进行区域传输。我们的 区域 zone 并没有大到在每个 地域 region 保留所有 区域 zone 的副本成为问题。(LCTT 译注:此处原文“Our zones are not large enough that keeping a copy of all of them in every region is a problem.”,根据上下文理解而翻译。)这意味着对于每个区域,即使某个地域处于脱机状态,或者上游服务提供商存在连接问题,所有缓存服务器都可以访问具备所有区域的本地副本的本地边缘服务器。这种变化在面对连接问题方面已被证明是相当有弹性的,并且在不久前本来会导致客户面临停止服务的故障期间帮助保持 GitHub 可用。

那些区域传输包括了内部和外部域从它们相应的权威服务器进行的传输。正如你可能会猜想像 github.com 这样的区域是外部的,像 github.net 这样的区域通常是内部的。它们之间的区别仅在于我们使用的类型和存储在其中的数据。了解哪些区域是内部和外部的,为我们在配置中提供了一些灵活性。

$ dig +short github.com
192.30.253.112
192.30.253.113

公共 区域 zone 被同步到外部 DNS 提供商,并且是 GitHub 用户每天使用的 DNS 记录。另外,公共区域在我们的网络中是完全可解析的,而不需要与我们的外部提供商进行通信。这意味着需要查询 api.github.com 的任何服务都可以这样做,而无需依赖外部网络连接。我们还使用了 Unbound 的 stub-first 配置选项,它给了我们第二次查询的机会,如果我们的内部 DNS 服务由于某些原因在外部查询失败,则可以进行第二次查找。

$ dig +short time.github.net
10.127.6.10

大部分的 github.net 区域是完全私有的,无法从互联网访问,它只包含 RFC 1918 中规定的 IP 地址。每个地域和站点都划分了私有区域。每个地域和/或站点都具有适用于该位置的一组子区域,子区域用于管理网络、服务发现、特定的服务记录,并且还包括在我们仓库中的配置主机。私有区域还包括 PTR 反向查找区域。

总结

用一个新系统替换可以为数百万客户提供服务的旧系统并不容易。使用实用的、基于需求的方法来设计和实施我们的新 DNS 系统,才能打造出一个能够迅速有效地运行、并有望与 GitHub 一起成长的 DNS 基础设施。

想帮助 GitHub SRE 团队解决有趣的问题吗?我们很乐意你加入我们。在这申请。


via: https://githubengineering.com/dns-infrastructure-at-github/

作者:Joe Williams 译者:geekpi 校对:wxy

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