web-dev-qa-db-ja.com

サーバーがDNSを解決できない理由

外部DNSサーバーとして機能するDNSを設定します。すべての設定はデフォルトです。管理者は/var/named/named.caの下にあるルートヒントファイルを使用するように指示しました。そして、ルートゾーンは/etc/named.confファイルに記載されています

options {
        listen-on port 53 { 127.0.0.1; 192.168.161.1; };
        #listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        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";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        allow-query     { any; };
        filter-aaaa-on-v4 yes;
        #OPTIONS = "-4"
        /*
         - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
         - If you are building a RECURSIVE (caching) DNS server, you need to enable
           recursion.
         - If your recursive DNS server has a public IP address, you MUST enable access
           control to limit queries to your legitimate users. Failing to do so will
           cause your server to become part of large scale DNS amplification
           attacks. Implementing BCP38 within your network would greatly
           reduce such attack surface
        */
        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

名前付きサービスを再起動しましたが、ドメインシステムにpingを実行すると解決できません

GoogleDNSを削除した後

「127.0.0.1」と「192.168.161.1」を追加してネットワークサービスを再起動したとき。そして、Dig google.com@localhostを実行します。それはこの返事をします

Dig google.com @localhost

; <<>> Dig 9.9.4-RedHat-9.9.4-72.el7 <<>> google.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24654
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      A

;; Query time: 4001 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 22 16:46:48 +03 2020
;; MSG SIZE  rcvd: 39
centosdnsbind9
1
OmiPenguin

まず、pingはDNSの問題を診断するための最良の方法ではありません。 Digが必要です：

shadur@vigil:~$ Dig google.com @localhost

; <<>> Dig 9.10.3-P4-Debian <<>> google.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55786
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             22      IN      A       216.58.211.110

;; Query time: 90 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 22 14:02:39 CET 2020
;; MSG SIZE  rcvd: 55

これにより、多くの情報が得られます。これは、まだ役に立たない場合でも、何が問題になっているのかを理解するのに役立つ情報を提供する可能性がはるかに高くなります。

次に、そこに配置した構成スニペットと実行しようとしていることの説明から判断すると、問題は次の行にあります。

recursion no;

これは、BIND9に、独自の内部既知リストにあるドメインのクエリ（そのすぐ上のコメントがAUTHORITATIVEサーバーと呼んでいるもの）にのみ応答する必要があることを示しているためです。 RECURSINGサーバー。

（通常、両方を同じマシンで実行することはお勧めしません。または、誰に再帰を許可するかについて非常に注意する必要がある場合は、オープン再帰はネットワークにとって悪いニュースです）。

また、上記のすべてが技術的すぎて理解できない場合は、代わりにpdns-recursor from PowerDNS プロジェクトをインストールすることを強くお勧めします。

1
Shadur