第40話で、browser工房はstandby programを組み立てた。
けれど、同じpageをもう一度取りに行くtestが残っている。
URL札のauthorityには、host名があった。
festival.example
route benchのdestination address欄は空白だ。
イトは青いhost札を、そのままIP address slotへ差した。
「名前が書いてある。これが宛先でいい」
確認packetを送るまで、五十二秒。
イトがsend leverを倒す。
packetはrouteへ出なかった。
入口gateが、青いhost札を押し戻した。
destination kind: registered name IP destination: not selected
「同じ札なのに、URLでは読めて、packetの宛先には入らない？」
名前は見えている。でも、IP routeを選べない
イトはもう一度、青い札を押し込んだ。
gateは閉じたままだ。
三つのprojectorのtest lampが、一台ずつamberへ変わる。
残り、四十五秒。
ピコは、host札とIP address slotの間にある小さなresolver deskを照らした。
イト
domain nameは、人が読みやすくしたIP addressじゃないの？
ピコ
同じものを別表記しただけとは限らない。DNSではnameに対して、欲しいtypeのresource dataを問い合わせる
イト
nameをIPへ一回置き換えて終わり、じゃない？
ピコ
addressが複数返ることも、address dataが返らないこともある。元のnameもURLから消えない
URLのhostには、nameもIP literalも入り得る
前話まで、イトはhostを一枚のname札だと思っていた。
でもURI syntaxでは、hostの形は一つではない。
RFC 3986のhost subcomponentは、IP literal、IPv4 address、registered nameを取り得る。
hostに文字があるからといって、すべてがDNS lookup対象とは限らない。
逆に、DNSで引くためのregistered nameなら、domain nameのsyntaxを使う。
このfixtureのfestival.exampleは、DNS lookupを行う架空のregistered nameだ。
.exampleは説明用で、実serviceではない。
browserやOSは通常、こうしたresolutionを内部で行う。
利用者がhost札を手でIP slotへ差すわけではない。
この工房では、見えない境界を学ぶために外へ出している。
「URLで読むhostと、IP routeで使うaddressは、同じ欄じゃない」
イトは、押し戻されたname札を机へ置いた。
DNSは、nameに関するdataを問い合わせる
resolver deskには、question cardが一枚ある。
空欄は二つだ。
name。
type。
RFC 1034では、DNSのdomain name spaceはtreeとして構成され、nameにresource record dataが関連づく。
queryは、調べたいdomain nameと、欲しいresource informationのtypeを示す。
name serverのresponseは、answerを返す場合がある。
別のserverへのreferralになる場合もある。
error conditionを返す場合もある。
DNSは、どんなquestionにも一つのIP addressだけを返す箱ではない。
このquestionで使う欄は、次のように呼ばれる。
QNAME: 問い合わせるname QTYPE: 欲しいresource record type
DNS messageにはQCLASS等のfieldもある。
ここではInternet classで、hostに対応するaddress dataだけを見る。
AとAAAAは、二種類のaddress question
resolver deskに、二枚のtype cardが出た。
A。
AAAA。
RFC 1035のA recordは、Internet classでIPv4 host addressを持つ。
RFC 3596のAAAA recordは、IPv6 addressを持つ。
二つは、同じaddress文字列の短い版と長い版ではない。
IPv4とIPv6という別のaddress familyのdataだ。
一つのnameに、AやAAAAが複数ある場合もある。
片方だけの場合もある。
queryに対して該当address dataがない場合もある。
alias等をたどってaddressへ着く場合もある。
「DNSへ聞けば、いつも一枚のIP札が出る」ではない。
今回のfixtureは、AとAAAAを別々に問い合わせる。
どのaddressをどの順で接続に試すかは、DNSのanswerだけで一律に決まらない。
clientのnetwork状態やconnection strategyも関わる。
ep41では、そのalgorithmまでは決めない。
browserは、世界中のserverへ直接聞き回るとは限らない
イトは、resolver deskの先にある長い廊下を見た。
いくつものDNS server lampが並んでいる。
「browserが、全部へquestion cardを持って行くの？」
RFC 9499は、DNS client / server、stub resolver、recursive resolver、authoritative server等の用語を分けている。
一般的な端末側のstub resolverは、recursive resolverへresolutionを頼る。
recursive resolverは、必要なresolution functionを引き受ける。
browserがrootから担当serverまですべてへ直接queryする、と決めつけない。
ただし、browser、OS、local service、encrypted DNS等の実装構成は一つではない。
このfixtureでは、browser工房からlocal stub deskへname / typeを渡し、その先をrecursive resolverへ頼む。
resolverがどのserverへ何を聞くかは、次話で追う。
今必要なのは、name-only packetをrouteへ押し出す前に、address dataを求めることだ。
DNS answerとWeb pageは、同じ成功lampではない
イトは、resolver deskの上に四つのlampを見つけた。
DNS response。
IP connection。
secured connection。
HTTP response。
一つずつ別のlampだ。
DNSでaddress dataが返っても、そのaddressへconnectionできるとは限らない。
connectionできても、TLS verificationやHTTP responseが成功するとは限らない。
HTTP responseが返っても、目的のcontentが使えるとは限らない。
逆にWeb pageが開かないだけで、DNSが誤ったとは断定できない。
DNS answerは、相手siteの安全や内容の正しさを証明する札でもない。
このfixtureでは、四lampを別々に観察する。
イトの前に、三つの宛先準備が開く
projector testのbellが鳴った。
残り、二十九秒。
route benchに三つのtrayが出る。
A 昨日覚えたaddress札を使う
手元には、前回testのaddress札が一枚ある。
でも今のDNS answerと同じとは確認していない。
複数候補やaddress familyも無視してしまう。
B host名をIP address slotへもう一度入れる
すでにgateで止まった。
registered nameとIP destinationを同じ値として扱う誤りを繰り返す。
C resolverへ、現在のA / AAAA dataを問い合わせる
QNAMEにfestival.exampleを置く。
QTYPE AとQTYPE AAAAを、このfixtureでは別queryとして送る。
返ったaddress dataをconnection候補rackへ置き、元のhost名はURL / authority railへ残す。
ピコはresolver deskを照らしただけだった。
「昨日は、このaddressで届いた」
イトは古い札を持ち上げる。
次に、青いhost札と、空のquestion cardを見る。
「昨日の数字でも、名前そのものでもない。今のnameに、今ほしいtypeを聞く」
イトはCを選んだ。
QNAME欄へfestival.exampleを置く。
自分の手でAとAAAAのquestion cardを二枚作り、resolver inputへ送った。
青いhost札は捨てず、authority railへ戻した。
name札を残したまま、address候補でrouteを開く
resolver deskのanswer lampが点いた。
このfixtureでは、A answerに一枚のIPv4 cardがある。
AAAA answerにも、一枚のIPv6 cardがある。
DNS response: address data received candidates: IPv4 / IPv6
イトは二枚を、connection candidate rackへ置いた。
今のlabで利用可能なrouteと、connection controllerの結果を確かめる。
controllerはIPv6 candidateへのconnectionを成立させた。
ここでIPv6が常に先、常に成功するという意味ではない。
このfixtureで観察できた一回の結果だ。
青いfestival.example札は、authority railに残っている。
secured connection lampが点く。
HTTP requestが、同じhostをauthorityとしてWeb originへ進む。
standby programのresponseが戻った。
三つのprojector test lampが、同時にblueへ変わる。
残り、十一秒。
イトは、DNS lampとHTTP lampの間へ透明な仕切りを立てた。
name resolved: observed page response: observed separately
DNS answerが出たことと、pageが戻ったことを一つのlampへまとめなかった。
nameはaddressへ化けて消えない
確認時計が止まった。
イトは、昨日のaddress札を古いmemory trayへ戻した。
resolverから返った二枚は、current candidate rackへ残す。
青いhost札は、その隣のauthority railに残す。
name札とaddress札は、重ねなかった。
address札はrouteで相手へ近づくために使った。
name札は、どのhostへaccessしようとしているかを示し続けた。
三つのprojectorには、同じstandby programが映っている。
その下で、DNS、connection、HTTPの三lampが別々に光っていた。
次回：resolverは、誰に聞いた？
イトはresolver deskの裏をのぞいた。
自分が送ったquestion cardは、一本の暗い廊下へ消えている。
遠くに、root、次の担当、zoneの担当を示す三つのlampが見えた。
「resolverは、最初から答えを知っていたの？」
ピコは、廊下のrelay switchを入れた。
次回、ピコルート第42話。
名前解決はどんな順番？ 案内所リレーを追いかけよう
DNSの基本を図で確かめる
domain name、resolver、A / AAAA、cache、authoritative serverの関係を一枚で整理するなら、DNSとは何かで確認できます。