トップ 追記

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


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

2020-07-04 遠隔授業用に

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

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

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

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

DNS mechanism

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 浸透って何?

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

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


2019-12-06 黒塗りのDNS -論文編-

論文「共用DNS権威サーバの脆弱性」を発表

12/4 に那覇市の沖縄県立博物館・美術館で行われた情報処理学会第87回コンピュータセキュリティ研究発表会 (CSEC87) で、論文「共用DNS権威サーバの脆弱性」を発表してきました。

これは 4/23 の ssmjp での「黒塗りのDNS (萎縮編) ~共用サービスの闇~」および 9/7 の DNS 温泉 6 の夜の部の「黒塗りの DNS (あからさま編)」で語らせて頂いた話を注意喚起のために論文にまとめたものです。

会場では以下のような質疑がありました。(要約)

  1. RFC を変えさせるよう動いてはどうか?
    私はやらない。JPRS などが動いてくれるとよいかと思う。
  2. DoT, DoH は関係ないですね?
    ない。ちなみに DNSSEC も攻撃可能。
  3. 脆弱性のある事業者には連絡したか?
    メールサーバの脆弱性を確認した事業者に対しては JPCERT/CC に報告した。(動いてくれているはず)
    Lame delegation の乗っ取りに脆弱な Route53 についても AWS は問題を認識している。(ゾーンを削除する際に警告がでる / 不十分だがさらなる対応もとられるだろうと認識している)
  4. 脆弱な事業者はどれくらいあるのか?
    たくさんあるだろうが調査しきれない。調べるには金がかかる。大多数が対応するまで利用者を危険に晒しながら注意喚起しないのは問題ではと思う。公的団体は責任ある開示という立場から及び腰であるが隠し通せる問題ではないし、利用者に注意喚起しつつ対策を促す必要があると思う。  

今回の発表で議論したかったのはまさにこの 3, 4 番めの話でした。対策や公的な注意喚起が遅々として進まない状況において微力ながらも注意喚起を行うとともに、隠せない問題や解決が進みそうもない問題にまで責任ある開示 (responsible disclosure) にこだわる方面への問題提起として、この論文を書き、発表を行わせて頂きました。もし議論が進むならうれしく思います。

なお同日、私のゼミの M1 の太田くんも "A survey on the status of measures against IP fragmentation attacks on DNS" (第一フラグメント便乗攻撃への対策状況の調査) を発表してくれました。近いうちに彼からも資料の公開があると思います。(CSEC非会員は有料ですがこちらではすでに公開されています)

私の発表スライドはこちら。論文はこちら (あるいは IPSJ のこちら)。

ところで沖縄はやはりとても良いところですね。飛行機嫌いを押して行ってきてよかったです。写真は発表会場、情報交換会会場のお姉さん、帰りに寄った屋台村。てびち、山羊、ぐるくん、沖縄そば、そして白百合 (泡盛) 等々たっぷり沖縄を堪能してきました。(しかし飛行機は嫌い/もう乗りたくない)

なお本記事は「DNS温泉 Advent Calendar 2019」への参加記事 (5日目)です。


最近の日記

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|

リンク

Copyright by T.Suzuki