Модул 8 · 8.4
Често срещани грешки
Модул 8: Сигурност и отстраняване на проблеми · Време за четене: 10 минути
Цел на урока: След този урок ще разпознавате десетте най-често срещани DNS грешки по симптомите им и ще знаете как да ги отстраните.
Основни понятия: точка в края, двойно име на домейн, промяна на грешното място, два SPF записа, CNAME на основния домейн, забравен AAAA, MX без адрес, proxy за имейл, стар DS след трансфер, кеш
Как да използвате този урок
Грешките по-долу не идват от учебник, а от въпроси, които хостинг доставчиците получават всяка седмица. За всяка грешка ще видите: какво забелязва потребителят, как да го установите с един въпрос, и какво е решението. При проблем винаги започвате с едни и същи два въпроса: кои DNS сървъри (nameservers) има домейнът (dig +short NS example.com) и какво връща авторитетният DNS сървър (dig @<nameserver> <naam> <type>). С това решавате половината от случаите веднага.
1. Забравена точка в края
Симптом: CNAME, MX или NS не работи; дадена услуга казва "запис не е намерен".
Доказване: dig +short CNAME shop.example.com връща shops.platform.example.example.com.
Причина: в зона име без точка в края е относително: панелът добавя Вашия собствен домейн след него (урок 2.2).
Решение: запишете целевото име като пълно име с точка (shops.platform.example.). Някои панели добавят точката сами; след запазване проверете какво точно е записано.
2. Домейнът дублиран в името
Симптом: верификация или DKIM проверка при дадена услуга не минава, въпреки че записът "е там".
Доказване: dig +short TXT k2._domainkey.example.com не връща нищо, но dig +short TXT k2._domainkey.example.com.example.com връща резултат.
Причина: услугата изисква пълното име (k2._domainkey.example.com), а Вашият панел добавя домейна още веднъж след него.
Решение: в полето за име въведете само частта преди домейна Ви: k2._domainkey. Панелът обикновено показва под полето пълното име: проверете го.
3. Промяна на грешното място
Симптом: променяте запис, но нищо не се променя, дори след ден.
Доказване: dig +short NS example.com връща DNS сървъри на друга страна, различна от тази, при която сте направили промяната (например конструктор на сайтове или Cloudflare).
Причина: само страната, при която са DNS сървърите, определя DNS записите (урок 2.1). Записи на друго място не вършат нищо.
Решение: променете записа при страната на DNS сървърите, или върнете DNS сървърите обратно. Реален пример: някой настрои DNS сървърите към платформа за конструиране на сайтове за уебсайта, но A записът за mail не беше там. Резултат: изпращането работеше, получаването не, защото MX сочеше към mail.example.com, а това име вече не съществуваше.
4. Два SPF записа
Симптом: имейлите по-често попадат в спам или биват отказвани, откакто сте свързали нова услуга.
Доказване: dig +short TXT example.com връща два реда, които започват с v=spf1.
Причина: новата услуга е казала "добавете този SPF запис", и това е направено буквално. С два SPF записа SPF е невалиден (permerror, RFC 7208), което е по-лошо от липса на SPF.
Решение: обединете ги в един запис: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Внимавайте за ограничението от десет справки (урок 4.3).
5. CNAME на основния домейн (apex)
Симптом: панелът отказва записа, или след запазване имейлът Ви спира да работи.
Доказване: услугата изисква "направете CNAME за @".
Причина: CNAME не може да съществува заедно с други записи, а на основния домейн винаги има SOA и NS записи (и често MX и TXT). Вижте урок 3.2.
Решение: на @ използвайте A записа (и евентуално AAAA), който услугата предоставя, а CNAME използвайте само за www или поддомейн. Някои DNS доставчици имат ALIAS или "CNAME flattening" за този случай.
6. Забравен AAAA при трансфер
Симптом: след трансфер част от посетителите (често мобилни) все още виждат стария сайт, или грешка в сертификата.
Доказване: dig +short A example.com връща новия адрес, dig +short AAAA example.com все още връща адрес на стария сървър.
Причина: устройствата с IPv6 предпочитат AAAA. Само A записът е променен.
Решение: променете и AAAA, или го премахнете, ако новият сървър няма IPv6. Реален пример: при свързване на платформа за онлайн магазин, освен новия A запис трябваше да се премахне и старият AAAA, иначе магазинът оставаше недостъпен за част от посетителите.
7. MX, който сочи към нищо
Симптом: не получавате имейли; подателите получават съобщение за грешка.
Доказване: dig +short MX example.com връща 10 mail.example.com., но dig +short A mail.example.com не връща нищо (NXDOMAIN).
Причина: MX сочи към име, а това име трябва да има A или AAAA запис. Често A записът за mail изчезва при трансфер на DNS сървъри. MX не може да сочи и към IP адрес или към CNAME (RFC 2181).
Решение: създайте A запис за името на пощенския сървър, или насочете MX към име, което има адрес.
8. Имейлът е другаде, но старият сървър мисли, че трябва да го достави
Симптом: имейл отвън пристига нормално при новия Ви доставчик, но имейл от собствения Ви уебсайт (контактна форма, онлайн магазин) никога не пристига. Понякога получавате 550 Unknown user.
Доказване: MX сочи към новия доставчик, но на уеб сървъра локалната доставка на имейли все още е включена.
Причина: това не е DNS грешка, но изглежда точно като такава. Уеб сървър, който смята, че сам управлява пощенските кутии, не поглежда MX записа.
Решение: изключете локалната доставка в панела на Вашия хостинг (в DirectAdmin: отметката "Use this server to handle my e-mails"). Други панели имат подобна настройка, често наречена "Remote mail exchanger" или "външен имейл".
9. Включен proxy за имейл
Симптом: при DNS доставчик с proxy функция (като оранжевото облаче при Cloudflare) уебсайтът работи, но пощенската Ви програма не може да се свърже, или сертификатът на сайта не се подновява.
Доказване: dig +short A mail.example.com връща адрес на proxy вместо на Вашия пощенски сървър.
Причина: уеб proxy препраща само уеб трафик, не и имейл.
Решение: изключете proxy (сиво облаче, "DNS only") за mail и всички имена, които пощенската Ви програма използва. За сертификати: временно изключете proxy, докато сертификатът бъде издаден, или използвайте правилния SSL режим при proxy.
10. Стар DS след трансфер
Симптом: след трансфер на DNS сървъри домейнът Ви е недостъпен за част от света; други хора нямат никакъв проблем.
Доказване: dig example.com @1.1.1.1 връща SERVFAIL, dig +cd example.com @1.1.1.1 връща отговор. DNSViz (https://dnsviz.net/, урок 8.1) оцветява DS в червено и рисува под него сив, пунктиран ключ, който вече не е във Вашата зона. Zonemaster и Verisign DNSSEC Debugger съобщават същото с думи.
Причина: в регистъра все още стои DS на старата страна (урок 8.1). Само валидиращите резолвери се провалят, затова не всеки забелязва проблема.
Решение: актуализирайте DS с ключа на новата страна, или го премахнете и после включете DNSSEC отново.
И "грешката", която всъщност не е грешка: кешът
Много често всичко е наред, но Вие все още виждате стария отговор. Разпознава се по следното: dig @<nameserver> връща новия отговор, онлайн проверка от други държави също, само Вашият компютър не. Решение: режим "в анонимен прозорец", телефон през 4G/5G, или изчистване на кеша (урок 8.2). Също така забравен ред в hosts файла на компютъра Ви (от по-ранен тест преди трансфер) дава същата картина: премахнете този ред.
Свързан капан: ново име се заявява, преди да е създадено. Резолверът запомня "не съществува" (отрицателен кеш) и отнема повече време, преди новото име да заработи (урок 6.2).
На практика: как изглежда това в панела
Много панели предотвратяват част от тези грешки. Моят WebOké например предупреждава, ако липсва точката в края, и показва под полето за име пълното име; DirectAdmin отказва записи, които не са валидни, със съобщение "Error Writing Records". Cloudflare и други доставчици имат подобни предупреждения. Преди по-големи промени направете резервно копие или експорт на зоната си, за да можете винаги да се върнете назад.
Обобщение
- Винаги започвайте с: кои DNS сървъри, и какво казва авторитетният DNS сървър.
- Повечето грешки са в името (точка, двойно име на домейн) или в мястото (грешна страна).
- Един SPF запис, без CNAME на @, AAAA се прехвърля заедно с A, MX сочи към име с адрес.
- SERVFAIL след трансфер обикновено е стар DS.
- Ако само Вие виждате стария отговор, причината е Вашият кеш или hosts файл.
Тест
Задача
Задача Z8.4: Разпознаване на грешки. Получавате пет кратки случая с извадка от dig към тях (в учебната среда). За всеки случай изберете коя от десетте грешки е налице. След това истинско проучване: разберете с dig или онлайн инструмент кой запис е грешен за dnssec-failed.org (статус и какво дава +cd), и дали wikipedia.org има точно един SPF запис.
Допълнително четене
Тези статии описват решенията в панелите на WebOké; при други доставчици бутоните се наричат различно.
- Уебсайтът или имейлът не работи след преместване или промяна на DNS: проверете Вашия домейн
- Колко време отнема промяна на nameserver или DNS, и какво да направите, ако не я виждате?
- Ръководство за DirectAdmin 18.7: Моят домейн още не работи след трансфер или промяна
- Ръководство за DirectAdmin 18.9: Вече не получавам имейли
- Ръководство за DirectAdmin 5.4: CNAME записи и точката в края
- Изпращането на имейл през PHP не работи, MX записите сочат другаде
- Използване на собствени или външни nameserver сървъри (като Cloudflare) за Вашия домейн