第41話で、イトはfestival.exampleのA / AAAA dataをresolverへ問い合わせた。
address候補は返った。
三つのprojectorも、時間内に復旧した。
でも、resolver deskの裏には、まだ閉じたままのrelay roomがある。
「resolverは、最初から答えを知っていたの？」
イトがrelay switchを入れると、三つのstationが暗闇に浮かんだ。
mock root。
mock upper zone。
mock authoritative。
今日は、この学習用fixtureのcacheを空にする。
festival.exampleのpublic DNSを再現する装置ではない。
rootからauthoritative serverへ進む境界を、外から見えるように組んだ閉じた模型だ。
最初のserverなら、最後のaddressまで知っている？
stub deskから、前話と同じquestion cardが届いた。
QNAME: festival.example
QTYPE: A
recursive resolver役のイトは、cache shelfを確認した。
使えるrecordはない。
forwarderも、このfixtureでは使わない。
残り、六十秒。
イトはroot hints trayから、mock root stationの接続先を取った。
そしてquestion cardを送る。
「rootなら、世界の名前の入口だ。最後のaddressも返せるはず」
mock rootから、黄色い札が戻った。
でも、greenのaddress cardではない。
子のzoneを担当する次のserverを示す札だった。
response kind: referral
next authority: indicated
イトは札を裏返した。
「答えじゃない」
黄色い札をdiscard slotへ落とす。
relay railは、そこで消灯した。
stub deskのanswer lampは点かない。
二度目のquestion cardだけが、mock rootの前で待ち続ける。
残り、四十七秒。
recursive requestとiterative queryは、同じ役ではない
ピコは、stub deskとrelay roomの間にある透明な仕切りを照らした。
イト
stubがroot、upper、authoritativeへ順番に聞くんじゃないの？
ピコ
このfixtureでは、stubはrecursive resolverへ結果を頼む。外側のserverへqueryを重ねる役はresolverだよ
イト
rootのreferralは、答えられなかった印じゃない？
ピコ
final addressではない。でもdelegationをたどる次のquery先を示す、resolutionを進めるresponseだ
RFC 9499は、stub resolver、recursive resolver、authoritative server等の役割を分けている。
端末側のstub resolverは、通常、recursive resolverへresolutionを依頼する。
recursive resolverは、そのclientに代わって必要な処理を進め、得られた結果を返す。
一方、resolverが外側のDNS serverへ行うqueryは、相手にすべてを代行させる形とは限らない。
iterative resolutionでは、受け取ったresponseを評価し、必要なら次のserverを選んでqueryを続ける。
browserがrootからauthoritative serverまで、直接走り回ると決めつけない。
root hintsは、最初の入口を見つける手がかり
イトはroot hints trayを持ち上げた。
中にあるのは、最終addressの一覧ではない。
resolverがroot serverへqueryを始めるための情報だ。
RFC 1034のresolver algorithmは、まずlocal informationやcacheを調べ、不足すればqueryするserverを選び、responseを分析しながら処理を続ける流れを示している。
最初から必ずrootへ行く、とは限らない。
usable cacheがあれば、そこからanswerできる場合がある。
configured forwarderへ処理を渡す構成もある。
aliasをたどれば、別のnameへのqueryが増えることもある。
networkやresolver policyでもsequenceは変わる。
今回だけは、その差を隠さず見るため、cacheなし、forwarderなし、aliasなしに固定した。
referralは、「次はここを確かめて」の札
RFC 1034とRFC 1035では、name serverのresponseはfinal answerだけではない。
別のname serverへ近づくためのreferralになる場合も、errorを返す場合もある。
referralには、委任された子zoneを担当するname serverの情報が入る。
そのserverへ到達する助けとして、追加のaddress情報が付くこともある。
ただし、どの追加情報も無条件に信用してよい、という意味ではない。
glueやbailiwick、DNSSEC validationの詳しい条件は、この話では扱わない。
大切なのは、referralをfinal answerと取り違えないこと。
同時に、「addressがないからfailure」と捨てないことだ。
イトの前に、三つの続け方が開く
relay roomのtimerが鳴った。
残り、三十一秒。
stub deskには、まだ何も返せていない。
イトの前に、三つのleverが上がった。
A 同じmock rootへ、final answerをもう一度要求する
さっきと同じ相手に、同じ期待を押しつける。
返ったreferralを評価しないため、次のauthorityへ進めない。
B 昨日のaddressをshortcutとして返す
古いmemory trayにはaddress cardがある。
でも現在のTTLも、現在のanswerとの一致も確かめていない。
resolverが調べた結果としてstubへ返すことはできない。
C referralを次のserverへの案内としてたどる
discard slotから黄色い札を回収する。
示されたmock upper zoneへquestionを送り、次のresponseも評価する。
mock authoritativeからanswerを得たら、recursive outputを通してstubへ返す。
ピコは三つのleverに触れなかった。
「あと二十八秒」
イトは、消えたrelay railと、discard slotの黄色い角を見た。
「最初のstationで終わらない。返ってきた札が、次の行き先になる」
イトはCを選んだ。
自分の手で、捨てたreferral cardをdiscard slotから取り戻した。
mock rootが示した次のserverを、next-server railへ置く。
そして同じQNAME / QTYPEのquestion cardを、mock upper zone stationへ送った。
三つのresponseを、一本のresolutionへつなぐ
mock upper zone stationから、二枚目の黄色い札が戻った。
ここでもfinal addressではない。
festival.exampleを担当するmock authoritative stationへのreferralだ。
イトは捨てなかった。
二枚目の札をnext-server railへつなぎ、question cardをmock authoritativeへ送る。
最後のstationがgreenに変わった。
このfixtureのzone dataを持つauthoritative serverから、A answerが返る。
response kind: authoritative answer
requested address data: present
イトはanswer cardをrecursive outputへ置いた。
recursive resolverからstub deskへresponseが戻る。
第41話で使ったconnection candidate rackに、現在のaddress候補が届いた。
三つのprojector test lampが、一斉にblueへ変わる。
残り、九秒。
mock rootがpageのaddressを答えたわけではない。
mock upper zoneも、final addressを答えていない。
二つのreferralが次のauthorityを示し、最後にauthoritative answerへ届いた。
イトが三つのresponseを評価してつないだから、stub側へ結果を返せた。
cacheは、relayを永久に省略する札ではない
relayが終わると、cache shelfに空の枠が開いた。
イトは、得たrecordとTTL timerを一緒に置く。
DNS resource recordのTTLは、そのrecordをcacheしてよい時間の上限を示す。
TTL内なら、次の同種queryにcacheを使える場合がある。
だから次回は、同じ三stationを必ず通るとは限らない。
ただしcacheは、永遠に正しい答えへ変わる魔法ではない。
TTLが切れれば、再びresolutionが必要になる。
途中のreferral informationも、条件とTTLに従ってcacheされ得る。
どのcacheが使われ、どこから再開するかで、観察するquery列は変わる。
negative cachingやerror responseの切り分けは、第45話で扱う。
「答えじゃない札」が、次の一手を残していた
timerが止まった。
イトは二枚の黄色いreferral cardを、relay railの横へ順番どおり残した。
greenのanswer cardとは重ねない。
cache shelfには、recordと一緒にTTL timerが回っている。
mock root stationの「final answer」slotは、最後まで空のままだ。
それでもstub deskのanswer lampは点いている。
最初のserverが答えを持っていなくても、resolutionは止まらない。
イトは、さっきreferralを落としたdiscard slotへ、小さな透明板をかぶせた。
not final does not mean useless
その横で、三stationを結ぶ一本のrailがblueに光っていた。
次回：点で区切られたnameは、どこまで同じ？
イトはfestival.exampleのname札を裏返した。
今度は、点の左右が別々の小さな札に分かれる。
その隣には、IP address cardと、pathまで続くURL cardがある。
「domain name、IP address、URL。似た場所に出てくるけど、どこまでが同じsiteのnameなの？」
ピコは三枚を、重ならないslotへ並べた。
次回、ピコルート第43話。
IPアドレスとドメイン名はどう違う？ 名前札を選ぼう
DNSの流れを図で確かめる
resolver、cache、referral、authoritative serverの関係を一枚で整理するなら、名前解決とは何かで確認できます。