Learning Scalable DNS Resolvers from Hyper-Scalers Kento KAWAKAMi 1 

whoami Kento KAWAKAMi Infrastructure System Software Engineer Enginnering Manager & Developer DNS, Load Balancer, Service Discovery, Service Mesh Hobby 登山, 読書, 映画 SNS x.com/Kawakami_Kento github.com/kimitoboku linkedin.com/in/kimitoboku 2 

普段作ったり してる物 DNS の移譲関係を可視化するやつ github.com/kimitoboku/RecResolve 学習用 DNS Full Resolver github.com/kimitoboku/dns_full_resolver_handson DNS の挙動を伝えるために作ってる [WIP] DNS orchestrator inspired by Public DNS github.com/kimitoboku/pegassa AI と一緒に作っていたらbug って動かなくなったりをくり返して る 今年度中に公開したい whoami 3 

DNS 本来: ドメインからIP アドレスを取得するためのProtocol & System 現在: インターネットにおいて、ドメイン名からIP アドレスより前 or 同タイミングで欲しい情報を全て格納する場所 課題 DNS に求められる機能は増え続ける それでいて性能が求められ続ける Latency が悪いISP は怒られる 可用性も求められる 名前解決が出来ないとインターネットが基本的に使えない状態に なる 問題設定 4 

目的地 DNS の可用性を担保するための方法を一通り頭に入れてもらう DNS を分散Key-Value Store として理解してDNS の設定変更などを理 解出来るようになる DNS はほっといても良いほど枯れたシステムではない事を知る Hyper-scalers がDNS Full Resolver をどのようにScaling しているか 知る事で、DNS 以外のシステムにおいても、使える技術や考え方を 知る 問題設定 5 

DNS の基礎 DNS とは for Software Engineer Domain という構造を元に管理 者を分割して管理する事がで ききる、分散Key-Value Store DNS Auth Key-Value Store の Storage Engine DNS Full Resolver Key-Value Store のQuery Engine DNS Full Resolver に名前解決 のQuery を問い合わせ、Full Resolver がDomain の移譲関係 を解決し、Key に対応したデ ータを取得する 6 

Query Example: Qname: www.example.com, Qtype: A dig www.example.com -t A www.example.com という名前のA というData 構造のData を取 得して欲しいというQuery DNS の基礎 7 

DNS の基礎 8 

DNS の基礎 9 

DNS の基礎 DNS Auth はInmemory KVS Zone で自身が可能な応答と移 譲関係を応答する 10 

DNS Full Resolver は計算コストも高い root-server から移譲関係をたどり解決するため DNSSEC を利用するとさらに20% コストが上がるという報告もあ る DNS Full Resolver はメモリコストも高い DNS Query のCache を保持する必要があるため DNS の基礎 1 11 

DNS は変化し続けている Extended DNS Errors RFC 8914 (2020) QNAME minimisation RFC 9156( 2021) DNS over QUIC RFC 9250 (2022) SVCB/HTTPS RR RFC 9460 (2023) DNS Zone Version RFC 9660 (2024) TLS Encrypted Client Hello (Draft) DNS の新機能 12 

通常のWeb アプリケーションに近いScaling ごく小規模の場合 中規模の場合 ーーーーーーーーーーーーーーーーーーーーーーーー DNS や分散DB エンジンとしてのScaling 大規模の場合 Hyper-Scaler (Public DNS) DNS Scaling Pattern 13 

通常のWeb アプリケーションに近いScaling とく何もしなくてもDNS は冗長化される DNS は長く利用されているシ ステムなので、Client 側が発 達している Client がresolve.conf から Nameserver を読み取って動作 する (libc) client 側で自動的に問い合わせ に1 台失敗したら次のサーバに 問い合わせる nameserver 192.168.1.1 nameserver 192.168.1.2 14 

通常のWeb アプリケーションに近いScaling resolv.conf に任せている だけでは性能上の問題が ある resolv.conf では1 Node が性能 限界に DNS では、DNS の構成にドメ イン名を利用する事が出来な い Query Engine としては Stateless LB で単純にスケール 15 

単純なLB 構成での課題 LB 構成の問題 DNS を冗長構成出来るLB は限られる 多くの場合でHWLB を買う必要がある HWLB の問題にも遭遇する(EoL) 筐体のスケールの課題 IP Address の持ち運びの困難性 HWLB のEoL によりIP Address の変更が必要になる場合も 通常のWeb アプリケーションに近いScaling 16 

DNS & 分散key-Value Store としての Scaling 17 

DNS & 分散key-Value Store としてのScaling Routing を利用した冗長 構成 OCN の場合 Router とDNS サーバ間で Peer を張り経路広報 Router とDNS Cache が動い ているサーバでBFD のコネ クションを貼り生存確認 Router からはECMP を利用 してトラヒックを分散 2 18 

DNS & 分散key-Value Store としてのScaling Routing を利用した地理 分散 ANYCAST 事例 IP ANYCAST で1 つのIP Address で地理的に近い DNS Full Resolver を利用 してもらう 3 19 

さらにスケールするために for Public DNS ECS によるメモリ利用量の増大 超巨大なQPS maintenance の課題 DNS Full Resolver はCache の有無で性能が大きく変わる 単純な再起動などでは投入時に大きな性能低下が発生する DNS & 分散key-Value Store としてのScaling 20 

ECS(EDNS Client Subnet) Client の多様性があるDNS Full Resolver でGSLB に、Client の Network 情報を伝達する仕組み Client Subnet 毎にCache を持つ Full Resolver に到達可能なNetwork size ÷ ECS に利用するsubnet size /10 から /24 で問い合わせ = 16,384 倍 /10 から /16 で問い合わせ = 64 倍 DNS & 分散key-Value Store としてのScaling 21 

