Ustawienia zaawansowane
Podświetl węzły, które rozwiązują do tej wartości.
Eksperymentalny weryfikator MG (Mail Group)
Rekord MG (Mail Group) był niezwykle ambitną, wczesną próbą inżynieryjną wbudowania funkcjonalności list dyskusyjnych (mailingowych) natywnie w samą strukturę systemu nazw domen (DNS). Przed pojawieniem się menedżerów list dyskusyjnych w warstwie aplikacji, inżynierowie sieciowi wysnuli teorię, że mogliby używać rekordów DNS do dyktowania logiki dystrybucji grupowej w obrębie całego szkieletu Internetu (backbone). Koncepcja ta została opisana w RFC 1035 jako eksperymentalny mechanizm obsługi duplikowania wiadomości e-mail w przypadku przesyłania masowego (bulk) na etapie routingu między serwerami (server-to-server).
Powielanie Payloadu na poziomie DNS
Mechanika działania rekordu MG opierała się na klastrowaniu węzłów DNS. Administrator tworzył pseudo-domenowy węzeł, np. dev-team.example.com. Następnie do tego jednego węzła dołączał wiele rekordów MG, z których każdy wyraźnie wskazywał na indywidualne rekordy MB (Mailbox) poszczególnych członków zespołu. Gdy zewnętrzny serwer pocztowy próbował wysłać wiadomość e-mail na ten grupowy adres, odpytywał DNS o rekordy MG. Autorytatywny serwer nazw zwracał pełną tablicę (array) członków. Zakładano, że serwer wysyłający następnie powieli Payload wiadomości e-mail i zainicjuje oddzielne połączenia SMTP, aby dostarczyć wiadomość do każdej pojedynczej skrzynki pocztowej wymienionej w odpowiedzi DNS.
Porażka z powodu mechanizmów buforowania (Caching) i propagacji
Protokół MG poniósł spektakularną porażkę we wdrożeniach w świecie rzeczywistym z powodu nieodłącznej natury buforowania DNS. DNS w dużym stopniu polega na wartościach Time-To-Live (TTL), gdzie pośredniczący dostawcy usług internetowych buforują rekordy od 24 do 48 godzin, aby zmniejszyć obciążenie sieci. Jeśli użytkownik chciał wypisać się z listy dyskusyjnej, administrator systemu musiał usunąć jego rekord MG z pliku strefy. Jednak ponieważ serwery zewnętrzne miały zapisaną w pamięci podręcznej starą listę grup, użytkownik nadal otrzymywałby masowe wiadomości e-mail przez wiele dni, dopóki globalne TTL nie wygasły. Zarządzanie dynamicznymi subskrypcjami użytkowników poprzez statyczne edycje strefy DNS było obliczeniowo nieefektywne i wysoce frustrujące dla użytkowników.
Rozwój list w warstwie aplikacji (Application-Layer)
Architekci sieci zgodnie doszli do wniosku, że listy dyskusyjne wymagają złożonego zarządzania stanem (state management) — obsługi odrzuceń (bounces), przetwarzania linków do anulowania subskrypcji i zarządzania kolejkami moderacji — do obsługi czego DNS nigdy nie był przeznaczony. Rekord MG został całkowicie porzucony. Branża przeszła na menedżerów list na poziomie aplikacji, takich jak GNU Mailman, Majordomo i nowoczesne grupy dystrybucyjne Exchange (Distribution Groups). Aplikacje te działają za standardowym rekordem MX, odbierają pojedynczy Payload wiadomości e-mail i używają wewnętrznych baz danych SQL do natychmiastowego zarządzania powielaniem i dystrybucją, całkowicie oddzielając logikę list dyskusyjnych od globalnych tabel routingu DNS.