DNS: Subdomain yang Membutuhkan Catatan MX dan CNAME

17

Katakanlah kita memiliki zona mywebservice.com.

Saya ingin setiap pelanggan saya mendapatkan subdomain mereka sendiri, seperti customer.mywebservice.com.

customer.mywebservice.com harus menjadi CNAME untuk server di luar lokasi yang diberikan. Karena situs itu mengelola peralatannya sendiri dan dapat mengubah alamat kapan saja, CNAME merupakan persyaratan.

Orang-orang juga harus dapat mengirim email ke [email protected], yang akan membutuhkan data MX sederhana.

Namun, dan di sinilah saya ingin beberapa panduan:

Menurut RFC 1034 :

If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.

Saya juga telah memverifikasi bahwa server DNS saya akan menolak untuk menayangkan apa pun selain CNAME untuk host yang menggunakannya.

Jadi, sepertinya saya mungkin mengalami situasi yang kalah. Jika saya ingin menggunakan data MX, saya harus menggunakan A alih-alih CNAME.

Adakah yang bisa memikirkan penyelesaian masalah? Terima kasih!

domain-name-system cname-record mx-record Michael Gorsuch
sumber

Jawaban:

20

Sayangnya, yang Anda temui adalah keterbatasan spesifikasi DNS. Memiliki catatan MX untuk nama host yang sama seperti yang didefinisikan sebagai catatan CNAME akan gagal di sebagian besar implementasi server DNS. Beberapa server DNS lama akan mengizinkan ini, tetapi mereka sebagian besar telah dihapus demi implementasi yang lebih baru, lebih aman.

Alih-alih menggunakan catatan CNAME, Anda harus menggunakan catatan 'A' dengan alamat IP dari situs pelanggan secara langsung alih-alih menyebut nama.

Justin Scott
sumber
Ya, saya kira saya hanya akan menghadapi yang satu ini. Terima kasih!
Michael Gorsuch
2
Saya juga harus mencatat, bagi mereka yang membaca ini di jalan, bahwa alasan untuk pembatasan ini adalah bahwa CNAME seharusnya merujuk pada "nama kanonik" untuk tuan rumah yang sedang melihat ke atas. Misalnya, jika Anda memiliki host, x2.example.com yang merupakan catatan CNAME yang menunjuk ke x1.example.com, maka setiap resolver yang mencari x2 akan melihat CNAME, ganti apa pun yang dilakukan untuk x2 dengan x1, dan mulai lagi dari awal. . Jika Anda memiliki catatan MX untuk x2 selain CNAME, maka jika x1 juga memiliki MX, ada kemungkinan mereka akan berbeda yang tidak diinginkan, jadi mereka hanya melarangnya.
Justin Scott
18

Setelah banyak pekerjaan dan penelitian di sini, saya telah menemukan solusi yang dapat diterima. Pertama, penting bahwa kita semua mengikuti RFC. Saya menambal server DNS saya untuk melanggar RFC, dan saya menemukan bahwa beberapa server DNS utama lainnya tidak akan menghargai perubahan.

Langkah yang sesuai adalah menempatkan MX pada host yang ditunjuk CNAME. Jadi, jika customer.mywebservice.com adalah CNAME ke a record loadbalancer.mywebservice.com, maka layak untuk juga membuat data MX untuk loadbalancer.mywebservice.com. Saya telah memverifikasi bahwa ini berfungsi dengan semua penyelesai utama.

Jika permintaan MX dibuat untuk customer.mywebservice.com, perpustakaan resolver akan mengikuti CNAME dan mendapatkan MX yang tepat untuk catatan A akhir. Hore!

Michael Gorsuch
sumber
4

customer.mywebservice.com harus menjadi CNAME untuk server di luar lokasi yang diberikan. Karena situs itu mengelola peralatannya sendiri dan dapat mengubah alamat kapan saja, CNAME merupakan persyaratan.

Adakah yang bisa memikirkan penyelesaian masalah? Terima kasih!

Anda memiliki persyaratan bahwa pelanggan harus dapat mengubah alamat, sudahkah Anda mempertimbangkan untuk mengizinkan pelanggan untuk memperbarui catatan mereka sendiri secara dinamis? Dengan dns dinamis, Anda dapat menggunakan catatan A, dan pelanggan dapat mengubah catatan sesuai kebutuhan. Ini akan membutuhkan sedikit usaha, tetapi Anda dapat masing-masing sub-domain sebagai zona terpisah sehingga Anda dapat memastikan pelanggan hanya dapat menyentuh zona mereka sendiri.

Saya belum mencobanya, tetapi gnudip tampaknya merupakan alat open source untuk memfasilitasi pembaruan dinamis tanpa harus berurusan dengan otentikasi dan menyiapkan banyak zona di server DNS Anda.

Sakit kepala
sumber
3

Jika catatan MX Anda akan sama untuk semua catatan ini, maka Anda dapat mencoba menggunakan DNAME untuk mengarahkan XYZ.mywebservice.com ke hosting.mywebservice.com. Di bawah hosting.mywebservice.com, tambahkan catatan MX dan A yang relevan.

