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


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

Ini pengetahuan yang relatif umum itu CNAME catatan di puncak domain adalah praktik tabu.

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

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

Baru-baru ini saya memiliki instruksi perusahaan webhosting ke unit bisnis yang kami butuhkan untuk CNAME puncak domain kami ke rekor baru. Mengetahui bahwa ini akan menjadi konfigurasi bunuh diri ketika diumpankan ke BIND, saya menyarankan mereka bahwa kami tidak akan dapat mematuhi dan bahwa ini adalah saran susun secara umum. Perusahaan webhosting mengambil sikap bahwa itu tidak langsung dilarang oleh RFC mendefinisikan standar dan itu mereka perangkat lunak mendukungnya. Jika kami tidak dapat melakukan CNAME pada apeks, saran mereka adalah tidak memiliki catatan puncak sama sekali dan mereka tidak akan memberikan server web pengalihan. ...Apa?

Sebagian besar dari kita tahu itu RFC1912 bersikeras itu A CNAME record is not allowed to coexist with any other data., tetapi mari kita jujur ​​dengan diri kita di sini, bahwa RFC hanya Informasi. Yang paling dekat yang saya ketahui adalah bertele-tele yang melarang praktik itu berasal RFC1034:

Jika RR CNAME hadir di node, tidak ada data lain yang seharusnya   menyajikan; ini memastikan bahwa data untuk nama kanonik dan aliasnya   tidak bisa berbeda.

Sayangnya saya sudah cukup lama di industri ini untuk mengetahui bahwa "tidak boleh" tidak sama dengan "tidak boleh", dan itu adalah tali yang cukup bagi sebagian besar perancang perangkat lunak untuk menggantung diri. Mengetahui bahwa apa pun yang pendek kaitannya dengan slam dunk akan membuang-buang waktu saya, saya akhirnya membiarkan perusahaan lolos dengan omelan karena merekomendasikan konfigurasi yang dapat merusak perangkat lunak yang biasa digunakan tanpa pengungkapan yang tepat.

Ini membawa kita ke Tanya Jawab. Untuk sekali ini aku ingin kita mendapatkannya sangat teknis tentang kegilaan CNAMEs apeks, dan tidak mengitari masalah seperti yang biasanya kita lakukan ketika seseorang memposting tentang subjek. RFC1912 terlarang, sebagaimana RFC Informasional lainnya yang berlaku di sini yang tidak saya pikirkan. Ayo kita diamkan bayi ini.


107
2017-07-19 10:53




RFC 1034 mendahului RFC 2119 dengan sedikit waktu dan pengalaman. - Michael Hampton♦


Jawaban:


CNAME catatan itu semula dibuat untuk memungkinkan beberapa nama yang menyediakan sumber daya yang sama untuk menjadi alias ke satu "nama kanonik" untuk sumber daya. Dengan munculnya virtual hosting berbasis nama, itu telah menjadi umum untuk menggunakannya sebagai bentuk umum dari aliasing alamat IP. Sayangnya, kebanyakan orang yang datang dari latar belakang web hosting mengharapkan CNAME catatan untuk menunjukkan kesetaraan dalam DNS, yang tidak pernah menjadi niatnya. Puncaknya berisi tipe catatan yang jelas tidak digunakan dalam identifikasi sumber daya host kanonik (NS, SOA), yang tidak dapat di-alias tanpa melanggar standar pada tingkat dasar. (khususnya dalam hal pemotongan zona)

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

6.1. Otoritas zona

Server otoritatif untuk zona dicacah dalam catatan NS      untuk asal-usul zona, yang, bersama dengan Mulai dari Otoritas      (SOA) record adalah catatan wajib di setiap zona.  Server seperti itu      berwibawa untuk semua catatan sumber daya di zona yang tidak ada      zona lain. Catatan NS yang mengindikasikan pemotongan zona adalah      properti zona anak dibuat, seperti halnya catatan lain untuk      asal zona anak itu, atau sub-domain apa pun darinya. Server untuk      zona tidak boleh mengembalikan jawaban otoritatif untuk kueri yang terkait      nama di zona lain, yang mencakup NS, dan mungkin A, catatan      di potongan zona, kecuali itu juga terjadi menjadi server untuk yang lain      daerah.

Ini menetapkan itu SOA dan NS catatan adalah wajib, tetapi tidak menyebutkan apa pun A atau jenis lain yang muncul di sini. Mungkin tampak berlebihan bahwa saya mengutip ini, tetapi itu akan menjadi lebih relevan dalam beberapa saat.

RFC 1034 agak kabur tentang masalah yang bisa timbul ketika a CNAME ada di samping tipe catatan lainnya. RFC 2181 menghapus ambiguitas dan secara eksplisit menyatakan jenis catatan yang diizinkan ada di sampingnya:

10.1. Catatan sumber daya CNAME

Data DNS CNAME ("nama kanonik") ada untuk menyediakan      nama kanonis yang dikaitkan dengan nama alias. Mungkin hanya ada satu      nama kanonik untuk satu alias apa pun. Nama itu seharusnya secara umum      nama yang ada di tempat lain dalam DNS, meskipun ada beberapa yang langka      aplikasi untuk alias dengan nama kanonis yang menyertainya      tidak terdefinisi dalam DNS. Nama alias (label data CNAME) dapat,      jika DNSSEC sedang digunakan, miliki SIG, NXT, dan RRS KUNCI, tetapi mungkin tidak      data yang lain.  Yaitu, untuk label apa pun dalam DNS (nama domain apa pun)      tepatnya salah satu dari berikut ini benar:

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

"Nama alias" dalam konteks ini mengacu pada sisi kiri CNAME merekam. Daftar bullet membuatnya jelas bahwa a SOA, NS, dan A catatan tidak dapat dilihat di titik di mana a CNAME juga muncul. Ketika kami menggabungkan ini dengan bagian 6.1, tidak mungkin untuk a CNAME ada di puncak karena harus hidup berdampingan SOA dan NS catatan.

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


Memperbarui:

Tampaknya kebingungan yang lebih baru datang Keputusan baru Cloudflare untuk mengizinkan data CNAME ilegal untuk didefinisikan di puncak domain, di mana mereka akan mensintesis rekam A. "RFC compliant" seperti yang dijelaskan oleh artikel terkait mengacu pada fakta bahwa catatan yang disintesis oleh Cloudflare akan bermain baik dengan DNS. Ini tidak mengubah fakta bahwa itu benar-benar perilaku khusus.

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


85
2017-07-19 10:53



Saya setuju dengan bukti ini dan saya tidak berpikir dua jalur bukti ini sangat panjang atau berbelit-belit. (1. Puncak zona dijamin memiliki setidaknya SOA + NS rekaman, 2. CNAME catatan tidak diizinkan untuk hidup berdampingan dengan data lain) - Håkan Lindqvist
Secara keseluruhan, saya pikir itu penjelasan yang sangat bagus. Jika ada yang bisa ditambahkan, saya pikir itu mungkin akan menjelaskan lebih lanjut apa a CNAME Rekam sebenarnya berarti, karena mungkin itu adalah tipe catatan yang paling banyak disalahpahami. Meskipun itu bukan masalah, saya pikir ini menjadi FAQ adalah hasil langsung dari banyak (kebanyakan?) Tidak memiliki pemahaman yang tepat tentang CNAME. - Håkan Lindqvist
@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 rujukan apa, apa perilaku yang diperlukan untuk rujukan (AUTHORITY, SOA record presence, dll.), Dan mengapa jenis ini "aliasing tanpa referensi" melanggar banyak harapan server DNS pada tingkat fungsional. Dan itu hanya untuk memulai. Pertanyaan itu bukan topik yang bagus untuk di sini karena spekulatif dan tidak berakar pada masalah yang akan Anda hadapi saat bekerja dengan server DNS yang sesuai dan dirancang dengan standar. - Andrew B
@DenisHowe secara singkat: tidak ada hal seperti "domain" tanpa NS dan rekaman SOA. itu adalah catatan non-opsional. - hakamadare
@Ekevoo Satu dapat membantah implementasi HTTP seharusnya diadopsi SRV sebagai gantinya, itu juga akan menjadikan ini sebagai tidak masalah. Masalahnya tidak terbatas pada apa yang dibahas di sini; CNAME bertentangan dengan kepercayaan populer, bukan kecocokan yang bagus untuk apa yang dibutuhkan. Pada akhirnya, seperti CNAME tidak berfungsi seperti yang diharapkan orang (!) dan tidak dapat didesain ulang secara retroaktif dan karena penerapan HTTP tidak digunakan SRV tampaknya lebih mungkin bahwa "alias" fungsionalitas gaya menjadi lebih umum untuk melayani HTTP (jenis catatan aliasing spesifik yang diimplementasikan di belakang layar daripada sebagai tipe catatan yang terlihat) - Håkan Lindqvist


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

RR DNAME dan RR CNAME [RFC1034] menyebabkan pencarian      (berpotensi) mengembalikan data yang sesuai dengan nama domain yang berbeda      dari nama domain yang dikueri. Perbedaan antara keduanya      catatan sumber daya adalah bahwa RR CNAME mengarahkan pencarian data di      pemiliknya ke nama tunggal lainnya, sedangkan RR DNAME mengarahkan pencarian      untuk data di turunan dari nama pemiliknya ke nama yang sesuai      di bawah node (tunggal) yang berbeda dari pohon.

Misalnya, lihatlah melalui zona (lihat RFC 1034 [RFC1034],      Bagian 4.3.2, langkah 3) untuk nama domain "foo.example.com", dan a      Catatan sumber daya DNAME ditemukan di "example.com" yang menunjukkan semuanya      pertanyaan di bawah "example.com" diarahkan ke "example.net". Pencarian      proses akan kembali ke langkah 1 dengan nama permintaan baru      "foo.example.net". Apakah nama kueri telah "www.foo.example.com",      nama kueri baru adalah "www.foo.example.net".


0
2018-03-27 15:41



Ini adalah interpretasi yang salah. Lihat baris kedua dari tabel di RFC 6672 §2.2. DNAME puncak akan menghasilkan tidak cocok untuk jenis kueri selain DNAME di puncak, yaitu tidak menghasilkan aliasing sebenarnya dari catatan APEX A atau AAAA. - Andrew B
DNAME puncak akan menghasilkan no pengalihan untuk kueri nama puncak. Secara teknis tidak benar untuk mengatakan bahwa itu akan menghasilkan tidak pertandingan. Anda masih akan mendapatkan kecocokan jika Anda meminta NS, SOA, atau jenis RR lainnya yang sebenarnya menyajikan untuk nama puncak. Dari RFC 6672: "Jika ada catatan DNAME di puncak zona, masih ada kebutuhan untuk memiliki catatan sumber daya SOA dan NS biasa di sana juga. DNAME seperti itu tidak dapat digunakan untuk cermin zona sepenuhnya, karena tidak cermin titik zona. " - Quuxplusone