DNS におけるセキュリティ&プライバシ動向

DNS におけるセキュリティ&プライバシ動向
栗原淳
(株) 国際電気通信基礎技術研究所
兵庫県立大学大学院
(株) ゼタント
2021-3-15
Jun Kurihara (ATR/U-Hyogo/Zettant) Security and Anonymity in DNS Mar. 15, 2021 1 / 29

栗原淳 (くりはらじゅん)
(株) 国際電気通信基礎技術研究所客員研究員
兵庫県立大学大学院准教授
(株) ゼタント主任研究員
研究分野
[基礎エリア] ⇒ 情報理論・符号理論
符号理論を応用した秘匿検索
ネットワーク符号
etc...
[応用エリア] ⇒ ネットワークアーキテクチャ
情報指向ネットワーキングのセキュリティ技術
エッジコンピューティングのセキュリティ
etc...
⇒ 本日は NW アーキテクチャの観点から DNS の話をする

はじめに

Domain Name System (DNS)
DNS: ドメイン名と IP アドレスの対応付けの管理システム
1) www.atr.jpにアクセスしたい！
2) ドメイン: www.atr.jpは、
IPアドレス:133.186.4.12
に対応しているよ！
133.186.4.12
(www.atr.jpのサーバ)
3) 133.186.4.12にアクセス！
DNS (サーバ群)
ユーザ
DNS query (www.atr.jp)
DNS response (133.186.4.12)
IPアドレスによるアクセス
意識しない透過的な機構だが，現在のインターネットを支える重
要なバックボーン．もし DNS が止まったら URL による web アク
セスもメール送受信も不可能．

DNS の「名前解決」の仕組み
トップレベルドメイン (ex.: ‘.jp’) からの「再帰的」な反復検索で実現
Full-service
resolver
Stub
resolver
Root server (.)
Name server (.jp)
Name server (atr.jp)
1.) query
(www.atr.jp?) 2.) query (www.atr.jp?) 3.) query (www.atr.jp?)
[a-h].dns.jp
ns[1-2].atr.jp
4.) response (jp is in NS [a-h].dns.jp)
[a-m].root-servers.net
7.) query (www.atr.jp?)
6.) response (atr.jp is
in NS ns[1-2].atr.jp)
5.) query (www.atr.jp?)
8.) response (www.atr.jp
is 133.186.4.12)
ISP
9.) response (133.186.4.12)
10.) response
(133.186.4.12)
App
133.186.4.12
Web server of ATR
11.) HTTP GET
Authority servers
DNS レコード (IP アドレス・ドメインの関係) は，所望のドメイン名を直
接管理するサーバにり着くまで繰り返す．

用語の解説:
リゾルバ (Resolver):
ドメイン・IP アドレスの対応を検索 (＝解決)．
スタブリゾルバ (Stub resolver):
再帰検索を上流に要求．端末内や家庭内ルータ等．
フルサービスリゾルバ (Full-service resolver)1:
スタブリゾルバの再起検索要求に応じて反復検索．
権威サーバ (Authority server)2:
自管理ドメイン名空間 (ex.: ‘*.atr.jp’) 配下のドメイン状況を管理．
DNS レコード:
ドメイン名と IP アドレスの対応3，ドメインを管理する権威サーバの情報4
など，当該ドメインに関係する種々のデータ．コンテンツサーバより発
行．キャッシュサーバも高速化のため一定時間保持．
1DNS キャッシュサーバ
2DNS コンテンツサーバ, 単にネームサーバと呼ばれたりも
3A/AAAA レコード
4NS レコード

古の DNS の「セキュリティ」の問題
次のいずれも担保され「ない」
DNS パケットの機密性
⇒ 第三者に盗聴され放題．
DNS パケット・レコードの完全性
⇒ 通信路で改竄し放題．
DNS レコードの真正性
⇒ 各リゾルバは偽レコードを返し放題．5
⇓
DNS そのものの設計が古い (1983 年) ので，致し方ない部分はある
ものの，DNS はセキュリティに関して非常に脆弱．
5ex.) 実際，米国 ISP はレコードを書き換え放題してる．(DNS 汚染)

