DNSサーバーのセットアップに問題があります。私のバインドサーバーは主にキャッシュサーバーですが、一部の内部ドメインにも対応しています。プライベートネットワークでのみリッスンし、そこからのリクエストのみを処理します。
今日、バインドを有効にしてDNSSECを検証したかったのですが、どういうわけかそれは正しく行われません。バインドLinuxマシン自体のホスト名を解決すると、無効なDNSSECは完全にそのように表示されます。しかし、ネットワーク内の他のマシンで同じDigコマンドを使用して同じドメインを解決しようとしても、DNSSECチェックは失敗せず、ドメインは正しく解決されます。私がしたいことは、正しいSERVFAILをネットワーク内の他のDNSクライアントに送信することです。
必要な情報はすべてここにあります(バインドバージョン、構成など)。最後に行った発掘を追加します。
OSバージョン
root@thor:/etc/bind# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.5 (jessie)
Release: 8.5
Codename: jessie
root@thor:/etc/bind# uname -a
Linux thor.home.intranet 3.16.0-4-AMD64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux
バインドバージョン
BIND 9.9.5-9+deb8u6-Debian (Extended Support Version)
named.conf
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
named.conf.options
options {
directory "/var/cache/bind";
forwarders {
208.67.222.222; # resolver1.opendns.com
208.67.220.220; # resolver2.opendns.com
# 8.8.8.8; # google-public-dns-a.google.com
# 8.8.4.4; # google-public-dns-b.google.com
};
dnssec-enable yes;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on {
127.0.0.1;
192.168.10.36;
};
recursion yes;
allow-recursion { 127.0.0.0/8; 192.168.10.0/24; };
max-ncache-ttl 0;
};
named.conf.local
zone "intranet" {
type master;
file "/etc/bind/master/db.intranet";
};
zone "10.168.192.in-addr.arpa" {
type master;
file "/etc/bind/master/db.10.168.192";
};
zone "box" {
type master;
file "/etc/bind/master/db.box";
};
named.conf.default-zones
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
DNS結果
サーバー(thor)で無効なドメインを要求すると、次のようになります。
user@thor:/etc/bind$ Dig @192.168.10.36 sigfail.verteiltesysteme.net
; <<>> Dig 9.9.5-9+deb8u6-Debian <<>> @192.168.10.36 sigfail.verteiltesysteme.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11750
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net. IN A
;; Query time: 256 msec
;; SERVER: 192.168.10.36#53(192.168.10.36)
;; WHEN: Fri Jul 08 21:27:37 CEST 2016
;; MSG SIZE rcvd: 57
Cygwinを使用してWindows 10を実行しているクライアントでまったく同じクエリを実行すると、次のようになります。
user@COMPUTER:~$ Dig @192.168.10.36 sigfail.verteiltesysteme.net
; <<>> Dig 9.10.3-P4 <<>> @192.168.10.36 sigfail.verteiltesysteme.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52681
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net. IN A
;; ANSWER SECTION:
sigfail.verteiltesysteme.net. 60 IN A 134.91.78.139
;; AUTHORITY SECTION:
verteiltesysteme.net. 3600 IN NS ns1.verteiltesysteme.net.
verteiltesysteme.net. 3600 IN NS ns2.verteiltesysteme.net.
;; ADDITIONAL SECTION:
ns1.verteiltesysteme.net. 2910 IN A 134.91.78.139
ns1.verteiltesysteme.net. 2910 IN AAAA 2001:638:501:8efc::139
ns2.verteiltesysteme.net. 2910 IN A 134.91.78.141
ns2.verteiltesysteme.net. 2910 IN AAAA 2001:638:501:8efc::141
;; Query time: 52 msec
;; SERVER: 192.168.10.36#53(192.168.10.36)
;; WHEN: Fr Jul 08 21:27:46 CEST 2016
;; MSG SIZE rcvd: 197
あなたが助けてくれるといいのですが。
前もって感謝します
-編集-
@HåkanLindqvistのおかげで、設定がかなり混乱していることに気付きました。少し整理して、すべてのエラーを取り除くために、私はすべての転送を破棄し、自分で解決しました。サーバーはとにかくそれをキャッシュするので、これはそれほど大きな問題ではないはずです。
My named.conf.optionsは次のようになります。
options {
directory "/var/cache/bind";
dnssec-enable yes;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on {
127.0.0.1;
192.168.10.36;
};
recursion yes;
allow-recursion { 127.0.0.0/8; 192.168.10.0/24; };
max-ncache-ttl 0;
};
ログに奇妙なエラーが表示されなくなり、無効な署名が正しく記録されるようになりました。
Jul 9 00:33:05 thor named[2940]: validating @0x7fd2d0391140: sigfail.verteiltesysteme.net A: no valid signature found
Jul 9 00:33:05 thor named[2940]: error (no valid RRSIG) resolving 'sigfail.verteiltesysteme.net/A/IN': 134.91.78.141#53
しかし、一貫性のない結果に関する私の問題はまだ残っています。両方のクライアントが同じバインドサーバーを使用しています。
コンピュータ:
user@COMPUTER:~$ Dig +short @192.168.10.36 hostname.bind CH TXT
"thor.home.intranet"
user@COMPUTER:~$ Dig +short @192.168.10.36 version.bind CH TXT
"9.9.5-9+deb8u6-Debian"
サーバー:
user@thor:/etc/bind# Dig @192.168.10.36 +short hostname.bind CH TXT
"thor.home.intranet"
user@thor:/etc/bind# Dig @192.168.10.36 +short version.bind CH TXT
"9.9.5-9+deb8u6-Debian"
しかし、結果はまだ異なります。
computer:
user@COMPUTER:~$ nslookup sigfail.verteiltesysteme.net
Server: 192.168.10.36
Address: 192.168.10.36#53
Non-authoritative answer:
Name: sigfail.verteiltesysteme.net
Address: 134.91.78.139
サーバー:
root@thor:/etc/bind# nslookup sigfail.verteiltesysteme.net
Server: 192.168.10.36
Address: 192.168.10.36#53
** server can't find sigfail.verteiltesysteme.net: SERVFAIL
注意すべき重要なこと(私は思う):コンピューターでリクエストを送信しても、サーバーは有効な署名がないことをログに記録しています。このようにして、DNSSEC検証が失敗したことを明確に認識します。しかし、とにかく、NOERRORを私のコンピューターに送信します。
-EDIT2- EDNSフラグが明示的に設定されている場合でも、結果が得られます。
user@COMPUTER:~$ Dig @192.168.10.36 +dnssec sigfail.verteiltesysteme.net
; <<>> Dig 9.10.3-P4 <<>> @192.168.10.36 +dnssec sigfail.verteiltesysteme.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48091
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net. IN A
;; ANSWER SECTION:
sigfail.verteiltesysteme.net. 60 IN A 134.91.78.139
sigfail.verteiltesysteme.net. 60 IN RRSIG A 5 3 60 20200610081125 20150611081125 30665 verteiltesysteme.net. //This+RRSIG+is+deliberately+broken///For+more+informati on+please+go+to/http+//dnssec+vs+uni/hyphen/+due+de////r eplace+/hyphen/+with+character////////////////////////// //8=
;; AUTHORITY SECTION:
verteiltesysteme.net. 3600 IN NS ns2.verteiltesysteme.net.
verteiltesysteme.net. 3600 IN NS ns1.verteiltesysteme.net.
verteiltesysteme.net. 3600 IN RRSIG NS 5 2 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. s4iS0q402GTqtpy1WWspX1KHY3hb0/SOq79qWzRL5PFacAAKK+2ltxWW PTuwsYOWP3l+uq7xu80G0UQNtWPmISa2SYnktvXoZWbdy8F7q8GOH5xw 2t+JokxheEz5Xe4Xy7TmONIxVGq7M9FX4hDBva62PztcGq7UMZMWgyNs P/o=
;; ADDITIONAL SECTION:
ns1.verteiltesysteme.net. 69 IN A 134.91.78.139
ns1.verteiltesysteme.net. 69 IN AAAA 2001:638:501:8efc::139
ns2.verteiltesysteme.net. 69 IN A 134.91.78.141
ns2.verteiltesysteme.net. 69 IN AAAA 2001:638:501:8efc::141
ns1.verteiltesysteme.net. 69 IN RRSIG A 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. kIcbu+YRC6xby461JYrNE3WSOQmTM6UstxKYo8uO1mEysvfDUs23Yuv6 nG+yMo3enmdIg89pPuLWIsz16uYxswl4DlplCYYPP9nT4d+9bjbMHu5S 7hi/uTlYEFwUCDlyQn38sEwnDHwbBnuW0uvYwV/TPTTjtcfYEw0R8zGI QQU=
ns1.verteiltesysteme.net. 69 IN RRSIG AAAA 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. PzZiFVbjYHb1+xpIfZGbbtogY94uNvpqHBBibk0Sp7n5BLz4PJZ+dJYc rlikoNK1KyhnHugqCzh6Cr/t23lpioXUPjMWHFYcHsV4kcldTzt7Pl9Q 8h/IvlvtC33TYXnopmmGoV9vbjgpmgpAt//dY8UdNlXD/Dh6CDver+XT 34A=
ns2.verteiltesysteme.net. 69 IN RRSIG A 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. PVIDSVFi0GLHavnTFj2JnHn+1A/wOAKS8fMzavMhkFycWjudxDuC19uW Ak9vCV5dR/3ZW4UGQUjZFgVI45fQP2yCJ5H98Z7vfn4FF9gxKwGy+TDt dLeOzcdorOF70aYHEWyYWK5tcq1SqXLXJQMp3G/MY362vqCzbFiIUk32 3q4=
ns2.verteiltesysteme.net. 69 IN RRSIG AAAA 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. Fhg3JLyBsuXG4UCvG3y48gL8lz2Tu5Hx+ClxoXf4NjWs2MK/XScHEzwb UdOhz4aHnZbfWORoXHSD3DR92vBooix+522Z2GhCg1eiXBP66VDyypqT Ar7kUTXJHmsa70k/ubYHC6P6Imy68CbIi5xPr+OFZHrL/CTv9fcLVg3A ikU=
;; Query time: 53 msec
;; SERVER: 192.168.10.36#53(192.168.10.36)
;; WHEN: Sa Jul 09 01:07:08 CEST 2016
;; MSG SIZE rcvd: 1277
-EDIT3-正しいクエリが送信されるように、デバッグレベル10でクエリログを有効にしました。次の3つのエントリは、「Dig @ 192.168.10.36 + dnssec sigfail.verteiltesysteme.net」というクエリによって生成されています。
09-Jul-2016 01:23:50.419 client 192.168.10.36#47038 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)
09-Jul-2016 01:23:59.620 client 192.168.10.2#64858 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)
09-Jul-2016 01:24:32.417 client 192.168.10.2#54071 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)
192.168.10.2は私のコンピューター、192.168.10.36はバインドが実行されるサーバーです。
私はあなたが提案して現在のバインドバージョンをisc.orgからさらにダウンロードして実行しました。結果はcygwinと同じです。上記のログの3番目の結果はisc.org bindによって生成されます。
-編集4-
非常に遅いが最後の編集として、私はようやく解決策を見つけました。私はAVとしてAvastを使用していましたが、これは一見DNSトラフィックを傍受し、Avastの「セキュアサーバー」に転送しました。アバストをアンインストールしてWindows Defenderを実行するだけで問題は解決しました。
構成したforwarders
は、DNSSEC検証を実行するときにOpendnsサーバーが連携しないため、検証リゾルバーを実行するときにのみ問題を引き起こします。
あなたがforward only
を指定しなかったので、とにかくほとんどそれはあなたのためにうまくいくと思います、それで、namedはフォワーダーが有用な結果を生成し続けないので、多かれ少なかれ常にそれ自体で解決することにフォールバックします。しかし、それが一種の作業であったとしても、それはあなたのログを完全に混乱させます。
実例として、forward only
を設定して同じフォワーダーを使用すると、次のようになります。
named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.220.220#53
named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.222.222#53
named[20057]: error (no valid DS) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.222.222#53
named[20057]: validating @0x7f36805ecb10: sigfail.verteiltesysteme.net A: bad cache hit (net/DS)
named[20057]: error (broken trust chain) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.220.2
ご覧のとおり、失敗しましたが、完全に間違った理由です。 (DS
のnet
で失敗しました。実際に壊れた署名をsigfail.verteiltesysteme.net
で検証するときではありません。)
あなたのログは現在、上記のようなものと、名前が付けられたときに実際に関連するエントリが適切に機能しているサーバーのクエリに戻ったときのエントリとの組み合わせであると思います。これを修正すると、トラブルシューティングに役立ちます。
一貫性のない結果については、構成に何かが本当にそれを説明できるかどうかはわかりません。クエリに答えたのは、実際には同じ名前のインスタンスであると思いますか?奇妙なNATルールなど、クライアントが別のサーバーと透過的に通信することになるようなものはありませんか?
Dig @192.168.10.36 version.bind CH TXT
やDig @192.168.10.36 hostname.bind CH TXT
のようなクエリは、このような事態を引き起こす可能性があります。
これは古い投稿ですが、まだ問題があり、できることはすべて行っていますが、 https://dnssec-analyzer.verisignlabs.com/ のアナライザはまだ確認できませんDSレコード。これは、DSすでに作成されているレコードを次の場所に挿入する必要があるためです:Domain RegistrarはDNSだけにありません。
ドメインレジストラーのコントロールパネルでDNSSECレコード/情報または委任署名者レコードを探し、そこにDS情報を追加できるフォームを表示します。実行しない場合は、 DNSサーバーに再接続すると、DS情報がDNSプロバイダーから提供されます。
例: