web-dev-qa-db-ja.com

dnsmasqを介した大きなAXFRにより、Digがハングし、部分的な結果が発生する

領事のローカルキャッシュとして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（私の領事のdnsポート）に転送するように設定されています。それ以外の場合は、dnsmasq defaults（resolv.conf内の他のDNSにリクエストを転送する）を使用しています。

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（BIND dnsサーバーへの転送）も正常に機能します。 Dig Host.hosts.domain.com +shortは10.22.1.23を返します

ただし、ゾーン転送Dig axfr us1.domain.comを実行すると、Digは約700行を返し、常に同じ場所でハングします。 +retry=0を含める場合、Digは700行の後に下部に;; connection timed out; no servers could be reachedを配置します。

アップストリーム（バインド）DNSサーバーからゾーン転送を実行すると、期待どおりに22kの結果がすべて返されます。

Dig（-mフラグ）のメモリデバッグをオンにすると、ハングするようです。

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

ctrl + cを押すと、リクエストが終了していないと思ってDigまで追跡できたバックトレースが吐き出されますが、これは本当だと思います。

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の増加まで、さまざまな設定を試しました。アップストリームDNSからaxfrを要求することが正常に機能するのは非常に奇妙ですが、dnsmasqを介すると、Digがハングする前に部分的な結果しか返されません。

編集：バージョン1.76を試し、最新の公式コミット7cbf497da4100ea0d1c1974b59f9503e15a0cf80もコンパイルして同じ結果を得ました。

CentOS Linuxリリース7.5.1804（コア）を実行しています。

新情報

Dnsmasqの有無にかかわらず両方のtcpdumpを実行した後、応答が2つのパケットに分割されていることがわかります。何らかの理由で、Digはdnsmasqをクエリするときにこの2番目のパケットを受信しないため、ハングするだけです。パケットのサイズは、2521バイトと189バイトです。

bindinternal-dnsdns-zonednsmasqconsul
5
Connor Bell

Simon Kelly教授（dnsmasqの作成者）によると、この問題は65536バイトを超えるゾーン転送が原因であり、dnsmasqは転送を複数のメッセージにプッシュするために使用される継続メソッドを実装していません。

したがって、大規模なゾーン転送は機能しません。推奨される回避策は、アップストリームの権限のあるサーバーと直接通信することです。

0
Connor Bell