古の DNS の「プライバシ」の問題
セキュリティだけではなく，クエリのプライバシに大きな課題有
フルサービスリゾルバに対する DNS クエリプライバシ: フルサービ
スリゾルバは反復解決の必要上，必ずユーザの DNS クエリの内容
を知りうる．
権威サーバへの DNS クエリプライバシ:
EDNS0 [1] の仕様では，エンドユーザの IP アドレス等の情報が含ま
れた DNS クエリが，権威サーバまで到達しうる．6
⇓
エンドユーザあるいは組織の，「行動履歴・行動パターン・業務上の秘
密等」が第三者へ漏洩．7
6EDNS Client Subnet (ECS)
7なお，DNS では通信の機密性も担保されないので，サーバ以外にも漏洩し放題．

DNS のセキュリティ・プライバシの社会的な課題
米国では，ISP による DNS クエリの記録・収益化の歴史 [15] や，
DNS レコードの汚染
各国において DNS クエリブロッキングや，政府によるクエリ監視
特に E. スノーデンの事件以降，DNS のセキュリティ・プライバシ，とり
わけ「Pervasive Monitoring」は社会的な課題として捉えられる [7] ように
なっている．8
⇓
近年新たな DNS セキュリティ・プライバシ技術の研究・標準化が活発に．
今回はその最近の動向を簡単に紹介する．
8とはいえ日本国内では通信の秘密により DNS はある意味「アンタッチャブル」
．

DNS のセキュリティ・プライバシの
最近の動向

最近ではないけれど: まずは導入として DNSSEC
DNS Security Extension (DNSSEC, RFC4034 [4])
オリジナルは 1999 年の RFC2535．20 年以上の歴史．
各レコードにデジタル署名を付与．
取得したレコードの署名を検証することで，正当な権威サーバで生
成されたこと (真正性)，改竄されていないこと (完全性) を保証．
response
[DNS record +
Signature record]
Full-service
resolver
Stub
resolver
App
Authority
server
query query query
response
response
Validate
response!
Velification
key
Signature record
DNS record
(xx.xx.xx.xx)
Generate signature
and store as a record
Signing key
※ Validation can be done at the stub resolver as well.

DNSSEC ででは足りないこと
DNSSEC は，レコードの完全性・真正性を担保するが機密性やク
エリのプライバシは何も担保しない
Full-service
resolver
Stub
resolver
Authority server
query
(www.atr.jp?)
ISP
App
Can eavesdrop
query/response!
Can connect each
user exactly with its
issues queries!
機密性・クエリプライバシの担保のためにには別の技術が必要．
⇒ 近年，企業・オープンソースソフトウェア主体で，DNS プロト
コル自体を下位のセキュアチャネル上で動作させる手法が提案．

最近の動向
∼DNS の暗号化技術∼

暗号化 DNS
OS やルータが非対応でも，App が対応すればクエリを暗号化！ 9
非対応 App 向けにスタブリゾルバとして動作する暗号化プロキシも存在．
Full-service
resolver
Authority server
Public Resolver
(Like Google/Cloudflare)
Secure encrypted channel
Encryption proxy
Encryption
supported app
Encryption non-
supported app
ISP のものに代わり，暗号化に対応した公開リゾルバをフルサービスリ
ゾルバとして利用．
9Firefox/Chrome/iOS/Android は暗号化 DNS に対応．

技術一覧
暗号化 DNS は，今のところ 4 種類が知られている．
DNS over TLS (DoT) [10]
DNS over HTTPS (DoH) [9]
DNSCrypt [5]
DNSCurve [6]
特に巨大企業の公開リゾルバ (Google/Cloudﬂare/Quad9) は
DoH/DoT に対応している．
2009 年に提案された DNSCurve は，今のところ OpenDNS 以外の
デプロイ例はない (ので今回は省略)．

