要約

  • DNS SRVにより、domain管理者は特定のserviceとtransportについて、複数target、port、primaryとbackupの階層、同順位内の静的な選択傾向を公開できるようになった。
  • PriorityとWeightは別の判断である。clientは到達できる最小のPriorityを先に試し、その一つの階層内だけでWeightに基づく乱択順序を作る。
  • SRVは発見の証拠にとどまる。clientはcanonical targetのaddressを解決し、指定transportとportへ接続し、応答するapplicationのidentityを別に確かめる。

serviceの所在がclient側の常識だった時代

初期DNSが直接答えたのは、host名に対応するaddressだった。serviceを見つけるため、applicationは既知のport、/etc/servicesのlocal表、または運用者が文書に書いたserver名を補った。公開名、service host、port、failover計画は一つの慣習に束ねられていた。

1996年10月のRFC 2052は、別の問いを扱う実験的resource recordを提案した。hostのaddressではなく、domain内のserviceの所在をDNSへ尋ねる。返答には複数targetとPriority、Weight、Portを置けた。

2000年2月、RFC 2782がProposed Standardとして前文書を置き換えた。複数serverを一つのdomainで用い、serviceをhost間で小さな手間で移し、primaryとbackupを分けることが狙いだった。IANAは現在もSRVをDNS type 33のServer Selectionとして登録している。

query名がservice、transport、domainを切り分けた

example.comでTCPのLDAPを探すclientは、domainのaddressと既定portを推測せず、_ldap._tcp.example.comをqueryする。左のlabelがserviceとtransportを示し、残りが管理domainを示す。

RFC 2782はserviceとprotocolのlabelへunderscoreを加えた。通常のDNS名とservice metadataが衝突しにくくするためであり、同時にWeightのalgorithmも明確化した。

その後、名前のcoordinationも制度化された。RFC 6335はservice nameとport numberの登録手続きを統合した。portの割当がなくても、登録service名はSRVなどの発見機構に使える。登録は名前を一意にするが、IANAによるproductやtrafficの承認ではない。

2019年のRFC 8552は、global scopeを持つunderscored DNS node nameのregistryを作った。RFC 8553は、既存実装を保ちながらSRV利用仕様をそのregistryへ適合させた。衝突を避ける記法は、検証可能な割当境界になった。

四fieldは四種類の主張である

SRVのRDATAはPriority、Weight、Port、Targetから成る。これらを単なるDNS load balancer設定と読むと設計を誤る。

Priorityはfailoverの階層である。clientは数値が最も小さく到達可能なtargetを試さなければならない。大きい数値の記録はtrafficが少ない同格ではなく、低い階層が使えない時に初めて候補となるbackupである。

Weightは同じPriorityのrecord間だけで働く。clientはweightの合計と累積値を作り、一様乱数で一つを選び、取り除いて繰り返す。domainは相対的な選択傾向を示し、実際の順序はclientが作る。正のweightがある集合でWeight 0も絶対禁止ではなく、仕様のalgorithmではごく小さな選択機会が残る。

RFC 2782の例では、Priority 0の二台にWeight 1と3が付く。十分多い独立したfirst choiceなら後者はおよそ四分の三へ近づく。Priority 1の二台は、preferred pairが使えない時だけ現れる。一回のqueryが正確な3対1を保証するわけではない。

Weightはlive loadのtelemetryでもない。CPU、queue、latencyはDNS cacheより速く変化する。短すぎるTTLで追えばDNS負荷が増え、cacheと信頼性が損なわれる。fieldが表すのは、相対的なserver能力やnetwork接続のような静的情報である。

Portは、もう一つの知識をclientからdomainへ移す。登録portと一致することは多いが必須ではない。各clientのlocal fileを更新せずに、serviceを標準portやUnixのprivileged rangeから移せる。

Targetにはaddress recordが必要で、aliasであってはならない。clientはAdditional DataのA/AAAAを使うか、別queryで得る。SRVのtargetはaddress解決へ終端し、CNAMEやDNAMEのchainを隠す場所ではない。

見つからないことと「提供しない」は違う

唯一のTargetがroot label .なら、そのdomainは当該serviceを明示的に提供しない。domain自体や他serviceの不存在を意味せず、一つのservice-transport組に限った肯定的な不提供表明である。

利用可能なSRVがない場合、元のprocedureはdomainのaddressを引き、旧来の規約を試す。RFC 2782は全clientの同時upgradeを非現実的と認め、旧client向けaddressを残すよう助言した。ただしbackup専用hostを通常address集合へ置けば、旧clientがprimaryと誤解するため避けるべきだった。

compatibilityは中立ではない。残せば接続を維持できるがSRVのPriorityやPortを迂回する。消せばpolicyは統一されるが、SRV非対応softwareが取り残される。移行のcostは運用者に残された。

DNSが公開したのは候補であってservice証明ではない

clientは全RRsetをparseし、Priorityごとに分け、Weightで順序を作り、Targetのaddressを解決し、transport-address-portを試す。各段階は独立に失敗する。

authenticなDNS answerが証明できるのは、該当DNS authorityが何を公開したかまでである。port上のprocessのhealth、application identity、target operatorの同意、複数targetの共通所有までは証明しない。

表現力が増えた分、誤った発見情報の影響も増える。DNS spooferはhostやaddressだけでなくportも偽れる。domainは第三者hostをTargetにして不要なtrafficを送れる。細かなport指定はfilterを難しくし、DNSとnetwork運用の協力を重要にする。

適用のmandateもdomain単独では作れない。application protocol仕様がSRV利用を示し、symbolic service nameとsecurity considerationsを定義する必要がある。protocolがqueryの意味を与え、domainが候補を公開し、clientが実行し、targetが実serviceで自らを証明する。

根拠とその限界

本稿の閉じたsource setはRFC 2052、RFC 2782、RFC 6335、RFC 8552、RFC 8553、現在のIANA DNS Parametersである。これらは仕様と境界を示すが、現在の普及率、latency短縮、weight精度、実装準拠、live serviceのhealthは測定していない。

SRVの歴史的貢献は限定の中にある。serviceは一つのhostとdefault portから離れても安定名を保てた。しかしその名前は、接続とapplication検証を代行する権限を得なかった。