O'ReillyのDNS本に必ず名前が出てくる著者のビデオを見てみる。
Databases typically have indexes
The Domain Name System is no different
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217128/
DNSがなによりもまず（分散）データベースであるということがよく分かっていなかった。そしてデータベースシステムなのでインデックスがある。DNS以前（HOSTS.TXT）の検索時間計算量はO(n)だった。
Later, top-level domains were reserved for every country in the world, called country code top-level domains, or ccTLDS
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217130/
.jp等、国別のトップレベルドメインのことをccTLDSと呼ぶ。
Resolution is the process by which resolvers and name servers cooperate to locate data stored in DNS
Resolution proceeds top-down by default
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217134/
resolverが適切なname serverを探すことをresolutionと呼ぶ。デフォルトではトップダウンに進む。例えばroot→com→google→wwwのように。しかし、これだと上位のname serverの負荷が非常に高そうだがどう解決するのか。
Queries and responses are types of DNS messages
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217135/
- Usually using UDP
DNS queryとDNS responseはDNS messageと呼ばれるインタフェースでやりとりをする。DNS messageはUDP上でやり取りされるので、packet lossを考慮しなければならない。
DNS message自体はTCP/IP インターネット以外のネットワークも利用可能なように設計されているものの、実質はインターネット以外には使われていない。
TIME TO LIVE
Cached data must eventually time out in order to force name servers to re- Each resource record has a value associated with it called time to live
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217136/
先述の性能問題を解決するためにcachingがある。DNSにおけるcachingは
- nameとaddress（DNS responseのanswer）のcaching
- name serverのaddressのcaching
2つの意味がある。cachingなので当然TTLもある
Authoritative, Recursive And Caching Name Servers
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217138/
3種のname server
- authoritative: 主機能がnon-recursive query
- recursive
- caching
primaryとsecondaryは誤解されやすい。
The forwarder is the name server that receives -not sends - the forwarded query
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217140/
forwarderはforwarder queryを受信者であって、forwader queryの送信者ではない。
Nowadays, to allow internal name servers to
resolve Internet domain names without giving them direct access to the Internet
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217141/
forwardingを使う理由は主に会社内のname server全てをインターネットに公開せずに名前解決を行うため。ただしDNSのポート番号53は公開されていることが多い。また、Log4Shellの際に指摘されていた環境変数の漏洩には無効であるように思われる。むしろ recursive queryを必要最小限に抑えることが必要なのか？
To map a single domain name to multiple IPv4 addresses, simply use multiple A records
Determining the order in which they're returned is complicated
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217143/
Aレコードの語源はaddress recordだが、実質的にはIPv4レコードを意味する。単一ドメインに複数のIPv4をマッピングしたい場合、複数のAレコードを使う。ただし、どのIPv4が返されるかは単純ではない。
多分クライアント依存。逆に言うとクライアントをコントロールできるのであればDNSをロードバランシングに使えるかもしれない。
Recursive namne servers that receive CNAME records as a response restart the query
- Replacing the alias witth the canonical name
- So don't chain CNAME records!
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217146/
CNAMEはエイリアス。まずAレコードを探し、なければCNAMEを探す。無駄な処理が走るのでCNAMEを数珠つなぎにするのは一般にいい考えではない。
BIND name servers support several configurable RRset orders:
- Round robin/cyclic: The first record is rotated to the end in the next response
- Random: The records are raurned in random order
- Fixed: The records are always returned in the same order, the order in which they appear in zone data
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217152/
RRsetがロードバランシングなのか？
Some folks use RRset order to distribute load among a set of servers, but
Ordering relies on the clent using the first address returned first
- Intermediate name servers (e.g., your local recursive name server) may reorder RRsets, too
- If the client reorders, all bets are off
https://learning.oreilly.com/videos/learning-dns/9781771373692/9781771373692-video217152/
…と思ったら即座に夢が打ち砕かれた。しかし"rrset load"でググってもこういう回答は出てこないのでやはりO'Reillyは素晴らしい。
結論としてインターネットからのアクセスをコントロールするという目的においてはDNSはact-sbyをマニュアル（ないし半自動）で切り替える程度の利用にとどめるのが懸命ぽい。理由は単純でクライアント頼みの箇所が多すぎるから。データセンター内でクライアントをコントロールできる場合はこの限りではないと思う。
この本も面白そう。
