MX kaydı - MX record

Bir posta değiştirici kaydı (MX kaydı) belirtir posta sunucusu kabul etmekten sorumlu e-posta bir alan adı adına mesajlar. Bu bir kaynak kaydı içinde Alan Adı Sistemi (DNS). Tipik olarak yük dengeleme ve yedeklilik için bir dizi posta sunucusuna işaret eden birkaç MX kaydını yapılandırmak mümkündür.

Genel Bakış

Kaynak kayıtları, Alan Adı Sisteminin (DNS) temel bilgi unsurudur. Bir MX kaydı bunlardan biridir ve bir alan, aşağıdaki gibi bunlardan bir veya daha fazlasına sahip olabilir:

Etki Alanı TTL Sınıf Türü Önceliği Hostexample.com. 1936 IN MX 10 onemail.example.com.example.com. 1936 IN MX 10 twomail.example.com.

Bir MX kaydının karakteristik yük bilgisi[1] bir tercih değeri (yukarıda "Öncelik" olarak etiketlenmiştir) ve bir posta sunucusunun alan adıdır (yukarıdaki "Ana Bilgisayar").

Öncelik alanı, hangi posta sunucusunun tercih edilmesi gerektiğini tanımlar - bu durumda değerlerin her ikisi de 10'dur, bu nedenle postanın her ikisine de eşit olarak akması beklenir. onemail.example.com ve twomail.example.com - ortak bir konfigürasyon. Ana bilgisayar adı doğrudan bir veya daha fazlasıyla eşleşmelidir adres kayıtları DNS'de (A veya AAAA) ve herhangi bir CNAME kayıtları.[2]

İnternet üzerinden bir e-posta mesajı gönderildiğinde, posta transfer aracısı (MTA), her alıcının MX kayıtları için Alan Adı Sistemini sorgular. alan adı. Bu sorgu bir liste döndürür ana bilgisayar adları Bu etki alanı için gelen postayı kabul eden posta alışverişi sunucularının sayısı ve tercihleri. Gönderen aracı daha sonra bir SMTP bağlantısı kurmaya çalışır ve önce en düşük "Öncelik" değerine sahip ana bilgisayarı dener. Sistem izin verir yüksek kullanılabilirlikli kümeler gerekirse bir alan adı için oluşturulacak posta ağ geçitlerinin sayısı.[3]

MX mekanizması, alternatif olarak posta hizmeti sağlama yeteneği sağlamaz. bağlantı noktası numaraları ve her birine bir ağırlık değeri atayarak posta dağıtımını bir dizi eşit olmayan öncelikli posta sunucusuna dağıtma yeteneği de sağlamaz.

MX tercihi, mesafe ve öncelik

Göre RFC 5321 en düşük numaralı kayıtlar en çok tercih edilenlerdir.[4] Bu ifade kafa karıştırıcı olabilir ve bu nedenle tercih numarası bazen şu şekilde anılır: mesafe: daha küçük mesafeler daha çok tercih edilir. Daha eski bir RFC, RFC 974, iki sunucu için tercih numaraları aynı olduğunda, bunların aynı olduğunu belirtir öncelikdolayısıyla bu iki terim birbirinin yerine kullanılır.

Temeller

En basit durumda, bir etki alanında yalnızca bir posta sunucusu olabilir. Örneğin, bir MTA, example.com için MX kayıtlarını ararsa ve DNS sunucusu yalnızca mail.example.com tercih numarası 50 ile yanıtlarsa, MTA postayı listelenen sunucuya teslim etmeye çalışır. Bu durumda, 50 sayısı, SMTP şartnamesinin izin verdiği herhangi bir tamsayı olabilirdi.

