CNAME kullanan DNS, MX kayıtlarını mı bozuyor?


42

Yeni yılda sunucu taşımayı planladığımız ve bazı müşterileri bir sunucuya ve başka bir yere başka bir yere taşımayı istediğimiz için barındırdığımız tüm web sitelerimizi CNAMES'e taşımaya çalışıyoruz. Müşterilere daha sonra değiştirebileceğimiz benzersiz bir CNAME vermeyi planlıyorduk. (Bunu şimdi yapmak için başka nedenlerimiz var ama asıl olan bu)

Bu teoriyi kendi etki alanlarımızdan birkaçı ile test ettik ve iyi görünüyordu. Ancak bir etki alanındaki MX kayıtlarını kontrol ederken, MX kaydı yerine CNAME değerini geri aldım.

Maalesef, bu etki alanlarının tümü kontrol panelleri aracılığıyla gerçekleştiriliyor, ancak sanırım sadece bölge dosyaları yazıyorlar.

Company.com için 2 CNAME oluşturmak istiyorum

company.com. IN CNAME client.dns.ourserver.com
www          IN CNAME client.dns.ourserver.com

MX kaydı aşağıdaki gibidir:

company.com  IN MX 10 mail.company.com

Mail.company.com için A kaydımız var

Yapma:

host -t mx company.com

Mx kaydı yerine CNAME değerini döndürür.

Bu beklenen davranış mı?

Yukarıdaki konfigürasyonu 123-reg.co.uk kontrol paneliyle çalışmayı başardım, ancak bunun her şeyden daha şanslı olup olmadığından emin değilim.


Bu yaygın bir sorudur ve daha önce birçok kez sorulmuştu. Örnek için bu bağlantıya bakın: serverfault.com/questions/18000/…
Russell Heilling

Cevap ararken biraz harcadım ama farklı bir şey yapıp yapmadığımı çözemedim. Özellikle bir etki alanı sağlayıcısıyla iyi çalıştığı için. Cevabım var bu yüzden serin ve umarım birileri için yarar sağlayacak.
johnwards

Yanıtlar:


54

Bu yaygın bir hatadır. Eğer Kök etki (örn company.com) için bir CNAME RR kullanamaz ve aynı bölge için ek kaynak kayıtlarını tanımlar.

Bkz . Kök kaydı için neden bir CNAME kaydı oluşturamıyorum? ve detaylar için RFC1034 bölüm 3.6.2:

Bir düğümde bir CNAME RR mevcutsa, başka veri bulunmamalıdır; bu, kanonik bir ad ve diğer adı için verinin farklı olamamasını sağlar.


RFC2181 Bölüm 10.1 ayrıca yukarıdakileri güçlendirmesiyle de ilgilidir.
Håkan Lindqvist

apeks alanı olarak da bilinir
Alex78191

5

RFC2181 bölüm 10.3, MX kaydınızı bir CNAME'ye yönlendiremeyeceğinizi söylüyor:

MX kaynak kaydının değeri ... olarak kullanılan alan adı bir takma ad olmamalıdır.


2
Bununla birlikte, sorunun konusu hakkında bir senaryo değil mi?
Håkan Lindqvist

2

A kayıtları yerine CNAME kullanan Heroku'ya taşındım ve yapmak zorunda olduğum şey, my_etkialani.com'u heroku'ya işaret eden bir CNAME yapmak yerine, CNAME'yi www.my_etkialani.com ile heroku'ya yönelttim. kök etki alanı yönlendirmedi ve MX kayıtlarım hala çalışıyordu. Sonra my_domain.com adresini www.my_domain.com adresine yönlendirmek için bir işaretçi ekledim. Harika çalışıyor gibi görünüyor. Etki alanı adı sağlayıcımda işaretçi, 'standart' 'URL' ve 'www.my_etkialani.com' olarak ayarladığım bir 'işaretçiler' ayarı kullanılarak oluşturuldu.


