web-dev-qa-db-ja.com

BIND / DNS-Dig + trace = Bad ReferralおよびBad Horizo​​ntal Referral

興味深い問題があります。権限のあるドメインの1つに対してDig + traceを実行すると、ネームサーバーから "Bad Referral"のエラーが発生し、名前空間ツリーをバックアップするのではなく、ネームスペースツリーにリクエストを転送したことがわかります。回答。残念ながら、現時点ではこの問題を再現できません。しかし私は悪い（HORIZONTAL）紹介を再現できます。基本的に、クエリがネームサーバーを参照すると、次のようになります。

;; BAD (HORIZONTAL) REFERRAL
;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms

時々、これは「too many lookups」エラーに到達するまでループし、あきらめるか、停止して他のサーバーを試してから応答を取得します。ここに興味深い部分があります。トレースが継続的に失敗するサーバーに対して単純なDig Aルックアップを実行すると、答えが返されます。次に振り返って、同じクエリに対してDig + traceを再度実行すると、失敗することはありません。レコードがどこかにキャッシュされていて、有効期限が切れると、メッセージが再び表示されるようになります。誰かが私がここで何が起こっているのかを理解するのを手伝ってくれる？ここに私たちの環境に関する情報があります。

1）BIND 9.8.2を実行するRHEL 6

2）公的な権限のあるマスターおよびスレーブサーバー。」

3）サーバーは「ビュー」構成でセットアップされます。 （デュアルビュー-「内部」用1つ、外部用1つ）

4）ビューを実装した後、これらの奇妙さを見始めたようです。

5）内部ビューにヒットしたクエリは、内部ビューに含まれていないゾーンの外部ビューに転送されます。これを実現するためにループバックIPを使用します。

6）これらの権限のあるサーバーは、再帰ステートメントとルートの「ヒント」ゾーンを使用して、権限のないクエリに再帰を返すように設定されています。

これはセットアップを簡略化したものです。

マスターサーバー：

acl ext_trusted {
x.x.x.x; // trusted net external
}; // end of "ext_trusted" ACL definition.

acl int_trusted {
x.x.x.x; // trusted internal
}; // end of ACL for "int_trusted"  


options {
    directory "/var/named";
    recursive-clients 30000;
    tcp-clients 2000;
    check-names master ignore;
    dump-file       "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named.stats.txt";
    memstatistics-file "/var/named/data/named_mem/stats.txt";
    zone-statistics yes;
    cleaning-interval 30;


// Listen on ipv4: // Adding localhost for view forwarding
listen-on port 53 { x.x.x.x; 127.0.0.1; };

// And, also listen on ipv6:
// loopback is required for view forwarding do not remove
listen-on-v6 { ::1; x.x.x.x; };

// Enforce the Customer DNS Query ACL Defined Above:
allow-query { ext_trusted; int_trusted; };

};


key "internal" {
algorithm HMAC-SHA512;
secret "xxxxxxxxx";
};

key "external" {
algorithm HMAC-SHA512;
secret "xxxxxxxx";
};

view "internal" {
    match-clients { !key external; int_trusted; key internal; };

    //IP of slave server IPv4
    server x.x.x.x {
    keys { internal; };
};
    //IP of slave server IPv6
    server x.x.x.x {
    keys { internal; };
};

    also-notify { //slave servers go here
    x.x.x.x; x.x.x.x; 

};

    allow-transfer { key internal; local_ns; int_ns; };
    empty-zones-enable no;
    server fe80::/16 { bogus yes; };
    server 0.0.0.0/8 {bogus yes; };

    zone "example.org" {
    type master;
    file "db.eamplein.org";
    allow-query { int_trusted; };
};

    forwarders {
    // forward to external view //
    127.0.0.1; ::1; 
};

    forward only;

};

view "external" {
  match-clients { any; };

 //IP of slave server IPv4
  server x.x.x.x {
  keys { external; };
};
  //IP of slave IPv6
  server x.x.x.x {
  keys { external; };
};

also-notify { //IP address of slave server
   x.x.x.x; x.x.x.x;
};

allow-transfer { key external; ext_ns; local_ns; };
server fe80::/16 { bogus yes; };
server 0.0.0.0/8 {bogus yes; };
empty-zones-enable yes;
recursion yes;
allow-recursion { any; };

zone "." {
     type hint;
     file "/var/named/named.ca";
};


zone "example.org" {
    type master;
    file "db.eampleout.org";
    allow-query { any; };
};

zone "example.com" {
    type master;
    file "db.eample.com";
    allow-query { any; };
};

};

スレーブサーバー設定：

acl ext_trusted {
x.x.x.x; // trusted net external
}; // end of "ext_trusted" ACL definition.

acl int_trusted {
x.x.x.x; // trusted internal
}; // end of ACL for "int_trusted"  

