DNS Summer Day 2022, 2022年6月24日

ドメイン名をまもるということ
木村泰司

1

概要
• なりすましメールやWebのサーバが本物かどうかを判別するためにユーザが目にするドメイン名。その正しさは、よくよく注意して確認されるべきと云われるわりに、まぎらわしいドメイン名を使うことや、正しいDNS応答かどうかをチェックする仕組みを導入しないことに対して、私たちは寛容になりすぎていないでしょうか。
• DNSは、アドレスシステムが、コンピューターではなく人にとって分かりやすく運用しやすいものであるために作られたはずです。分かりにくさ故にユーザが騙されやすくなってしまう環境を変えていくために、私たちができることを、この夏、みなさまに問いかけます。
2

フィッシング対策協議会 Council of Anti-Phishing Japan | ニュース | 緊急情報
https://www.antiphishing.jp/news/alert/3フィッシング対策協議会 月次レポートよりフィッシング対策協議会 Council of Anti-Phishing Japan | 報告書類 |月次報告書 | 2022/05 フィッシング報告状況
https://www.antiphishing.jp/report/monthly/202205.html

4

紛らわしいドメイン名• 他社のドメイン名だが本来のサイトらしいドメイン名• submit.example.com• 前後に文字列を加えたり入れ替えたりしたドメイン名• finance.example.com、www.example.finance.**• “一見、正規ドメインと見間違えるようなドメイン名”✓mとrn → micro > rnicro✓wwとv → will > vvill✓tとf → soft > soff：
(迷惑メール白書2021より)

5

わかりやすいドメイン名を使ったとしても...
• MyEtherWallet.comの事例 - 偽のサーバにアクセスさせて不正送金のスクリプトを実行させ、総額15万ドル（約1630万円）相当が不正送金される。
手法• BGP経路(/23など)を/24で経路広告• DNS問い合わせに対して偽のDNSサーバが偽のAレコードを応答• サーバ証明書は自己署名証明書（本来はEV SSL証明書）(情報源)• MyEtherWallet、DNSサーバーにハッキング、15万ドル分のETH盗難か
https://jp.cointelegraph.com/news/myetherwallet-warns-that-a-couple-of-its-dns-servers-have-been-hacked• AWS DNS network hijack turns MyEtherWallet into ThievesEtherWallet - The Register, 2018/4/24
https://www.theregister.co.uk/2018/04/24/myetherwallet_dns_hijack/6

対策技術(DNSSEC送信メールドメイン認証技術, Webサーバ認証技術)のカバー範囲と特徴 (1/2)
1.メール送信ドメイン認証技術の結果

2.メールアドレスのドメイン名

4.Webサイトのドメイン名

3.DNSSECの効果

枠Y-1

枠Y-2

5.Webサーバ認証技術の結果

枠Z• 配送される。
• (正しさの表示) 安心マーク, BIMI...

• 正しいドメイン名• 検証に成功しが表示されている。→
Webサイトに接→続できる。

B.メールアドレス
ドメイン名が紛らわしい＋サイトのURLが紛らわしい• 配送される。

• メールのドメイン• 検証に成功し名が紛らわしく、Webサイトに接→→正しいかどうかの続できる。
判断がつきにくい。

• 正しいサイト• サーバ認証に成功すかどうかの判る。
→→
断がつきにくい。

C.メールサーバの詐称＋サイトのURLが紛らわしい• “reject” → 配送されない。
• “none” → 配送される。

• 検証に成功し• (配送された場合)
正しいドメイン名
Webサイトに接→→が表示されている。
続できる。

• 正しいサイト• サーバ認証に成功すかどうかの判る。
→→断がつきにくい。

D.メールサーバの詐称＋サイトのドメイン名乗っ取り• “reject” → 配送されない。
• “none” → 配送される。

• 検証に失敗し、• (配送された場合)• 接続できない。
• 接続できない。
正しいドメイン名
Webサイトに接→→→→が表示されている。
続できない。

A.フィッシングではないケース• 正しいドメイ• サーバ認証に成功すン名が表示さ →る。
→れている。

枠X
フィッシングレポート 2022, フィッシング対策協議会 技術・制度検討ワーキンググループ より
https://www.antiphishing.jp/report/phishing_report_2022.pdf

7

送信ドメイン認証技術と DNSSEC が導入されるとエンドユーザーの体験はどう変わるのか• DMARC の検証ポリシーを reject にすると、ユーザーは紛らわしいドメイン名を判別しなくて良くなる（表中の枠 X）。ただし、DMARC の検証ポリシーが none であるとメールサーバーの管理者が検知できるだけで、ユーザーに起きることは送信ドメイン認証技術の導入前と変わらない。
• メールアドレスに紛らわしいドメイン名が使われると、ユーザーがフィッシングかどうかを判断するにはドメイン名が正しいかどうかを判別する必要がある（枠 Y1）。
Web サイトのドメイン名についても同様であ る（枠 Y2）。ユーザーにとってドメイン名が紛らわしいということ自体の判定は難しい。
• DNSSEC の検証で失敗し接続できなくなる挙動は、フィッシングサイト へのアクセスを抑止するという意味ではユーザーを保護する。しかしアクセスできない理由が分からなければユーザーは何とかしてアクセス しようとしてしまうかも知れない。これについては改善の方向性があ る。IETF の RFC8914 に記載されている Extended DNS Error（拡張 DNS エラー）や、提案中の DNS Access Denied Error Page（DNS アクセス禁止に関するエラーページ）である。これらのエラーを受け た Web ブラウザーの表示がどうなっていくのかが注目される。
フィッシングレポート 2022, フィッシング対策協議会 技術・制度検討ワーキンググループ より
https://www.antiphishing.jp/report/phishing_report_2022.pdf

8

みなさまに問いかけます。
2022年夏9

1.「わかりやすいドメイン名を使おう」
について可能わかる。

できるのか部分的に無理

“a”

“b”
“c”

コンセプトは...

人の世だから...
意味不明。

なぜなら...

わかりやすいって何？

“d”
“e”

ドメイン名って大事？

“f”
10Sli.do #1142811

11

2. 技術導入にある”敷居”にどう向き合うか- DNSSEC署名 a. みんなが署名しないことにする。
→ (例) I-Dを書く。
b. 開始操作と運用を簡単にする。
→ (例) プロにおまかせする。
c. SERV FAILが起きないような策を練る。
→ (例)監視と運用
d. エラーがユーザ側に伝わるようにする。
→ (例)RFC化と実装
e. その他→ [ご記入ください]12

Sli.do #1142811

13

3. 技術導入にある”敷居”にどう向き合うか- DNSSEC検証 a. みんなが検証しないようにする。
→ パブリックキャッシュサーバは...
b. 運用を簡単にする。
→ (例) プロにおまかせする。
c. 既に始めているところに教えを乞う。
→ 問い合わせられたレコード中、署名されている割合は...
d. 実験的に始めて起きる問題を観測する。
→ どのような問題が...?
e. その他→ [ご記入ください]14

Sli.do #1142811

15おわり16