У нас есть два удаленных офиса, которые используют одного и того же провайдера VOIP. Во время регистрации у этого провайдера они посоветовали нам изменить настройку DNS, чтобы телефоны использовали свой DNS-сервер для вызовов VOIP. Оба офиса используют dnsmasq локально. Вот часть конфигурации DNS для обоих офисов (они идентичны):
# Never forward plain names (without a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv
# If you don't want dnsmasq to read /etc/hosts, uncomment the
# following line.
no-hosts
# or if you want it to read another file, as well as /etc/hosts, use
# this.
#addn-hosts=/etc/banner_add_hosts
addn-hosts=/etc/dnsmasq.d/hosts/static.hosts
# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.
expand-hosts
# Ensure DNS servers are queried in the order they appear below. That
# will ensure proper georouting for VoIP, and will still work for websites
# on those domains
strict-order
# Our upstream DNS Servers
# 8x8 DNS servers (ensures best georouting for VoIP)
server=/8x8.com/packet8.net/8.28.0.9
server=/8x8.com/packet8.net/192.84.18.11
# 8x8's DNS servers don't handle web domains; fail over to our default servers
server=/8x8.com/packet8.net/#
# default to OpenDNS
server=208.67.222.222
server=208.67.220.220
Мы столкнулись с одной проблемой при настройке офиса №1: DNS-сервер VOIP-провайдера (по какой-то причине) не обслуживает имена хостов своих веб-серверов, и поэтому мы не смогли подключиться к их веб-приложению. Эта проблема была решена добавлением финального server=/xxxxx.com...
строка выше. Эта строка обеспечивает «отработку отказа» в случаях, когда первый сервер не дает результата. Офис №1 работает нормально после добавления этой конфигурации.
Недавно мы открыли офис №2, и единственные различия между №1 и №2 - это оборудование DNS-сервера (№1 = Ubuntu, работающий на x86_64, №2 = Raspberry Pi) и, следовательно, небольшая разница в версии dnsmasq
(# 1 = 2,68, # 2 = 2,76). И выяснилось, что в офисе №2 возникла та же проблема, что и в офисе №1.
Насколько я понимаю, на основе приведенной выше конфигурации запрос на sso.8x8.com
должен пройти следующие шаги:
8.28.0.9
для sso.8x8.com
CNAME
(см. dig
результаты ниже)192.84.18.11
для CNAME
208.67.222.222
для CNAME
Когда я dig
затронутые адреса в двух офисах, я получаю:
Офис №1:
; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> sso.8x8.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17588
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sso.8x8.com. IN A
;; ANSWER SECTION:
sso.8x8.com. 54 IN CNAME sso.8x8.com.cdn.cloudflare.net.
sso.8x8.com.cdn.cloudflare.net. 54 IN A 104.16.110.61
sso.8x8.com.cdn.cloudflare.net. 54 IN A 104.16.109.61
;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 02 13:39:34 PDT 2017
;; MSG SIZE rcvd: 116
Офис №2:
; <<>> DiG 9.9.5-9+deb8u13-Raspbian <<>> sso.8x8.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28188
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sso.8x8.com. IN A
;; ANSWER SECTION:
sso.8x8.com. 300 IN CNAME sso.8x8.com.cdn.cloudflare.net.
;; Query time: 20 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 02 13:40:34 PDT 2017
;; MSG SIZE rcvd: 84
В обоих случаях я вижу, что получаю CNAME, но в офисе № 2 он, похоже, не выполняет и не запрашивает IP-адрес (если я правильно это интерпретирую).
Итак, у меня есть пара вопросов:
Правильно ли я понимаю последовательность событий, связанных с таким сложным DNS-запросом?
Есть ли существенная разница между двумя архитектурами и версиями dnsmasq
что вызывает эту проблему? Что может быть причиной этого?
Есть ли способ исправить это?
После долгих поисков и экспериментов с настройками я нашел ответ.
Оказывается, изменилось поведение dnsmasq
в версии 2.69. Порядок, в котором server
оцениваемые директивы были изменены с «сверху вниз» на «снизу вверх». Вот подробности из dnsmasq
список рассылки.
Решением было просто изменить порядок server
директивы.