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 :
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 .