そういえば、どこに「浸透」するのだろう？ そんなことを、技術的目線から一つ一つ再確認してみました。 OSC2018 Tokyo/Spring で話した内容をアップデートしています。

1. 「DNS浸透いうな」
と言うけれど…
そういえば、どこに「浸透」するのだろう？
#ssmjp 2018/07
日本Unboundユーザー会
@goto_ipv6

2. 質問
• どこに「浸透」したら、あなたは満足ですか？
• 具体的に言えますか？
• 「浸透」というのだから、どこかに「浸透」するはずな
のです
• ここでは、そのあたりをちょっと考えてみたいと思
います

3. 自己紹介
• 名前 : 後藤 芳和
• 「JANOG 後藤 芳和」でググってください
• Twitter : @goto_ipv6
• https://www.slideshare.net/goto_ipv6
• https://togetter.com/id/goto_ipv6
• 仕事でDNSを運用しているわけではありません
• 趣味でもないと思っていますが…

4. 浸透するかも候補
• アプリケーション
• Webブラウザーとか
• Lightweight Languageも
• OS
• Windows
• Linux (Ubuntu, CentOS, Debian, Gentoo, RHELなど)
• BSD系 (FreeBSD, NetBSD, OpenBSDなど)
• フルリゾルバー(キャッシュDNSサーバー)
• 権威サーバー(コンテンツサーバー)

5. アプリケーションへ浸透？
• 得られたドメイン名についての情報をキャッ
シュする？
• いつまでキャッシュしていればよいのかわからない
ので、なかなかこんな実装はないはず
• Oracle JVMくらい？
• OSを介さずに独自で名前解決する？
• 名前解決に必要な情報をどうやって得るの？
• OSから得たとして、OS側で設定が変わったときに追随で
きる？
• OSにその機能があるのに、車輪を再発明するの？

6. Webブラウザーへ浸透？
• FirefoxやChromeは「キャッシュ」を持っている
• Firefoxはキャッシュの秒数や個数などが設定可能
• 参考： http://www.e-ontap.com/blog/20140323.html
• Chromeだと“chrome://net-internals/#dns”で確認可能
• これらは設定値の秒数の間しか利用されない
• DNS over HTTPSがWebブラウザーで有効化され
ると、Webブラウザーが自ら、名前解決を行う
ことになる
• この時の結果も「キャッシュ」する可能性がある
• お？

7. OSへ浸透？
• OSではなくてlibc/glibcといった「ライブラリ」
がアプリからの名前解決要求を受け付ける
• この機能を「スタブリゾルバ」という
• 当然、「キャッシュ」機能なんて持っていない
• アプリケーションへTTLも渡せない
• でも、「キャッシュ」機能を持ったOS(やディ
ストリビューション)も存在する
• デーモンやサービスとして実装されている
• 例) Ubuntu (systemd-resolved), FreeBSD (local_unbound),
Windows (DNS Client)
• お？

8. フルリゾルバーへ浸透？
• スタブリゾルバからの要求を受けて、実際に名
前解決をするサーバー
• Unboundが有名 ;-)
• Iterative(反復的)な問い合わせ「動作」をする
• DNSメッセージとしては「再帰のフラグ(RD bit)無
し」であり「非再帰問い合わせ」と言います
• RFC 1034に書いてあります ;->
• 「キャッシュ」機能を持つことが多い
• お？

9. キャッシュへ浸透？
• 問い合わせ要求を受けたときの、最終的な結果
を保持
• 要求を受けないと保持されないので「浸透」しない
• TTLが切れるまで情報は有効なので「浸透」しない
• 「要求されたドメイン名(など)はありませんで
した」という情報も保持される
• 「ネガティブキャッシュ」という
• これにもTTLがあるので、その期間中はずっと、要
求に対して「ありませんでした」という応答が続く
• 「DNSが浸透しない」ことの原因の一つなので注意

10. 権威サーバーへ浸透？
• ドメイン名などの情報を保持するサーバー
• その「ドメイン」に関する名前についての情報しか
知らない
• www.example.jpのIPアドレス情報を、jpドメインの権威
サーバー（a.dns.jpなど）が保持することはない
• ドメイン名の委譲元の権威サーバーへ「浸透」すること
はない
• ドメイン名の変更作業では実際に変更するため、結
果として作業内容が「即時反映」される
• 「浸透」するわけではない
• ゾーン転送は自分で制御可能
• そもそも「浸透」でもない

11. ルートサーバーへ浸透？
• ルートサーバーは “.” に関する権威サーバー
• com や jpドメインなど TLD (Top Level Domain) に関す
る権威サーバーの情報 (NSレコード) などを保持し
ている
• つまりこのサーバーに「浸透」することはない
• 権威サーバーなので

