Большой AXFR через dnsmasq приводит к зависанию dig с частичными результатами

Я пытаюсь настроить dnsmasq в качестве локального кеша для consul. Хотя это, кажется, работает нормально для обычных раскопок, dnsmasq, похоже, разрешает только частичную передачу зон.

Мой resolv.conf:

search x.domain.com y.domain.com z.domain.com domain.com
nameserver 127.0.0.1
nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3
options timeout: 2 attempts: 3

Мои настройки dnsmasq просто настроены на пересылку запросов для .consul на порт 3000 на той же коробке, который является моим днс-портом консула. В противном случае я использую значения по умолчанию dnsmasq (который перенаправляет запросы на другие DNS в resolv.conf).

server=/consul/127.0.0.1#3000 

Это отлично работает для обычных раскопок и возвращает результат с сервера localhost, например. dig consul.service.consul + short вернет:

10.22.1.15
10.22.1.16
10.22.1.17

, как и ожидалось. Нормальный DNS (пересылка на DNS-серверы BIND) также работает нормально, например. dig host.hosts.domain.com + short вернет 10.22.1.23

Однако при переносе зоны dig axfr us1.domain.com тогда dig будет вернуть около 700 строк и затем зависнуть, всегда в одном и том же месте. Если я включаю + retry = 0 dig помещает ;; время соединения истекло; невозможно получить доступ к серверам внизу после строк 700.

При выполнении передачи зоны с восходящего (привязанного) DNS-сервера, он возвращает все 22k результатов, как и ожидалось.

При включенной отладке памяти для dig ( -m флаг) кажется, что он зависает на

del 0x7f5c8131e010 size 152 file timer.c line 390 mctx 0x17572d0

при нажатии ctrl + c, он выплевывает обратную трассировку, которая Мне удалось отследить, чтобы копать, думая, что запрос не завершен, что, я полагаю, правда:

dighost.c:3831: REQUIRE(sockcount == 0) failed, back trace
#0 0x7f5c802c4227 in ??
#1 0x7f5c802c417a in ??
#2 0x41212d in ??
#3 0x405e0e in ??
#4 0x7f5c7de2f445 in ??
#5 0x405e6e in ??
Aborted (core dumped)

При включенном дополнительном журнале dnsmasq я вижу это для axfr:

Oct 04 12:17:41 hostname.hosts.domain.com dnsmasq[16055]: forwarded us1.domain.com to 10.0.0.1
Oct 04 12:17:41 hostname.hosts.domain.com dnsmasq[16055]: reply _kerberos.us1.domain.com is DOMAIN.COM
Oct 04 12:17:41 hostname.hosts.domain.com dnsmasq[16055]: reply consul-acl.prod.us1.domain.com is us4

И в журналах привязки восходящего потока:

Oct  4 12:20:07 upstreamdns named[17388]: client 10.22.10.20#42228: transfer of 'us1.domain.com/IN': AXFR started
Oct  4 12:20:07 upstreamdns named[17388]: client 10.22.10.20#42228: transfer of 'us1.domain.com/IN': AXFR ended

Я подозреваю, что это как-то связано с максимальными размерами пакетов или чем-то в этом роде, но я пробовал варьировать настройки от разных размеров кеша, до увеличения dns вперед и edns-packet-max. Очень странно, что запрос axfr из восходящего DNS работает нормально, но через dnsmasq он возвращает только частичный результат, прежде чем вызывает зависание dig.

Edit: Я пробовал версию 1.76, а также скомпилировал последний официальный коммит 7cbf497da4100ea0d1c1974b59f9503e15a0cf80 с теми же результатами.

Я запускаю CentOS Linux версии 7.5.1804 (Core).

Новая информация

После выполнения tcpdump обоих с / без dnsmasq видим, что ответ разбивается на два пакета. По какой-то причине dig никогда не получает этот второй пакет при запросе dnsmasq, поэтому он просто зависает. Размеры пакетов составляют 2521 байт и 189 байт, если это что-то для кого-то значит.

5
задан 19 December 2018 в 15:36
1 ответ

По словам профессора Саймона Келли (создателя dnsmasq), эта проблема вызвана тем, что передача зоны превышает 65536 байт, а dnsmasq не реализует методы продолжения, используемые для принудительной передачи нескольких сообщений.

Таким образом, передача больших зон не будет работать, и рекомендуется обходной путь - поговорить напрямую с вышестоящим уполномоченным сервером.

0
ответ дан 3 December 2019 в 02:06

Теги

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