Bir MX sorgusu için birden fazla sunucu döndürüldüğünde, önce en küçük tercih numarasına sahip sunucu denenmelidir. Aynı tercih numarasına sahip birden fazla MX kaydı varsa, bunların tümü daha düşük öncelikli girişlere geçmeden önce denenmelidir. SMTP istemcisi zorunlu bir teslimat girişimi başarılı olana kadar listedeki ilgili adreslerin her birini sırayla deneyebilir (ve yeniden deneyebilir).[4]

Yük dağılımı

Gelen postanın bir yükünü bir sunucu dizisi üzerinden dağıtmanın standart yaklaşımı, kümedeki her sunucu için aynı tercih numarasını döndürmektir. Postayı hangi eşit tercihli sunucuya göndereceğini belirlerken, "gönderen-SMTP, bunları, belirli bir organizasyon için birden fazla posta değiştiricisine yaymak üzere rastgele hale getirmelidir" ZORUNLU, birini tercih etmek için açık bir neden yoksa.[4]

Alternatif bir yaklaşım kullanmaktır çok evli bir ana bilgisayarın birkaç IP adresi döndürdüğü sunucular.[3] Bu yöntem, yük dengelemeyi gerçekleştirmek için SMTP göndericisinden ziyade DNS sistemine yük bindirir, bu durumda, posta değiştiricisinin A kaydını sorgulayan istemcilere belirli bir sırayla IP adreslerinin bir listesini sunar. RFC, SMTP göndereninin A kaydı sorgusunda verilen sırayı kullanmasını gerektirdiğinden, DNS sunucusu, aşağıdakiler dahil olmak üzere herhangi bir yönteme dayalı olarak kendi dengelemesini dikkatli bir şekilde yapmakta özgürdür round robin DNS, posta sunucusu yükü veya açıklanmayan bazı öncelik şemaları.

"Yedekleme" MX

Bazı alan adlarında, biri "yedek" olarak tasarlanmış, daha yüksek bir tercih numarasına sahip, böylece normalde e-posta teslimi için hedef olarak seçilmeyecek birkaç MX kaydı olacaktır.

Bununla birlikte, daha düşük numaralı ana bilgisayarlardan gelen hatalar durumunda (belki bir tür kesintiden dolayı), e-posta sunucularının gönderilmesi "yedek" ana bilgisayara teslim edilecektir - queue.example.com aşağıdaki örnekte:

Etki Alanı TTL Sınıf Türü Önceliği Hostexample.com. 1936 IN MX 10 onemail.example.com.example.com. 1936 IN MX 10 twomail.example.com.example.com. 1936 IN MX 100 queue.example.com.

Yedekleme sunucusunun kullanıcı posta kutularına doğrudan erişimi varsa, posta oraya ilerleyecek, aksi takdirde büyük olasılıkla queue.example.com kesinti çözülene kadar.

Bu tür bir düzenlemenin yokluğunda, bir alanın posta sunucularının tümü çevrimdışı olduğunda, gönderme sunucuların, daha sonra yeniden denemek için söz konusu etki alanına yönelik iletileri sıraya koyması gerekir. Ancak, bu gönderen sunuculara, önceden çevrimdışı olan bir etki alanının sunucularının artık kullanılabilir olduğu konusunda bildirim almanın hiçbir yolu yoktur ve bu nedenle, seçim programı - ve yalnızca bir sonraki teslimatı denediklerinde alanın kullanılabilir olduğunu keşfedeceklerdir. Alıcı etki alanının sunucularının çevrimiçi olması ile geciken iletilerin nihayet teslim edilmesi arasındaki gecikme, bu nedenle, gönderen sunucuların yeniden deneme programına bağlı olarak dakikalar veya günler arasında olabilir ve alıcı etki alanının bunun üzerinde hiçbir görünürlüğü veya kontrolü yoktur.

Spam gönderenler

Spam gönderenler Bu tür bir sunucunun daha az etkili istenmeyen posta önleme filtrelerine sahip olacağı varsayımıyla, postayı ilk önce bir etki alanının yedek (yüksek mesafe) MX sunucularından birine yönlendirebilir. Anti-spam tekniği adı verilen nolisting bu davranışı varsaymaya dayanır.

