Почему эта конфигурация 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-адрес

Когда я копаю затронутые адреса в двух офисах, я получаю:

Офис №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. Есть способ исправить это?

0
задан 2 November 2017 в 22:50
1 ответ

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

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

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

1
ответ дан 4 December 2019 в 16:06

Теги

Похожие вопросы