Tajemnice DNS

Tajemniczy MX

Rekord tego typu określa tzw. mail exchangera, czyli hosta, którego zadaniem jest obsługa poczty przychodzącej pod wskazany adres. Jako, że takich serwerów może być kilka, przypisuje się im priorytety będące liczbami naturalnymi (mniejsze wartości oznaczają wyższy priorytet). Jeśli nie jest możliwe użycie MX-a o wyższym priorytecie, wykorzystuje się tego o niższym.

W przypadku kiedy nie będzie można nawiązać połączenia z hostem docelowym, poczta trafi na drugi, który przechowa ją do czasu, gdy połączenie będzie dostępne. Jeśli mamy hosta, do którego nie ma połączenia internetowego, a jedynie np. modemowe, można skierować pocztę wysyłaną do niego na adres innego hosta, który będzie ją przesyłał przez modem (w ten sposób można uzyskać własny domowy adres e-mailowy).

Przypisanie mail exchangera domenie pozwala na skrócenie zapisu adresów e-mailowych - dzięki pominięciu nazwy hosta. Adres taki jest nie tylko krótszy, ale i łatwiejszy do zapamiętania - nazwa domeny wiąże się z instytucją, podczas gdy nazwa hosta nie musi.

Adres występujący po prawej stronie znaku '@' w adresie pocztowym nie musi wcale odpowiadać żadnemu istniejącemu hostowi. Wówczas jednak nie można np. użyć go jako parametru dla programu finger. Aby uzyskać rzeczywisty adres, pod którym odbierana jest poczta, należy odczytać rekord MX o najwyższym priorytecie przypisany temu adresowi. Jeżeli okazuje się, że szukany użytkownik nie ma konta na tym hoście, można jeszcze spróbować skorzystać z komendy VRFY protokołu SMTP (połączyć się z portem 25 hosta i podać komendy HELO, VRFY user, QUIT) - o ile jest ona dostępna (choć niestety nie wszystkie implementacje prawidłowo rozwijają aliasy pocztowe).

W jaki sposób działa DNS?

Warto najpierw omówić zawartość rekordu SOA. Jego część informacyjna jest podzielona na siedem pól:

- nazwę pierwotnego name servera dla strefy (czyli domeny bez poddomen)

- adres e-mailowy osoby odpowiedzialnej za jego zawartość (znak at jest zastąpiony kropką)

- numer seryjny zawartości strefy (serial number)

- odstęp czasowy odświeżania (refresh time; podany w sek)

- odstęp czasowy ponawiania próby połączenia (retry time)

- czas ważności (expire time)

- minimalny (domyślny) czas życia rekordów (minimum TTL).

Pierwotny DNS czyta dane z pliku konfiguracyjnego - ma on więc zawsze aktualne dane o strefie. Pozostałe name servery muszą je aktualizować, aby mieć w bazach takie same informacje, jak DNS pierwotny. Jeśli od ostatniego odświeżenia informacji upłynął czas określony przez parametr refresh, podejmowana jest próba aktualizacji danych. W przypadku niepowodzenia kolejne próby podejmowane są cykliczne w odstępach czasowych określonych parametrem retry.

Przesyłanie przy każdej aktualizacji całej bazy dla danej strefy generowałoby zbyt duży ruch (typowe czasy aktualizacji są na poziomie kilku godzin, podczas gdy zmiany w bazie DNS na rzadko są wykonywane częściej niż co kilka tygodni), zastosowano więc rozwiązanie minimalizujące ilość przesyłanych danych. Próba aktualizacji rozpoczyna się od wysłania żądania przesłania rekordu SOA - jak pamiętamy zawiera on pole z numerem wersji bazy. Jest on porównywany z tym, który jest pamiętany w bazie. Jeżeli numer wzrósł - oznacza to, że baza została zmieniona, wysyłane więc jest żądanie przesłania całej bazy.

Znikające domeny

Zapewne każdy użytkownik Internetu spotkał się już z sytuacją, w której przy próbie nawiązania połączenia z hostem zgłaszany jest błąd - "ta domena nie istnieje", i to mimo, że domena ta jeszcze nie tak dawno funkcjonowała bez zarzutu. Co więcej, w większości przypadków istnieje ona nadal.

Jeśli przez dłuższy czas brak jest routingu do pierwotnego DNS-a domeny, name servery wtórne nie mogą aktualizować swoich baz danych. Jeśli upłynie czas określony przez pole expire rekordu SOA i pola TTL odpowiednich rekordów (zazwyczaj od jednego do kilku dni), tracą one ważność i są usuwane z pamięci wtórnych DNS-ów. W takiej sytuacji jedynym sposobem dostania się do hosta jest użycie adresu IP.