1年ぶりに帰ってきました！コミケ90の3日目、西4 f-44b に出展します。「低級はっかーズ」です。
今回は前回までとは異なり、HTTP/2のお話です。Nginxを使って「安全で高速な」HTTP/2サーバーを構築するまでのガイドを掲載しています。SSL LabsでももちろんAランクになります。
その他、平文HTTP/1.1とのベンチマーク比較、Cipher suiteの解読方法など、見本には載せきれない内容が詰まってます。会場でお待ちしています！
タイトルは「Get Started with HTTP/2」です。表紙はきのとなおとさんに描いていただきました。
Linux Kernel Updates 2015.08と2014.12も持っていきます。会場でお待ちしています！
コミケが終わったら出せてなかった過去のLinux Kernel Updatesの分も含めてKindle版出します。
今日のニュースに次のようなものがありました。
無線ＬＡＮのメール丸見え 成田、関西、神戸の３空港
成田、関西、神戸の３空港が提供する無料の公衆無線ＬＡＮサービスでインターネットを利用した場合、送信したメールの宛先や中身、閲覧中のウェブサイトのＵＲＬを他人がのぞき見できる状態になることが２６日、神戸大大学院の森井昌克教授（情報通信工学）の実地調査で確認された。
無線ＬＡＮを暗号化すればのぞき見を防止できるが、パスワードの入力などが必要となり、３空港は利便性を考慮し暗号化していないという。
無線ＬＡＮのメール丸見え 成田、関西、神戸の３空港 - 47NEWS（よんななニュース）より引用
「無線LANを暗号化すればのぞき見を防止できる」というのは、誤解です。
無線LANの暗号化方式には複数あり、WEP, TKIP, CCMP(AES)の3種類が使われています。これらは暗号化の方式を定めただけで、鍵交換(パスフレーズの認証)は別の規格です。それぞれ WEP, WPA2-Personal(PSK), WPA2-Enterprise の3種類です。WEPだけは暗号化方式、鍵交換の両方を定めていて、WPA2は暗号化と鍵交換の方式を組み合わせて使うことができます。
| WEP | WPA2-Personal(PSK) | WPA2-Enterprise | |
| WEP | 危険 | - | - |
| TKIP | - | 危険 | 危険 |
| CCMP(AES) | - | 事前共有鍵を持っている人は、他人の通信内容を見れる | 一人一人認証鍵が違うので、他人の通信を見れない |
まず、WEP、WPA、TKIPを使うWPA2は危険なので使わないようにしましょう。これらには脆弱性が見つかっています。使っていいのはWPA2-CCMP(AES)の組み合わせのみです。表には掲載していませんが、WPAもWPA2と同様に組み合わせを選ぶことができますが、WPA2に置き換わっているので使わないようにしましょう。
家庭や無線LANのホットスポットで利用されるのは WPA2-Personal と言われるタイプで、事前にPSK(Pre-shared key, 事前共有鍵)を決めてパスワードにします。これはこの事前共有鍵を知らない人には内容は読まれないのですが、鍵を持っている人には内容が見えます。つまり、不特定多数で同じパスワード(PSK)を使い回すような環境では、WPA2-Personalで保護されていたとしても、パスワード(PSK)を知っている人には内容が見えてしまいます。
WPA2-Personalでは、接続時にPSKを元に暗号化に使うセッション鍵を決定します。このセッション鍵は無線LANの端末ごとに割り当てられ、お互いに知ることはできません。ところが、PSKと、接続時の鍵交換の情報があればセッション鍵が計算されてしまいます。鍵交換は平文で行われます。そして、無線LANでは「切断する」というパケットは暗号化されないので、第三者が他人になりすまして「切断する」というパケットを送れてしまいます。端末は切断されたことを知ると再接続しようとしますが、そのときには鍵交換の内容を盗み見られるので、セッション鍵を入手され、その後の通信は盗み放題となってしまいます。
ということで、無線LANの暗号化は「パスワードを知らない人からは守られるけど、パスワードを知っている人には他人であっても通信内容が見えている」というものです。
WPA2-Enterpriseでは、一人一人に違う鍵(パスワードや証明書)を割り当てるので、このような問題は起こりません。
追記: WPA2-Personalは、家庭内のように全員が信頼できる環境で安全な無線LANを構築するには十分なもので、有線LANに近い水準のセキュリティが実現できます。不特定多数がPSKを知っている環境では意味が無いよ、ということです。
Linuxのネットワークパラメータの一つに、net.core.somaxconnというのがあります。これはlisten(2)の第二引数backlogの上限値となっています。このsomaxconnは一見intに見えますが、実はunsigned shortの範囲の数値しか受け付けません。それを超える数値を入れると黙って切り捨てられます。つまり
と同じような動作を内部的にします。なので、この値は絶対に0～65535の範囲を超えてはいけません。以下、詳しい説明です。
おことわり: この仕様はLinux 3.11以降変更されており、範囲外の数値を設定できないようになっています。ここに書いてある内容が再現するのは、Linux 3.10以前の古いカーネルのみです。
まずsysctlの定義ですが
static struct ctl_table netns_core_table[] = {
{
.procname = "somaxconn",
.data = &init_net.core.sysctl_somaxconn,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec
},
struct netns_core {
/* core sysctls */
struct ctl_table_header *sysctl_hdr;
int sysctl_somaxconn;
struct prot_inuse __percpu *inuse;
};
以上のようにしっかりと"int"と書かれています。
さて、この値がどう使われているかというと、listen(2)でbacklogの最大値として利用された後inet_listenに引き渡されます。
int inet_listen(struct socket *sock, int backlog)
{
struct sock *sk = sock->sk;
unsigned char old_state;
int err;
(途中省略)
sk->sk_max_ack_backlog = backlog;
err = 0;
out:
release_sock(sk);
return err;
}
という感じで、socket.sk_max_ack_backlogに渡されています。この値の宣言を見ると
struct sock {
(途中省略)
unsigned short sk_ack_backlog;
unsigned short sk_max_ack_backlog;
unsigned shortとなっています。intをunsigned shortにそのまま代入してますね。なので、一番上に書いたようにオーバーフローします。黙ってオーバーフローします。net.core.somaxconnの値は正しくセットされるのが余計にたちが悪いですね。
ところでbacklog=0ってなんでしょうか？全くacceptできないように思えますが、実はキューの長さは
static inline bool sk_acceptq_is_full(const struct sock *sk)
{
return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
}
という感じで不等号で比較されているので、最低一つはaccept待ちのソケットが使用できます。
これはTCPのコードですが、unix domain socketでも似たような事象が起こります。
あと何年かすれば役に立たなくなる感じの知識ではありますが、今のところsomaxconnは16bitです。
sshでログインする際にローカルホストで使用する鍵は.ssh/id_rsaですが、この時このid_rsaと異なる鍵の公開鍵がid_rsa.pubとして置かれていると、そちらを参照してしまいログインできないという状況が発生しました。
再現手順は以下のとおり。
これで正しい秘密鍵を見ているはずなのに、ログインできなくなります。デバッグ出力には
debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/yuryu/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Trying private key: /home/yuryu/.ssh/id_dsa debug1: Trying private key: /home/yuryu/.ssh/id_ecdsa debug1: Next authentication method: password
と出力されています。この「Offering RSA public key」が、.pubを見ているという出力です。 もし.pubが存在しないと
debug1: Next authentication method: publickey debug1: Trying private key: /home/yuryu/.ssh/id_rsa debug1: read PEM private key done: type RSA
といったログ出力になります。
この公開鍵がなぜ使われているのかまでは調べていませんが、おそらく公開鍵の計算をサボるために、公開鍵がすでに存在したら読み込むといった感じで使っているのではないかと思います。
ぐぐってもパーミッションの設定を間違えているケースばかりで、このハマり方をしている人はいませんでした。無駄に2時間ぐらい悩みました...
iPhone 5s/5c が発表されましたね！
まだ各キャリアでどの周波数をサポートするという話がないので、iPhone のスペック表から突き合わせてみました。また、ドコモはどのモデルを発売するか公式情報がありませんが、おそらくA1533(GSM)だと仮定して話を進めますドコモもA1453でした。
各キャリアの周波数割り当てはWikipediaのLTE記事他を参考にしました。
| Band | Docomo | KDDI | Softbank |
|---|---|---|---|
| 1 (2100MHz) | 10MHz*2 | 20MHz*2 | 10MHz*2 |
| 3 (1800MHz) | 20MHz*2(東名阪) | 10MHz*2(emobile) | |
| 8 (900MHz) | 10MHz*2(2014年夏以降) | ||
| 18 (800MHz) | 10MHz*2 | ||
| 19 (800MHz) | 10MHz*2 |
Docomo, KDDI が保有する 1.5GHz帯には対応しません。
以上からまとめてみますと...
ドコモは東名阪バンドの1800MHz帯が使用可能なので、特に周波数の逼迫する首都圏で高速通信が可能と推測。 800MHz帯はサービス開始間もないのでエリアはまだ狭そう。
KDDIは田中社長ご自慢の800MHz帯に対応したので、エリアの問題はおそらくクリアし、3キャリアで一番広くなりそう。ただし800MHz帯+1500MHz帯+2100MHz帯全体のエリアは公表しているけれど、800MHz帯+2100MHz帯のみのエリアは公表されていない。2100MHz帯の20MHzはまだ数局という感じなので、実質15MHzでのサービス。2100MHz帯での品質は皆様ご存知の通り。 VoLTE はまだ使えないので通話中のデータ通信はできないまま。
ソフトバンクは相変わらず厳しい。イーモバイルの1800MHz帯が今後も使えるとしても相変わらず逼迫したまま。特にプラチナバンドと呼ばれる900MHz帯でのサービスが来年夏以降なのが厳しい。2100MHz帯のみの比較ではKDDIよりも良いようですが、800MHz帯が加わった時にどうなるかは未知数。
現在KDDIでiPhone 5を使っているユーザーは、iPhone 5sに乗り換えると使える周波数が増えます。現在ソフトバンクでiPhone 5を使っているユーザーは、iPhone 5sに乗り換えても使える周波数は今のところ変わりません。
カタログスペックのみの比較なので、実際の通信速度や品質にはもちろんキャリアの基地局整備状況によります。ドコモは特にiPhone初めてなので、そこらへんも含めて注目です。
10.234.130.1 host1301 10.234.130.2 host1302 10.234.130.3 host1303
| #hosts | hosts | dnsmasq |
|---|---|---|
| 2 | 1.516 | 4.8068 |
| 102 | 2.6598 | 4.9224 |
| 252 | 4.4474 | 4.9286 |
| 1002 | 13.2376 | 4.831 |
$ ./a.out 100000 host127183 Resolved 100000 times. Elapsed time = 0.740 seconds, 0.007 us per host.
DNSSEC は本来ルートゾーンから順番に証明していき、最後にホストのレコードを確認するという仕組みになっています。ところが、大人の事情で上位ゾーンに鍵を登録できない人のために、DNSSEC Look-aside Verification (DLV, RFC5074) という仕組みがあります。
DLV は、以下のような仕組みで動きます。
この dlv.isc.org を DLV に使って良いというのは別途設定し、 trust anchor をリゾルバに登録しておきます。
これだけ見ると、一見便利そうなのですが、私は使うべきではないと思います。3つほど理由をあげます。
本来の認証の連鎖が途切れた時に DLV が引かれますので、単純に2倍以上遅くなります。さらに、日本からだと dlv.isc.org の NS が遠くにあるので、かなり待たされます。これは単純にレスポンスの悪化につながります。
グラフは DNSSEC on, DNSSEC on + DLV有効, DNSSEC オフでそれぞれ名前を引いてみた場合の、レスポンスタイムになります(5回平均)。 jprs.jp は DNSSEC の鍵が正しく登録されているドメイン、yuryu.jp はされていないドメインになります。 計測は unbound 1.4.18 を用い、毎回の計測の前にリスタートしてキャッシュをクリアしています。また、実際のクエリタイムに近づけるために、 .jp 及び dlv.isc.org の SOA をクエリして、上位ゾーン情報はキャッシュ済みの状態です。
jprs.jp は上位ゾーンからの連鎖で正しく証明ができるので、 DLV のオンオフにかかわらずクエリタイムは一定です。ところが、 yuryu.jp のように証明できないドメインだと、 DLV のクエリが追加で走るのでとても遅くなります。 DNSSEC の on/off よりも重大なパフォーマンスの低下をもたらします。
DNSSEC がきちんと普及すれば問題ないのですが、DLV は「普及過程のためのworkaround」という位置づけです。ほとんどのドメインが署名されていない現状で、このパフォーマンス低下は許容できません。
ルートゾーンの KSK は定期的に更新される、少なくとも5年に1度は更新されることになっています。また、 IANA によって鍵更新ポリシーや記録がきちんとメンテされています。 DLV のキーはこれと同等の基準では運用されていません。一応ポリシーは書かれてあるんですが、そこには「年1回 KSK 更新します」とあります。ところが実際には 2008年から鍵は更新されていません。
BIND は DLV の trust anchor も含めて自動更新に対応しています。ところが、 unbound の場合はルートゾーンの trust anchor については自動更新に対応しているものの、 DLV trust anchor は自動更新しません。
もし KSK が更新されたとなると、 trust anchor も含めてアップデートしなければなりませんが、これが人力になってしまいます。放置すると証明できないゾーンが生まれることになります。
そして、別の記事にも書きましたが、リゾルバによって挙動が異なる場合があります。利用者も少ないので、枯れているとは言いがたい状況です。
以上3つの理由により、少なくとも現状は DLV を使うのは望ましくないと思います。 ルートゾーンが署名され、多くの ccTLD も署名されつつありますから、無理に DLV を用いて DNSSEC を導入するのではなく、上位ゾーンの対応を待つべきでしょう。
大人の事情で最近 DNSSEC にはまってます。 unbound も BIND も、新し目のバージョンは標準対応しているし、標準で有効になっているのですが、どうも BIND で DLV を使おうとすると、うまく動きませんでした。
環境は以下のとおりです。
DNSSEC には、自分の上位ゾーンが署名に対応していない場合に備えて、 DLV(DNS Look-aside Verification )という仕組みがあります。おおまかに言うと、本来はルートゾーンから順繰りにたどっていってドメインの認証をするのですが、その代わりに ドメイン名.dlv.isc.org を問い合わせて、 DS レコードの代わりに DLV レコードを引っ張ってきてドメインの認証をします。これが BIND9 でうまく動きません。
テストには DNS-OARC から提供されているテストレコード を使用しました。
まず unbound 1.4.18 での想定通りの動きです。
~/bind/9.9.1 $ bin/dig -p 1418 @localhost +dnssec a.nsec.dlvtest.dns-oarc.net txt ; <<>> DiG 9.9.1-P2 <<>> -p 1418 @localhost +dnssec a.nsec.dlvtest.dns-oarc.net txt ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58334 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;a.nsec.dlvtest.dns-oarc.net. IN TXT ;; ANSWER SECTION: a.nsec.dlvtest.dns-oarc.net. 917 IN TXT "A is for AXFR" a.nsec.dlvtest.dns-oarc.net. 917 IN RRSIG TXT 5 5 3600 20310611060557 20110616060557 54345 nsec.dlvtest.dns-oarc.net. c4CXn8ejvaiexLq5FuQv6bFrfRlUGF//2jew7rGqICUZAj0lEdLkxu6Y H47SrIjYIb0xwzO2QMnVcLKAvVfuozQ8bq/mgn0x7RHQ32Bh0ZS55scw Wxji8iCHxcr5rzxtkMcAZzjx28A/ir+jKizfF8RCEv3MtPqd7+Y71YCk 0Jw= ;; Query time: 0 msec ;; SERVER: 127.0.0.1#1418(127.0.0.1) ;; WHEN: Sun Sep 2 00:39:06 2012 ;; MSG SIZE rcvd: 267
きちんと引けてますね。 flags に "ad" が入っていれば DNSSEC により認証ができたという意味です。
さて次は BIND9 です。
~/bind/9.9.1 $ bin/dig -p 9912 @localhost +dnssec a.nsec.dlvtest.dns-oarc.net txt ; <<>> DiG 9.9.1-P2 <<>> -p 9912 @localhost +dnssec a.nsec.dlvtest.dns-oarc.net txt ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21002 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;a.nsec.dlvtest.dns-oarc.net. IN TXT ;; Query time: 1690 msec ;; SERVER: 127.0.0.1#9912(127.0.0.1) ;; WHEN: Sun Sep 2 00:38:28 2012 ;; MSG SIZE rcvd: 56
待たされた挙句 SERVFAIL になってしまいました。ところが、 BIND を再起動した上で次の手順を踏むと、引けるようになります。
~/bind/9.9.1 $ bin/dig -p 9912 @localhost +dnssec nsec.dlvtest.dns-oarc.net any ; <<>> DiG 9.9.1-P2 <<>> -p 9912 @localhost +dnssec nsec.dlvtest.dns-oarc.net any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45581 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;nsec.dlvtest.dns-oarc.net. IN ANY ;; ANSWER SECTION: nsec.dlvtest.dns-oarc.net. 3600 IN RRSIG DNSKEY 5 4 3600 20310611060557 20110616060557 23716 nsec.dlvtest.dns-oarc.net. EIBG75iE6v53oOOI1PfWvrvMi0qHYigxrtJMTdMdFUHzZrh71+hZSM88 ILw6UUvotyb9YUH1opjB4iA9Ks8ZBqaSn+AwzbP6pNfMRFiNVlYoLBLq y6cERjpb/6jUr/dxGq/57VThi8BYjiHF1aYv3vgSLhCvfvI2tvnfgxlN YeL286GDojf9bSaQrrHOcWdqivTibiBarxNrAfxHGE3MIpX1eZUGsXL4 aHrMv7n7juy86mfm+lZg7y4JfT32IADygbdTWQQYF8P7TYzPZof38D6s cYnvYCx+m770Uj9Z3z7eTHkk5AgvTDcorNVp/xPFPqGaJ9iwReMoeE9N wngNtA== nsec.dlvtest.dns-oarc.net. 3600 IN RRSIG DNSKEY 5 4 3600 20310611060557 20110616060557 54345 nsec.dlvtest.dns-oarc.net. UiNDgsQdHdb2Tni4d6ebGajNwmxTFk+6gvil9M4/stimqOnL2RQqX6Kb IASX+8z4AzYVQFsb7OCyGugmsBc5ukjTR4at2j3sp6Xjk4r7J5DMAADY ZHTgBua2AOySy/DdVTfTdRK4YbQcHLggw3Nr8r64daD14SFUAL2nGOSk cNM= nsec.dlvtest.dns-oarc.net. 3600 IN DNSKEY 257 3 5 AwEAAejxNtUB1RBO7DZP1NtC2V46LWt5r2XM5ykywFYmeG6LCmn6oafG 27djNKFyCHWAmNmZXaQXg60YAGT8XQdMrmvidPCQqrB7w2ZO0w/rEqVp 74KT46yuTKGBOUFJ4nWLw77mvxG4v8HEhvZUyYspLvBSt/qi72S66SP2 njyymaQbZAT0ZP4NsjO6L8UugDwGJuRdd1qXyOLf9blogviFjdFe7Y8a TV071VCSj7/iTg0sqPlZvy5kZB1Sz+yE/xrvqDA7WIMDpr5nahWPbAzm NigLZFy1+PKF4U4ZTp3t9+kPqWpSBE0NpfaGY79b96JRMRHtGM/+TqWj 79jRZyUE1oU= nsec.dlvtest.dns-oarc.net. 3600 IN DNSKEY 256 3 5 AwEAAfGatB0iI+BHO7JStuOFATy2iRyVDnmdCsdDTgtINKtcIqKWbw7w xjQ3dXhUSrjVVfEHJIScxiyjBJ0u1mG4FhY0zGusenn5R6RuhTAjZ/Ow wvp+1X1orWdwUVncYS3a+sGfyr4XBbFQSSB0HLSZxzskPbNQ1NR8fX2L iy8V89Zv nsec.dlvtest.dns-oarc.net. 3600 IN DNSKEY 256 3 5 AwEAAamEbJrkD6whOxQH7y+JhH5AH5kwjXfG43p9SJ/j0d+58tcK2cuQ 4rpXGD0KybG8rte7F0ja0Dlv9PFhL2UqKrdtk43ZLwZjAnotcTODqDog D8EHEOTwt2LMy9FGTf40IgoUQfG3PxcJsAkNOswqw41vu5Te4mzzDhrh AQWRldL5 ;; Query time: 1578 msec ;; SERVER: 127.0.0.1#9912(127.0.0.1) ;; WHEN: Sun Sep 2 00:37:11 2012 ;; MSG SIZE rcvd: 1124 ~/bind/9.9.1 $ bin/dig -p 9912 @localhost +dnssec a.nsec.dlvtest.dns-oarc.net txt ; <<>> DiG 9.9.1-P2 <<>> -p 9912 @localhost +dnssec a.nsec.dlvtest.dns-oarc.net txt ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25080 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;a.nsec.dlvtest.dns-oarc.net. IN TXT ;; ANSWER SECTION: a.nsec.dlvtest.dns-oarc.net. 3600 IN TXT "A is for AXFR" a.nsec.dlvtest.dns-oarc.net. 3600 IN RRSIG TXT 5 5 3600 20310611060557 20110616060557 54345 nsec.dlvtest.dns-oarc.net. c4CXn8ejvaiexLq5FuQv6bFrfRlUGF//2jew7rGqICUZAj0lEdLkxu6Y H47SrIjYIb0xwzO2QMnVcLKAvVfuozQ8bq/mgn0x7RHQ32Bh0ZS55scw Wxji8iCHxcr5rzxtkMcAZzjx28A/ir+jKizfF8RCEv3MtPqd7+Y71YCk 0Jw= ;; AUTHORITY SECTION: nsec.dlvtest.dns-oarc.net. 3600 IN NS ns.dns-oarc.net. nsec.dlvtest.dns-oarc.net. 3600 IN NS sns-pb.isc.org. nsec.dlvtest.dns-oarc.net. 3600 IN RRSIG NS 5 4 3600 20310611060557 20110616060557 54345 nsec.dlvtest.dns-oarc.net. E0FInFhHCmZ/C6jh8+QZ0HP5V4GYXBLvEbSiCYTVJgsvRXIbBdzAG4MN jUgMFnrSjyCKOGSelrD4whnbOExD6MdtY0Vwq6xMt1XIpjRc6JoG8ja6 DL5qwlqb5NtRQCV2Z2FDT6QuXtyr6ODh7amj+YSWCOW5cS25DYmBcsnC 2UU= ;; ADDITIONAL SECTION: ns.dns-oarc.net. 172791 IN A 149.20.58.65 ;; Query time: 118 msec ;; SERVER: 127.0.0.1#9912(127.0.0.1) ;; WHEN: Sun Sep 2 00:37:18 2012 ;; MSG SIZE rcvd: 513
"ad" も立っていて、正常に認証できていると示されています。ログはこんな感じです。
client 127.0.0.1#39784 (a.nsec.dlvtest.dns-oarc.net): query: a.nsec.dlvtest.dns-oarc.net IN TXT +ED (127.0.0.1) validating @0x7f8a5802a9c0: a.nsec.dlvtest.dns-oarc.net TXT: no valid signature found validating @0x7f8a5802a9c0: a.nsec.dlvtest.dns-oarc.net TXT: no valid signature found validating @0x7f8a58042860: nsec.dlvtest.dns-oarc.net SOA: no valid signature found validating @0x7f8a58042860: nsec.dlvtest.dns-oarc.net SOA: no valid signature found validating @0x7f8a58042860: a.nsec.dlvtest.dns-oarc.net NSEC: no valid signature found validating @0x7f8a58042860: a.nsec.dlvtest.dns-oarc.net NSEC: no valid signature found validating @0x7f8a58042860: nsec.dlvtest.dns-oarc.net SOA: no valid signature found validating @0x7f8a58042860: nsec.dlvtest.dns-oarc.net SOA: no valid signature found validating @0x7f8a58042860: a.nsec.dlvtest.dns-oarc.net NSEC: no valid signature found validating @0x7f8a58042860: a.nsec.dlvtest.dns-oarc.net NSEC: no valid signature found error (no valid RRSIG) resolving 'a.nsec.dlvtest.dns-oarc.net/DS/IN': 192.5.4.1#53 validating @0x7f8a60056310: nsec.dlvtest.dns-oarc.net SOA: no valid signature found validating @0x7f8a60056310: nsec.dlvtest.dns-oarc.net SOA: no valid signature found validating @0x7f8a60054670: a.nsec.dlvtest.dns-oarc.net NSEC: no valid signature found validating @0x7f8a60054670: a.nsec.dlvtest.dns-oarc.net NSEC: no valid signature found validating @0x7f8a60054670: nsec.dlvtest.dns-oarc.net SOA: no valid signature found validating @0x7f8a60054670: nsec.dlvtest.dns-oarc.net SOA: no valid signature found validating @0x7f8a60054670: a.nsec.dlvtest.dns-oarc.net NSEC: no valid signature found validating @0x7f8a60054670: a.nsec.dlvtest.dns-oarc.net NSEC: no valid signature found error (no valid RRSIG) resolving 'a.nsec.dlvtest.dns-oarc.net/DS/IN': 149.20.58.65#53 error (no valid DS) resolving 'a.nsec.dlvtest.dns-oarc.net/TXT/IN': 149.20.58.65#53 validating @0x7f8a580337d0: a.nsec.dlvtest.dns-oarc.net TXT: no valid signature found validating @0x7f8a580337d0: a.nsec.dlvtest.dns-oarc.net TXT: no valid signature found validating @0x7f8a580337d0: a.nsec.dlvtest.dns-oarc.net TXT: bad cache hit (a.nsec.dlvtest.dns-oarc.net/DS) error (broken trust chain) resolving 'a.nsec.dlvtest.dns-oarc.net/TXT/IN': 192.5.4.1#53
もう一つのレコード、 a.nsec3.dlvtest.dns-oarc.net は両方とも正常に引くことができます。
BIND の設定ファイルには
dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;
と書いてあります。
正直お手上げです... BIND の挙動がおかしいように思えるんですが、どうなんでしょう。検索してもよくわかりませんでした。
.png)