第43話で、イトはURL ribbonを役割ごとに分けた。
exact hostをresolverへ渡し、address candidateを得る。
元のhostとpathも残したから、stage用finale pageが開いた。
次のtestでは、そのstageを新しいrehearsal serverへ移す。
閉じた学習fixtureのfestival.example zoneでは、A dataをnew addressへ変更済みだ。
二台のmock authoritative serverにも、同じcurrent zone dataが読み込まれている。
イトは、いつものrecursive resolverへstage.festival.exampleを問い合わせた。
返ったのは、old address cardだった。
rehearsal projectorにも、古いcue pageが映る。
「正式な台帳を書き換えたのに、戻っていない」
イトはrollback leverへ手を伸ばした。
new server lineを戻すまで、五十五秒。
resolverのanswerは、いつもauthoritative answer？
イトはold address cardの角を見た。
小さなtimerが動いている。
残り、三十八秒。
でも、彼はtimerを裏へ隠した。
「answerが返った。なら、name serverの正式回答だ」
ピコは、recursive resolver deskと、far-sideのauthoritative desksを別々に照らした。
イト
DNSのanswerなら、全部authoritativeじゃないの？
ピコ
recursive resolverはcacheから答えることがある。authoritative serverが担当zoneのdataから答えたresponseとは、観測が違うよ
イト
どちらもaddress cardなのに？
ピコ
cardの値だけでなく、誰へ何を聞き、authorityとTTLをどう観測したかを分けるんだ
name serverは、DNS tree全部の台帳を持たない
RFC 1034では、name serverはdomain treeの情報を持つserver programだ。
一台がDNS tree全体のcomplete dataを持つとは限らない。
一般に、あるsubsetについてcomplete informationを持ち、別の部分へ進むpointerやcacheを持ち得る。
そのserverがcomplete informationを持ち、authorityとして答える範囲がある。
authoritative informationは、zoneという単位で組織される。
だから「name server」という広い役名だけで、返ったdataがすべてofficial / authoritativeだと決めない。
一台のsoftwareが、あるzoneにはauthoritativeで、別のnameにはcacheやreferralを返す構成もあり得る。
recursive serviceとauthoritative serviceを別hostへ分離する運用もある。
役割を、serverの見た目だけで決めない。
domainとzoneは、同じ形とは限らない
イトは、第43話のname treeを開いた。
festival.example
その下に、stage.festival.example。
さらに別の枝に、tickets.festival.exampleがある。
domainは、あるname以下に広がるsubtreeとして見られる。
zoneは、authoritative serverが一つの管理単位として持つdataの範囲だ。
もしtickets.festival.exampleを別のauthorityへdelegateすれば、その下のdomainはfestival.example domainの一部であり続ける。
でも、parentのfestival.example zoneは、delegation pointより下のauthoritative dataを持ち続けるわけではない。
parent zoneには、childへ進むためのdelegation dataが残る。
このため、domain subtreeとzone fileの範囲を常に同じと考えない。
今回のfixtureでは、stage.festival.exampleはfestival.example zoneの中にある。
tickets branchの細部はtest対象外だ。
authoritative serverは、担当zoneのdataから答える
RFC 9499は、authoritative serverを、あるzoneのoriginを知り、そのzoneに関するqueryへdefinitive answerを返せるserverとして整理している。
一つのzoneには、通常、複数のauthoritative serverがある。
primaryとsecondaryというdata維持の役割があっても、「primaryだけがauthoritativeでsecondaryは参考回答」という意味ではない。
そのzoneを正しくserveしていれば、どちらもauthoritative answerを返せる。
ただし、zone dataが各serverへ行き渡る時間や障害は別に観察する必要がある。
このfixtureでは、test開始前に二台のcurrent data一致を確認済みだ。
production運用を自動で再現しているわけではない。
AA bitは、query先を見ずに押す「公式」stampではない
RFC 1035のDNS response headerには、AA bitがある。
AAはAuthoritative Answerを示し、responseしたname serverがquestion sectionのdomain nameに対するauthorityであることを表す。
aliasを含むanswerでは、どのowner nameに対応するかに注意がいる。
この話のfixtureはaliasなしのA queryへ固定する。
known authoritative serverへ、exact QNAME / QTYPEを直接送る。
recursionを頼まないdiagnostic queryとして、RDは0にする。
ただしRDを0にしただけで、相手がauthoritativeへ変わるわけではない。
delegationから確認した担当serverをqueryし、responseのAAとanswerを一緒に観察する。
cached answerは、偽物ではない
イトはold address cardを捨てようとした。
ピコは、cardの横のtimerを照らした。
recursive resolverは、以前得たresource recordをTTLの範囲でcacheできる。
TTLが残る間、clientへold dataを返すことがある。
authoritative zoneのcurrent dataがnew addressでも、すでに配られたcached old dataがその瞬間に全世界から消えるとは限らない。
old cacheは「偽のauthority」ではない。
authoritative dataとは別の時点に得られ、期限付きで再利用されているdataだ。
RFC 2181は、authoritative data、answer sectionのnon-authoritative data、additional information等のtrustworthinessを同じものとして扱わない。
診断では、値が違うだけで片方を改ざんと決めない。
query先とauthority、cacheの残TTLを分ける。
イトの前に、三つのleverが上がる
rollback clockが鳴った。
残り、二十四秒。
old pageはまだprojectorに映っている。
new server lineを戻せば、今日のrehearsalは古い構成のままになる。
A 同じA dataを、zoneへもう一度書く
authoritative側がすでにcurrent dataなら、同じwriteを重ねても、別resolverのexisting cacheを直接消せない。
どの観測がoldなのか分からないまま、change historyだけを増やす。
B recursive resolverのcacheを、client側から強制削除する
このshared resolverはイトの管理対象ではない。
clientのlocal cacheを消しても、upstream resolver cacheまで消えるとは限らない。
権限とcache layerを混同する。
C authoritative dataとcached answerを、別query / 別trayで確かめる
mock delegationから、festival.example zoneのknown authoritative serversを確認する。
exact QNAME stage.festival.example、QTYPE A、RD 0で直接queryする。
AAとcurrent answerをauthoritative trayへ置く。
recursive resolverから返ったold answerとremaining TTLはcache trayへ残す。
二つが違えば、すぐrollbackせず、どのclockが動いているかを観察する。
ピコはrollback leverへ触れなかった。
「あと二十一秒」
イトはleverから手を離した。
「old answerが返った場所と、current zoneを持つ場所を、先に分ける」
イトはCを選んだ。
自分の手で、old address cardをauthoritative sealの下から外した。
timerを隠さず、transparent cache trayへ置く。
次に、mock delegation cardから二台のauthoritative serverを確かめた。
同じQNAME / QTYPE、RD 0のquestion cardを、一台ずつへ送った。
current zoneとold cacheが、同時に見えた
一台目のresponse lampが点いた。
response source: known authoritative server
AA: 1
A data: current
二台目も、同じcurrent A dataを返した。
このfixtureでは、二台のzone dataが一致している。
イトは二枚をauthoritative trayへ置く。
recursive cache trayには、old addressとremaining TTLが残る。
response source: recursive resolver cache
AA: 0
TTL: counting down
値は違う。
でも、観測の出どころも時間も違う。
イトはrollback leverへ透明なcoverを下ろした。
zone recordを再編集しない。
shared resolver cacheを無理に消そうともしない。
残り、十二秒。
cache trayのtimerが0になる。
次のfixture queryで、recursive resolverはusable old recordを失い、resolutionをやり直した。
今度はcurrent addressが返る。
rehearsal projectorがnew pageへ切り替わった。
blueのstageに、goldのcue starが二回点滅する。
new server lineのlampもgreenへ変わった。
「どちらが正しい？」の前に、出どころを残す
rollback clockが止まった。
イトは二つのtrayを重ねなかった。
左には、TTLが0になったold cache card。
右には、AA付きのcurrent authoritative cards。
中央には、current dataへ更新されたrecursive answer。
old cardを破らない。
それは「設定失敗」の証拠ではなく、違う時点のcacheを観察した証拠だからだ。
authoritative sealも、すべてのnameへ押せる万能stampにはしない。
sealの下には、festival.example zoneだけを示す枠が残っている。
その外側のDNS treeは、暗いままだった。
次回：answerでなく、errorが返ったら？
片づけの途中で、別のquestion cardが赤く点滅した。
今度はaddress cardがない。
response trayには、三つの異なる札が落ちている。
nameがない。
serverが処理できない。
responseそのものが時間内に来ない。
「全部『DNS error』でまとめていいの？」
ピコは、response codeとtimeoutの札を離して置いた。
次回、ピコルート第45話。
DNSエラーはどこで止まった合図？
name serverの役割を図で確かめる
authoritative server、zone、resolver、cache、DNS recordsの違いを一枚で整理するなら、ネームサーバーとは何かで確認できます。