Catatan SRV yang diterbitkan menunjuk ke CNAME alias melanggar RFC 2782?

Dalam beberapa tanggung jawab kerja saya perlu mencari tahu tentang catatan SRV, dan saya mencoba untuk mendamaikan pernyataan Wikipedia dengan apa yang saya lihat dalam penggalian DNS.

Menurut entri catatan SRV Wikipedia ,

target dalam catatan SRV harus menunjuk ke nama host dengan catatan alamat (catatan A atau AAAA). Menunjuk ke nama host dengan catatan CNAME bukan konfigurasi yang valid.

tapi saya melihat catatan di mana digmengembalikan catatan SRV menunjuk ke nama yang merupakan alias dalam catatan CNAME.

Yaitu, kira-kira seperti ini:

> 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

Sepertinya catatan SRV dikonfigurasi persis seperti yang dikatakan entri Wikipedia tidak diizinkan. Apa yang saya salah pahami? Bukankah itu menunjukkan bahwa catatan SRV menunjuk pada alias.domain.com, yang memiliki catatan CNAME, bukan catatan alamat?

Artikel Wikipedia yang Anda kutip melaporkan apa yang dinyatakan oleh RFC 2782 untuk catatan SRV yang relevan :

Target

Nama domain dari host target. HARUS ada satu atau lebih catatan alamat untuk nama ini, nama HARUS TIDAK menjadi alias (dalam arti RFC 1034 atau RFC 2181).

Apa yang Anda lihat adalah pelanggaran yang jelas terhadap aturan; namun, itu mungkin berhasil (dan biasanya memang demikian), jika aplikasi klien apa pun yang mencari catatan SRV cukup pintar untuk menangani catatan CNAME dengan benar, bahkan jika itu hanya mengharapkan catatan A dalam respons.

Tetapi itu juga mungkin tidak berfungsi sama sekali: itu tidak didukung dan sepenuhnya tergantung pada aplikasi klien; karena itu harus dihindari, karena tidak mengikuti aturan yang tepat dan dapat menyebabkan hasil yang salah dan / atau tidak dapat diprediksi.

Ini mirip dengan mengarahkan catatan MX ke CNAME, yang didefinisikan sebagai kesalahan tidak hanya pada satu , tetapi dua RFC, namun ini merupakan praktik yang cukup umum (dan tidak ada server mail yang tampaknya memiliki masalah dengannya).

Itu contoh perilaku terbatas, ya. Pembatasan itu sendiri berasal dari RFC 2781 dalam definisi "target":

   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.

Sayangnya, perangkat lunak server DNS yang memungkinkan konfigurasi terlarang bukanlah hal yang baru. Itu bisa dan memang terjadi, seperti halnya dengan tipe catatan lain di mana target alias dilarang seperti NSdan MX. (disebutkan di atas)

Hanya karena dapat ditemukan di alam liar tidak berarti bahwa itu "oke", dan apa yang terjadi ketika standar diabaikan bervariasi dari satu produk ke produk lainnya. Saya belum menguji interaksi dengan SRVcatatan, tetapi keputusan desain yang sangat terkenal oleh ISC BIND sehubungan dengan NScatatan yang menunjuk pada alias adalah untuk menghapus catatan sepenuhnya jika ditemukan selama rekursi. Jika semua NScatatan dijatuhkan dengan cara ini, hasil dari semua kueri akan menjadi SERVFAILuntuk subdomain yang dimaksud.

Singkatnya, tetap berpegang pada standar. Itu satu-satunya hal yang aman untuk dilakukan.