DNS over TLS (DoT)
DoT [10]
IETF RFC7858 にて標準化．
DNS クエリ・レスポンス 10
を，クライアント・サーバ間の
TLS のセキュアチャネル上で実行．
DNSCrypt のクライアント用暗号化プロキシ (dnscrypt-proxy)
がそのまま DoT のクライアントとして利用できる．iOS14 お
よび Android Pie でネイティブ対応．
DNS サーバ Unbound/Knot Resolver でも DoT をサポート．
Cloudﬂare, Google, Quad9, IIJ 等々が DoT 対応の公開リゾルバ
として存在．
10
over TCP

DNS over HTTPS (DoH)
DoH [9]
IETF RFC8484 にて標準化．
HTTPS プロトコル上で DNS クエリ・レスポンスの送受信を行
う．即ち TLS 上で HTTP のコンテキスト (PUT/GET) を利用．
HTTPS 向けの高速化プロトコル (HTTP/2) が使える．
DoT 同様，dnscrypt-proxy を DoH のクライアントとして利用可
能．iOS14, Windows10, Firefox/Chrome/Edge でもサポート．
DNS サーバ Unbound/Knot Resolver でも DoH をサポート．
Cloudﬂare, Google, Quad9, IIJ 等々が DoH 対応の公開リゾルバ
として存在．
匿名化プロトコル Oblivious DNS over HTTPS (ODoH) [13] が
Cloudﬂare によって IETF に提案中．

DNSCrypt
DNSCrypt [5]
IETF の技術標準ではなく，オープンソースソフトウェア
(OSS) としてコミュニティ開発．11
DNS クエリ・レスポンスを直接暗号化によりラップ，
UDP/TCP パケットに載せて送受信．
クライアント用暗号化プロキシ (dnscrypt-proxy) および
DNSCrypt 対応フルサービスリゾルバの実装が OSS として
公開．
DoH 同様の匿名化手法が実装済 (後述 12
)
OpenDNS, Yandex, Adguard, Quad9 などが DNSCrypt 対応の公
開リゾルバとして存在．
11
https://github.com/dnscrypt
12
Anonymized DNSCrypt [2]

最近の動向
∼DNS の匿名化技術∼

暗号化 DNS はクエリプライバシを担保しない
Authority server
Public Resolver
Encryption
supported app
Decrypt, then recursively resolve
requested domain names
Both plaintext query and user IP address are known to the resolver!
-> Every query is uniquely bound with the user who query issued.
Encrypted query
(当然だが) 暗号化 DNS であっても，フルサービスリゾルバは名前解
決のために暗号化クエリを復号して平文のクエリを取得する．
暗号化 DNS クエリのソースアドレスより，ユーザの IP アドレスは
公開リゾルバへ公開される．
⇓
IP アドレスとクエリが一意に紐づいてしまう

匿名化 DNS
DNS クエリの匿名性を担保する，すなわちユーザ IP アドレスとクエリ内
容を分離する手法がいくつか提案・実装されている．
Tor ベース:
DoHoT (DNS over HTTPS over Tor [14])
Proxy(Relay/Anonymizer) ベース:
Oblivious DNS over HTTPS (ODoH) [13]
Anonymized DNSCrypt [2,3]
Oblivious DNS [12] (今回は省略)
Full-service
resolver
Proxy
Can’t see the source IP
addresses!!!
Send on behalf of users!
Figure: Proxy ベースの手法のイメージ

DNS over HTTPS over Tor (DoHoT)
DoHoT
Tor [14] ネットワーク上を通じて DoH を行う．
= とてつもなく遅い．
dnscrypt-proxy は Socks v5 プロキシ 13
経由での通信をサポート = Tor
上で簡単に動作する．
信頼できるノードを経由しているのか？
地域によってレスポンスが変化する DNS レコードについては，Exit
ノードの適切な設定が必要 14
DoT や DNSCrypt (TCP) も Tor 経由で動作する．15
13
Tor を起動すると Tor NW への入口として Socks プロキシが立ち上がる
14
「StrictExitNodes 1」および「ExitNodes {node nickname}」を torrc に指定
15Tor は TCP のみをサポートするので UDP 不可．

