Назад | Перейти на главную страницу

Почему эта конфигурация dnsmasq работает в одном офисе, а в другом - нет?

У нас есть два удаленных офиса, которые используют одного и того же провайдера 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 должен пройти следующие шаги:

  1. запрос 8.28.0.9 для sso.8x8.com
  2. вернуть CNAME (см. dig результаты ниже)
  3. запрос 192.84.18.11 для CNAME
  4. ничего не вернуть
  5. запрос 208.67.222.222 для CNAME
  6. вернуть IP-адрес

Когда я 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-адрес (если я правильно это интерпретирую).

Итак, у меня есть пара вопросов:

  1. Правильно ли я понимаю последовательность событий, связанных с таким сложным DNS-запросом?

  2. Есть ли существенная разница между двумя архитектурами и версиями dnsmasq что вызывает эту проблему? Что может быть причиной этого?

  3. Есть ли способ исправить это?

После долгих поисков и экспериментов с настройками я нашел ответ.

Оказывается, изменилось поведение dnsmasq в версии 2.69. Порядок, в котором server оцениваемые директивы были изменены с «сверху вниз» на «снизу вверх». Вот подробности из dnsmasq список рассылки.

Решением было просто изменить порядок server директивы.