Я пытаюсь настроить dnsmasq как локальный кеш для консула. Хотя это, кажется, нормально работает для обычных раскопок, 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 копать ставит ;; connection timed out; no servers could be reached внизу после 700 строк.
При выполнении передачи зоны с восходящего (привязанного) DNS-сервера он возвращает все 22k результатов, как и ожидалось.
При включенной отладке памяти на копать (-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.
Изменить: я пробовал версию 1.76, а также скомпилировал последнюю официальную фиксацию 7cbf497da4100ea0d1c1974b59f9503e15a0cf80 с теми же результатами.
Я использую CentOS Linux версии 7.5.1804 (Core).
После выполнения tcpdump обоих с / без dnsmasq я вижу, что ответ разделяется на два пакета. По какой-то причине dig никогда не получает этот второй пакет при запросе dnsmasq, поэтому он просто зависает. Размеры пакетов составляют 2521 байт и 189 байт, если это что-то для кого-то значит.
По словам профессора Саймона Келли (создателя dnsmasq), эта проблема вызвана тем, что передача зоны превышает 65536 байт, а dnsmasq не реализует методы продолжения, используемые для отправки передач в несколько сообщений.
Таким образом, передача больших зон не будет работать, и рекомендуется обратиться напрямую к вышестоящему авторитетному серверу.