第42話のrelay roomで、イトは二枚のreferralをたどった。
mock authoritativeからaddress dataを受け取り、stub deskまで返した。
でも、机には三種類の札が残っている。
URL ribbon。
青いname card。
緑のIP address card。
「結局、どれが目的地なの？」
そのとき、rehearsal projectorの確認bellが鳴った。
本番前に、stage用のfinale pageを一度だけ表示する。
指定されたURLは、これだ。
https://stage.festival.example/program/finale
残り、六十秒。
長い札なら、全部をDNSへ渡せばいい？
イトはURL ribbonを両手で持ち上げた。
schemeも、hostも、pathもつながっている。
「これ全部が行き先なら、全部を名前として聞けば間違えない」
前話のresolver deskへ、ribbonを丸ごと押し込む。
QNAME slotから、半分以上がはみ出した。
input gateはquestion cardを作らない。
input kind: URI
DNS question: not created
これはDNS serverから返ったerror responseではない。
学習fixtureのresolver input gateが、DNS questionへできない形をquery前に止めた。
rehearsal projectorはblackのままだ。
残り、五十二秒。
イトは、URL ribbonを強く押した。
slashの部分がslotへ引っかかる。
「URLにdomainが入っているなら、URL全部がdomainじゃないの？」
URL、host、domain name、addressは重ならない
ピコは、ribbonの上に四本の細いlightを落とした。
イト
domain nameは、人が読めるIP addressだと思ってた
ピコ
nameとaddressは関連づくことがある。でも同じ値の別表記ではないよ
イト
じゃあURLは、domain nameを長くしたもの？
ピコ
URLにはaccess方法やhost、resourceのpath等が入る。DNSへ聞くnameは、その全部ではない
RFC 3986では、URIは次のcomponentを持ち得る。
scheme://authority/path?query#fragment
すべてのURIに、すべてのcomponentが必ずあるわけではない。
今回のURLでは、httpsがschemeだ。
authorityの中にあるhostが、stage.festival.example。
/program/finaleがpathだ。
URL全体は、どのresourceへどうaccessするかを識別する札になる。
hostだけでも、pathだけでも、同じURLにはならない。
URIのhostは、いつもdomain nameとは限らない
イトはhost slotだけを拡大した。
RFC 3986のhostは、IP literal、IPv4 address、registered nameの形を取り得る。
だから、URLで//の後に見えるものを、何でもDNS domain nameと呼ぶことはできない。
今回のfixtureは、registered nameとして書かれたstage.festival.exampleをDNSで調べる。
.exampleはRFC 2606でdocumentation用に予約されたnameだ。
実在serviceのaddressやpublic DNSを示さない。
resolverへ渡すのは、schemeやpathを含むURL ribbonではない。
このhost nameと、欲しいrecord typeだ。
dotは、飾りではなくlabelの境界
青いhost cardが、三枚のtileへ開いた。
stage
festival
example
RFC 1034のdomain name spaceはtreeだ。
各nodeはlabelを持つ。
domain nameは、あるnodeからrootまでのpathに並ぶlabelsの列になる。
表示するときは、最も具体的なlabelからrootに近いlabelへ、左から右に書く。
人が入力する形では、labelの境界をdotで示す。
完全なdomain nameをDNSの表記で書くと、最後にroot labelを示すdotが付く形もある。
ただしURLでは、末尾のdotを省いたhostをよく見る。
このfixtureでは、URLにあるstage.festival.exampleをそのまま使う。
stageだけを抜き出しても、同じdomain nameにはならない。
festivalだけでも足りない。
三labelが順番どおり並んで、今回のhost nameになる。
domainは、treeの一部分
「三枚のうち、どれがdomainなの？」
イトはfestival tileを指した。
domainとdomain nameは、日常の説明で幅広く使われる。
DNSのtreeとして見ると、domain nameはnodeを識別するnameだ。
domainは、そのnode以下に広がるname spaceの一部分を指す。
stage.festival.exampleは、festival.exampleの下にあるsubdomainだ。
この包含関係は、name全体の末尾が一致するかで確かめられる。
途中に同じ単語が見えるだけでは、同じdomainとは判断できない。
どこまでを登録単位と呼ぶか、public suffixをどう扱うかはDNS treeだけで決まる単純な規則ではない。
その運用詳細や、似たnameを使うphishingの点検は別話へ譲る。
ここでは、dotで分けたlabelを一語だけのbrand札へ縮めない。
domain nameは、一個のIP addressを隠す札ではない
イトは、青い三label cardの上へ、昨日の緑のaddress cardを重ねた。
角が合わない。
DNSでは、nameに対してA / AAAA等のresource dataを問い合わせられる。
一つのnameに複数のaddress dataがある場合もある。
一方のaddress familyだけがある場合もある。
時期や場所、resolverが得たresponseによって、候補が変わる場合もある。
逆に、一つのIP addressで複数のhostを受ける構成もある。
「domain name一個 = 永久に同じIP address一個」ではない。
そしてresolutionが終わっても、元のhost nameを捨てない。
RFC 9110が扱うHTTPのtarget URIやauthorityでも、どのhost / resourceを求めるかという情報は役割を持つ。
TLSやHTTPの詳しい使い方は後の話で扱う。
今は、addressはconnection candidate rackへ、original hostはauthority railへ分けて残す。
イトの前に、三つの分け方が開く
rehearsal projectorのbellが、二度鳴った。
残り、二十九秒。
resolver input gateには、引っかかったURL ribbon。
机には、昨日のIP address card。
その間に、空のcomponent railがある。
A URL ribbonを丸ごと、QNAME slotへ押し込む
schemeとpathが混ざったままだ。
さっきと同じinput gateで止まり、DNS questionは作られない。
B 昨日のIP addressだけで接続する
現在のaddress dataかを確認しない。
original hostとpathも捨てるため、どのhostのどのresourceを求めるのか残らない。
C URLをcomponentへ分け、exact hostをresolverへ渡す
schemeはprotocol railへ置く。
host stage.festival.exampleは三labelを崩さず、QNAMEとしてA / AAAAを問い合わせる。
path /program/finaleはresource railへ残す。
返ったaddress dataはconnection candidate rackへ置き、original hostもauthority railへ残す。
ピコはcomponent railの境界を照らしただけだった。
「あと二十六秒」
イトは、はみ出したURL ribbonをQNAME slotから引き抜いた。
「長い一枚を押し込むんじゃない。同じURLの中で、役目を分ける」
イトはCを選んだ。
自分の手で、scheme cardをprotocol railへ外した。
次に、三labelがつながった青いhost cardをauthority railへ置く。
そのcardと同じnameをQNAME欄へ写し、A / AAAAのquestionをresolverへ送った。
path ribbonは切り捨てず、resource railへ固定した。
nameを消さず、addressでconnectionする
resolverのanswer lampが点いた。
このfixtureでは、現在使えるaddress dataが返る。
イトはgreenのcardを、connection candidate rackへ置いた。
blueのstage.festival.example cardとは重ねない。
connection controllerが、利用できるcandidateへのrouteを開く。
original hostはauthority railに残っている。
path ribbonの/program/finaleは、resource railからrequest benchへ進む。
protocol railでは、httpsの手順が選ばれている。
一枚だったURLの各componentが、別のstageで働いた。
rehearsal projectorがblueに変わる。
表示されたのは、general entrance pageではない。
stage用のfinale cue pageだ。
goldの星が、指定された位置で一度だけ点滅した。
残り、八秒。
DNSがURLをIP addressへ丸ごと変換したのではない。
DNSで得たaddress candidateがconnectionを助けた。
元のhostとpathが残っていたから、目的のresourceまで届いた。
三種類の札は、最後まで三種類だった
確認bellが止まった。
イトはcomponent railを片づけなかった。
上段には、scheme cardと三labelのhost cardとpath ribbon。
下段には、TTL timer付きのaddress candidate card。
resolver inputには、host nameとtypeだけを書いたquestion card。
三つは一枚に重ならない。
それでも、一本のaccessとしてprojectorまでつながっている。
イトは、最初にURL ribbonを押し込んだwide slotへ、細い仕切りを三枚立てた。
scheme。
host。
path。
その隣のaddress rackだけは、別の高さに置いた。
次回：そのnameについて、誰が正式に答える？
三labelのhost cardをたどると、relay roomの最後のstationが開いた。
中には、zoneごとに分かれた台帳がある。
でも、一つのname serverがDNS treeのすべてを持っているわけではない。
イトは、stage.festival.exampleのquestion cardを持ち上げた。
「このnameについて、どのserverが正式なdataを持っているの？」
ピコは、authoritativeとcacheの二つのsealを離して置いた。
次回、ピコルート第44話。
ネームサーバーはどの台帳を持つ？ 担当デスクを探そう
domain nameの基本を図で確かめる
domain name、subdomain、URL、IP addressの違いを一枚で整理するなら、ドメインとは何かで確認できます。