serwer MX

Serwer MX to system wskazany w rekordzie DNS jako odpowiedzialny za przyjmowanie poczty dla domeny.

Zasada działania rekordu MX w systemie nazw domenowych

Rekord MX (Mail Exchanger) stanowi integralny element systemu DNS, odpowiadający za poprawne kierowanie poczty elektronicznej w infrastrukturze internetowej. Kiedy użytkownik wysyła wiadomość e-mail na zdefiniowany adres docelowy, serwer poczty wychodzącej nadawcy, zwany z języka angielskiego Message Transfer Agent (MTA), musi ustalić, do jakiego fizycznego lub wirtualnego węzła ma przekazać skompletowane pakiety danych. W tym celu serwer inicjujący wysyła zapytanie do systemu DNS o weryfikację rekordu typu MX dla danej strefy. Otrzymana odpowiedź serwera DNS zawiera nazwy hostów, które są technicznie upoważnione do przyjmowania pakietów SMTP dla analizowanej domeny. Z punktu widzenia projektowania sieci, sam rekord MX nigdy nie zawiera bezpośrednich adresów IP. Zawsze wskazuje on na nazwy domenowe innych serwerów, co wymusza na węźle nadawcy wykonanie kolejnego zapytania rekurencyjnego DNS, aby przetłumaczyć uzyskaną nazwę hosta docelowego na adresację opartą na protokole IPv4 (rekord A) lub IPv6 (rekord AAAA). Zależność ta zapewnia skalowalność infrastruktury, ponieważ umożliwia administratorom dokonywanie zmian fizycznej lokalizacji serwerów i przypisanych do nich protokołów IP bez konieczności modyfikowania samych wpisów MX w rejestratorze.

Architektura globalnego systemu nazewnictwa pozwala na przypisanie wielu równoległych rekordów MX do jednej domeny publicznej. Wynika to z faktu, że środowiska pocztowe w organizacjach przetwarzających duży wolumen wiadomości rzadko opierają się na wydajności pojedynczego procesora i dysku. Dodanie kilku wpisów MX umożliwia implementację mechanizmów rozpraszania obciążenia oraz redundancji środowiskowej, definiowanej w środowiskach informatycznych jako High Availability. Serwer węzła wysyłającego, po otrzymaniu pełnej listy rekordów MX dla analizowanej strefy, dokonuje próby zestawienia połączenia zgodnie z protokołami komunikacyjnymi rodziny SMTP. Standardowa komunikacja nieszyfrowana odbywa się na porcie 25, natomiast sesje wspierające tunelowanie szyfrowane wykorzystują porty 465 lub 587. Proces nawiązywania komunikacji nie odbywa się sekwencyjnie, lecz jest ściśle determinowany przez parametry numeryczne przypisane w strukturze każdego rekordu powiązanego ze strefą.

Priorytetyzacja ruchu SMTP i redundancja środowiskowa

Kluczowym elementem rekordu MX, obok samej nazwy serwera docelowego, jest wartość liczbowa nazywana priorytetem lub preferencją. Parametr ten decyduje o kolejności, według której wszystkie zewnętrzne systemy pocztowe będą próbowały dostarczyć ładunek transmisji. Logika ustalania priorytetu przypisuje pierwszeństwo najniższej wartości liczbowej. W sytuacji, gdy domena konfiguruje serwer główny z priorytetem 10 oraz dodatkowy serwer zapasowy z priorytetem 20, wszelki początkowy ruch sieciowy jest bezwarunkowo kierowany na maszynę opisaną liczbą 10. Dopiero w wypadku, gdy główny węzeł przekaźnikowy przestaje odpowiadać na żądania protokołu ICMP lub jego daemon pocztowy odrzuca połączenia ze względu na awarię macierzy dyskowej, węzeł nadawcy inicjuje próbę nawiązania sesji TCP z serwerem o wyższej wartości numerycznej, czyli z priorytetem 20.