ECS(EDNS Client Subnet) DNS & 分散key-Value Store としてのScaling 22 

ECS(EDNS Client Subnet) Client の多様性があるDNS Full Resolver でGSLB に、Client の Network 情報を伝達する仕組み Client Subnet 毎にCache を持つ Full Resolver に到達可能なNetwork size ÷ ECS に利用するsubnet size /10 から /24 で問い合わせ = 16,384 倍 /10 から /16 で問い合わせ = 64 倍 -> Cache に必要なメモリの増大 = Cache Hit Rate の低下 DNS & 分散key-Value Store としてのScaling 23 

巨大なQPS DNS Full Reolver のCache に必要なメモリ量 domain 名: 40B ( 最大で256 文字だけど平均すると40 くらい), Type/TTL/Class: 30B Data: (A: 4B / Data), (AAAA: 16B / Data), (CNAME: 40B( ドメイン 名の長さ) 1 entry 最小でも0.3KB 程度 インターネット上に存在するドメイン数 362.3 million https://www.openprovider.com/blog/how-many-domains-are- there?utm_source=chatgpt.com 最小構成でも100GB ECS ならもっともっと -> Cache に必要なメモリの増大 = Cache Hit Rate の低下 DNS & 分散key-Value Store としてのScaling 24 

maintenance の課題 DNS Full Resolver の性能は移譲関係をどの程度Cache しているのか に依存 D-Plane の再起動などのmaintenance によりCache がFlush される D-Plane の再起動後などにQuery の性能が低下する Cache Hit Rate の低下 -> Latency の悪化 DNS & 分散key-Value Store としてのScaling 25 

DNS は分散Key-Value Store DNS Full Resolver はQuery Engine DNS & 分散key-Value Store としてのScaling 26 

Internet ANCYAST (Geo Sharding) 地理的にFull Resolver を分散 Cient のSrc Network を限定 ECS によるメモリ利用量が削減 DNS & 分散key-Value Store としてのScaling 27 

DNS & 分散key-Value Store としてのScaling Consisten Hashing (Qname Sharding) Domain name により担当の Full Resolver を決める Domain name のCache の容量 をCluser として分割 Cache Hit Rate の向上 -> Latency の向上 28 

DNS & 分散key-Value Store としてのScaling Quorum 1 つのQuery に対して複数の Full Resolver に問い合わせ 多数決や1st one を結果として 利用 Tail Latency の改善 node のmaintenance などに対 応 Cache が貯まるまでは他の Node が応答する事が出来る 29 

DNS & 分散key-Value Store としてのScaling Quorum 1 つのQuery に対して複数の Full Resolver に問い合わせ 多数決や1st one を結果として 利用 Tail Latency の改善 node のmaintenance などに対 応 Cache が貯まるまでは他の Node が応答する事が出来る 30 

Top Rank Cache Shareing 全世界で問い合わせが行われているQuery を全てのNode で共有 インターネットトラヒックのTop1000 のドメインでQuery 全体の 50% DNS Observatory: The Big Picture of the DNS DNS & 分散key-Value Store としてのScaling 31 

DNS & 分散key-Value Store としてのScaling 32 

まとめ DNS はQuery Engine とStorage Engine が存在する分散Key-Value Store 分散DB の技術を適用してScaling Sharding Key Level Geo Level Quorum Tail Letency Security DNS だって出来る事はいっぱいあるし、まだまだこれからも必要な 楽しい技術! まとめ 33 

触らぬDNS に祟りなし、寝たDNS を起 こすな -> DNS に求められる事が増え変わって いくしかない -> 眠らないように触り続ける 4: レジストラとDNS プロバイダの世界 （後⽇公開Ver ） @garnet_yn P.11 http://ck.rozen.jp/docs/dnsonsen/20230909-dnsonsen8- registrar-and-dnsprovider.pdf まとめ 4 34 

Q. どのような場合でも、Consistent Hashing を使った方が性能が良さそうに 見えない? そんな事はない DNS Full Resolver の動作として、Cache は移譲関係もCache するの でCache のメモリに余裕があるのであれば、持てるだけCache を持 った方が早い Query の多様性が増えてCache のメモリが消えはじめて初めて、 Consistent hashing の方が安定した性能を出すようになる Appendix Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) Rob Pike's 5 Rules of Programming “ “ 35 

DNS ってどうやって開発しはじめると良い? DNS は良いライブラリがあります Golang github.com/miekg/dns Python github.com/rthalley/dnspython Full Resolver も最近はHaskell で書かれた物などもあるので、挙動を あるていど仕様として感じられる物もある github.com/iijlab/dnsext Appendix 36 

1: Performance Effects of DNSSEC Validation - July 2022 https://www.isc.org/blogs/dnssec-validation-performance-july-2022/ 2: 変化するDNS 運用とこれからの課題について (DNS 設計/ 運用者の目 線から) 小坂 良太 https://www.janog.gr.jp/meeting/janog53/wp- content/uploads/2024/01/janog53-dnsops- 小坂良太.pdf 3 ： DNS Anycast Deployment: A Case Study of Resilient DNS Infrastructure for a Nationwide ISP https://medium.com/%40sohag.shamim/dns-anycast-deployment-a- case-study-of-resilient-dns-infrastructure-for-a-nationwide-isp- fa42be88c138 4: レジストラとDNS プロバイダの世界 （後⽇公開Ver ） @garnet_yn P.11 http://ck.rozen.jp/docs/dnsonsen/20230909-dnsonsen8- registrar-and-dnsprovider.pdf 5 ： Google Public DNS Performance Benefits https://developers.google.com/speed/public-dns/docs/performance 6: How Rust and Wasm power Cloudflare's 1.1.1.1 https://blog.cloudflare.com/big-pineapple-intro/ Reference 37