Sağlam iş! Bunu paylaştığın için teşekkürler!
duhaime

0

Bu ikisinin tamamen ayrılabileceğini farkettim.

mydomain.com. -  A Record  - 01.0.0.1
mydomain.com - CNAME - www.cname.eg.com

Sunucunuzu posta sunucusu olarak kullanmıyorsanız, gerçekten hiçbir şeyi etkilemez. Posta, etkialanim.com MX kayıtlarını arayacak. Onun ancak böyle olması durumunda etkilenecek

mydomain.com - MX - mail.mydomain.com

ancak bunun böyle ise (ayrı bir posta sunucusu kullandığınız anlamına gelir) etkilenmeyecektir

mydomain.com - MX - mail.mycustommailserver.com

Posta Sunucuları için bir IP kullanamazsınız.


-1

SOME DNS sağlayıcılarının, SOME DNS sağlayıcıları ile paralel olarak, yalnızca yukarıdan aşağıya kayıt sırasına göre CNAME YUKARI üzerindeki MX kaydını sipariş ederseniz, çıplak bir CNAME ile birlikte çalışacaklarını öğrendim .

Office 365 MX kaydına sahip Name.com kayıt şirketi üzerinde çalışıyor ve HTTP'yi başka bir etki alanına yönlendiren çıplak CNAME kaydı. MX sorgularını test ederken CNAME sonucumun ilk önce DNS giriş siparişime karşılık geldiğini fark ettim, bu yüzden neden önce MX sipariş etmeyi denemediğime karar verdim ve bunun MX sağlayıcıyı tatmin edip etmediğini anladım. Sürprizim için Office 365 MX doğrulamasından sonra geçti ve gelen ve giden e-postanın gerçekten akmakta olduğunu onaylayabilirim. Ve birkaç web istemcisini test ettikten sonra, HTTP gerçekten de istenen CNAME varış yeri ana bilgisayarına istenir şekilde çözümlenir.

Uyarıcı emptor - Bu açıkça standarda aykırıdır ve bu nedenle muhtemelen kritik bir şey için düşünülmemelidir. Kayıt düzeninin şartnamede olmadığını ve bu nedenle resmen güvenilemediğini farz ediyorum ... yani, bu hack'ü unuttuktan hemen sonra değişebilir.

İpucu - MX Araç Kutusu ücretsiz sayfası, farklı DNS ayarlarının denenmesinin sonucunu kontrol etmek için çok kullanışlıdır.

Karşılık gelen yazı için utanmaz fiş .


2
Belgelenmemiş davranış olarak, bu kesinlikle güvenmek istediğim bir şey değil.
ceejayoz

2
bu davranış yalnızca bir hata olarak kabul edilebilir, önbellekleme sunucusu sunucusu CNAME yanıtını önbelleğe alabilir ve MDA'lar
Jasen

-3

Etki alanının kökünde bir CNAME kullanabilirsiniz, ancak, bu MX kayıtlarının ana bilgisayar kaydında da yapılandırılması gerekir; bu nedenle, etki alanınız için bölge üzerinde mx1.mail.com yapılandırılmışsa ve etki alanınızın kökü varsa. com, thisrecord.cname.com için CNAME'dir, ayrıca, mx1.mail.com'in bu CNAME sunucusunda yapılandırıldığından da emin olmalısınız; değilse, tüm postalar kaybolacak!


4
Sorun, RFC1034'e göre, "eğer bir CNAME RR bir düğümde mevcutsa, başka hiçbir veri bulunmamalıdır" - kök NS kayıtlarına ihtiyaç duyduğundan (faydalı olması için), her zaman başka veriler olacaktır. RFC'nin bu bölümünü ihlal eden.
Doktor J

Benim düşünceme göre cevap doğru, MX kaydının bunun yerine CNAME ana bilgisayarında olması gerekmiyor.
Alexander Taubenkorb
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.