SlideShare a Scribd company logo
1 of 22
Download to read offline
世界と日本のDNSSEC
やまぐち@iij
はじめに
• なんとなく気になったので、DNSSEC の普及状況を調べてみた
• 権威サーバ(署名側)
• ほかにも調べてる人はたくさんいるので新規性はない
• 他人の調査結果を探してくるより、自分でやったほうが早い、という程度
• 過去の調査事例:
https://dnsops.jp/event/20140627/SummerDays2014ohmoto.pdf
• ほんとは定期的に観測して推移を見られればいいんだろうけど、
やってません
• 発作的な思いつきをそのまま実行に移しただけなので
• 次回未定
調査対象
• Alexa Top 1M にリストされている100万ドメイン
• .arpa は含まない
• Top 1M ランク外のドメインに対しては何の調査もしていない
• DS レコードの登録状況を調査
• DNSKEY レコードや、正しく検証できるかどうかはまったく見ていない
• 2017/10/29 付のリストに含まれるドメインの DS を 10/30-31 に調査
結果
• 署名ドメイン数
17247/100万 = 1.7%
• Q. .jp は 1.7% より高い? 低い?
署名あり
17247
署名なし
982753
DNSSEC対応ドメイン
署名あり 署名なし
ランク上位の署名ドメイン
67 paypal.com
82 mozilla.org
138 nih.gov
148 avito.ru
195 4chan.org
203 abs-cbn.com
318 xfinity.com
332 gmx.net
335 web.de
342 canva.com
• 2.5%/1000 → 2.4%/1万 → 1.9%/10万 → 1.7%/100万
• 上位ほど署名割合も高くなる傾向(といっても微々たるもの…)
ランクによる署名割合
署名あり
25
署名なし
975
1-1000位
署名あり
244
署名なし
9756
1-10000位
署名あり
1926
署名なし
98074
1-100000位
署名あり
17247
署名なし
982753
1-1000000位
TLD ごとの署名割合(1)
• Alexa Top 1M に出現する全 TLD のう
ち、ひとつでも署名ドメインが存在し
た TLD 187/755 = 25%
• ある TLD に署名ドメインがなかったか
らといって、DNSSEC 非対応 TLD とは
限らないことに注意
• TLD としては対応していても、署名済み
ドメインが Top 1M ランク入りしなかった
だけの可能性
署名ドメインが
存在したTLD
187
署名ドメインが存
在しなかったTLD
568
TLD ごとの署名割合(2)
• レガシー gTLD (com, net, org, gov, edu, mil, int)
TLD ドメイン数 署名ドメイン数 割合
.com 476049 4638 0.97%
.net 49923 618 1.2%
.org 47070 571 1.2%
.gov 1073 405 38%
.edu 3278 87 2.7%
.mil 52 50 96%
.int 106 0 0%
合計 577551 6369 1.1%
TLD ごとの署名割合(3)
• ICANN 設立から2010年ぐらいまでの gTLD + sTLD
TLD ドメイン数 署名ドメイン 割合 TLD ドメイン数 署名ドメイン 割合
.aero 134 0 0% .museum 19 1 5.3%
.asia 423 0 0% .name 243 1 0.41%
.biz 2870 16 0.56% .post 7 7 100%
.cat 455 5 1.1% .pro 1320 3 0.23%
.coop 120 0 0% .tel 6 0 0%
.info 9926 86 0.87% .travel 177 0 0%
.jobs 152 0 0% .xxx 483 1 0.21%
.mobi 686 0 0% 合計 17021 120 0.71%
TLD ごとの署名割合(4)
• それ以外の gTLD (いわゆる新 gTLD + IDN TLD)
10ドメイン以上ランク入りしている TLD のうち、割合上位10TLD
合計は10ドメイン未満のTLDを含む
• 新gTLD総数 494、うちひとつでも署名ドメインが存在したTLD 95(19%)
TLD ドメイン数 署名ドメイン 割合 TLD ドメイン数 署名ドメイン 割合
.bank 41 41 100% .photo 21 3 14%
.ovh 81 39 48% .ist 10 1 10%
.google 10 3 30% .nrw 11 1 9.1%
.bzh 19 4 21% .brussels 11 1 9.1%
.paris 22 4 18% .email 37 3 8.1%
計494TLD 24836 263 1.1%
TLD ごとの署名割合(5)
• ccTLD 署名割合ベスト/ワースト10
• 2.8% (10495/381015)0
順位 TLD ドメイン数 署名ドメイン 割合 順位 TLD ドメイン数 署名ドメイン 割合
1 .cz 4909 2098 43% 69 .ie 1300 2 0.15%
2 .nl 4806 1657 34% 70 .by 1399 2 0.14%
3 .no 2318 728 31% 71 .sg 1079 1 0.093%
4 .se 3442 806 23% 72 .za 2793 2 0.072%
5 .nu 305 49 16% 73 .ru 50772 36 0.071%
6 .pm 31 4 13% 74 .il 1490 1 0.067%
7 .hu 2897 360 12% 75 .cn 12777 6 0.047%
8 .br 17254 1659 9.6% 76 .ar 2662 1 0.038%
9 .th 1120 94 8.4% 77 .kr 5906 2 0.034%
10 .fr 12604 1027 8.1% 78 .ua 7038 1 0.014%
合計 240 TLD 381015 10495 2.8%
.jp はどうなの?
• 署名ドメイン数/総数 = 40/21995 = 0.18%
• 平均(1.7%)のはるか下
• ひとつでも署名ドメインが存在する 187 TLD のうち、下から14番目
• ひとつでも署名ドメインが存在する 78 ccTLD のうち、下から11番目
• が、署名ドメインが存在するだけでもマシという考え方もできる
• 全 755 TLD 中 174位
• 240 ccTLD 中 68位
jp ドメイン内訳
ドメイン数 署名ドメイン 割合 ドメイン数 署名ドメイン 割合
ac.jp 548 6 1.1% lg.jp 203 0 0%
ad.jp 8 2 25% ne.jp 463 1 0.22%
co.jp 6266 10 0.16% or.jp 905 3 0.33%
ed.jp 115 0 0% 都道府県
型・地域型
366 0 0%
go.jp 179 6 3.4% 汎用 12815 12 0.094%
gr.jp 127 0 0% 合計 21995 40 0.18%
jp 以外の日本関連TLD
地域TLD ドメイン数 署名ドメイン数 ブランドTLD ドメイン数 署名ドメイン数
.tokyo 246 0 .canon 3 0
.osaka 5 0 .hitachi 2 0
.yokohama 7 0 .jcb 2 0
.kyoto 3 0 .komatsu 3 0
.nagoya 10 0 .nec 1 0
.okinawa 7 0 .nico 4 0
.ryukyu 3 0 .pioneer 1 0
.ricoh 2 0
• 以上 15TLD 299ドメインひとつも署名なし
• .moe(インターリンク 2/110), .earth(インターリンク 0/1), .shop(GMO 3/148)
• 署名5ドメインのレジストラントはいずれも海外の人っぽい
IDN (国際化ドメイン名)
• IDN TLD (example.xn--*)
• 23 TLD 1079 ドメイン中署名ドメインなし
• うち950ドメインが .рф (.xn--p1ai)
• 非 IDN TLD (xn--*.example)
• 56 TLD 1465 ドメイン中署名ドメイン22 (1.5%)
• .com(10/796) .se(3/7) .no(3/4) .fr(3/6) .de(1/41) .eu(1/7) .nu(1/4)
• .net(0/159) .jp(0/119) .xyz(0/79) .biz(0/39) .ua(0/25) .tokyo(0/16) .org(0/15) .kr(0/13) .es
(0/13) .su(0/12) 以下略
• 計 0.86% (22/2544)
DNSSEC 非対応 TLD
• Top-1M に1ドメインでもランク入りしている TLD のうち、署名ドメイン
がひとつもない TLD = 568/755 = 75%
• Top-1M に100ドメイン以上ランク入りしている TLD のうち、署名ドメイ
ンがひとつもない TLD = 80/188 = 43%
• Top-1M に1000ドメイン以上ランク入りしている TLD のうち、署名ドメ
インがひとつもない TLD = 8/71 = 11%
• .it (13963) .ir (12959) .tr (2906) .vn (2682) .sk (2270) .kz (1444) .pk (1401) .su
(1124)
• DNSSEC 対応 TLD だが、署名済みドメインが Top 1M ランク入りしな
かっただけの可能性もあることに注意
署名アルゴリズム
• RSASHA1(-NSEC3-SHA1) が半数
• ECDSA が予想以上に普及
• ほとんど Cloudflare 収容ドメイン
• これから新規に DNSSEC をはじめる
なら ECDSA がいいんじゃないかな
• 署名サイズが小さいというメリット
• RSASHA256 からの移行(アルゴリズム
ロールオーバー)は超めんどくさいので
十分に検討してから
• TLD ごとに割合が大きく偏っている
• .cz、.br、.fr などで RSASHA1 の割合
が高い
RSASHA1
17%
RSASHA1-
NSEC3-SHA1
34%
RSASHA256
25%
ECDSAP256SHA256
22%
その他
2%
アルゴリズム推移
https://twitter.com/reseauxsansfil/status/928010426402725888
.jp 署名アルゴリズム(1)
RSASHA1
17%
RSASHA1-
NSEC3-SHA1
34%
RSASHA256
25%
ECDSAP256SHA256
22%
その他
2%
top-1m 全体(再掲)
RSASHA1
1
RSASHA1-
NSEC3-SHA1
1
RSASHA256
38
.jp (40ドメイン)
.jp 署名アルゴリズム(2)
Q. なぜ jp には ECDSA 署名のドメインがないの?
A. ECDSA 鍵を登録しようとしても受け付けてくれないから
(追記: 発表後、2018年対応予定とコメントいただきました)
ダイジェストアルゴリズム
• Top 1M 全体(DS 総数20821)
• SHA1 (26%)
• SHA256 (73%)
• GOST (0.60%)
• SHA512 (0.25%)
• .jp 40ドメイン(DS 総数59)
• SHA1 (32%)
• SHA256 (68%)
• .jp では GOST と SHA512 は使用不可
まとめ
• TLD によって DNSSEC の対応状況は差があるよ
• .bank(100%) .mil(96%), .ovh(48%), .cz(43%)
• .net (1.2%) .org(1.2%) .com(0.97%)
• .jp (0.18%)
• 755 TLD のうち 568 が 0%
• 全体 1.7%
• いろんな署名アルゴリズムが使われてるよ
• RSASHA1, RSASHA256, ECDSAP256SHA256
• でも jp では ECDSAP256SHA256 が使えない
• 日本はみんなやる気なさげ
• そういえば DNS DAY のプログラムも今年は DNSSEC Update が消えましたね

