Я столкнулся с проблемой разрешения 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
cat /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, и приложение будет работать.
До сих пор я ожидал, что так как у меня есть 'rotate' в моих параметрах, запрос DNS будет таким:
первый запрос будет пытаться: nameserver 10.104.64.25, а затем попробовать второй сервер имен 10.104.65.25, а затем попробовать другой сервер имен 127.0.0.1 и bingo, найти его 'bbs.service.cf.internal'.
Но я использовал tcpdump, процесс не тот, что я думал. Из журнала я обнаружил, что это выглядит так:
QUERY1: 10.104.64.25 => QUERY2: 10.104.65.25 => QUERY3: 10.104.64.25 => QUERY4: 10.104.65.25 => QUERY5: 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)
В этом случае предпочтительнее использовать 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