Mengapa data CNAME tidak dapat digunakan di apex (alias root) domain?


117

Ini adalah Pertanyaan Canonical tentang CNAME di apeks (atau akar) zona

Sudah menjadi rahasia umum bahwa CNAMEcatatan di puncak domain adalah praktik yang tabu.

Contoh: example.com. IN CNAME ithurts.example.net.

Dalam kasus terbaik, perangkat lunak nameserver skenario mungkin menolak memuat konfigurasi, dan dalam kasus terburuk mungkin menerima konfigurasi ini dan membatalkan konfigurasi untuk example.com.

Baru-baru ini saya memiliki perusahaan webhosting meneruskan instruksi ke unit bisnis yang kami butuhkan untuk CNAME puncak domain kami ke catatan baru. Mengetahui bahwa ini akan menjadi konfigurasi bunuh diri ketika diumpankan ke BIND, saya menasehati mereka bahwa kami tidak akan dapat mematuhinya dan bahwa ini adalah saran tidur pada umumnya. Perusahaan webhosting mengambil sikap bahwa itu tidak langsung dilarang oleh RFC mendefinisikan standar dan bahwa perangkat lunak mereka mendukungnya. Jika kami tidak dapat CNAME apex, saran mereka adalah tidak memiliki catatan apex sama sekali dan mereka tidak akan menyediakan server web pengarah. ...Apa?

Sebagian besar dari kita tahu bahwa RFC1912 menegaskan hal itu A CNAME record is not allowed to coexist with any other data., tetapi mari kita jujur ​​pada diri kita sendiri di sini, bahwa RFC hanyalah informasi. Yang paling dekat yang saya tahu bertele-tele yang melarang praktik ini dari RFC1034 :

Jika CN CNAME hadir di sebuah node, tidak ada data lain yang harus ada; ini memastikan bahwa data untuk nama kanonik dan aliasnya tidak boleh berbeda.

Sayangnya saya sudah cukup lama berkecimpung dalam industri ini untuk mengetahui bahwa "seharusnya tidak" tidak sama dengan "tidak boleh", dan itu adalah tali yang cukup bagi sebagian besar perancang perangkat lunak untuk digantung. Mengetahui bahwa tautan singkat ke slam dunk akan sia-sia, saya akhirnya membiarkan perusahaan itu pergi dengan omelan karena merekomendasikan konfigurasi yang dapat merusak perangkat lunak yang biasa digunakan tanpa pengungkapan yang tepat.

Ini membawa kita ke T&J. Untuk sekali ini saya ingin kita benar-benar teknis tentang kegilaan CNAME puncak, dan tidak membahas masalah seperti yang biasa kita lakukan ketika seseorang memposting subjek. RFC1912 terlarang, seperti halnya RFC Informasi lain yang berlaku di sini yang tidak saya pikirkan. Mari kita matikan bayi ini.


1
RFC 1034 memang mendahului RFC 2119 dengan sedikit waktu dan pengalaman.
Michael Hampton

Jawaban:


94

CNAMEcatatan pada awalnya dibuat untuk memungkinkan beberapa nama yang menyediakan sumber daya yang sama untuk alias "nama kanonik" tunggal untuk sumber daya. Dengan munculnya virtual hosting berbasis nama, itu telah menjadi biasa untuk menggunakannya sebagai bentuk umum dari alamat IP alias. Sayangnya, kebanyakan orang yang berasal dari latar belakang web hosting mengharapkan CNAMEcatatan untuk menunjukkan kesetaraan dalam DNS , yang tidak pernah menjadi maksudnya. Apex berisi tipe rekaman yang jelas tidak digunakan dalam identifikasi sumber daya host kanonik ( NS, SOA), yang tidak dapat di aliasing tanpa melanggar standar di tingkat fundamental. (khususnya dalam hal pemotongan zona )

Sayangnya, standar DNS asli ditulis sebelum badan-badan pengatur standar menyadari bahwa kata-kata eksplisit diperlukan untuk mendefinisikan perilaku yang konsisten ( RFC 2119 ). Itu perlu untuk membuat RFC 2181 untuk mengklarifikasi beberapa kasus sudut karena kata-kata yang tidak jelas, dan verbiage diperbarui membuatnya lebih jelas bahwa a CNAME tidak dapat digunakan untuk mencapai aliasing puncak tanpa melanggar standar.

6.1. Otoritas zona

Server otoritatif untuk zona disebutkan dalam catatan NS untuk asal zona, yang, bersama dengan catatan Mulai Otoritas (SOA) adalah catatan wajib di setiap zona. Server seperti itu otoritatif untuk semua catatan sumber daya di zona yang tidak di zona lain. Catatan NS yang menunjukkan pemotongan zona adalah properti dari zona anak yang dibuat, seperti halnya catatan lain untuk asal zona anak itu, atau setiap sub-domainnya. Server untuk suatu zona tidak boleh mengembalikan jawaban otoritatif untuk kueri yang terkait dengan nama-nama di zona lain, yang mencakup NS, dan mungkin A, catatan pada pemotongan zona, kecuali jika itu juga merupakan server untuk zona lain.

