Haruskah CNAME Digunakan Untuk Subdomain?


84

Saya mengelola beberapa situs web yang saat ini memiliki konfigurasi DNS berikut:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - CNAME    - example.com
beta.example.com - CNAME    - test.example.com
dev.example.com  - CNAME    - test.example.com

Apakah ini penggunaan yang tepat dari catatan CNAME? Saya sudah mencari online dan belum menemukan jawaban yang jelas. Beberapa orang mengklaim bahwa catatan CNAME buruk (tidak jelas mengapa ini) dan mengusulkan pengaturan berikut:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - A Record - Production Server IP
beta.example.com - A Record - Test Server IP
dev.example.com  - A Record - Test Server IP

Yang mana dari ini adalah pendekatan yang lebih baik (dan mengapa)?

Catatan: Subdomain tidak memerlukan data MX sendiri, jadi itu bukan masalah di sini.


1
Saya merasa ini harus menjadi jawaban wiki. DNS sangat sulit untuk diperbaiki dan apakah jawaban yang diterima ini masih bagus 6 tahun kemudian?
the0ther

1
@ the0ther Ya, bahkan hari ini jawaban yang divalidasi, dari Jesper Mortensen , masih valid (bahkan jika seseorang dapat berdebat tentang penamaan barang atau nilai TTL yang benar untuk digunakan, tetapi ini adalah poin yang terpisah dari masalah menggunakan catatan CNAME atau tidak ). DNS adalah protokol lama, jadi hal-hal dasar seperti catatan CNAME tidak berubah seiring waktu.
Patrick Mevzek

Jawaban:


85

Ya, itu penggunaan yang tepat dari CNAME. Dalam diskusi yang saya ikuti, argumennya cenderung seperti ini:

Terhadap CNAME:

  • Ada penalti kinerja (kecil), karena cache DNS downstream harus melakukan 2 pencarian DNS, satu untuk CNAME dan satu untuk A-Record yang menunjuk CNAME.
  • Argumen tidak jelas dan palsu tentang CNAME yang kurang memiliki "otoritas" atau masalah kompatibilitas.

Mendukung CNAME:

  • Mereka memberikan abstraksi bersih antara perangkat keras (server fisik) dan layanan.
  • Mereka menyederhanakan manajemen DNS - ketika server bergerak, Anda hanya perlu mengubah satu catatan.

Setelah mencoba beberapa cara berbeda untuk melakukan ini, saya sekarang memiliki gaya favorit pribadi. Ini:

  • Satu A Record untuk setiap server fisik; dengan TTL yang cukup rendah (mungkin 30 menit); memberikan server nama yang ramah manusia .
  • Satu CNAME untuk setiap layanan; dengan TTL tinggi (mungkin 24 jam); menunjuk ke nama server di atas.
  • Sebagai pengecualian satu-satunya terhadap aturan di atas, root domain adalah A-Record, yang menunjuk ke server web / penyeimbang beban web. (@ Harus merupakan rekaman-A.)

Saya menemukan bahwa pengaturan ini berfungsi dengan baik. Itu membuat pencarian DNS tambahan untuk CNAMES turun; dan jika server crash saya masih dapat mengubah DNS publik sekitar cukup cepat.

Berikut adalah contoh (improvisasi) dalam sintaks BIND:

;name     ttl   class rr     value 
server01  30m   IN    A      192.168.0.3
server02  30m   IN    A      192.168.0.4

webmail   24h   IN    CNAME  server01
extranet  24h   IN    CNAME  server02
ftp       24h   IN    CNAME  server02

1
Terima kasih, akhirnya ada opini yang masuk akal tentang CNAME yang ditata dengan jelas dan ringkas.
Tyler

@Jesper Mortensen: bisakah Anda memperbarui sedikit jawaban dengan contoh kecil, terutama saya tidak mengerti poin ke-3 Anda ketika Anda mengatakan "Sebagai pengecualian satu-satunya terhadap aturan di atas, root domain adalah A-Record," Anda sudah mengatakan pada poin 1 bahwa Anda menggunakan satu A Record untuk setiap server lapisan fisik. (BTW
tautannya

2
@Marco Demaio: Tentang "Rekaman A root domain": Domain tingkat kedua seperti company.comadalah puncak zona. Perlu catatan SOA. Oleh karena itu, itu harus menjadi Catatan A dan bukan CNAME - lihat serverfault.com/questions/170194/…
Jesper Mortensen

4
@ tidak diharuskan memiliki catatan A; melainkan, CNAME dilarang.
Michael Hampton

1
Hanya ingin menambahkan bahwa CNAME sangat berguna jika server Anda juga mendukung alamat IPv6, karena Anda akan memerlukan setidaknya dua entri per server (masing-masing satu A dan AAAA record) sehingga menggunakan CNAME untuk sub-domain dalam hal ini jauh, lebih sederhana. Jika Anda menggunakan rekomendasi Jesper untuk TTL (atau penyedia DNS Anda memiliki penanganan otomatis yang baik) maka seharusnya tidak ada penalti kinerja nyata.
Haravikk

13

Ya itu tepat.

Praktik Terbaik Saya, yang dibagikan banyak orang, adalah membuat catatan 1 A untuk setiap IP server; dan gunakan CNAMES untuk hal lain.

Contoh umum adalah:

server1.example.com.      IN A      192.168.0.1
server2.example.com.      IN A      192.168.5.2
www                       IN CNAME  server1
ftp                       IN CNAME  server1
beta                      IN CNAME  server2

Saya tahu dalam pertanyaan ini mereka mengatakan surat bukan masalah di sini, tapi anggaplah Anda juga menggunakan email bagaimana Anda akan pergi dengan catatan MX? Terima kasih!
Marco Demaio

1
Catatan MX akan menunjuk ke nama server juga. IN MX server1dan untuk kenyamanan saya sarankan juga menyiapkan imapatau popdan smtpCNAME, mungkin juga mail, karena banyak program email menebaknya. Menyiapkan catatan SRV yang benar juga merupakan ide yang baik, tetapi karena ini adalah pertanyaan yang relatif mendasar, catatan SRV mungkin sedikit banyak untuk konfigurasi yang sederhana.
Chris S

1
Komentar cepat, MXcatatan tidak boleh CNAME, lihat serverfault.com/a/232243/2874 Mungkin berfungsi dengan baik dalam praktiknya - tapi tetap saja, lebih baik tidak melakukannya.
Jesper Mortensen

BIND akan menolak untuk memuat zona jika Anda menunjuk catatan MX atau SRV di CNAME ... Saya mungkin seharusnya menjelaskan bahwa catatan MX perlu mengarah ke catatan A. Terima kasih.
Chris S

@ Chris, bagaimana dengan mengedit jawaban Anda dan dengan jelas menyebutkan fakta bahwa data MX tidak dapat menunjuk ke entri CNAME?
Alexis Wilke
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.