Oblivious DNS over HTTPS (ODoH)
ODoH [13]
Cloudﬂare が主体となって IETF へ提案中 [11] (2020 年 10 月∼)
経由させることで IP アドレスを秘匿する Oblivious Proxy，および暗
号化クエリを復号・実クエリを行う Oblivious Target 16
というノード
を使うことでエンドユーザの匿名化を担保．
DoH の経路を暗号化するレイヤ (HTTPS/TLS) に加え，内部的にクエ
リを暗号化するレイヤ (Oblivious DNS) を追加．
DoH 同様 HTTPS 向けの高速化プロトコルが利用可能．
16
フルサービスリゾルバを兼ねる

Figure: ODoH の仕組み https://blog.cloudflare.com/oblivious-dns/
Client-Proxy と Proxy-Target で別の TLS セッションを構築．
TLS による経路の暗号化とは別に，Client でクエリ暗号化，Target で
クエリ復号を行うことで，Proxy はクエリ内容がわからない
Proxy により Target は Client の IP アドレスがわからない
ただし Target と Proxy が結託したら匿名性が崩れる
Target はクエリの復号・レスポンスの暗号化を行うのみ．フルサー
ビスリゾルバと同一ノードでも良い．

Anonymized DNSCrypt
Anonymized DNSCrypt [2,3]
2019 年に DNSCrypt の拡張仕様として実装．
Public relay を通じて，DNSCrypt のクエリ・レスポンスを送受
信することでユーザ匿名性を担保．
ODoH との違い: HTTPS ではなく生の UDP/TCP．
やっぱり proxy が宛先と共謀したら匿名性が崩れる．
Full-service
resolver
DNSCrypt supported
resolver
DNSCrypt
supported app
Relay
Just forward!
Encrypted
query
Encrypted
query
Encrypted
response
Encrypted
response
Encrypt query,
decrypt response!
Decrypt query,
resolve the query, and
encrypt response!
DNSCrypt supported resolver is ‘target’ in ODoH
Figure: Anonymized DNSCrypt の仕組み

まとめ

まとめ
DNS のセキュリティ・プライバシの技術動向についてお話しした．
DNS 暗号化
DNS 匿名化
現実的な課題であり，今後も重要な研究トピックであろう．17
17ただ，日本では「通信の秘密」により大きな問題にはならないかもしれない．

参考文献 I
[1] J. Damas, M. Graff, and P. Vixie, “Extension mechanisms for DNS (EDNS(0)),” RFC6891, Apr. 2013. [Online]. Available:
https://tools.ietf.org/html/rfc6891
[2] F. Denis, “Anonymized dnscrypt specification,”
https://github.com/DNSCrypt/dnscrypt-protocol/blob/master/ANONYMIZED-DNSCRYPT.txt, Jun. 2020, commit ID: 78547018.
[3] ——, “Anonymized dns,” https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-DNS, Jan. 2021, commit ID: 9e384ee.
[4] DNS Security Extensions (DNSSEC), RFC 4033, etc.
[5] DNSCrypt, https://www.dnscrypt.org.
[6] DNSCurve, https://dnscurve.org.
[7] S. Farrell and H. Tschofenig, “Pervasive monitoring is an attack,” RFC7258, May 2014. [Online]. Available:
[8] Google Public DNS, “JSON API for DNS over HTTPS (DoH),” https://developers.google.com/speed/public-dns/docs/doh/json, 2021.
[9] P. Hoffman and P. McManus, “DNS queries over HTTPS (DoH),” RFC8484, Oct. 2018. [Online]. Available:
[10] Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, and P. Hoffman, “Specification for DNS over transport layer security (TLS),”
RFC7858, May 2016. [Online]. Available: https://tools.ietf.org/html/rfc7858
[11] E. Kinnear, P. McManus, T. Pauly, and C. A. Wood, “Oblivious DNS over HTTPS,” IETF Network WG Internet-Draft, Dec. 2020. [Online].
Available: https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh
[12] P. Schmitt, A. Edmundson, A. Mankin, and N. Feamster, “Oblivious DNS: Practical privacy for DNS queries,” in Proc. PET 2019, Feb.
2019, pp. 228–244.
[13] S. Singanamalla, S. Chunhapanya, M. Vavruša, T. Verma, P. Wu, M. Fayed, K. Heimerl, N. Sullivan, and C. Wood, “Oblivious DNS over
HTTPS (ODoH): A practical privacy enhancement to DNS,” https://arxiv.org/abs/2011.10121, Nov. 2020.
[14] Tor Project, https://www.torproject.org.
[15] N. Weaver, C. Kreibich, and V. Paxson, “Redirecting DNS for ads and profit.” in Proc. USENIX FOCI 2011, 2011.

