グローバルWKS (Well Known Service) 検索
WKS (Well Known Service) レコードは、RFC 1035におけるドメインネームシステムの最初の起草時に導入された、現在では非推奨で非常に硬直したDNSレコードタイプです。その主なエンジニアリング目的は、特定のIPアドレスをサポートされているインターネットプロトコル (具体的にはTCPまたはUDP) の定義済みリストにパブリックにマッピングし、それぞれの開いているポートを公に宣言することでした。例えば、管理者はWKSレコードを使用して、 192.168.1.100 にあるサーバーがポート25でのSMTPとポート21でのFTPをアクティブにサポートしていることをブロードキャストすることができました。
接続前リソースの最適化
ネットワークコンピューティングの初期において、帯域幅が制限され、レイテンシが高いARPANET接続上でTCPハンドシェイクを確立することは、計算コストが高く非常に遅いものでした。WKSレコードは効率化のハックとして設計されました。これにより、クライアントアプリケーションは、リモートサーバーへのトラフィックのルーティングを試みる前に、軽量なUDPベースのDNS層にクエリを実行して、リモートサーバーが実際に特定のサービスをサポートしているかどうかを確認できました。ユーザーがTelnetセッションを開始しようとしたが、ドメインのWKSレコードのビットマップにポート23が明示的にリストされていない場合、ローカルのクライアントアプリケーションは即座に接続の試みを中止できました。これにより、ネットワークのタイムアウトを待つ間にクライアントがハングするのを防ぎ、大西洋横断リンク上の貴重な帯域幅を節約できました。
ビットマップのボトルネック
WKSレコードの致命的な欠陥は、その基盤となるデータ構造でした。ペイロードは非常に硬直したバイナリビットマップとしてエンコードされ、各ビットはInternet Assigned Numbers Authority (IANA) によって定義された特定のポート番号に対応していました。インターネットサービスが複雑に爆発するにつれ、このフォーマットは信じられないほど扱いにくくなり、人間の管理者が手動で維持することはほぼ不可能になりました。システム管理者が新しいサービスをインストールしたりポートを閉じたりするたびに、サーバーの正確な状態を反映させるためだけに、ビットマップを再生成し、ゾーンのシリアルを更新し、グローバルDNSの伝播を待つ必要がありました。管理上のオーバーヘッドは、帯域幅の節約を劇的に上回っていました。
セキュリティの露出とSRVによる置き換え
HINFOレコードと同様に、WKSプロトコルはネットワークセキュリティに対して完全に盲目でした。パブリックDNS層に直接、サーバー上のすべてのオープンポートの包括的なプレーンテキストリストを公開することは、ハッカーに事前スキャンされた包括的な偵察 (Reconnaissance) マップを与えることになりました。これはNmapのような、ノイズが多く簡単に検出されるポートスキャナーの必要性を完全に排除しました。これらの致命的なアーキテクチャおよびセキュリティ上の欠陥を認識したIETFは、RFC 1123の公開により、WKSレコードを公式に廃止 (Obsolete) と宣言しました。特定のサービスとポートをドメイン名にマッピングするという要件は、その後、SRV (Service) レコードに完全に移行されました。SRVレコードは無限に大きな柔軟性を提供し、ターゲットマシンの基盤となるポートプロファイル全体を公開することなく、動的なポート割り当て、負荷分散の重みづけ、および優先度フェイルオーバーを可能にします。BIND9やCoreDNSなどの最新のDNSソフトウェアは、WKSのフォーマットを完全に無視します。