NW 39 - AddrToName

Q: MacTCP および OT 1.0.x では、ホスト・ファイルを使って AddrToName を実行すると、名前が正しいアドレスとして解決されます。しかし、OT 1.1 ではAddrToName の戻り値は authNameErr になってしまいます。これはどういうことなのですか？

A: Open Transport 1.0.8 では、名前からアドレスおよびアドレスから名前への変換を同じキャッシュに格納し、名前からアドレスまたはアドレスから名前へのマッピングがリクエストされたときには、そのキャッシュを検索していました。これは一見正しいように見えますが、実は問題があります。１つのサービス名を CNAME リストのエイリアスとして登録し、リストの項目がそれぞれ実際のサーバを指すロードシェアリングシステムがあります。OT 1.0.8 のキャッシュ方式の場合、ロードシェアリングを利用したリバース検索はいつも元のエイリアスに対して同じホスト名とハードウェア・アドレスを結び付けてしまい、正常に動作しませんでした。

これを受けて、OT 1.1 では、アドレスから名前へのマッピング (PTR レコード) をキャッシュに格納することをやめ、アドレスから名前へのマッピングがリクエストされても、名前からアドレスへのマッピングを格納したキャッシュを検索しなくなりました (受け取った CNAME レコードの取り扱い方法も変更しましたが、この質問には直接関係ないので詳細は省略します)。キャッシュを検索する代わりに、設定されたドメイン・ネーム・サーバを対象にクエリーを実行します。たとえ、DNS のいずれかからも信頼できる情報を取得できないように見える場合も同様です (あるいは、DNS をまったく使用していない場合も)。

Mac の「Hosts」ファイルは、伝統的に PTR レコードのサポートはありませんでした。また、現在でも PTR レコードはサポートされていません。というのも、これを行おうとすると、これらのレコードのキャッシュに逆戻りすることになり、再度ロードシェアリングサーバを犯すことになってしまうためです。ホスト・ファイルでは、A (名前からアドレス)、CNAME (完全に限定されたドメイン名のエイリアス)、および NS (ドメイン・ネーム・サーバの完全に限定されたドメイン名) リソース・レコードだけがサポートされています。PTR マッピングが必要な場合は、ローカル・ドメイン・ネーム・サーバの管理者がそれを登録するか、独自のコードで以前の名前からアドレスへのマッピングを維持する必要があります。

ご質問のような状況が起こることは残念なことですが、アップルでは、Open Transport ができるかぎり広範囲のクライアントをサポートできるようにしようと考えています。場合によっては、これらのクライアントと他のクライアントとの間にコンフリクトが発生する可能性もありますが、そのときには Apple としても何らかの選択を行う必要があると考えられます。ただし、その場合にも、アップルでは、技術的により正しい選択を行おうとしています。残念ながら、ご質問のような状況はこうした選択の 1 つなのです。

[ Technical Q&A's : Communications & Collaboration : Networking : NW39 ]