Ini menetapkan bahwa SOAdan NScatatan adalah wajib, tetapi tidak mengatakan tentang Aatau jenis lain yang muncul di sini. Mungkin kelihatannya berlebihan bahwa saya mengutip ini, tetapi itu akan menjadi lebih relevan dalam sekejap.

RFC 1034 agak kabur tentang masalah yang dapat muncul ketika CNAMEada bersama jenis rekaman lainnya. RFC 2181 menghapus ambiguitas dan secara eksplisit menyatakan jenis rekaman yang diizinkan ada di sampingnya:

10.1. Catatan sumber daya CNAME

Catatan DNS CNAME ("nama kanonik") ada untuk memberikan nama kanonik yang dikaitkan dengan nama alias. Mungkin hanya ada satu nama kanonik tersebut untuk satu alias saja. Nama itu umumnya harus merupakan nama yang ada di tempat lain di DNS, meskipun ada beberapa aplikasi yang jarang untuk alias dengan nama kanonik yang menyertainya tidak ditentukan dalam DNS. Nama alias (label catatan CNAME) dapat, jika DNSSEC sedang digunakan, memiliki SIG, NXT, dan RR Kunci, tetapi mungkin tidak memiliki data lain. Yaitu, untuk label apa pun di DNS (nama domain apa saja), persis salah satu dari yang berikut ini benar:

  • satu catatan CNAME ada, opsional disertai oleh SIG, NXT, dan RR KUNCI,
  • satu atau lebih catatan ada, tidak ada catatan CNAME,
  • nama ada, tetapi tidak memiliki RR terkait dari jenis apa pun,
  • nama itu tidak ada sama sekali.

"alias nama" dalam konteks ini mengacu pada sisi kiri CNAMEcatatan. Daftar bullet membuatnya secara eksplisit jelas bahwa SOA, NS, dan Acatatan tidak dapat dilihat pada simpul mana CNAMEjuga muncul. Ketika kami menggabungkan ini dengan bagian 6.1, tidak mungkin untuk CNAMEada di apex karena harus hidup berdampingan dengan wajib SOAdan NScatatan.

(Ini tampaknya melakukan pekerjaan itu, tetapi jika seseorang memiliki jalan yang lebih pendek untuk membuktikan tolong beri celah padanya.)


Memperbarui:

Tampaknya kebingungan yang lebih baru datang dari keputusan Cloudflare baru-baru ini untuk memungkinkan catatan CNAME ilegal didefinisikan di puncak domain, di mana mereka akan mensintesis catatan A. "Sesuai RFC" seperti yang dijelaskan oleh artikel yang ditautkan mengacu pada fakta bahwa catatan yang disintesis oleh Cloudflare akan bermain dengan baik dengan DNS. Ini tidak mengubah fakta bahwa itu adalah perilaku yang sepenuhnya khusus.

Menurut pendapat saya ini adalah merugikan komunitas DNS yang lebih besar: itu sebenarnya bukan catatan CNAME, dan menyesatkan orang untuk percaya bahwa perangkat lunak lain kurang karena tidak mengizinkannya. (seperti yang ditunjukkan oleh pertanyaan saya)


8
Saya setuju dengan bukti ini dan saya pikir dua langkah bukti ini tidak panjang atau berbelit-belit. (1. puncak zona dijamin memiliki setidaknya SOA+ NScatatan, 2. CNAMEcatatan tidak diizinkan untuk hidup berdampingan dengan data lain)
Håkan Lindqvist

2
Secara keseluruhan, saya pikir ini penjelasan yang sangat bagus. Jika ada yang bisa ditambahkan, saya pikir itu mungkin akan lebih jauh menjelaskan apa CNAMEarti sebenarnya dari sebuah catatan, karena itu mungkin merupakan tipe catatan yang paling banyak disalahpahami. Meskipun itu agak di luar batas, saya pikir ini menjadi FAQ adalah akibat langsung dari banyak (sebagian besar?) Tidak memiliki pemahaman yang tepat CNAME.
Håkan Lindqvist

2
OK itu ilegal tetapi apakah masuk akal? Mengapa domain dengan CNAME membutuhkan catatan NS dan SOA? Dan jika ya, mengapa tidak memilikinya?
Denis Howe

2
@Denis Itu tidak bisa dijawab secara komprehensif dalam komentar. Jawaban terpendek adalah bahwa Anda perlu membaca RFC (1034, 1035) dan memiliki pemahaman yang baik tentang apa itu rujukan, apa perilaku yang diperlukan untuk rujukan (OTORITAS, kehadiran catatan SOA, dll.), Dan mengapa jenis "Rujukan kurang" alias melanggar banyak harapan server DNS pada tingkat fungsional. Dan itu hanya permulaan saja. Pertanyaan itu bukan topik yang baik untuk di sini karena bersifat spekulatif dan tidak berakar pada masalah yang Anda temui saat bekerja dengan server DNS yang sesuai standar dan dirancang dengan benar.
Andrew B