Tak zaprojektowany mechanizm routingu eliminuje powstawanie pojedynczych punktów awarii (Single Point of Failure). Urządzenia o niższym priorytecie operacyjnym, odgrywające rolę serwerów zapasowych, są konfigurowane przez inżynierów w ten sposób, by nie przetwarzały lokalnie plików bazy skrzynek docelowych. Zamiast tego buforują nadchodzące wiadomości w wyodrębnionych sektorach pamięci tymczasowej i podejmują cykliczne próby przekazania ich do głównego serwera w momencie przywrócenia mu sprawności układów sieciowych. W sytuacji, gdy administratorzy przydzielą identyczne wartości liczbowe trzem serwerom, na przykład po priorytecie 10, następuje automatyczny podział przetwarzanego ruchu. System wysyłający wybiera w takiej sytuacji jeden z docelowych hostów w oparciu o algorytm dystrybucji Round-Robin. Skutkuje to równomiernym rozłożeniem wykorzystania procesora oraz obciążenia układów I/O dysków na kilka współpracujących stacji, zwiększając łączną przepustowość podsystemu wejścia-wyjścia całej sieci doręczeniowej.

Ustandaryzowane dyrektywy techniczne RFC narzucają dodatkowe restrykcje, które nie zezwalają na wskazywanie w wartościach MX hostów będących aliasami opartymi o zapytania typu CNAME. Adres maszyny widniejący jako węzeł pocztowy musi posiadać bezpośrednie dowiązanie z właściwym adresem logicznym poprzez rekordy A i AAAA. Błędy konfiguracyjne łamiące tę regułę skutkują problemami przy parsowaniu drzewa zapytań przez filtry bezpieczeństwa docelowego dostawcy, co na poziomie protokołu warstwy 7 modelu OSI prowadzi do twardego odrzucenia procesu autoryzacji wiadomości.

Analiza najczęstszych usterek konfiguracyjnych i odrzuceń

Przerwy w działaniu przepływu maili w środowiskach biurowych nie wynikają bezpośrednio ze struktury samego pakietu, a w zdecydowanej większości przypadków mają źródło w synchronizacji systemów buforujących oraz w mechanizmach weryfikacji tożsamości. Powszechnym błędem popełnianym przez techników IT przy wdrożeniach jest lekceważenie opóźnienia propagacji determinowanego przez czynnik TTL (Time To Live). Skutkiem aktualizacji rekordu MX na serwerze autorytatywnym nie jest jego natychmiastowa replikacja we wszystkich węzłach internetowych na świecie. Buforujące serwery dostawców usług utrzymują zapamiętane wartości przez czas określony parametrem strefy. Zbyt wysoka wartość tego licznika, sięgająca na przykład kilkudziesięciu tysięcy sekund, powoduje, że transmisje danych przez długi czas podążają dwiema odmiennymi ścieżkami logicznymi, doprowadzając do zjawiska niekontrolowanej fragmentacji plików bazy w programach czytających korespondencję.

Przyczyną zablokowania transmisji jest także zaniechanie publikacji rekordu wstecznego PTR, znanego jako Reverse DNS, na adresie publicznym utrzymującym usługi powiązane z wpisem MX. Jeśli serwer wskazany w strefie MX inicjuje kontakt z docelowym węzłem infrastruktury w celu zrzutu poczty lub dwukierunkowej weryfikacji tożsamości, zaawansowane filtry sieciowe dokonują kwerendy wstecznej. Brak rekordu przyporządkowującego publiczne IP do domeny kończy się wymuszeniem komendy DROP i wygaszeniem całej sesji. Problemem topologicznym zgłaszanym w środowiskach opartych o systemy Unix bywają pętle routingu (routing loop). Usterka ujawnia się, gdy tablica DNS wskazuje jako docelowy MX maszynę, której wewnętrzny system operacyjny nie posiada konfiguracji akceptującej maile dla danej nazwy domeny. Maszyna taka zachowuje się jak zwykły węzeł tranzytowy, przeszukując ponownie strefę DNS i wysyłając odpowiedź dalej lub próbując przesłać pakiet z powrotem do samego siebie, co szybko skutkuje błędem przepełnienia TTL samego pakietu i zwrotnym komunikatem Too many hops do nadawcy pierwszej transmisji.

