BIND DNSを再帰的に作成するには、CLASS = ANY（255）でクエリを送信しますか？

Question

私はローカルの再帰的なBIND9 DNS（タイプではありません！）ANYを使ってクエリを作成すると、再帰的に、フォワーダにクラス= INのクエリを送信します。彼が私が送ったのと同じクラスで再帰的なクエリを送る方法 可能ですか？

私が欲しいもの：実際に発生した

****** QUERY WITH CLASS "ANY" *********************** CLASS "ANY" ************* 
* ME *----------------------->* Local Recursive DNS *------------>* FORWARDER * 
******      ***********************    ************* 

何：

****** QUERY WITH CLASS "ANY" *********************** CLASS "IN" ************* 
* ME *----------------------->* Local Recursive DNS *----------->* FORWARDER * 
******      ***********************   ************* 

設定が

options { 
    directory "/var/cache/bind"; 

    allow-query { any; }; 

    forwarders { 
      8.8.8.8 
    }; 
    forward only; 

    listen-on { 
      ... 
    }; 

    auth-nxdomain no; # conform to RFC1035 
}; 

Answer 1

興味深いコーナーケースです。

"なぜあなたはそれをしたいのですか？"事実、答えは実際によく定義されていないということです。QCLASSANYという再帰を意味します。

RFC 1035は、NSレコードが "指定されたクラスとドメイン"（RFC 1035セクション3.3.11）のネームサーバーに関するデータを保持することを指定しています。つまり、異なるクラスのNS RRSetsが異なる可能性があります。これは、そのような異なるセットを持つポイントに到達する再帰はに分割され、に分割され、の両方でのネームサーバーのセットに続くことを意味します。このような分割再帰の結果を単一のレスポンスにマージするための定義されたプロシージャはなく、単一の再帰は複数のレスポンスを持つことはできません。したがって、明確なプロセスではありません。また、RFC1034と1035の両方が、QCLASSANYクエリへの応答が決して権威的ではないと指定するという複雑な問題があります。

dig ns -c CH www.google.com +traceとdig ns -c IN www.google.com +traceの出力を比較し、両方が同じルックアッププロセスの一部であるということを想像してみると、妥当なヒントが得られます。それは本当に意味をなさない。

あなたがBINDから見る正確な振る舞いは、誰も再現しようとしたことのない結果であると思われます。ANYQCLASS再帰これは、クエリがINクエリに変換され、より正確な応答がFORMERR（RFC 1035のセクション4.1.1「ネームサーバーはクエリを解釈できませんでした）」になるというバグだと合理的に主張できます。