MX kayıtları, yük dengeleme ve yük devretme için daha iyi kurulum


9

Example.com alan adını alın, iki posta sunucusu mail1.example.com ve mail2.example.com'dur, her ikisi de önceden yapılandırılmıştır, genellikle aşağıdaki kurulumla giderdim:

example.com.           1200    IN      MX      10 mail1.example.com.
example.com.           1200    IN      MX      10 mail2.example.com.
mail1.example.com.     1200    IN      A       172.16.10.1
mail2.example.com.     1200    IN      A       172.16.10.2

Bir iş arkadaşı aşağıdaki kurulumu önerdi:

example.com.           1200    IN      MX      10 mail.example.com.
mail.example.com.      1200    IN      A       172.16.10.1
mail.example.com.      1200    IN      A       172.16.10.2

mail1.example.com.     1200    IN      A       172.16.10.1
mail2.example.com.     1200    IN      A       172.16.10.2

İki sunucuyu gösteren iki A kaydına sahip tek bir yeni ana bilgisayar adı, bazı istemcilerin aynı öncelikli MX ile yuvarlak robin yapmadığını doğru bir şekilde belirtmediğinden, yasal bir kurulum olmalıdır, ancak yine de yük devretmeyi doğru bir şekilde destekliyor mu, örneğin 172.16. 10.1 başarısız, 172.16.10.2 teslimat için deneniyor mu? Yoksa şu gibi bir kurulum daha iyi olur:

example.com.           1200    IN      MX      10 mail.example.com.
example.com.           1200    IN      MX      20 mail1.example.com.
example.com.           1200    IN      MX      20 mail2.example.com.
mail.example.com.      1200    IN      A       172.16.10.1
mail.example.com.      1200    IN      A       172.16.10.2

mail1.example.com.     1200    IN      A       172.16.10.1
mail2.example.com.     1200    IN      A       172.16.10.2

Teşekkürler.

Yanıtlar:


11

MTA'nın MX kayıtlarını nasıl işlemesi gerektiğini belirten RFC'ler RFC974 , RFC1123 bölüm 5.3.4 , RFC2821 bölüm 5 ve RFC5321 bölüm 5'tir .

RFC974 durumu artık TARİHİ . Buna göre, MTA'ların bir alanla ilişkili MX kayıtlarının listesini sorgulamaları ve tercih edilen sırada tüm SMTP sunucularını (veya sabit sayıda) denemelerini "teşvik etmesi" beklenir. Eşit tercih değerine sahip birden fazla MX kaydı varsa, MTA'lar iletiyi başarılı olana kadar tüm SMTP sunucularına teslim etmeye çalışmalıdır. Deneme sırası bir MTA'nın seçimidir, yani RFC, SMTP sunucularına rasgele mi yoksa DNS sunucusu tarafından verilen sırayla mı bağlanılması gerektiğini yönetmez. Ayrıca, RFC birden çok A kaydına başvuran bir MX kaydının nasıl işleneceğine karar vermez.

(...) If the list of MX RRs is not empty, the mailer should try to deliver
the message to the MXs in order (lowest preference value tried
first). The mailer is required to attempt delivery to the lowest
valued MX. Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried. A somewhat less demanding system, in which
a fixed number of MXs is tried, is also reasonable. Note that
multiple MXs may have the same preference value. In this case, all
MXs at with a given value must be tried before any of a higher value
are tried. In addition, in the special case in which there are
several MXs with the lowest preference value, all of them should be
tried before a message is deemed undeliverable. (...)

RFC1123 durumu İNTERNET STANDARDIDIR . Bölüm 5.3.4, MX kayıtlarının nasıl işleneceğine ilişkin RFC974 prosedürlerini "hassaslaştırmayı" amaçlamaktadır. Artık MTA'ların başarılı olana kadar tüm SMTP sunucularını artan bir tercih sırasına göre denemesi gerekiyor. Ancak yine de deneme sayısı üzerinde yapılandırılabilir bir sınıra izin verir. Eşit tercih değerine sahip birden fazla MX kaydı varsa, RFC, MTA'ların rastgele bir kayıt seçmesini önerir (ve gerektirmez). Ancak, bir MX kaydı birden çok A kaydına (IPv4 adresleri) başvuruyorsa, RFC, MTA'ların DNS sunucusu tarafından verilen sırayla başarılı olana kadar tüm bu adreslerle iletişim kurmasını gerektirir.

(...) When it succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address,
because of (a) multiple MX records, (b) multihoming, or both.
To provide reliable mail transmission, the sender-SMTP MUST be
able to try (and retry) each of the addresses in this list in
order, until a delivery attempt succeeds. However, there MAY
also be a configurable limit on the number of alternate
addresses that can be tried. In any case, a host SHOULD try at
least two addresses.

The following information is to be used to rank the host
addresses:

(1) Multiple MX Records -- these contain a preference
indication that should be used in sorting. If there are
multiple destinations with the same preference and there
is no clear reason to favor one (e.g., by address
preference), then the sender-SMTP SHOULD pick one at
random to spread the load across multiple mail exchanges
for a specific organization; note that this is a
refinement of the procedure in [DNS:3].

(2) Multihomed host -- The destination host (perhaps taken
from the preferred MX record) may be multihomed, in which
case the domain name resolver will return a list of
alternative IP addresses. It is the responsibility of the
domain name resolver interface (see Section 6.1.3.4 below)
to have ordered this list by decreasing preference, and
SMTP MUST try them in the order presented.

(...)

[DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974,
January 1986.

RFC2821 durumu ÖNERİLEN STANDART . Bu RFC, RFC974'ü geçersiz kılar ve MX kaydı işleme kapsamında RFC1123'ten biraz farklıdır. Birincisi, eşit tercih değerine sahip birden fazla MX kaydı arasında rastgele bir SMTP sunucusu seçimi GEREKİR, ancak ikincisi sadece TAVSİYE EDER.

(...) Multiple MX records contain a preference indication that MUST be used
in sorting (see below). Lower numbers are more preferred than higher
ones. If there are multiple destinations with the same preference
and there is no clear reason to favor one (e.g., by recognition of an
easily-reached address), then the sender-SMTP MUST randomize them to
spread the load across multiple mail exchangers for a specific
organization.

The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and SMTP MUST try them in the
order presented. (...)

RFC5321 durumu DRAFT STANDARD . Bu RFC, RFC2821'i geçersiz kılar ve DNS çözümlemesi bağlamında, temel olarak aynı sunucu arama yordamını yeniden yazar ve IPv6 adreslerine başvuran MX kayıtlarının işlenmesini hafifçe tartışan yeni bir bölüm sunar.

(...) When a domain name associated with an MX RR is looked up and the
associated data field obtained, the data field of that response MUST
contain a domain name. That domain name, when queried, MUST return
at least one address record (e.g., A or AAAA RR) that gives the IP
address of the SMTP server to which the message should be directed.

(...) When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds.

(...)  MX records contain a preference indication that MUST be used in
sorting if more than one such record appears (see below). Lower
numbers are more preferred than higher ones. If there are multiple
destinations with the same preference and there is no clear reason to
favor one (e.g., by recognition of an easily reached address), then
the sender-SMTP MUST randomize them to spread the load across
multiple mail exchangers for a specific organization.

The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and the SMTP sender MUST try them
in the order presented. (...)

Modern bir posta aktarım aracısının en az RFC2821 veya RFC5321 yordamlarını izlediğini tahmin ediyorum, bu nedenle her üç DNS kurulumu da yük devretme özellikleri sağlıyor. Ancak, sadece ilk kurulum daha iyi bir yük dengeleme sağlayabilir. İkinci veya üçüncü düzene bir deneme yaparsanız, DNS sunucunuzun yanıtları rasgele bir sırayla verdiğinden emin olmanız gerekir. Ayrıca, DNS kayıtları MTA'nın kendileri veya özyinelemeli DNS sunucuları tarafından önbelleğe alınabilir, bu nedenle rasgele garanti edilemez. Sanırım mail1.example.commesajların çoğunu alacak.

Fikrimi ikinci ve üçüncü kurulumlara yönlendiren bir başka neden, birden çok ismin bir IP adresine referanslanmasıdır. İnternet'teki posta sunucuları, IP address => PTR => hostname => A => IP addresseşleşmeleri eşleşmeyen (Postfix kısıtlaması reject_unknown_client_hostname gibi ) ana bilgisayarlardan gelen iletileri genellikle reddeder , bu nedenle PTR kayıtlarını ayarlamak için özel dikkat göstermeniz gerekir.

MX kayıtlarını rastgele sırada denemeyen istemciler zaten RFC2821 ve RFC5321 standartlarını ihlal ediyor. Bu nedenle, bu istemcilerin ikincil IP adresini de otomatik olarak deneyeceklerine dair bir garanti olmadığını düşünüyorum. Bu nedenle, en basit DNS yapılandırmasını tercih ederim:

example.com.           1200    IN      MX      10 mail1.example.com.
example.com.           1200    IN      MX      10 mail2.example.com.
mail1.example.com.     1200    IN      A       172.16.10.1
mail2.example.com.     1200    IN      A       172.16.10.2

EDIT: RFC1123 referansları eklendi.


Ayrıntılı referanslar için teşekkür ederiz, belki de Marki'nin belirttiği gibi, uygun bir yük dengeleyici olmadan çok fazla şey bekleriz; PTR ile ilgili bir noktanız var, uyumsuzluk sorunlara neden olabilir ve dikkat edilmelidir.
Krdan

2

İkinci kurulum, yük devretmeyi desteklemez. Diyelim ki mail.example.com 172.16.10.1 olarak çözüldü ve başarısız oldu. 172.16.10.2 yalnızca bir MX kaydı olduğu için denenmeyecektir.

Üçüncü kurulum, ilk kurulumun iki katı DNS trafiği oluşturur. Fom trafiğinin yanı sıra, her ikisi de aynı davranışa sahiptir: Dediğiniz gibi, bazı istemciler aynı öncelik MX ile yuvarlak robin yapmaz.

Hem yük dengeleme hem de yük devretme için şunu denerdim:

example.com.           1200    IN      MX      10 mail1.example.com.
example.com.           1200    IN      MX      10 mail2.example.com.
example.com.           1200    IN      MX      20 mail3.example.com.
example.com.           1200    IN      MX      30 mail4.example.com.
mail1.example.com.     1200    IN      A       172.16.10.1
mail2.example.com.     1200    IN      A       172.16.10.2
mail3.example.com.     1200    IN      A       172.16.10.1
mail4.example.com.     1200    IN      A       172.16.10.2
  • 10 MX kaydı ------> Bir çeşit yük dengeleme
  • 20, 30 MX kaydı -> Yük Devretme

1

Bence ilk kurulumunuz doğru. Nedenleri:

  1. Yük dengeleme için iyi olan aynı önceliğe sahip 2 MX kaydınız var. RFC5321, SMTP sunucusunun tüm sunucular için yükü rastgele dağıtması gerektiğini belirtir

  2. Bahsettiğiniz gibi, A turu robin kaydı düzgün bir şekilde yerine çalışmaz. Buna çoklu evli-A kaydı denir, gönderen önce posta gönderir DNS yanıtı ve DNS sunucusu bir liste dönüş sırasına karar verir. Bu yüzden yük dağıtımına veya yük devretmeye ihtiyacınız varsa bir DNS sunucusuna ihtiyacınız olabilir (heath ve load monitor). Yine RFC'ye dayanarak, tüm gönderenlerin MX kayıtlarında aynı önceliğe sahip tüm sunucuları denemesi gerekir, böylece iki MX kaydıyla yük devretme yapabilirsiniz.

ref: https://tools.ietf.org/html/rfc5321 sayfa 69


0

Yük devretme için şunları yapın:

example.com.           1200    IN      MX      10 mail1.example.com.
example.com.           1200    IN      MX      20 mail2.example.com.
mail1.example.com.     1200    IN      A       172.16.10.1
mail2.example.com.     1200    IN      A       172.16.10.2

MTA önce mail1'i sonra mail2'yi dener.

Yük dengeleme ve yük devretmeyi birleştirmek gerçekten mümkün değildir. Şunları yapabilirsiniz:

example.com.           1200    IN      MX      10 mail1.example.com.
example.com.           1200    IN      MX      20 mail2.example.com.
mail1.example.com.     1200    IN      A       172.16.10.1
mail1.example.com.     1200    IN      A       172.16.10.2    
mail2.example.com.     1200    IN      A       172.16.10.1
mail2.example.com.     1200    IN      A       172.16.10.2

MTA önce mail1'i dener, bu da zamanın yarısı .1'i, diğeri ise .2'yi gösterir. Buradaki sorun, mail2'nin ulaşılamadığı senaryoda mail2'nin mail1 ile aynı adresi gösterebilmesidir.

Böylece deneyebilirsin

example.com.           1200    IN      MX      10 mail1.example.com.
example.com.           1200    IN      MX      10 mail2.example.com.
example.com.           1200    IN      MX      20 mail2.example.com.
example.com.           1200    IN      MX      20 mail1.example.com.
mail1.example.com.     1200    IN      A       172.16.10.1
mail1.example.com.     1200    IN      A       172.16.10.2    
mail2.example.com.     1200    IN      A       172.16.10.1
mail2.example.com.     1200    IN      A       172.16.10.2

ilk bağlantının çalışma riskini azaltmak için. Yine de risk sıfır olmayacaktır. Ancak MTA'lar bağlantıyı daha sonra tekrar dener.

Etkin bir görev yükü dengeleme ve yük devretme için, bir yük dengeleyici (küme) alın veya bir araya getirin.


Marki'ye tamamen katılmıyorum. Yine de aynı öncelikli MX kayıtları ile yük devretme ve yük dengeleme yapabilirim. Üretim ortamında kullandım ve iyi çalışıyor
Gk.

OP, aynı prio MX'in yük dengeleme için çalışacağından şüpheleri olduğunu belirtti. Bu durumda bir yük dengeleyici edinmeleri gerekir :)
Marki

-1

Hangi posta sunucunuzun olduğuna bağlıdır. Reddoxx adında bir posta sunucumuz var - sadece ilk mx kaydını kullanıyor. (aynı önceliğe sahip) Sadece ilk mx'den yanıt yoksa ikinci mx'e bağlanır vb. Posta sunucumuz RFC5321'i görmezden geliyor


1
Peki, tarif edilen OP ile aynı isim için iki A kaydı ile ne yapardı?
civcivler
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.