More Related Content

What's hot

「NIST SP 800-204C サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」概説
「NIST SP 800-204C  サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」概説「NIST SP 800-204C  サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」概説
「NIST SP 800-204C サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」概説Eiji Sasahara, Ph.D., MBA 笹原英司
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)NTT DATA Technology & Innovation
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...NTT DATA Technology & Innovation
 
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会ShuheiUda
 
GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)
GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)
GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)NTT DATA Technology & Innovation
 
PenTesterが知っている危ないAWS環境の共通点
PenTesterが知っている危ないAWS環境の共通点 PenTesterが知っている危ないAWS環境の共通点
PenTesterが知っている危ないAWS環境の共通点 zaki4649
 
10GbE時代のネットワークI/O高速化
10GbE時代のネットワークI/O高速化10GbE時代のネットワークI/O高速化
10GbE時代のネットワークI/O高速化Takuya ASADA
 
構成情報データベースをGitで管理したいネットワーク運用者の憂鬱
構成情報データベースをGitで管理したいネットワーク運用者の憂鬱構成情報データベースをGitで管理したいネットワーク運用者の憂鬱
構成情報データベースをGitで管理したいネットワーク運用者の憂鬱Yuya Rin
 
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方歩 柴田
 
大規模サービスを支えるネットワークインフラの全貌
大規模サービスを支えるネットワークインフラの全貌大規模サービスを支えるネットワークインフラの全貌
大規模サービスを支えるネットワークインフラの全貌LINE Corporation
 
