☰

问题描述：

tag-icon • tag-icon linux ubuntu domain-name-system resolv.conf
问题描述：

我遇到了一个 DNS 解析问题。有人能给我一些关于这个问题的建议吗？先谢谢了~

uname -a

Linux 152a580f-e3c2-405f-acde-eac4d928af22 4.4.0-111-generic #134~14.04.1-Ubuntu SMP Mon Jan 15 15:39:56 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

猫/etc/resolv.conf

nameserver 127.0.0.1
nameserver 10.104.64.25
nameserver 10.104.65.25
options timeout:5 attempts:4 rotate

问题描述：

我的解析文件中使用了 3 个名称服务器，其中 127.0.0.1 由本地 CONSUL dns 监听，它能够解析域“cf.internal”下的主机名。

另外 2 个名称服务器是我的本地 DNS 服务器，它们将解析我的内部域：dummysite.com，以及对公共 DNS 名称的递归查询。

问题是：有一个应用程序想要解析“bbs.service.cf.internal”，但我可以在日志中看到一些失败，例如：

{"timestamp":"1542522679.406200409","source":"rep","message":"rep.running-bulker.sync.batch-operations.do-request.failed-doing-request","log_level":2,"data":{"error":"Post http://bbs.service.cf.internal:8889/v1/actual_lrp_groups/list: dial tcp: lookup bbs.service.cf.internal: no such host","session":"13.1.1.3"}}

但是，过了一会儿，应用程序最终能够获得正确的 DNS 条目并且应用程序可以运行。

到目前为止，我所期望的是：由于我的选项中有“旋转”，所以 DNS 查询将如下所示：

第一个查询将尝试：名称服务器 10.104.64.25，然后尝试第二个名称服务器 10.104.65.25，然后尝试另一个名称服务器 127.0.0.1，然后 bingo，找到它“bbs.service.cf.internal”。

但是我用tcpdump，发现过程跟我想象的不太一样，从日志中看到它的流程是这样的：

查询 1：10.104.64.25 => 查询 2：10.104.65.25 => 查询 3：10.104.64.25 => 查询 4：10.104.65.25 => 查询 5：127.0.0.1（知道了）

为什么DNS查询按照这样的顺序进行？

tcpdump 日志作为参考：

10.104.148.102.48457 > cn1c6ocvcu01.dummysite.net.domain: [udp sum ok] 26743+ A? bbs.service.cf.internal. (41)
10.104.148.102.48457 > cn1c6ocvcu01.dummysite.net.domain: [udp sum ok] 5283+ AAAA? bbs.service.cf.internal. (41)
cn1c6ocvcu01.dummysite.net.domain > 10.104.148.102.48457: [udp sum ok] 26743 NXDomain q: A? bbs.service.cf.internal. 0/1/0 ns: . [1h56m16s] SOA a.root-servers.net. nstld.verisign-grs.com. 2018111800 1800 900 604800 86400 (116)
cn1c6ocvcu01.dummysite.net.domain > 10.104.148.102.48457: [udp sum ok] 5283 NXDomain q: AAAA? bbs.service.cf.internal. 0/1/0 ns: . [1h56m16s] SOA a.root-servers.net. nstld.verisign-grs.com. 2018111800 1800 900 604800 86400 (116)

10.104.148.102.54378 > cn1c6ocvcu02.dummysite.net.domain: [udp sum ok] 51897+ A? bbs.service.cf.internal. (41)
10.104.148.102.54378 > cn1c6ocvcu02.dummysite.net.domain: [udp sum ok] 32472+ AAAA? bbs.service.cf.internal. (41)
cn1c6ocvcu02.dummysite.net.domain > 10.104.148.102.54378: [udp sum ok] 32472 NXDomain q: AAAA? bbs.service.cf.internal. 0/1/0 ns: . [1h56m43s] SOA a.root-servers.net. nstld.verisign-grs.com. 2018111800 1800 900 604800 86400 (116)
cn1c6ocvcu02.dummysite.net.domain > 10.104.148.102.54378: [udp sum ok] 51897 NXDomain q: A? bbs.service.cf.internal. 0/1/0 ns: . [1h56m43s] SOA a.root-servers.net. nstld.verisign-grs.com. 2018111800 1800 900 604800 86400 (116)