options {
    directory "/var/named/slaves";
    recursive-clients 30000;
    tcp-clients 2000;
    check-names master ignore;
    dump-file       "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt"; 
    cleaning-interval 30;

// Listen on ipv4:
// Change this to the proper IP address if you ever switch back!
// loopback is required for view forwarding do not remove
listen-on port 53 { 127.0.0.1; x.,x.x.x;; };

// And, also listen on ipv6:

// Configure ipv6 before uncommenting this:
// loopback is required for view forwarding do not remove
listen-on-v6 port 53 { ::1; x,x.x.x; ;

// Enforce the "trusted" ACL defined at the begining of this config file: 
allow-query { ext_trusted; int_trusted; };

};


key "internal" {
algorithm HMAC-SHA512;
secret "xxxxxxxxx";
};

key "external" {
algorithm HMAC-SHA512;
secret "xxxxxxxx";
};

view "internal" {
    match-clients { !key external; int_trusted; key internal; };

    //IPv4 of master server
    server x.x.x.x {
    keys { internal; };
};
    // IPv6
    server x.x.x.x. {
    keys { internal; };
};
    allow-transfer { key internal; local_ns; int_ns; };
    transfer-source x.x.x.x.; 
    empty-zones-enable no;
    server fe80::/16 { bogus yes; };
    server 0.0.0.0/8 {bogus yes; };

    zone "example.org" {
    type slave;
    file "db.example.org";
    masters { x.x.x.x; x.x.x.x; };
    allow-query { int_trusted; };
};

    forwarders {
    // forward to external view // 
    127.0.0.1; ::1; 
};

    forward only;
};

view "external" {
  match-clients { any; };

 //IP of master server
 server x.x.x.x {
 keys { external; };
};
 //IPv6
 server x.x.x.x. {
 keys { external; }; 
};

allow-transfer { key external; ext_ns; local_ns; };
transfer-source x.x.x.x; 
server fe80::/16 { bogus yes; };
server 0.0.0.0/8 {bogus yes; };
empty-zones-enable yes;

recursion yes;
allow-recursion { any; };

zone "." {
    type hint;
    file "/var/named/named.ca";
};

zone "example.org" {
    type slave;
    file "db.exampleout.org";
    masters { x.x.x.x; x.x.x.x; };
    allow-query { any; };
};

zone "example.com" {
    type master;
    file "db.example.com";
    allow-query { any; }; 
};

};

更新：内部ビューのACL内のIPからのDig + traceが、内部ビュー内のゾーンへのDig + traceを実行しても失敗しないことに気付いたという簡単なメモです。これは、内部ビューをポイントしているIPから外部ビューのゾーンを+トレースするときに失敗するようです。

domain-name-systembinddns-zonedig
3
user53029

@ andrew-bのコメントによると、これは通常、委任の不一致が原因です。

+開発者がHost.subdomain.example.orgの行に沿ってレコードの+ traceルックアップを行おうとしたときに同じエラーに遭遇しました。正確な原因はおそらく異なりますが、おそらく同じようなテーマになります。

私たちのケースの原因は、「無許可」のサーバーに送信されたDNSルックアップをキャプチャしてリダイレクトするファイアウォールルールがあることです。代わりに、リクエストは独自のDNSサーバーに到達し、DNSサーバーは再帰的なルックアップを実行しました。クライアントは、それがインターネットに連続する各ルックアップを送信していると考えますが、これらの要求は実際には内部サーバーによって応答されます。

修正は、DNSリクエストが傍受されること、およびDNSリダイレクトルールをバイパスするためにホワイトリストに登録されているサーバーからテストを実行できることを開発者に思い出させることでした。

以下で開発者が受け取った編集済みエラーを参照してください。

tricky-desktop:~ tricky$ Dig +trace Host.subdomain.example.org

; <<>> Dig 9.8.3-P1 <<>> +trace Host.subdomain.example.org
;; global options: +cmd
.           3600    IN  NS  g.root-servers.net.
.           3600    IN  NS  l.root-servers.net.
.           3600    IN  NS  j.root-servers.net.
.           3600    IN  NS  k.root-servers.net.
.           3600    IN  NS  b.root-servers.net.
.           3600    IN  NS  m.root-servers.net.
.           3600    IN  NS  d.root-servers.net.
.           3600    IN  NS  i.root-servers.net.
.           3600    IN  NS  e.root-servers.net.
.           3600    IN  NS  c.root-servers.net.
.           3600    IN  NS  h.root-servers.net.
.           3600    IN  NS  a.root-servers.net.
.           3600    IN  NS  f.root-servers.net.
;; Received 477 bytes from 192.168.1.2#53(192.168.1.2) in 87 ms

subdomain.example.org.  0   IN  NS  ns-outside-1.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-2.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-3.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-4.example.org.
;; Received 295 bytes from 199.43.133.53#53(199.43.133.53) in 14 ms

subdomain.example.org.  0   IN  NS  ns-outside-2.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-3.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-4.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-1.example.org.
;; BAD (HORIZONTAL) REFERRAL
;; Received 295 bytes from 199.43.135.53#53(199.43.135.53) in 5 ms

... 29 REPEATS REDACTED ...

subdomain.example.org.  0   IN  NS  ns-outside-4.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-1.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-2.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-3.example.org.
;; BAD (HORIZONTAL) REFERRAL
Dig: too many lookups
tricky-desktop:~ tricky$

ファイアウォールルールは、もともとBYODスタッフがDNS構成を変更する「スマートDNS」サービスのためにプライベート内部サービスを検索できないために必要でした。

2
zaTricky