Unified JVM Logging
Unified JVM LoggingUnified JVM Logging
Unified JVM LoggingYuji Kubota
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介AdvancedTechNight
 
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密ShuheiUda
 
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)NTT DATA Technology & Innovation
 
閉域網接続の技術入門
閉域網接続の技術入門閉域網接続の技術入門
閉域網接続の技術入門Masayuki Kobayashi
 
フロー技術によるネットワーク管理
フロー技術によるネットワーク管理フロー技術によるネットワーク管理
フロー技術によるネットワーク管理Motonori Shindo
 
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)Kuniyasu Suzaki
 

What's hot (20)

Helidon 概要
Helidon 概要Helidon 概要
Helidon 概要
 
「NIST SP 800-204C サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」概説
「NIST SP 800-204C  サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」概説「NIST SP 800-204C  サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」概説
「NIST SP 800-204C サービスメッシュを利用したマイクロサービスベースのアプリケーション向けDevSecOpsの展開」概説
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
CloudNativePGを動かしてみた! ~PostgreSQL on Kubernetes~(第34回PostgreSQLアンカンファレンス@オンライ...
 
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
サポート エンジニアが Azure Networking をじっくりたっぷり語りつくす会
 
GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)
GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)
GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)
 
PenTesterが知っている危ないAWS環境の共通点
PenTesterが知っている危ないAWS環境の共通点 PenTesterが知っている危ないAWS環境の共通点
PenTesterが知っている危ないAWS環境の共通点
 
