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?

domain-name-system cname-record srv-record

— Scott
sumber

di perusahaan saya, kami banyak menggunakan catatan SRV, dan kebanyakan dari mereka menggunakan CNAME dan berfungsi dengan baik, jadi bertentangan dengan peraturan atau tidak, itu berfungsi dengan baik :)

— olivierg

Jawaban:

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).

— Massimo
sumber

Ingatlah bahwa "cukup pintar" itu relatif. Beberapa perancang perangkat lunak berpendapat bahwa memasang dengan implementasi braindead hanya mendorong lebih banyak implementasi yang sama. RFC 2781 hanya diperbarui oleh satu RFC dan bahasa tentang apa yang diharapkan sangat tegas, jadi saya tidak akan berharap banyak belas kasihan di sini.

— Andrew B

Sebagian besar aplikasi klien hanya mengandalkan pustaka sistem untuk melakukan kueri DNS, dan sebagian besar pustaka (terutama dalam bahasa tingkat yang lebih tinggi) akan mencoba yang terbaik untuk menyelesaikan kueri apa pun yang Anda berikan, dan dengan senang hati dan diam-diam akan mengikuti CNAME ke tujuannya. Catatan dan Alamat IP.

— Massimo

Aplikasi tidak memerlukan banyak kecerdasan, cukup meminta OS untuk terhubung ke "alias.domain.com" pada port 4443 dan meninggalkan semua detailnya.

— Massimo

Aplikasi klien dan pustaka sistem tidak akan memiliki kesempatan untuk mengikuti alias jika kursor hulu menolak data otoritatif dan menolak untuk melanjutkan. (yang merupakan kepintaran relatif yang saya maksudkan) Penanganan NScatatan dan pengucilan yang dilarang oleh BIND adalah contoh klasik dari ini. Terlepas dari itu, kami sepakat bahwa itu adalah permainan siapa pun dengan hasil yang tidak terduga.

— Andrew B

Beberapa server email mulai secara aktif mengabaikan MX ke CNAME, misalnya GMX medienconsulting.at/...

— Marcel Waldvogel

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.

— Andrew B
sumber