Teslimat arızasının ele alınması

SMTP RFC[4] tam olarak hangi tür teslimat hatalarının daha uzak MX kayıtları (daha yüksek tercih değerlerine sahip olanlar) aracılığıyla yeniden dağıtım girişimiyle sonuçlanması gerektiği konusunda belirsizdir.

Sunucular, ya açıkça bir 4xx hatası göndererek ya da bağlantıyı beklenmedik bir şekilde sonlandırarak (bu, bir 451 hatası olarak ele alınmalıdır. Bölüm 3.8 RFC'nin), Bölüm 4.5.4.1 diyor:

Gönderen, bir deneme başarısız olduktan sonra belirli bir hedefi yeniden denemeyi ertelemelidir * ZORUNLU *.

Ancak, gönderen yeniden denediğinde, RFC bunun aynı sunucuya mı yoksa daha "uzak" bir MX kaydına mı gönderileceği konusunda sessiz kalır. Diyor ki Bölüm 5.1:

Arama başarılı olduğunda, eşleme, birden çok MX kaydı, birden çok ağ bağlantısı veya her ikisi nedeniyle tek bir adres yerine alternatif teslimat adreslerinin bir listesiyle sonuçlanabilir. Güvenilir posta iletimi sağlamak için, SMTP istemcisi, bir teslim girişimi başarılı oluncaya kadar bu listedeki ilgili adreslerin her birini sırasıyla deneyebilmeli (ve yeniden denemeli) OLMALIDIR.

Bazı sunucular (örneğin Posta göndermek ve Postfix 2.1 veya üstü),[5] karşılama hataları gibi bazı geçici teslim hatalarından sonra bir sonraki en uzaktaki MX sunucusunu deneyecektir.[6] Diğer sunucular (örneğin qmail ve Postfix 2.0 veya öncesi), yalnızca en kısa mesafeli MX kayıtlarında belirtilen sunucularla hiç bağlantı kurulamadığında daha uzak MX kayıtlarını kullanır. Aradaki farka rağmen, RFC spesifik olmadığı için her iki davranış da geçerlidir.

Adres kaydına geri dönüş

Bir MX kaydının olmaması durumunda, e-posta gönderenler adres kaydına teslim etmeyi deneyeceklerdir - ör. ornek.com.

Bu dayanmaktadır RFC 5321 sn. 5, şunları belirtir:

  • SMTP istemcileri bir MX kaydına bakmalıdır;
  • Eğer (ve sadece eğer) etki alanı için MX kaydı yoksa, etki alanını hedef ana bilgisayar adı ve tercih değeri 0 olarak verilen etki alanıyla bir MX kaydına sahipmiş gibi ele alın
  • Hedef ana bilgisayar adının IP adresini belirlemek için gerektiği şekilde A veya AAAA aramaları gerçekleştirin

Tarihsel arka plan

RFC 821 1982'de yayınlandı. DNS'ye yalnızca geçiş referansları yapıyor, çünkü o sırada HOSTS.TXT DNS henüz başlamamıştı. RFC 883, DNS'nin ilk tanımı, bir yıldan uzun bir süre sonra 1983'ün sonlarında yayınlandı. Deneysel ve az kullanılan MD ve MF kayıtlarını açıkladı. Göre RFC 897 ve RFC 921, DNS'ye geçiş 1983'te başladı, ancak HOSTS.TXT'nin 1985'in sonuna kadar aşamalı olarak kaldırılması planlanmamıştı ve 1990'ların sonlarına kadar tamamen aşamalı olarak kaldırılmamıştı.

Ocak 1986'da, RFC 973 ve RFC 974 MD ve MF kayıtlarını kullanımdan kaldırdı, bunları MX ile değiştirdi ve MX aramasını A'ya geri dönüş ile tanımladı. RFC 974 müşterilere bir WKS bakmak[7] SMTP'yi gerçekten destekleyip desteklemediğini görmek ve desteklemiyorsa MX girişini atmak için her MX ana bilgisayarında. Ancak, RFC 1123 bunu WKS olduğunu söylemek için değiştirdi yapmamalı kontrol edilmelidir.

Bu, SMTP'nin HOSTS.TXT kullanarak en az bir yıldır ve MX gelmeden önce A, MD ve MF kullanarak birkaç yıl daha kullanıldığı anlamına gelir. MD ve MF'nin kullanımı zordu, bu yüzden çoğu insan A kaydını kullandı. Bu koşullar altında, A'ya geri dönüş olmadan MX, A kayıtlarını kullanan posta sunucularının önemli ölçüde kurulu olması nedeniyle çalışmazdı. MX'in ilk kullanımı, diğer ağlara giden ağ geçitlerini tanımlamaktı, ancak DNS 1990'ların başlarında iyi bir şekilde kurulana kadar yaygın olarak kullanılmadı.[8]

Standart belgeler

  • RFC 1035 (1987), Etki Alanı Adları - Uygulama ve Spesifikasyon
  • RFC 1912 (1996), Yaygın DNS Çalışma ve Yapılandırma Hataları
  • RFC 5321 (2008), Basit Posta Aktarım Protokolü
  • RFC 7505 (2015), Posta Kabul Etmeyen Etki Alanları için "Boş MX" Hizmet Kaynağı Kaydı Yok

Obsoletes:

  • RFC 2821 (2001), Basit Posta Aktarım Protokolü (geçersiz kılan RFC-5321)
  • RFC 974 (1986), Posta Yönlendirme ve Etki Alanı Sistemi (RFC-5321 tarafından kullanılmıyor)

Ayrıca bakınız

Referanslar

  1. ^ Bu örneklerde, ilgili alan adı ilk sütunda, TTL (yaşam süresi) ikincisinde ve üçüncüsü "kayıt Sınıfı" (bu durumda İnternet için IN) - sonra kayıt türünü tanımlamak için MX. TTL bir geçerlilik süresidir ve bilgilerin bir yerden ne zaman yenilenmesi gerektiğini belirtir. yetkili ad sunucusu.
  2. ^ RFC 2181, Bölüm 10.3, DNS Spesifikasyonunun Açıklamaları, R. Elz, R. Bush (Temmuz 1997)
  3. ^ a b NASIL - Round Robin ve Yük Dengelemeyi Yapılandırma, Sayfa değiştirildi: 28 Şubat 2014., zytrax.com
  4. ^ a b c d RFC 5321
  5. ^ Birincil MX yanıt verir ancak işlemin ortasında başarısız olursa, Postfix 1.2 ve 2.0 bir yedek MX'i denemeyecektir. Arşivlendi 2009-06-23 de Wayback Makinesi, Re: daha düşük önceliğe sahip mx olarak değişmez, Kimden: Victor Duchovni (Victor.DuchovniMorganStanley.com) Tarih: Cum Kasım 11 2005
  6. ^ Karşılama hatası, standart SMTP karşılama anlaşması yerine veya buna yanıt olarak gönderilen bir hata kodudur.
  7. ^ Craig Partridge (Ocak 1986). POSTA YÖNLENDİRME VE ALAN SİSTEMİ. IETF. doi:10.17487 / RFC0974. RFC 974. Alındı 18 Kasım 2011. Her MX için, listelenen alan adının gerçekten istenen posta hizmetini destekleyip desteklemediğini görmek için bir WKS sorgusu düzenlenmelidir. Hizmeti desteklemeyen alan adlarını listeleyen MX RR'ler atılmalıdır. Bu adım isteğe bağlıdır, ancak şiddetle tavsiye edilir.
  8. ^ Bu bölüm, John Levine ietf-smtp mesajı Arşivlendi 2008-06-01 de Wayback Makinesi