10GbE時代のネットワークI/O高速化
10GbE時代のネットワークI/O高速化10GbE時代のネットワークI/O高速化
10GbE時代のネットワークI/O高速化
 
構成情報データベースをGitで管理したいネットワーク運用者の憂鬱
構成情報データベースをGitで管理したいネットワーク運用者の憂鬱構成情報データベースをGitで管理したいネットワーク運用者の憂鬱
構成情報データベースをGitで管理したいネットワーク運用者の憂鬱
 
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
 
Multi Chassis LAG for Cloud builders
Multi Chassis LAG for Cloud buildersMulti Chassis LAG for Cloud builders
Multi Chassis LAG for Cloud builders
 
大規模サービスを支えるネットワークインフラの全貌
大規模サービスを支えるネットワークインフラの全貌大規模サービスを支えるネットワークインフラの全貌
大規模サービスを支えるネットワークインフラの全貌
 
Unified JVM Logging
Unified JVM LoggingUnified JVM Logging
Unified JVM Logging
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
 
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
サポート エンジニアが語る、Microsoft Azure を支えるインフラの秘密
 
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
 
NGINXをBFF (Backend for Frontend)として利用した話
NGINXをBFF (Backend for Frontend)として利用した話NGINXをBFF (Backend for Frontend)として利用した話
NGINXをBFF (Backend for Frontend)として利用した話
 
閉域網接続の技術入門
閉域網接続の技術入門閉域網接続の技術入門
閉域網接続の技術入門
 
フロー技術によるネットワーク管理
フロー技術によるネットワーク管理フロー技術によるネットワーク管理
フロー技術によるネットワーク管理
 
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
 

More from IIJ

プロダクトオーナーと開発者が別会社・別組織でも前のめりなチームを生み出す取り組み事例
プロダクトオーナーと開発者が別会社・別組織でも前のめりなチームを生み出す取り組み事例プロダクトオーナーと開発者が別会社・別組織でも前のめりなチームを生み出す取り組み事例
プロダクトオーナーと開発者が別会社・別組織でも前のめりなチームを生み出す取り組み事例IIJ
 
IIJ_デジタルワークプレース事業紹介資料
IIJ_デジタルワークプレース事業紹介資料IIJ_デジタルワークプレース事業紹介資料
IIJ_デジタルワークプレース事業紹介資料IIJ
 
監視 Overview
監視 Overview監視 Overview
監視 OverviewIIJ
 
HTTPを理解する
HTTPを理解するHTTPを理解する
HTTPを理解するIIJ
 
DevOps Overview
DevOps OverviewDevOps Overview
DevOps OverviewIIJ
 
ただいま三河。あれから1年、チームNOCKncokが開発しないスクラムで成果を出した経験から得た学び
ただいま三河。あれから1年、チームNOCKncokが開発しないスクラムで成果を出した経験から得た学びただいま三河。あれから1年、チームNOCKncokが開発しないスクラムで成果を出した経験から得た学び
ただいま三河。あれから1年、チームNOCKncokが開発しないスクラムで成果を出した経験から得た学びIIJ
 