参考文献 II
[16] 藤原和典, “Dnssec の普及度 (+ipv6 の普及度),” 2019. [Online]. Available:
https://www.nic.ad.jp/ja/materials/iw/2019/proceedings/d3/d3-fujiwara.pdf

付録

DNSSEC の構造
DNSSEC では権威サーバで 3 つのレコードを追加．18
RRSIG レコード: 各レコードに対して生成される署名
DNSKEY レコード: RRSIG レコードの検証用の公開
DS レコード: 上位のドメイン (atr.jp なら jp) の権威サーバに登録す
る，検証用の公開のハッシュ．これに対しても RRSIG レコード
が作られる．
DNSKEY の正当性は，上流の権威サーバの DS ＋ RRSIG を取得して検
証．つまり，PKI と同じような階層構造．19
18ドメイン毎の存在レコードを列挙する「NSEC/NSEC3 レコード」も DNSSEC の一部として提供
19ルートサーバの公開はトラストアンカーとして各リゾルバに埋め込む．

実際に DNSSEC のレコードを確認してみる
jprs.jp 20についてクエリを掛けてみる．
$ dig jprs.jp +dnssec +noall +comments +answer @8.8.8.8
; <<>> DiG 9.10.6 <<>> jprs.jp +dnssec +noall +comments +answer +multiline @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53979
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; ANSWER SECTION:
jprs.jp. 9 IN A 117.104.133.164
jprs.jp. 9 IN RRSIG A 8 2 300 (
20210212042611 20210113042611 36888 jprs.jp.
xZFsZqu0/XdQP31MpYBIQGj1SpgPPZkk91LLO/9Nf+xG
ctf7tMOn8ufUv+aDaLT3tioN8SIisKEfyDAienlhkLLq
sU1e5rac+Y3uBGriR1JM2z3wBCLYjhC+mNiMkBHtZ4nj
ndStCHMTOBVZDDxjs4exdlkzga6uHXM9TWO+RxM= )
A レコードと RRSIG が取得できた．
20日本レジストリサービス

jprs.jp の A & RRSIG を検証するには DNSKEY を取得．
$ dig dnskey jprs.jp +dnssec +noall +comments +answer +multiline @8.8.8.8
; <<>> DiG 9.10.6 <<>> dnskey jprs.jp +dnssec +noall +comments +answer +multiline @8.8.8.8
;; Got answer:
;; ANSWER SECTION:
jprs.jp. 20914 IN DNSKEY 256 3 8 (
AwEAAdTXO47w9zyHTOQih/e7NFFkV1qNCcIP6VsNL7qu
中略
) ; ZSK; alg = RSASHA256 ; key id = 36888
jprs.jp. 20914 IN DNSKEY 257 3 8 (
AwEAAbEW7c61WQ+ZWrUivmXoOTqqN4i7yB1MhCtaG2YC
中略
2dO78ndRUaGos725rOkISqtEP0O6Cu96/ecggkU=
) ; KSK; alg = RSASHA256 ; key id = 43519
jprs.jp. 20914 IN RRSIG DNSKEY 8 2 86400 (
20210212042611 20210113042611 43519 jprs.jp.
aO+Tk5lmMBSUdVI5FuLMwfKJCvvwElC+jSmb5c5LbLLh
中略
EN0FGmJHsYkZTBJTQ77fo0a6tzK8ParQoA== )
KSK と ZSK と対応する RRSIG が取得できた．

