Moduł 8 · 8.4
Najczęściej popełniane błędy
Moduł 8: Bezpieczeństwo i rozwiązywanie problemów · Czas czytania: 10 min
Cel lekcji: Po tej lekcji rozpoznają Państwo dziesięć najczęściej popełnianych błędów DNS po ich objawach i będą wiedzieć, jak je rozwiązać.
Kluczowe pojęcia: kropka na końcu, podwójna nazwa domeny, zmiana w niewłaściwym miejscu, dwa rekordy SPF, CNAME na gołej domenie, zapomniany AAAA, MX bez adresu, proxy dla poczty, stary DS po transferze, pamięć podręczna
Jak korzystać z tej lekcji
Poniższe błędy nie pochodzą z podręcznika, lecz z pytań, które dostawcy hostingu otrzymują co tydzień. Przy każdym błędzie znajdą Państwo: co zauważa użytkownik, jak wykazać to jednym zapytaniem oraz jakie jest rozwiązanie. Przy problemie zawsze zaczynają Państwo od tych samych dwóch pytań: jakie serwery nazw ma domena (dig +short NS example.com) oraz co zwraca autorytatywny serwer nazw (dig @<nameserver> <naam> <type>). Dzięki temu rozwiążą Państwo już połowę przypadków.
1. Zapomniana kropka na końcu
Objaw: CNAME, MX lub NS nie działa; usługa zgłasza, że "rekord nie został znaleziony".
Jak wykazać: dig +short CNAME shop.example.com zwraca shops.platform.example.example.com.
Przyczyna: w strefie nazwa bez kropki na końcu jest względna: panel dokleja do niej Państwa własną domenę (lekcja 2.2).
Rozwiązanie: proszę zapisać nazwę docelową jako pełną nazwę z kropką (shops.platform.example.). Niektóre panele same dodają kropkę; po zapisaniu proszę sprawdzić, co faktycznie zostało zapisane.
2. Podwojona nazwa domeny w nazwie rekordu
Objaw: weryfikacja lub sprawdzenie DKIM u danej usługi nie powodzi się, mimo że rekord "jest obecny".
Jak wykazać: dig +short TXT k2._domainkey.example.com nic nie zwraca, natomiast dig +short TXT k2._domainkey.example.com.example.com owszem.
Przyczyna: usługa podaje pełną nazwę (k2._domainkey.example.com), a Państwa panel dokleja domenę jeszcze raz.
Rozwiązanie: proszę wpisać w polu nazwy tylko część przed swoją domeną: k2._domainkey. Panel zwykle pokazuje pod polem pełną nazwę: proszę ją sprawdzić.
3. Zmiana w niewłaściwym miejscu
Objaw: zmieniają Państwo rekord, ale nic się nie zmienia, nawet po upływie doby.
Jak wykazać: dig +short NS example.com zwraca serwery nazw innego podmiotu niż ten, u którego dokonali Państwo zmiany (na przykład kreatora stron lub Cloudflare).
Przyczyna: o DNS decyduje wyłącznie podmiot obsługujący serwery nazw (lekcja 2.1). Rekordy zapisane gdzie indziej nie mają żadnego znaczenia.
Rozwiązanie: proszę zmienić rekord u podmiotu obsługującego serwery nazw albo przywrócić poprzednie serwery nazw. Prawdziwy przykład: ktoś ustawił serwery nazw na platformę do budowy stron dla strony internetowej, ale rekordu A dla mail tam nie było. Skutek: wysyłanie działało, odbieranie nie, ponieważ MX wskazywał na mail.example.com, a ta nazwa już nie istniała.
4. Dwa rekordy SPF
Objaw: poczta coraz częściej trafia do spamu albo jest odrzucana, odkąd podłączyli Państwo nową usługę.
Jak wykazać: dig +short TXT example.com zwraca dwie linie zaczynające się od v=spf1.
Przyczyna: nowa usługa poprosiła o "dodanie tego rekordu SPF", i zostało to zrobione dosłownie. Przy dwóch rekordach SPF, SPF jest nieważne (permerror, RFC 7208), co jest gorsze niż brak SPF w ogóle.
Rozwiązanie: proszę połączyć je w jeden rekord: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Proszę pamiętać o limicie dziesięciu wyszukiwań (lekcja 4.3).
5. CNAME na gołej domenie
Objaw: panel odrzuca rekord, albo po zapisaniu poczta przestaje działać.
Jak wykazać: usługa prosi o "utworzenie CNAME dla @".
Przyczyna: CNAME nie może występować obok innych rekordów, a na gołej domenie zawsze znajdują się rekordy SOA i NS (a często też MX i TXT). Zob. lekcja 3.2.
Rozwiązanie: proszę użyć na @ rekordu A (oraz ewentualnie AAAA) wskazanego przez usługę, a CNAME zastosować wyłącznie dla www lub subdomeny. Niektórzy dostawcy DNS mają na ten przypadek funkcję ALIAS lub tzw. "CNAME flattening".
6. Zapomniany AAAA przy transferze
Objaw: po transferze część odwiedzających (często na urządzeniach mobilnych) nadal widzi starą stronę, albo pojawia się błąd certyfikatu.
Jak wykazać: dig +short A example.com zwraca nowy adres, natomiast dig +short AAAA example.com nadal adres starego serwera.
Przyczyna: urządzenia z IPv6 preferują rekord AAAA. Zaktualizowany został tylko rekord A.
Rozwiązanie: proszę zaktualizować również AAAA albo usunąć go, jeśli nowy serwer nie obsługuje IPv6. Prawdziwy przykład: przy podłączaniu platformy sklepu internetowego oprócz nowego rekordu A trzeba było usunąć także stary rekord AAAA, inaczej sklep pozostawał niedostępny dla części odwiedzających.
7. MX wskazujący donikąd
Objaw: nie odbierają Państwo poczty; nadawcy otrzymują komunikat o błędzie.
Jak wykazać: dig +short MX example.com zwraca 10 mail.example.com., ale dig +short A mail.example.com nic nie zwraca (NXDOMAIN).
Przyczyna: MX wskazuje na nazwę, a ta nazwa musi mieć rekord A lub AAAA. Często rekord A dla mail zniknął przy transferze serwerów nazw. MX nie może też wskazywać na adres IP ani na CNAME (RFC 2181).
Rozwiązanie: proszę utworzyć rekord A dla nazwy serwera poczty albo skierować MX na nazwę, która ma przypisany adres.
8. Poczta gdzie indziej, ale stary serwer uważa, że to on ma dostarczać pocztę
Objaw: poczta z zewnątrz trafia poprawnie do nowego dostawcy, ale wiadomości z Państwa własnej strony (formularz kontaktowy, sklep internetowy) nigdy nie docierają. Czasem pojawia się komunikat 550 Unknown user.
Jak wykazać: MX wskazuje na nowego dostawcę, ale na serwerze WWW nadal włączone jest lokalne dostarczanie poczty.
Przyczyna: to nie jest błąd DNS, choć na niego wygląda. Serwer WWW, który uważa, że sam obsługuje skrzynki pocztowe, nie zwraca uwagi na MX.
Rozwiązanie: proszę wyłączyć lokalne dostarczanie w panelu hostingu (w DirectAdmin: pole wyboru "Gebruik deze server om mijn e-mails af te handelen", czyli "Użyj tego serwera do obsługi mojej poczty e-mail"). Inne panele mają podobne ustawienie, często nazywane "Remote mail exchanger" lub "poczta e-mail zewnętrzna".
9. Proxy włączone dla poczty
Objaw: u dostawcy DNS z funkcją proxy (jak pomarańczowa chmurka w Cloudflare) strona działa, ale program pocztowy nie może się połączyć, albo certyfikat strony nie jest odnawiany.
Jak wykazać: dig +short A mail.example.com zwraca adres proxy zamiast adresu Państwa serwera poczty.
Przyczyna: proxy internetowe przekazuje wyłącznie ruch WWW, nie pocztę.
Rozwiązanie: proszę wyłączyć proxy (szara chmurka, "DNS only") dla mail oraz wszystkich nazw używanych przez Państwa program pocztowy. W przypadku certyfikatów: proszę tymczasowo wyłączyć proxy do czasu wydania certyfikatu albo zastosować odpowiedni tryb SSL przy proxy.
10. Stary DS po transferze
Objaw: po transferze serwerów nazw Państwa domena jest niedostępna dla części świata; inni nie zauważają żadnego problemu.
Jak wykazać: dig example.com @1.1.1.1 zwraca SERVFAIL, natomiast dig +cd example.com @1.1.1.1 zwraca odpowiedź. DNSViz (https://dnsviz.net/, lekcja 8.1) oznacza DS na czerwono i rysuje pod nim szary, przerywany klucz, którego już nie ma w Państwa strefie. Zonemaster i Verisign DNSSEC Debugger zgłaszają to samo słownie.
Przyczyna: u rejestru nadal widnieje DS od poprzedniego podmiotu (lekcja 8.1). Problem dotyczy tylko walidujących resolverów, dlatego nie wszyscy go zauważają.
Rozwiązanie: proszę zlecić aktualizację DS z kluczem nowego podmiotu albo usunąć go, a następnie ponownie włączyć DNSSEC.
A "błąd", który błędem nie jest: pamięć podręczna
Bardzo często wszystko jest w porządku, ale Państwo nadal widzą starą odpowiedź. Rozpoznają to Państwo po tym, że: dig @<nameserver> zwraca nową odpowiedź, podobnie jak internetowy serwis sprawdzający w innych krajach, tylko nie Państwa komputer. Rozwiązanie: tryb prywatny przeglądarki, telefon przez 4G/5G, albo wyczyszczenie pamięci podręcznej (lekcja 8.2). Taki sam obraz daje też zapomniany wpis w pliku hosts na Państwa komputerze (pozostałość po wcześniejszym teście przed transferem): proszę usunąć ten wpis.
Pokrewna pułapka: sprawdzanie nowej nazwy, zanim jeszcze ją Państwo utworzyli. Resolver zapamiętuje wtedy "nie istnieje" (negatywna pamięć podręczna) i działanie nowej nazwy trwa dłużej (lekcja 6.2).
W praktyce: jak to wygląda w panelu
Wiele paneli zapobiega części tych błędów. Moje WebOké na przykład ostrzega, gdy brakuje kropki na końcu, i pokazuje pod polem nazwy pełną nazwę; DirectAdmin odrzuca nieprawidłowe rekordy z komunikatem "Error Writing Records". Cloudflare i inni dostawcy mają podobne ostrzeżenia. Przed większymi zmianami proszę zrobić kopię zapasową lub eksport swojej strefy, dzięki czemu zawsze będą mogli Państwo wrócić do poprzedniego stanu.
Podsumowanie
- Proszę zawsze zaczynać od: jakie są serwery nazw i co zwraca autorytatywny serwer nazw.
- Większość błędów tkwi w nazwie (kropka, podwójna nazwa domeny) albo w miejscu (niewłaściwy podmiot).
- Jeden rekord SPF, brak CNAME na @, AAAA przeniesione razem z A, MX wskazujący na nazwę z adresem.
- SERVFAIL po transferze to zwykle stary DS.
- Jeśli tylko Państwo widzą starą odpowiedź, to kwestia pamięci podręcznej albo pliku hosts.
Quiz
Zadanie
Zadanie Z8.4: Rozpoznawanie błędów. Otrzymają Państwo pięć krótkich przypadków wraz z wynikiem polecenia dig (w środowisku kursowym). Dla każdego przypadku proszę wybrać, który z dziesięciu błędów to jest. Następnie prawdziwe poszukiwanie: proszę ustalić za pomocą dig lub narzędzia internetowego, który rekord jest nieprawidłowy dla dnssec-failed.org (jaki jest status i co daje +cd), oraz czy wikipedia.org ma dokładnie jeden rekord SPF.
Dalsza lektura
Poniższe artykuły opisują rozwiązania w panelach WebOké; u innych dostawców przyciski mogą nazywać się inaczej.
- Strona internetowa lub poczta e-mail nie działają po przeniesieniu lub zmianie DNS: prosimy sprawdzić Państwa domenę
- Jak długo trwa zmiana nameserverów lub DNS i co zrobić, jeśli zmiana nie jest widoczna?
- Instrukcja DirectAdmin 18.7: Moja domena jeszcze nie działa po transferze lub zmianie
- Instrukcja DirectAdmin 18.9: Nie otrzymuję już wiadomości e-mail
- Instrukcja DirectAdmin 5.4: Rekordy CNAME i kropka na końcu
- Wysyłanie poczty przez PHP nie działa, rekordy MX wskazują na inny serwer
- Korzystanie z własnych lub zewnętrznych serwerów nazw (np. Cloudflare) dla Państwa domeny