6
@Ekevoo Satu dapat berpendapat bahwa implementasi HTTP seharusnya telah diadopsi SRV, yang juga akan membuat ini menjadi tidak masalah. Masalahnya tidak terbatas pada apa yang dibahas di sini; CNAMEadalah, bertentangan dengan kepercayaan populer, bukan pasangan yang cocok untuk apa yang dibutuhkan. Pada akhirnya, karena CNAMEtidak berfungsi seperti yang diharapkan orang (!) Dan tidak dapat dirancang ulang secara surut dan karena implementasi HTTP tidak digunakan SRV, tampaknya lebih mungkin bahwa fungsionalitas gaya "alias" menjadi lebih lazim untuk memenuhi HTTP (jenis catatan spesifik aliasing diimplementasikan di belakang layar alih-alih sebagai jenis rekaman yang terlihat)
Håkan Lindqvist

2

Konsorsium Sistem Internet baru-baru ini memposting tulisan di CNAME di puncak zona , mengapa pembatasan ini ada, dan sejumlah alternatif. Ini tidak akan berubah dalam waktu dekat, sayangnya:

Kami tidak dapat mengubah cara catatan CNAME khusus digunakan tanpa mengubah semua> implementasi server DNS di dunia secara bersamaan. Ini karena makna dan interpretasinya sangat ditentukan dalam protokol DNS; semua implementasi klien dan server DNS saat ini mematuhi spesifikasi ini. Mencoba untuk 'bersantai' bagaimana CNAME digunakan di server otoritatif tanpa secara simultan mengubah semua resolver DNS yang saat ini sedang beroperasi akan menyebabkan resolusi nama terputus (dan layanan web dan email menjadi sebentar-sebentar tidak tersedia bagi organisasi yang menerapkan solusi server otoritatif 'santai'.

Tapi ada harapan:

Solusi potensial lain yang saat ini sedang dibahas akan menambahkan tipe catatan sumber daya dns baru yang akan dicari browser, yang bisa ada di apex. Ini akan menjadi nama host aplikasi khusus untuk permintaan http (mirip dengan cara kerja MX).

Pro: Ini sepenuhnya konsisten dengan desain DNS.
Cons: Ini belum tersedia, dan akan memerlukan pembaruan klien browser.


2
"Berharap"? Sudah ada "solusi", yaitu catatan HTTP SRV, tetapi ini ditolak secara universal. Yang tidak jelas adalah apa "masalahnya" itu.
Michael Hampton

Saya bahkan tidak mengetahui HTTP SRV jadi saya tidak tahu mengapa ditolak. Semoga solusi baru yang potensial ini melihat penerimaan yang lebih baik setiap kali / jika keluar.
Daniel Liuzzi

0

Jika Anda mengarahkan ulang seluruh zona, Anda harus menggunakan DNAME. Menurut RFC 6672 ,

DNAME RR dan CNAME RR [RFC1034] menyebabkan pencarian ke (berpotensi) mengembalikan data yang sesuai dengan nama domain yang berbeda dari nama domain yang diminta. Perbedaan antara kedua catatan sumber daya adalah bahwa CNAME RR mengarahkan pencarian data pada pemiliknya ke nama tunggal lainnya, sedangkan RR DNAME mengarahkan pencarian data pada keturunan nama pemiliknya ke nama yang sesuai di bawah simpul (tunggal) berbeda dari pohon.

Misalnya, lihatlah melalui zona (lihat RFC 1034 [RFC1034], Bagian 4.3.2, langkah 3) untuk nama domain "foo.example.com", dan catatan sumber daya DNAME ditemukan di "example.com" yang menunjukkan bahwa semua kueri di bawah "example.com" diarahkan ke "example.net". Proses pencarian akan kembali ke langkah 1 dengan nama permintaan baru "foo.example.net". Seandainya nama permintaan adalah "www.foo.example.com", nama permintaan yang baru adalah "www.foo.example.net".


3
Ini adalah interpretasi yang salah. Lihat baris kedua tabel di RFC 6672 §2.2 . Apeks DNAME tidak akan menghasilkan kecocokan untuk jenis kueri selain DNAME di apeks, yaitu tidak menghasilkan alias aktual dari catatan apeks A atau AAAA.
Andrew B

DNAME apeks tidak akan menghasilkan pengalihan untuk permintaan nama apeks. Secara teknis tidak benar untuk mengatakan bahwa itu akan menghasilkan kecocokan . Anda masih akan mendapatkan kecocokan jika Anda mencari NS, SOA, atau tipe RR lainnya yang benar-benar ada untuk nama puncak. Dari RFC 6672 : "Jika catatan DNAME hadir di puncak zona, masih ada kebutuhan untuk memiliki catatan sumber daya SOA dan NS biasa di sana juga. DNAME semacam itu tidak dapat digunakan untuk mencerminkan zona sepenuhnya, karena tidak cerminkan puncak zona. "
Quuxplusone
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.