RFC 7505 (Null MX) neden gereklidir?


18

IETF RFC 7505 , açıkça bir e-posta almaması gereken bir alan / ana bilgisayar için MX kayıtlarını açıklar. Bu, MX'i Etki Alanı Adı Sistemi köküne işaret ederek gerçekleştirilir. Örneğin,

nomail.example.com. 86400 IN MX 0 "."

Bu neden gerekli? Anladığım kadarıyla, TLD altındaki alanlar kullanılarak açık reddetme yapılabilir invalid. Örneğin,

nomail.example.com. 86400 IN MX 0 "spam.invalid."
nomail.example.com. 86400 IN MX 10 "null.invalid."

Görüyorum ki, RFC 2782, DNS SRV, aynı şekilde "A hedefi". hizmetin bu alanda kesinlikle kullanılamadığı anlamına gelir. " Yani sorum şu:

Neden invalidbu işlevi yerine getirdiğinde "kullanılamaz" anlamına gelen DNS kökünü kullanmalıyız ?


2
Bu açık bir çürütme değil! Sadece geçersiz veriler.
Michael Hampton

Yanıtlar:


21

Çünkü bunun için kullanman gerekmiyor .invalid. Gibi .exampleyerel test ve dokümantasyon içindir.

Buna ek olarak, kullanmak .invalidyine de ek şeylerin gerçekleşmesine neden olur - ek DNS aramaları ve kafamın üst kısmına bir kez denemek için posta sunucusunda kuyruğa alma.

Biçimin kullanılması "."derhal bir hataya neden olur. MTA'nın teslimatı derhal durdurmasına neden oluyor. En azından RFC'ye giriş bu şekilde.


2
Teşekkürler. Ancak BCP: 32 / RFC 2606 Bölüm 2'de ".invalid" yazıyor, geçersiz olduğundan ve bir bakışta geçersiz olduğu açık olan alan adlarının çevrimiçi yapımında kullanılmak üzere tasarlanmıştır. 2606, ".invalid" ın yalnızca yerel sınama için olduğunu gösteren hiçbir şey söylemez. Bu, geçersiz, geçersiz olması gereken herhangi bir alan içindir
Alpha Whisky

Tamam neden bir ana bilgisayar adı gibi görünüyor bir şey "." İle karşılaştırıldığında dezavantajlı olduğunu görebilirsiniz.
Alpha Whisky

1
@ AlfaWhiskey Bir şeye "bakabilen" ve sonuç çıkarabilen insanlar . Bilgisayarların açık talimatlara ihtiyacı vardır.
Michael Hampton

3
adil olmak gerekirse, bu özel durumda bilgisayarlara açık talimat vermek tam olarak zor değildir.
muhmuhten

@res Bu da kolay değil bilgisayarları o açık talimat vermek üzere.
musiKk

9

Bir bütün olarak soru, RFC7505'in neden faydalı bir şey eklediğini cevaplamak için hepsi dikkate alınması gereken birkaç farklı konuya değiniyor.


Her şeyden önce, RFC7505 öncesi posta dağıtımının nasıl yapılacağına ilişkin tanımın, adres kayıtları olan bir ad için posta dağıtım girişiminde bulunulmaması gerektiğini açıkça belirtmenin bir yolu yoktur.

Gönderen RFC7505 bölüm 1 :

SMTP istemcileri, bir etki alanı için e-posta kabul eden bir sunucuyu tanımlamak için önceden belirlenmiş bir sıraya sahiptir. [RFC5321] 'in 5. Bölümü bunu ayrıntılı olarak kapsar; özünde, SMTP istemcisi önce bir DNS MX RR arar ve bulamazsa, bir DNS A veya AAAA RR aramaya geri döner. Bu nedenle, bu, e-posta hizmeti semantiği olan bir DNS kaydını (farklı bir birincil görevi olan) aşırı yükler.

Bir alan adında MX kaydı yoksa, gönderenler alan adının A veya AAAA kayıtlarındaki adreslerden ana bilgisayarlara posta teslim etmeye çalışır. A / AAAA adreslerinde hiçbir SMTP dinleyicisi yoksa, gönderen Posta Aktarım Aracısı (MTA) vazgeçmeden önce, genellikle bir hafta gibi uzun bir süre boyunca ileti teslimi denenir. Bu, yanlış yönlendirilmiş posta durumunda gönderene bildirimi geciktirir ve gönderende kaynak tüketir.

Bu belge, alan adlarının teslimat girişimlerini önlemeye adanmış SMTP dinleyicileri oluşturmasına gerek kalmadan bir alan adındaki tüm posta teslim girişimlerinin hemen başarısız olmasına neden olacak boş bir MX tanımlar.


Sonra RFC7505'in bunu nasıl uyguladığı ( IN MX 0 .).

Gönderen RFC7505 bölüm 3 :

  1. Boş MX Belirleyen MX Kaynak Kayıtları

    Bir alan adının e-postayı kabul etmediğini belirtmek için, tercih numarası 0 ve ana dosyalarda "olarak yazılan sıfır uzunluklu etiketten oluşan bir RDATA bölümü içeren tek bir MX RR (bkz. [RFC1035] Bölüm 3.3.9). ", exchange alanı olarak, bir alan adı için posta değiştirici bulunmadığını belirtir. Dan beri "." geçerli bir ana bilgisayar adı değil, boş bir MX kaydı normal bir MX kaydı ile karıştırılamaz. Kullanımı "." pseudo-hostname anlamına gelen SRV RR [ RFC2782 ] üzerinde benzer bir anlama sahip olan hiçbir hizmet modellenmemiştir .

    Boş bir MX tanıtan bir alan adı, başka bir MX RR'nin reklamını YAPMAMALIDIR.

(vurgu eklendi)

Burada belirtildiği gibi, "null MX" için uygulama ayrıntıları SRVRR tipinden önceden oluşturulmuş bir desene dayanmaktadır . SRVRR tipinin az ya da çok RR tipinin genelleştirilmiş bir versiyonu olması nedeniyle bunu taklit etmek mantıklıdır MX.

Bu nedenle, esas olarak SRVRR tipi tanımlanırken karar alınmıştır .


Peki neden faydalanmıyorsunuz .invalid?

Gönderen RFC2606 section2 :

".invalid", geçersiz olduğundan ve bir bakışta geçersiz olduğu açık olan alan adlarının çevrimiçi yapımında kullanılmak üzere tasarlanmıştır.

Burada görülebileceği gibi, bu ayrılmış TLD insan tüketimi içindir. Yazılımda bunun özel kullanımını tanımlamanın bir emsali yoktur.

Elbette farklı bir şekilde uygulanabilirdi, ancak .geçerli bir ana bilgisayar adı olmayan ve bu nedenle yine de normal kullanıma müdahale etmeyen minimal kullanım yaklaşımıyla gitmeyi seçtiler .


Anlayabildiğim kadarıyla, .A veya AAAA kayıtları kökte yayınlanmış olsaydı, MX kaydı olarak kullanılamazdı. Ben telnet . 25yazarken kesinlikle kökünde A ve AAAA kayıtları arar.
kasperd

1
@kasperd DNS protokolü mutlaka bunu temsil edebilir, ben de adres kayıtlarını sahip inanmıyorum .ya belirterek (ön RFC7505) .olarak EXCHANGEbir değer MXkaydının aslında geçerli olurdu. (Geçerli bir ana bilgisayar adı değil.)
Håkan Lindqvist

Geçerli ya da değil - A kaydı olmayan bir alana işaret eden bir MX kaydı ile karşılaşıldığında, vazgeçmeden önce günlerce teslimatı yeniden deneyecek uygulamaları kolayca hayal edebiliyorum.
kasperd
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.