RFC 2782に違反してCNAMEエイリアスを指す公開されたSRVレコード？

いくつかの仕事の責任の中で、SRVレコードを骨組みにする必要があり、ウィキペディアの声明をDNSの発掘で見ているものと一致させようとしています。

SRVレコードのターゲットは、アドレスレコード（AまたはAAAAレコード）を持つホスト名を指している必要があります。CNAMEレコードでホスト名を指すことは有効な構成ではありません。

しかしdig、CNAMEレコードのエイリアスである名前を指すSRVレコードを返すレコードが表示されます。

つまり、次のようなものです。

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

SRVレコードは、Wikipediaのエントリで許可されていない方法で構成されているようです。私は何を誤解していますか？SRVレコードが、アドレスレコードではなくCNAMEレコードを持つalias.domain.comを指していることを示していませんか？

domain-name-system cname-record srv-record

— スコット
ソース

私の会社ではSRVレコードを多く使用していますが、それらのほとんどはCNAMEを使用しており、正常に動作します。そのため、ルールに反するかどうかにかかわらず、うまく動作します:)

— オリビエル

回答:

あなたが引用しているウィキペディアの記事は、関連するものを報告します、SRVレコードに RFC 2782の状態。

目標

ターゲットホストのドメイン名。この名前には1つ以上のアドレスレコードがなければならず、名前はエイリアス（RFC 1034またはRFC 2181の意味）であってはなりません（MUST NOT）。

あなたが見ているのは、明らかにルール違反です。ただし、そのSRVレコードを探しているクライアントアプリケーションがCNAMEレコードを適切に処理するのに十分な場合、応答でAレコードのみを想定している場合でも、機能する可能性があります（通常は機能します）。

ただし、まったく機能しない場合もあります。サポートされておらず、クライアントアプリケーションに完全に依存しています。したがって、適切なルールに従わず、誤った結果や予測不可能な結果につながる可能性があるため、回避する必要があります。

これは、MXレコードを1つだけでなく2つの RFCで間違っていると定義されているCNAMEを指すことに似ていますが、それでも非常に一般的な方法です（メールサーバーに問題があるようには見えません）。

— マッシモ
ソース

「十分にスマート」は相対的なものであることに注意してください。一部のソフトウェア設計者は、頭の痛い実装に耐えることは、同じ実装をさらに促進するだけだと考えています。RFC 2781は単一のRFCによってのみ更新されており、何を期待するかについての言語は非常に堅実であるため、ここではあまり慈悲を期待しません。

— アンドリューB

ほとんどのクライアントアプリケーションはDNSクエリを実行するためにシステムライブラリに依存しているだけであり、ほとんどのライブラリ（特に高レベル言語）は、あなたが投げたクエリを解決するために最善を尽くし、CNAMEに従って目的のAレコードとIPアドレス。

— マッシモ

アプリケーションはそれほどスマートである必要はありません。OSにポート4443で「alias.domain.com」に接続し、すべての詳細を残すように要求するだけです。

— マッシモ

上流の再帰者が信頼できるデータを拒否して続行を拒否した場合、クライアントアプリケーションとシステムライブラリはエイリアスを追跡する機会がありません。（これは私が言及していた相対的なスマートさです）BINDのNSレコードの処理と禁止されたエイリアスはこの典型的な例です。とにかく、予測不可能な結果をもたらす誰のゲームでもあることに同意します。

— アンドリューB

GNAMEmedienconsulting.at/…など、一部のメールサーバーはCNAMEへのMXを積極的に無視し始めました

— Marcel Waldvogel

それは制限された動作の例です、はい。制限自体は、「ターゲット」の定義のRFC 2781に基づいています。

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

禁止された構成を許可するDNSサーバーソフトウェアは、残念ながら新しいものではありません。エイリアスターゲットが禁止されている他のレコードタイプ（NSやなど）の場合と同様に、実際に発生する可能性がありMXます。（上記の通り）

それが野生で見つかるからといって、それが「大丈夫」であることを意味するわけではなく、標準が無視されたときに何が起こるかは製品ごとに異なります。SRVレコードとの相互作用はテストしていませんが、NSエイリアスを指しているレコードに関するISC BINDの非常によく知られている設計上の決定は、再帰中に見つかった場合、レコードを完全に削除することです。この方法ですべてのNSレコードが削除されるSERVFAILと、すべてのクエリの結果は問題のサブドメインになります。

要するに、標準に固執します。それが唯一の安全なことです。

— アンドリューB
ソース