上っ面スクラムチームにならないために気を付けたいこと
上っ面スクラムチームにならないために気を付けたいこと上っ面スクラムチームにならないために気を付けたいこと
上っ面スクラムチームにならないために気を付けたいことIIJ
 
Super Easy Memory Forensics
Super Easy Memory ForensicsSuper Easy Memory Forensics
Super Easy Memory ForensicsIIJ
 
チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談
チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談
チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談IIJ
 
【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?
【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?
【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?IIJ
 
コロナ禍での白井データセンターキャンパスの運用施策
コロナ禍での白井データセンターキャンパスの運用施策コロナ禍での白井データセンターキャンパスの運用施策
コロナ禍での白井データセンターキャンパスの運用施策IIJ
 
コロナ禍の開発勉強会~社内教育ツールの開発と実装
コロナ禍の開発勉強会~社内教育ツールの開発と実装コロナ禍の開発勉強会~社内教育ツールの開発と実装
コロナ禍の開発勉強会~社内教育ツールの開発と実装IIJ
 
セキュリティ動向2020
セキュリティ動向2020セキュリティ動向2020
セキュリティ動向2020IIJ
 
バックボーン運用から見るインターネットの実情
バックボーン運用から見るインターネットの実情バックボーン運用から見るインターネットの実情
バックボーン運用から見るインターネットの実情IIJ
 
データセンターのエネルギーコントロールの仕組み
データセンターのエネルギーコントロールの仕組みデータセンターのエネルギーコントロールの仕組み
データセンターのエネルギーコントロールの仕組みIIJ
 
世界のインターネット事情
世界のインターネット事情世界のインターネット事情
世界のインターネット事情IIJ
 
フロントからバックエンドまで - WebAssemblyで広がる可能性
フロントからバックエンドまで - WebAssemblyで広がる可能性フロントからバックエンドまで - WebAssemblyで広がる可能性
フロントからバックエンドまで - WebAssemblyで広がる可能性IIJ
 
あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~
あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~
あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~IIJ
 
インシデント調査システムが内製すぎる件~CHAGEのご紹介~
インシデント調査システムが内製すぎる件~CHAGEのご紹介~インシデント調査システムが内製すぎる件~CHAGEのご紹介~
インシデント調査システムが内製すぎる件~CHAGEのご紹介~IIJ
 
IIJ Technical DAY 2019 ~ IIJのサーバインフラはここまでやっています
IIJ Technical DAY 2019 ~ IIJのサーバインフラはここまでやっていますIIJ Technical DAY 2019 ~ IIJのサーバインフラはここまでやっています
IIJ Technical DAY 2019 ~ IIJのサーバインフラはここまでやっていますIIJ
 

More from IIJ (20)

プロダクトオーナーと開発者が別会社・別組織でも前のめりなチームを生み出す取り組み事例
プロダクトオーナーと開発者が別会社・別組織でも前のめりなチームを生み出す取り組み事例プロダクトオーナーと開発者が別会社・別組織でも前のめりなチームを生み出す取り組み事例
プロダクトオーナーと開発者が別会社・別組織でも前のめりなチームを生み出す取り組み事例
 
IIJ_デジタルワークプレース事業紹介資料
IIJ_デジタルワークプレース事業紹介資料IIJ_デジタルワークプレース事業紹介資料
IIJ_デジタルワークプレース事業紹介資料
 
監視 Overview
監視 Overview監視 Overview
監視 Overview
 
HTTPを理解する
HTTPを理解するHTTPを理解する
HTTPを理解する
 
DevOps Overview
DevOps OverviewDevOps Overview
DevOps Overview
 
ただいま三河。あれから1年、チームNOCKncokが開発しないスクラムで成果を出した経験から得た学び
ただいま三河。あれから1年、チームNOCKncokが開発しないスクラムで成果を出した経験から得た学びただいま三河。あれから1年、チームNOCKncokが開発しないスクラムで成果を出した経験から得た学び
ただいま三河。あれから1年、チームNOCKncokが開発しないスクラムで成果を出した経験から得た学び
 
上っ面スクラムチームにならないために気を付けたいこと
上っ面スクラムチームにならないために気を付けたいこと上っ面スクラムチームにならないために気を付けたいこと
上っ面スクラムチームにならないために気を付けたいこと
 