DNSKEY の正しさを検証するには，上流の JP ドメインの権威サーバに
登録される jprs.jp の DS を取得．
$ dig ds jprs.jp +dnssec +noall +comments +answer +multiline @8.8.8.8
; <<>> DiG 9.10.6 <<>> ds jprs.jp +dnssec +noall +comments +answer +multiline @8.8.8.8
;; Got answer:
;; ANSWER SECTION:
jprs.jp. 7199 IN DS 43519 8 2 (
F1253DCC0CEE00CFB6518894AD23F135E1801D67D67D
9CCDA81AADA9954109DC )
jprs.jp. 7199 IN RRSIG DS 8 2 7200 (
20210208174502 20210109174502 39945 jp.
p5wU7jjYqiolJSpB/CkBA9eCOwRlU98JxC5K755BntR5
UgyrQoZ73VEp6YkbrrflDYBk23qqBt7TdqkbOTBn+7Ne
hvacu1Iw5sUh2rTNm6DS0+A93zLlJv44ClwB2vz0q0dJ
uN9RgPEPZhU9kgAwJhDTe0pPYkpjGUtya1cgMuk= )
DS と JP ドメインの署名が入った RRSIG が入手できた．
. (root) → .jp → jprs.jp の順番で名前解決するので，正当性を上流から検証
しながらレコード取得できる．

おまけ
$ dig www.atr.jp +dnssec +noall +comments +answer @1.1.1.1
; <<>> DiG 9.10.6 <<>> www.atr.jp +dnssec +noall +comments +answer @1.1.1.1
;; Got answer:
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
...www.atr.jp は DNSSEC 非対応でした．
DNSSEC は 20 年掛けても普及率が非常に低く，2019 年時点で jp ドメイ
ン全体で DS レコード登録数は500 未満 [16]．

簡単に DoH を試してみる
www.atr.jp を google の DoH サーバで解決してみる [8]
$ curl -s -H ’Accept: application/dns-json’
’https://dns.google:443/resolve?name=www.atr.jp&type=A’ | jq
{
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": false,
"CD": false,
"Question": [
{
"name": "www.atr.jp.",
"type": 1
}
],
"Answer": [
{
"name": "www.atr.jp.",
"type": 1,
"TTL": 21599,
"data": "133.186.4.12"
}
],
"Comment": "Response from 133.186.4.11."
}
curl で簡単にクエリできる．https なので経路も暗号化されている．

DoH で jprs.jp の DNSSEC も確認できる
$ curl -s -H ’Accept: application/dns-json’
’https://dns.google:443/resolve?name=jprs.jp&type=A&do=1’ | jq
{
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": true,
"CD": false,
"Question": [
{
"name": "jprs.jp.",
"type": 1
}
],
"Answer": [
{
"name": "jprs.jp.",
"type": 1,
"TTL": 196,
"data": "117.104.133.164"
},
{
"name": "jprs.jp.",
"type": 46,
"TTL": 196,
"data": "a 8 2 300 1613103971 1610511971 36888 jprs.jp. xZFsZqu0/XdQP31MpY~~~~~~"
}
],
"Additional": []
}