Saya harus mengatakan bahwa saya belum pernah menggunakan catatan DNAME dalam produksi, tetapi Anda dapat membaca lebih lanjut tentang mereka di RFC2672 .

Doug Luxem
sumber
Saya ingin mencoba menggunakan DNAME dengan beberapa domain SSL kami, tetapi saya dengar masih ada masalah dengan server DNS yang lebih lama, dll. Apakah ini relevan? Atau apakah DNAME aman untuk digunakan di server produksi?
drybjed
Jika saya harus menebak, banyak aplikasi tidak mengharapkan catatan DNAME dan mungkin rusak saat menggunakannya. Apakah semua server email mengikuti DNAME untuk mencari data MX? Saya tidak tahu, tetapi mereka harus tahu. Untuk masalah SSL Anda, server DNS yang tidak mengerti DNAME seharusnya menerima referensi CNAME. Saya benar-benar akan menguji ini sebelum mengimplementasikannya.
Doug Luxem
Aplikasi tentu TIDAK harus memproses data DNAME! Ini dilakukan hanya di server nama.
bortzmeyer
3

Apakah RHS CNAME customer.mywebservice.com memiliki entri MX?

Jika demikian, maka server email akan menggunakan MX itu untuk menemukan server email yang akan digunakan. Semoga Anda bisa mengendalikan itu.

MikeyB
sumber
1

Jawaban Michael Gorsuch sebagian besar benar, CNAME -> A + MX chain tidak berfungsi ... kebanyakan . Namun, hal itu memicu beberapa perilaku buruk di MTA tertentu. Apa yang saya temukan menjalankan solusi ini pada skala yang layak:

  • beberapa MTA hanya akan menolak untuk menemukan catatan.
  • yang lain akan secara salah mengganti catatan A di mana CNAME seharusnya: yaitu saya mengirim email ke "[email protected]", yang CNAMES ke web.example.com, yang memiliki MX dari mail.example.com, dan MTA menulis ulang header amplop sebagai "To: [email protected]".

Masih belum jelas seberapa luas masalah ini (google / hotmail / yahoo / etc semua tampaknya berurusan dengan ini dengan benar), tetapi mereka tentu saja meminta kita mencari solusi yang lebih baik.

osheroff
sumber
2
Ini benar; perilaku yang didokumentasikan untuk server SMTP yang sesuai dengan RFC5321 adalah untuk pertama memeriksa keberadaan catatan MX untuk domain, dan jika itu gagal, periksa keberadaan catatan A. Perilaku ini adalah alasan teknis yang sebenarnya mengapa MX tidak boleh menjadi CNAME: itu akan berhenti menyelesaikan setelah jawaban pertama yang dapat digunakan.
adapttr
0

Solusi yang mungkin dan valid adalah membuat nama host dasar untuk semua pelanggan Anda dan mengaturnya ke catatan a dan aaaa dari server situs dan mx Anda, lalu CNAME semua domain pelanggan Anda ke nama host tunggal itu. Dengan begitu Anda hanya perlu mengubah satu catatan ketika alamat IP luar-situs berubah.

Ini adalah satu-satunya cara valing dan mungkin, karena CNAME adalah alias untuk set lengkap catatan, bukan hanya a.

Bachsau
sumber
-4

MX dan CNAME adalah catatan yang benar-benar terpisah - yang pertama menentukan server surat untuk domain yang diberikan, kedua memberikan alamat untuk domain. Ini seharusnya bekerja:

@ DALAM SOA ns1.mywebservice.com. root.mywebservice.com. (
                        2009060201
                        12 jam
                        1 jam
                        1w
                        8 jam
)

                        NS ns1.mywebservice.com.
                        NS ns2.mywebservice.com.

pelanggan CNAME offsite.host.
mail.server pelanggan MX 10.
drybjed
sumber
4
Itu mungkin berhasil, tetapi melanggar RFC1034 dan RFC1219 yang menyatakan bahwa tidak ada catatan sumber daya lain yang memiliki nama yang sama dengan CNAME.
Doug Luxem
Daemon DNS saya ketat RFC, yang hanya menolak untuk mengirim respons untuk MX. Saya percaya bahwa ada beberapa masalah caching potensial di sisi klien jika kita ingin menerapkannya.
Michael Gorsuch
Daemon DNS yang mana? Saya menggunakan BIND9 yang seharusnya berfungsi dengan konfigurasi itu tanpa masalah. Mungkin sudah waktunya untuk meningkatkan? Infrastruktur besar, saya kira?
drybjed
Saya menggunakan MyDNS. Ini konfigurasi yang cukup besar, dan daemon kecil ini telah menjadi berkah hingga saat ini. Saya sedang mempertimbangkan untuk menambalnya, tetapi saya tidak terlalu tertarik berurusan dengan efek samping apa pun yang melahirkannya. Jika itu bertentangan dengan RFC, itu terdengar seperti ide yang buruk.
Michael Gorsuch
@ Maciej - tentu saja, server otoritatif Anda mungkin dapat meng-host catatan ini. Mereka akan membingungkan sebagian besar server rekursif yang meminta mereka.
Alnitak