12. その他にも？
• 既存の権威サーバーを新しい権威サーバーへ切
り替える手順を間違えると「DNSが浸透しな
い」「DNSが反映されない」状態となる
• ドメイン名の委譲元への変更「申請」と、権威サー
バーに対するドメイン名の変更「作業」とを区別し
なければならない
• 前者は、作業タイミングがわからないことも
• レジストリとレジストラについては後述
• 後者は、移転元と移転先の両方に対し、新しい権威サー
バーに関する情報を登録 (更新) することが必要だが、特
に移転元の方の作業を忘れがち
• 忘れると、移転元の権威サーバーを使い続けることに

13. その他にも？ (続き)
• レジストリ
• 「ドメイン名のレジストリは、登録済みドメイン名
の情報と登録者情報を管理しています。」
• https://jprs.jp/glossary/index.php?ID=0102 より抜粋
• レジストラ
• 「個々の登録者からドメイン名の登録申請を受け付
けたり、登録者からの要求に基づいてドメイン名の
データベース（レジストリデータベース）への情報
登録を行う機関がレジストラです。」
• https://jprs.jp/glossary/index.php?ID=0101 より抜粋
• この「情報登録」の結果が「DBに反映される」ま
でに時間がかかる場合がある (jpだと最大15分)

14. そもそも既存の説明が悪い？
• 今までの説明(絵)ではそれぞれの登場人物が一
つずつなのが大半
• ルートサーバー
• jpドメインの権威サーバー
• example.jp の権威サーバー
• フルリゾルバー
• クライアント(アプリケーション)

15. よくある例
簡略化して説明するのが
目的なのでこれはこれで
仕方がない
ルートサーバー
jp の権威サーバー
example.jp の
権威サーバー
フルリゾルバー
クライアント

16. 本当はこんな世界
• 登場人物があっちこっちに存在し、OSもアプ
リケーションもいっぱい存在する
• アプリケーション
• OS
• フルリゾルバー(キャッシュDNSサーバー)
• ISPの数以上、あると言っても過言ではない
• 権威サーバー(コンテンツサーバー)
• 冗長構成を取っているため多数に

17. DNS関係者はいっぱいいる
a.root-servers.net b.root-servers.net c.root-servers.net
a.dns.jp b.dns.jp / c.dns.jp d.dns.jp
ns1.example.jp ns2.example.jp
フルリゾルバ クライアント
http://www.dns.jp/index-j.html
https://www.iana.org/domains/root/servers

18. よく考えてみて！
• これら全てに「浸透」すると思うのはそもそも
おかしい
• 冒頭に書いた質問を思い出してください
• どこに「浸透」したら、あなたは満足ですか？
• ドメイン名だって、星の数ほど存在する
• これら全部、キャッシュで保持するの？
• できません

19. 気持ち悪いですよね？
• あなたが使っている「アプリケーション」や
「Webブラウザー」
• あなたが使っている「OS」
• あなたが構築した「フルリゾルバー」
• あなたが使っている「権威サーバー」
• これらに、他人のデータが「浸透」してきたら
うれしいですか？

20. まとめ
• 「浸透」する先は存在しません
• 「反映」は、いろいろな意味を含むので、適切に使
いましょう
• DNSを勉強しましょう！
• 大抵は作業手順や確認手順の誤りが原因
• 「浸透」を待たなくても、作業確認のための正しい
手順はあります
• フルリゾルバーの気持ちになって、dig/drillコマンドで、
自分でIterative(反復的)な問い合わせ手順をやってみたら
良いのです

21. 見るべき資料
• 浸透いうな！ (@tss_ontap)
• http://www.e-ontap.com/dns/propagation/
• ネガティブキャッシュについて
• http://www.e-ontap.com/dns/onsen4/index.html
• JPRS さんの資料
• https://jprs.jp/related-info/guide/019.pdf
• https://jprs.jp/tech/material/iw2011-lunch-L1-01.pdf
• 浸透問題を解説してくださっています
• https://jprs.jp/tech/material/iw2012-lunch-L3-01.pdf

22. 見るべき資料 (続き)
• あきみち (@geekpage) さんのブログ
• なぜ「DNSの浸透」は問題視されるのか
• 「DNSの浸透」とアプリケーションのキャッシュ

23. 参考: Iterativeな問い合わせ例
• drill –o rd @a.root-servers.net. www.example.jp.
• “-o rd” によりRD bitが落とされる
• ⇒フルリゾルバーの気持ちになって動いている
• dig コマンドの場合は “+norec” オプション
• jpドメインの権威サーバーのFQDNが分かる
• drill –o rd @a.dns.jp. www.example.jp.
• “example.jp”ドメインの委譲元 (JPRS) が保持してい
る “example.jp” の権威サーバーのFQDNが分かる
• drill –o rd @ns.example.jp. www.example.jp.
• “www.example.jp” のIPアドレスが分かる