このケースのシナリオは、Linuxが組み込まれているルータについてのものですが、答えはおそらくすべてのLinuxシステムで同じであると思います。
これは私のものです。DNS確認:
~ $ cat /etc/resolv.conf
nameserver 80.58.61.250
nameserver 80.58.61.254
~ $ ping 80.58.61.250
PING 80.58.61.250 (80.58.61.250): 56 data bytes
64 bytes from 80.58.61.250: seq=0 ttl=250 time=50.0 ms
64 bytes from 80.58.61.250: seq=1 ttl=250 time=40.0 ms
^C
--- 80.58.61.250 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 40.0/45.0/50.0 ms
~ $ ping www.google.es
PING www.google.es (2a00:1450:4007:808::101f): 56 data bytes
ping: sendto: Network is unreachable
~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=57 time=50.0 ms
64 bytes from 8.8.8.8: seq=1 ttl=57 time=40.0 ms
64 bytes from 8.8.8.8: seq=2 ttl=57 time=40.0 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 40.0/43.3/50.0 ms
ご覧のとおり、8.8.8.8インターネット（）では応答がありますが、ドメイン名（などwww.google.es）ではwww.google.com応答がありません。
DNSサーバー（80.58.61.250）がpingに応答します。
もしそうなら、DNSサーバーに問題があるのだろうか？
Telnetやそのような方法はありますか？指定されたDNSがあることを確認してください。IPは正常に動作します（ドメイン名が要求されたときにIPアドレスで応答するなど）。
たとえば、SSHサーバーをテストする際の可能な技術の1つは次のとおりです。
C:\Users\Luis>telnet Midnighter- 22
SSH-2.0-OpenSSH_6.7p1 Debian-5
サードパーティのツールを受け入れます。コマンドラインとオープンソースが優先されます。
答え1
ICMP pingは、動作しているDNSサーバーがこれらの要求にファイアウォールを掛ける可能性があるため、悪いテストです。 DNS-over-UDPにはSSH-over-TCPなどの「接続」ハンドシェイク（SYN / SYN + ACK / ACK）がないので、最善の方法は仮想DNSサーバーでDNSクエリを実行し、何が起こるかを確認することですです。 。ファイアウォールがある場合、またはクエリがDNSレート制限に対して実行されている場合（ファイアウォールレベルまたはDNSサーバー自体では、これらのクエリは現在のDNS増幅攻撃により一般的です）、クエリまたはDNSサーバーによって異なります。 （たとえば、非再帰的なクエリの場合です。クエリは再帰的ですか？NSそれともDNSサーバーがローカルではないビューと見なすクライアントですか？など）
私は普通dig（またはNet::DNSPerlプログラムから）DNS検証のため。また見る監視ソフトウェア、DNSの監視、グラフ作成、および報告をサポートする必要がありますが、内蔵ルーターで使用するには重すぎる可能性があります。いくつかのdig例：
# possibly get server version info (unreliable)
$ dig +short @128.95.120.1 TXT CHAOS version.bind
"UW 3A7_3"
$ dig +short @8.8.8.8 TXT CHAOS version.bind
$
$ dig +short @8.8.8.8 NS example.org
b.iana-servers.net.
a.iana-servers.net.
$ dig +short @8.8.8.8 SOA example.org
sns.dns.icann.org. noc.dns.icann.org. 2015082419 7200 3600 1209600 3600
$
$ dig +short @8.8.4.4 A www.example.org
93.184.216.34
$ dig +short @8.8.4.4 CNAME www.example.org
$
# checking via TCP and via IPv6 might also be useful
$ dig +tcp +short @2001:4860:4860::8888 A www.example.org
93.184.216.34
$
BINDユーティリティをインストールしたくない場合は、nslookupコマンドもあります。getent hostsこれは強力であるか非常に弱くはありdigませんが、特定のホストへの照会が特定のIPを返すことを確認する必要がある場合は十分です。
答え2
今日、私は非常に奇妙な問題に直面しました。実際、私のDNSサーバーは、1つのドメインを除くすべてのドメインで動作します。他のすべてのドメインで動作するため、明らかにファイアウォールの問題ではありません。だけでなく、しばらくファイアウォールを変更していません。
もう少し詳しく見てみると、地域のキャッシュされたバージョンが最後に言及されたページを見つけました。そのキャッシュは犯人です。削除してサーバーを再起動したら、もう一度機能しました。ドメインが失敗する前にドメインを変更しましたが、まだそうです。これは予想される動作ではありません。
$ dig NS www.example.com
; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> NS www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62918
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.example.com. IN NS
;; Query time: 605 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Jun 05 13:20:25 PDT 2020
;; MSG SIZE rcvd: 42
ファイルをリセットするコマンド：
$ sudo rm /var/lib/bind/example.com.zone.jnl
$ sudo systemctl restart bind9
その後、期待どおりに機能しました。
興味深いのは、named-checkzoneソースファイルが問題ないため、ツールがエラーを返さないということです。
$ sudo named-checkzone example.com /etc/lib/bind/example.com.zone
上記のように、文書は大丈夫です。日記が時々私たちを欺くだけです。