DoHoT を試してみる
Tor Socks プロキシを指定して curl で DoH してみる
curl -s -H ’Accept: application/dns-json’ ’https://dns.google:443/resolve?name=jprs.jp&type=A&do=1’
--proxy socks5://127.0.0.1:9050 | jq
{
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": true,
"CD": false,
"Question": [
{
"name": "jprs.jp.",
"type": 1
}
],
"Answer": [
{
"name": "jprs.jp.",
"type": 1,
"TTL": 299,
"data": "117.104.133.164"
},
{
"name": "jprs.jp.",
"type": 46,
"TTL": 299,
"data": "a 8 2 300 1613269802 1610677802 36888 jprs.jp. gZwK+HmIp..."
}
],
"Additional": [],
"Comment": "Response from 203.105.65.181."
}

どれくらい速度低下が起きるか．
Socks プロキシを指定して curl で GoogleDNS へ DoH した例21:
% time curl -s -H ’Accept: application/dns-json’ --proxy socks5://127.0.0.1:9050
0.01s user 0.01s system 1% cpu 2.335 total
% time curl -s -H ’Accept: application/dns-json’
0.02s user 0.01s system 8% cpu 0.275 total
Tor 経由だと体感でわかるほどに DNS クエリが遅くなる．
21平均とるとかはしていないので参考値

Oblivious DNS (ODNS)
ODNS [12]
特殊な TLD “odns” の権威サーバを，同時にフルサービスリゾルバと
して利用．
⇒ [domain_name] への DNS クエリを
Encrypt(domain_name, session_key).odns
というクエリに変換，受信した odns の権威サーバがフルサービス
リゾルバとして所望の名前解決を実行．22
結果，odns を解決する ISP のフルサービスリゾルバがプロキシとし
て動作．ユーザアドレスは生のクエリを解決する odns 権威サーバ
に非公開，クエリ内容も ISP のリゾルバに漏洩しない．
既存の DNS の構造に手を入れずに実現可能
全てのクエリが権威サーバまで到達するので低速
22
[session_key] はサーバの公開で暗号化されて，DNS クエリの additional information フィール
ドに格納して送付．

Figure: ODNS の仕組み https://odns.cs.princeton.edu

Anonymized DNSCrypt を試してみる
以下の 2 つを使って，tcpdump 経由でクエリ・レスポンスがリレーされ
ることを確認する
client: dnscrypt-proxy23
relay: encrypted-dns-server24
23https://github.com/junkurihara/dnscrypt-proxy
24https://github.com/junkurihara/encrypted-dns-server

ローカルで dnscrypt-proxy を port 50443 で待ち受け．dig コマンドを実行
% dig atr.jp @localhost -p 50053
VPS で encrypted-dns-server をリレーとして起動．tcpdump でキャプチャ
$ sudo tcpdump -i eth0 port 443
22:34:10.221391 IP
flh2-122-131-55-32.osk.mesh.ad.jp.13246 > v150-95-211-62.ite3.static.cnode.io.443: UDP, length 604
22:34:10.221902 IP
v150-95-211-62.ite3.static.cnode.io.50967 > scaleway-ams.dnscrypt.info.443: UDP, length 576
22:34:10.721320 IP
scaleway-ams.dnscrypt.info.443 > v150-95-211-62.ite3.static.cnode.io.50967: UDP, length 368
22:34:10.721450 IP
v150-95-211-62.ite3.static.cnode.io.443 > flh2-122-131-55-32.osk.mesh.ad.jp.13246: UDP, length 368
mesh.ad.jp (biglobe) から
∼cnode.io (VPS) を経由して，
∼scaleway-ams.dnscrypt.info (DNSCrypt 対応の公開リゾルバ) とやりとり
していることが確認できる．
リレーはクエリ内容がわからず，リゾルバはクライアントの IP アドレス
がわからない．

DNS におけるセキュリティ&プライバシ動向

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DNS におけるセキュリティ&プライバシ動向

Similar to DNS におけるセキュリティ&プライバシ動向 (20)

More from Jun Kurihara

More from Jun Kurihara (8)

Recently uploaded

Recently uploaded (8)

DNS におけるセキュリティ&プライバシ動向