UbuntuでBINDを使用して再帰ローカルネームサーバーを実行しています。現在IPv4ネットワークがあります。 BINDはデフォルトでクエリを受信し、IPv4とIPv6の両方で名前を再帰的に解決するようです。
次のシステムログでエラーが発生します。
命名[1907]: 'DELETED.FOR.PRIVACY.in-addr.arpa/PTR/IN' 解析エラー (ネットワークに接続できません): 2001:503:ba3e::2:30#53
この場合、2001:503:ba3e::2:30再帰プロセスの最初のサーバー（a.root-servers.net）にも接続できません。
時々（実際には常にそうかもしれませんが、わかりません）、これが発生した場合、digはSERVFAILを返します。 BINDが接続可能なサーバーを見つけるまでフェイルオーバーを実行する限り、これらのエラーメッセージが表示されても問題ありませんが、そうではありません。私の質問は現在IPv6ネットワークに接続できないため、BINDが見つけることができる別のネームサーバーに戻らないのはなぜですか？これがネームサーバーを複数持つことの核心だと思います。クエリを解決するときにBINDが試みるネームサーバーの数。
BINDでIPv6を無効にできることを知っていますが、そうすると、ローカルネットワークが自動的にIPv6にアップグレードする準備ができていないため、これは悪い習慣のようです。
ベストアンサー1
IPv6パスがあるかどうかわからない場合は、それを必要とするすべてのデーモンでこれを無効にするのが賢明でしょう。部分的には、IPv4とIPv6の両方の表現を持つDNS名の場合、問題が発生するのが一般的であるためです。 、IPv6はIPv4よりも優先順位が高くなります。
パブリックIPアドレスがなくても、デーモンがIPv6リンクローカルアドレスをソースとして使用してIPv6接続を試みることは珍しくありません。サービス。
IPv6で見られるエラーの種類についてもっと心配なのは、タイムアウトが頻繁に発生し、IPv4トランザクションが不可能であることです。
また、近い将来に IPv6 サポートを再度有効にするのを防ぐことはできません。 IPv4専用DNSを使用しても、近い将来にネットワークのどこかでIPv6アドレスを確認することを防ぐことはできません。マルチスタックIPv4 / IPv6システムが表示されます。
したがって、最善を尽くしてBINDをIPv4に設定してください。 Debian では -4 で実行します。次のように編集し/etc/default/bind9て変更できます。
OPTIONS="-u bind -4"
また、次のようにdb.rootからすべてのAAAAアドレスを抽出します。
grep -v "AAAA" /etc/bind/db.root > /tmp/a
mv /tmp/a /etc/bind/db.root
/etc/gai.confまた、IPv6よりもIPv4に優先順位を付けるために、次の行を編集して追加します。
precedence ::ffff:0:0/96 100
ここでも私の答えを読むことをお勧めします。
タイムアウトの場合、TCP DNS 要求がタイムアウトした場合、x 回試行後に DNS RFC は UDP n 回試行を使用して、同じ要求が再試行されるように定義します。
IPv6リクエストはまだ実行を試みているため、明らかにタイムアウトしましたが、パスはどこにもありません。
IPv6要求ごとに約6回の試行とタイムアウトに加えて、次のIPv6ルートに進むことができます。ルートネームサーバーのリストには、ルートネームサーバーが多すぎるため、失敗したIPv6アドレスを想定することはできません。 IPv4 アドレスを自動的に再試行します。 - したがって、全体の要求を受け取ったときの時間の大きな変化は、この場合、ほぼ予想される動作だとあえて言いたいと思います。
免責事項：これは全体的な動作です。私はBINDコードの汚れた詳細ではなく、パーサーの動作をよく知っています。
それを使用してこそ、何が起こっているのかをよりよく理解するtcdumpことができます。dnstracerを見ることも役に立ちますnamed.stats。
忙しい本番サーバーでは、これらのタイムアウト/要求が追加される可能性があることにも注目する価値があります。
しかし、私が見るには、ただ過度に考えて多くの仮定をしているようです。
推奨されるアプローチは、実装していないサービスを使用しようとしないことです。
IPv4モードでのみBINDを実行することをお勧めします。