Mechanizmy autoryzacji domenowej i kryptograficznej, w tym standardy SPF (Sender Policy Framework) oraz DKIM (DomainKeys Identified Mail), nakładają na konfigurację infrastruktury MX rygorystyczne wytyczne w zakresie spójności tożsamości serwera. Adres sieciowy wskazany w odpowiedzi na zapytanie o MX musi legitymować się certyfikatem bezpieczeństwa TLS (Transport Layer Security) dokładnie odpowiadającym nazwie tego węzła wpisanej w panelu. Wszelkie rozbieżności w nazewnictwie hosta skutkują natychmiastowym przerwaniem operacji przesyłania pakietów przez maszyny z rygorystyczną polityką ochrony przed spamem. Procedury nawiązywania bezpiecznego tunelu nakazują zakończenie łączności już we wczesnym etapie negocjacji szyfrowania, przez co same e-maile nie są ładowane do pamięci masowej na poziomie sprzętowym.

Rozbieżności między administracją siecią a naprawą fizycznego sprzętu

Kilkanaście lat temu, utrzymanie poprawnie funkcjonującego serwera MX w środowisku małej lub średniej firmy bardzo często opierało się na lokalnie działających, fizycznych komputerach. Komputery stacjonarne pełniące role maszyn dystrybucyjnych gromadziły korespondencję na klasycznych nośnikach talerzowych wewnątrz pomieszczeń biurowych. Usterki doręczeń poczty nierzadko pokrywały się w tamtych realiach z diagnozowaniem konkretnego uszkodzenia układów zasilania, przetwornic sekcji CPU na płytach głównych czy głowic magnetycznych samych dysków. Dziś zgłoszenia dotyczące usterek serwera pocztowego zlokalizowanego fizycznie w jednostce PC to prawdziwa rzadkość. Konfiguracje lokalnych serwerów poczty dla biur wyparte zostały niemal całkowicie na rzecz wielkoskalowych centrów danych dostarczających chmurowe pakiety biurowe, ze względu na standardy bezpieczeństwa zasilania awaryjnego i systemy redukujące ryzyko zniszczenia danych.

Analiza logów transportu SMTP, diagnostyka błędów propagacji w systemie DNS, poprawna budowa reguł uwierzytelniania kryptograficznego oraz sama rekonfiguracja rekordów to w obecnych standardach zadania stricte software'owe. Wymagają one uprawnień dostępowych do panelu operatora domeny i pracy bezpośrednio na linii komend systemów linuksowych na obcych stacjach serwerowych. Wymienione procedury weryfikacyjne leżą całkowicie poza zakresem działań warsztatu ukierunkowanego na przywracanie działania uszkodzonych obwodów, wymianę mostków PCH, lutowanie gniazd i układów KBC na płytach głównych urządzeń biurowych, przez co prawidłowa naprawa zablokowanego routingu MX powinna zostać zlecona administratorowi środowiska IT klienta lub wsparciu technicznemu jego zewnętrznego dostawcy usług hostingu.

Pomoc sprzętowego punktu naprawczego jest możliwa w ściśle określonym fizycznym scenariuszu. Jeżeli domena przestaje przyjmować i dystrybuować pocztę z powodu spalonego fizycznie sprzętu utrzymującego stare lokalne wdrożenie serwera z archiwami EDB i PST, interwencja serwisu staje się koniecznością. Technicy mogą usunąć bezpośrednie zwarcie na laminacie, dokonać wymiany uszkodzonego układu przetwornicy, czy przeprowadzić specjalistyczny proces zgrania sektorów dysku twardego w celu ratowania zgromadzonej dotychczas bazy danych klientów i skrzynek e-mail. Należy jednak jasno rozgraniczyć, że o ile przywrócenie sprawności samego komputera w formie hardware'owej i ewakuacja jego zarchiwizowanych plików należy do kanonu podstawowych napraw serwisowych, to zestawianie reguł na serwerach domenowych wymaga zaangażowania innych, niezależnych od warsztatu podmiotów zarządzających architekturą sieciową.