Super Easy Memory Forensics
Super Easy Memory ForensicsSuper Easy Memory Forensics
Super Easy Memory Forensics
 
チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談
チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談
チームみを大切にした 私たちの“受託アジャイル・スクラム”体験談
 
【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?
【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?
【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?
 
コロナ禍での白井データセンターキャンパスの運用施策
コロナ禍での白井データセンターキャンパスの運用施策コロナ禍での白井データセンターキャンパスの運用施策
コロナ禍での白井データセンターキャンパスの運用施策
 
コロナ禍の開発勉強会~社内教育ツールの開発と実装
コロナ禍の開発勉強会~社内教育ツールの開発と実装コロナ禍の開発勉強会~社内教育ツールの開発と実装
コロナ禍の開発勉強会~社内教育ツールの開発と実装
 
セキュリティ動向2020
セキュリティ動向2020セキュリティ動向2020
セキュリティ動向2020
 
バックボーン運用から見るインターネットの実情
バックボーン運用から見るインターネットの実情バックボーン運用から見るインターネットの実情
バックボーン運用から見るインターネットの実情
 
データセンターのエネルギーコントロールの仕組み
データセンターのエネルギーコントロールの仕組みデータセンターのエネルギーコントロールの仕組み
データセンターのエネルギーコントロールの仕組み
 
世界のインターネット事情
世界のインターネット事情世界のインターネット事情
世界のインターネット事情
 
フロントからバックエンドまで - WebAssemblyで広がる可能性
フロントからバックエンドまで - WebAssemblyで広がる可能性フロントからバックエンドまで - WebAssemblyで広がる可能性
フロントからバックエンドまで - WebAssemblyで広がる可能性
 
あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~
あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~
あ! やせいのEmotetがあらわれた! ~ IIJ C-SOCサービスの分析ルールについて~
 
インシデント調査システムが内製すぎる件~CHAGEのご紹介~
インシデント調査システムが内製すぎる件~CHAGEのご紹介~インシデント調査システムが内製すぎる件~CHAGEのご紹介~
インシデント調査システムが内製すぎる件~CHAGEのご紹介~
 
IIJ Technical DAY 2019 ~ IIJのサーバインフラはここまでやっています
IIJ Technical DAY 2019 ~ IIJのサーバインフラはここまでやっていますIIJ Technical DAY 2019 ~ IIJのサーバインフラはここまでやっています
IIJ Technical DAY 2019 ~ IIJのサーバインフラはここまでやっています
 