10.104.148.102.47650 > cn1c6ocvcu01.dummysite.net.domain: [udp sum ok] 23809+ A? bbs.service.cf.internal. (41)
10.104.148.102.47650 > cn1c6ocvcu01.dummysite.net.domain: [udp sum ok] 4790+ AAAA? bbs.service.cf.internal. (41)
cn1c6ocvcu01.dummysite.net.domain > 10.104.148.102.47650: [udp sum ok] 23809 NXDomain q: A? bbs.service.cf.internal. 0/1/0 ns: . [1h56m15s] SOA a.root-servers.net. nstld.verisign-grs.com. 2018111800 1800 900 604800 86400 (116)
cn1c6ocvcu01.dummysite.net.domain > 10.104.148.102.47650: [udp sum ok] 4790 NXDomain q: AAAA? bbs.service.cf.internal. 0/1/0 ns: . [1h56m15s] SOA a.root-servers.net. nstld.verisign-grs.com. 2018111800 1800 900 604800 86400 (116)

10.104.148.102.42652 > cn1c6ocvcu02.dummysite.net.domain: [udp sum ok] 60294+ A? bbs.service.cf.internal. (41)
10.104.148.102.42652 > cn1c6ocvcu02.dummysite.net.domain: [udp sum ok] 24929+ AAAA? bbs.service.cf.internal. (41)
cn1c6ocvcu02.dummysite.net.domain > 10.104.148.102.42652: [udp sum ok] 60294 NXDomain q: A? bbs.service.cf.internal. 0/1/0 ns: . [1h56m42s] SOA a.root-servers.net. nstld.verisign-grs.com. 2018111800 1800 900 604800 86400 (116)
cn1c6ocvcu02.dummysite.net.domain > 10.104.148.102.42652: [udp sum ok] 24929 NXDomain q: AAAA? bbs.service.cf.internal. 0/1/0 ns: . [1h56m42s] SOA a.root-servers.net. nstld.verisign-grs.com. 2018111800 1800 900 604800 86400 (116)

localhost.46454 > localhost.domain: [bad udp cksum 0xfe44 -> 0xde60!] 41944+ A? bbs.service.cf.internal. (41)
localhost.46454 > localhost.domain: [bad udp cksum 0xfe44 -> 0x924b!] 54509+ AAAA? bbs.service.cf.internal. (41)
localhost.domain > localhost.46454: [bad udp cksum 0xfe76 -> 0x5e62!] 54509* q: AAAA? bbs.service.cf.internal. 0/1/0 ns: cf.internal. [0s] SOA ns.cf.internal. postmaster.cf.internal. 1542524177 3600 600 86400 0 (91)
localhost.domain > localhost.46454: [bad udp cksum 0xfe54 -> 0xff5e!] 41944* q: A? bbs.service.cf.internal. 1/0/0 bbs.service.cf.internal. [0s] A 10.104.149.223 (57)

答案1

在这种情况下，您的首选设置是使用 DNSMasq

添加/修改/etc/consul.d/config.json

"dns-config": {
    "recursors" : [ "10.104.64.25", "10.104.65.25" ]
}
"ports": {
    "dns": 8600
},

现在安装 DNSMasq，然后按如下方式配置

/etc/dnsmasq.d/00-base.conf

# Never forward plain names (without a dot or domain part)
domain-needed

# Never forward addresses in the non-routed address spaces.
bogus-priv

# Disable negative caching.
no-negcache

# Point to our upstream servers
resolv-file=/etc/resolv.dnsmasq.conf

/etc/dnsmasq.d/10-consul.conf

# Forward queries for ".cf.internal" TLD to the Consul Agent.
server=/cf.internal/127.0.0.1#8600

/etc/resolv.conf（保留此条目，删除其余内容）

nameserver 127.0.0.1

/etc/resolv.dnsmasq.conf

nameserver 10.104.64.25
nameserver 10.104.65.25

相关内容