世界と日本のDNSSEC

  • 2. はじめに • なんとなく気になったので、DNSSEC の普及状況を調べてみた • 権威サーバ(署名側) • ほかにも調べてる人はたくさんいるので新規性はない • 他人の調査結果を探してくるより、自分でやったほうが早い、という程度 • 過去の調査事例: https://dnsops.jp/event/20140627/SummerDays2014ohmoto.pdf • ほんとは定期的に観測して推移を見られればいいんだろうけど、 やってません • 発作的な思いつきをそのまま実行に移しただけなので • 次回未定
  • 3. 調査対象 • Alexa Top 1M にリストされている100万ドメイン • .arpa は含まない • Top 1M ランク外のドメインに対しては何の調査もしていない • DS レコードの登録状況を調査 • DNSKEY レコードや、正しく検証できるかどうかはまったく見ていない • 2017/10/29 付のリストに含まれるドメインの DS を 10/30-31 に調査
  • 4. 結果 • 署名ドメイン数 17247/100万 = 1.7% • Q. .jp は 1.7% より高い? 低い? 署名あり 17247 署名なし 982753 DNSSEC対応ドメイン 署名あり 署名なし
  • 5. ランク上位の署名ドメイン 67 paypal.com 82 mozilla.org 138 nih.gov 148 avito.ru 195 4chan.org 203 abs-cbn.com 318 xfinity.com 332 gmx.net 335 web.de 342 canva.com
  • 6. • 2.5%/1000 → 2.4%/1万 → 1.9%/10万 → 1.7%/100万 • 上位ほど署名割合も高くなる傾向(といっても微々たるもの…) ランクによる署名割合 署名あり 25 署名なし 975 1-1000位 署名あり 244 署名なし 9756 1-10000位 署名あり 1926 署名なし 98074 1-100000位 署名あり 17247 署名なし 982753 1-1000000位
  • 7. TLD ごとの署名割合(1) • Alexa Top 1M に出現する全 TLD のう ち、ひとつでも署名ドメインが存在し た TLD 187/755 = 25% • ある TLD に署名ドメインがなかったか らといって、DNSSEC 非対応 TLD とは 限らないことに注意 • TLD としては対応していても、署名済み ドメインが Top 1M ランク入りしなかった だけの可能性 署名ドメインが 存在したTLD 187 署名ドメインが存 在しなかったTLD 568
  • 8. TLD ごとの署名割合(2) • レガシー gTLD (com, net, org, gov, edu, mil, int) TLD ドメイン数 署名ドメイン数 割合 .com 476049 4638 0.97% .net 49923 618 1.2% .org 47070 571 1.2% .gov 1073 405 38% .edu 3278 87 2.7% .mil 52 50 96% .int 106 0 0% 合計 577551 6369 1.1%
  • 9. TLD ごとの署名割合(3) • ICANN 設立から2010年ぐらいまでの gTLD + sTLD TLD ドメイン数 署名ドメイン 割合 TLD ドメイン数 署名ドメイン 割合 .aero 134 0 0% .museum 19 1 5.3% .asia 423 0 0% .name 243 1 0.41% .biz 2870 16 0.56% .post 7 7 100% .cat 455 5 1.1% .pro 1320 3 0.23% .coop 120 0 0% .tel 6 0 0% .info 9926 86 0.87% .travel 177 0 0% .jobs 152 0 0% .xxx 483 1 0.21% .mobi 686 0 0% 合計 17021 120 0.71%
  • 10. TLD ごとの署名割合(4) • それ以外の gTLD (いわゆる新 gTLD + IDN TLD) 10ドメイン以上ランク入りしている TLD のうち、割合上位10TLD 合計は10ドメイン未満のTLDを含む • 新gTLD総数 494、うちひとつでも署名ドメインが存在したTLD 95(19%) TLD ドメイン数 署名ドメイン 割合 TLD ドメイン数 署名ドメイン 割合 .bank 41 41 100% .photo 21 3 14% .ovh 81 39 48% .ist 10 1 10% .google 10 3 30% .nrw 11 1 9.1% .bzh 19 4 21% .brussels 11 1 9.1% .paris 22 4 18% .email 37 3 8.1% 計494TLD 24836 263 1.1%
  • 11. TLD ごとの署名割合(5) • ccTLD 署名割合ベスト/ワースト10 • 2.8% (10495/381015)0 順位 TLD ドメイン数 署名ドメイン 割合 順位 TLD ドメイン数 署名ドメイン 割合 1 .cz 4909 2098 43% 69 .ie 1300 2 0.15% 2 .nl 4806 1657 34% 70 .by 1399 2 0.14% 3 .no 2318 728 31% 71 .sg 1079 1 0.093% 4 .se 3442 806 23% 72 .za 2793 2 0.072% 5 .nu 305 49 16% 73 .ru 50772 36 0.071% 6 .pm 31 4 13% 74 .il 1490 1 0.067% 7 .hu 2897 360 12% 75 .cn 12777 6 0.047% 8 .br 17254 1659 9.6% 76 .ar 2662 1 0.038% 9 .th 1120 94 8.4% 77 .kr 5906 2 0.034% 10 .fr 12604 1027 8.1% 78 .ua 7038 1 0.014% 合計 240 TLD 381015 10495 2.8%
  • 12. .jp はどうなの? • 署名ドメイン数/総数 = 40/21995 = 0.18% • 平均(1.7%)のはるか下 • ひとつでも署名ドメインが存在する 187 TLD のうち、下から14番目 • ひとつでも署名ドメインが存在する 78 ccTLD のうち、下から11番目 • が、署名ドメインが存在するだけでもマシという考え方もできる • 全 755 TLD 中 174位 • 240 ccTLD 中 68位
  • 13. jp ドメイン内訳 ドメイン数 署名ドメイン 割合 ドメイン数 署名ドメイン 割合 ac.jp 548 6 1.1% lg.jp 203 0 0% ad.jp 8 2 25% ne.jp 463 1 0.22% co.jp 6266 10 0.16% or.jp 905 3 0.33% ed.jp 115 0 0% 都道府県 型・地域型 366 0 0% go.jp 179 6 3.4% 汎用 12815 12 0.094% gr.jp 127 0 0% 合計 21995 40 0.18%
  • 14. jp 以外の日本関連TLD 地域TLD ドメイン数 署名ドメイン数 ブランドTLD ドメイン数 署名ドメイン数 .tokyo 246 0 .canon 3 0 .osaka 5 0 .hitachi 2 0 .yokohama 7 0 .jcb 2 0 .kyoto 3 0 .komatsu 3 0 .nagoya 10 0 .nec 1 0 .okinawa 7 0 .nico 4 0 .ryukyu 3 0 .pioneer 1 0 .ricoh 2 0 • 以上 15TLD 299ドメインひとつも署名なし • .moe(インターリンク 2/110), .earth(インターリンク 0/1), .shop(GMO 3/148) • 署名5ドメインのレジストラントはいずれも海外の人っぽい
  • 15. IDN (国際化ドメイン名) • IDN TLD (example.xn--*) • 23 TLD 1079 ドメイン中署名ドメインなし • うち950ドメインが .рф (.xn--p1ai) • 非 IDN TLD (xn--*.example) • 56 TLD 1465 ドメイン中署名ドメイン22 (1.5%) • .com(10/796) .se(3/7) .no(3/4) .fr(3/6) .de(1/41) .eu(1/7) .nu(1/4) • .net(0/159) .jp(0/119) .xyz(0/79) .biz(0/39) .ua(0/25) .tokyo(0/16) .org(0/15) .kr(0/13) .es (0/13) .su(0/12) 以下略 • 計 0.86% (22/2544)
  • 16. DNSSEC 非対応 TLD • Top-1M に1ドメインでもランク入りしている TLD のうち、署名ドメイン がひとつもない TLD = 568/755 = 75% • Top-1M に100ドメイン以上ランク入りしている TLD のうち、署名ドメイ ンがひとつもない TLD = 80/188 = 43% • Top-1M に1000ドメイン以上ランク入りしている TLD のうち、署名ドメ インがひとつもない TLD = 8/71 = 11% • .it (13963) .ir (12959) .tr (2906) .vn (2682) .sk (2270) .kz (1444) .pk (1401) .su (1124) • DNSSEC 対応 TLD だが、署名済みドメインが Top 1M ランク入りしな かっただけの可能性もあることに注意
  • 17. 署名アルゴリズム • RSASHA1(-NSEC3-SHA1) が半数 • ECDSA が予想以上に普及 • ほとんど Cloudflare 収容ドメイン • これから新規に DNSSEC をはじめる なら ECDSA がいいんじゃないかな • 署名サイズが小さいというメリット • RSASHA256 からの移行(アルゴリズム ロールオーバー)は超めんどくさいので 十分に検討してから • TLD ごとに割合が大きく偏っている • .cz、.br、.fr などで RSASHA1 の割合 が高い RSASHA1 17% RSASHA1- NSEC3-SHA1 34% RSASHA256 25% ECDSAP256SHA256 22% その他 2%
  • 20. .jp 署名アルゴリズム(2) Q. なぜ jp には ECDSA 署名のドメインがないの? A. ECDSA 鍵を登録しようとしても受け付けてくれないから (追記: 発表後、2018年対応予定とコメントいただきました)
  • 21. ダイジェストアルゴリズム • Top 1M 全体(DS 総数20821) • SHA1 (26%) • SHA256 (73%) • GOST (0.60%) • SHA512 (0.25%) • .jp 40ドメイン(DS 総数59) • SHA1 (32%) • SHA256 (68%) • .jp では GOST と SHA512 は使用不可
  • 22. まとめ • TLD によって DNSSEC の対応状況は差があるよ • .bank(100%) .mil(96%), .ovh(48%), .cz(43%) • .net (1.2%) .org(1.2%) .com(0.97%) • .jp (0.18%) • 755 TLD のうち 568 が 0% • 全体 1.7% • いろんな署名アルゴリズムが使われてるよ • RSASHA1, RSASHA256, ECDSAP256SHA256 • でも jp では ECDSAP256SHA256 が使えない • 日本はみんなやる気なさげ • そういえば DNS DAY のプログラムも今年は DNSSEC Update が消えましたね