DNS записи на един лист за сайт и поща

01Какво прави всеки от шестте записа

Всеки запис има тип, име, съдържание и TTL, тоест срок, за който резолверите го пазят в кеша си. Типът определя какво се пише в полето за съдържание.

Източник: Cloudflare Docs, DotPAPA, dnsrobot

A и AAAA са двете версии на един и същ запис, по една за всеки вид IP адрес. Ако сървърът ви има и двата адреса, добавя се по един запис от всеки тип.

02Кои записи сочат сайта

Най-простата настройка е `A` за основния домейн и `CNAME` за `www`. Примерна зона от наръчника на DotPAPA сочи домейна към адрес `192.0.2.1`, а `www` е псевдоним на `example.com.`.

CNAME е удобен, когато услугата ви дава име, а не фиксиран адрес. Така при смяна на адреса от страна на доставчика не променяте нищо у себе си. Това е наш извод от начина, по който работи псевдонимът.

Netlify автоматично създава собствени записи, когато свържете домейн със сайт, ако той се управлява от Netlify DNS. Не ги трийте, освен ако искате да откачите сайта от домейна. За хостинг на статичен сайт от хранилище вижте и GitHub Pages с ваш домейн.

03Как се нареждат MX и TXT за поща

MX записът казва кои сървъри приемат пощата за домейна. Всеки има приоритет, като по-малкото число се предпочита. Например `10 mail1.example.com` се опитва преди `20 mail2.example.com`.

TXT записите носят защитата на пощата. В тях стоят SPF, DKIM и свързаните с DMARC настройки, както и проверките за собственост на домейна. Пример за SPF е `v=spf1 include:_spf.google.com ~all`.

Netlify съветва да ползвате TXT вместо отделния тип SPF, който е остарял. Един TXT запис при Netlify побира до 255 знака. Cloudflare пък добавя двойни кавички сама, ако запазите нов TXT без тях. Подробната настройка е в статията за SPF, DKIM и DMARC, а изборът къде да стои пощата е в материала за имейл на собствен домейн.

04За какво служи CAA

CAA указва кои удостоверителни центрове имат право да издават сертификати за домейна. Записът `0 issue "letsencrypt.org"` разрешава издаване само от Let's Encrypt. Ако CAA липсва, ограничение няма, а ако го добавите, проверете дали включва центъра, който реално ползвате. Този извод е наш.

TXT често се използва и преди издаване на SSL/TLS сертификат, за да се докаже собствеността върху домейна. Затова не изтривайте непознат TXT запис, без да проверите за какво е.

05Грешки, които се повтарят

Горната граница за размера е 4096 байта на запис, а за няколко записа с едно и също име и тип общата дължина не бива да надвишава 8192 знака. Малките сайтове рядко стигат до нея, но дълги TXT стойности за DKIM могат да се доближат.

• Несъответстващ тип. Адрес в IPv4 формат в AAAA или име на сървър в A не работят. Проверете, че типът отговаря на съдържанието.
• Объркани кавички в TXT. Cloudflare връща грешка при непоследователни кавички, например отваряне без затваряне.
• Конфликтни записи. Преглеждайте за дублирани или противоречиви редове, преди да търсите причината другаде.
• Редакция вместо подмяна. Netlify не позволява директна редакция. Добавяте нов запис и после триете стария, така че при прехода да не настъпи прекъсване.
• Неподходящи имена. Етикетът е до 63 знака, а цялото име до 253. За съвместимост със сертификатите се препоръчват само букви, цифри и тирета.
• Забравен MX след смяна на сървъри. Ако промените DNS сървърите, преместете и пощенските записи. Стъпките за `.bg` домейн са в материала за смяна на DNS сървърите.

06Как да проверите записите след промяна

Най-бързо е с `dig`. Командите са `dig example.com A`, `dig example.com MX` и `dig example.com TXT`. На Windows съответстват `nslookup -type=A example.com` и `nslookup -type=MX example.com`. Същото покрива и инструментът за DNS на нашия сайт.

Ако промяната не личи, минете през този списък:

1. Проверете на кои сървъри за имена е зоната. 2. Сверете стойността на записа буква по буква. 3. Убедете се, че типът е правилен. 4. Погледнете TTL на стария запис. 5. Потърсете конфликтни записи. 6. Пробвайте с няколко резолвера.

Кешът обяснява забавянето. Резолверите могат да ползват стари данни, докато TTL не изтече. Netlify обявява до 48 часа за разпространение, като повечето промени се виждат до няколко часа.

Преди планирана миграция намалете TTL. Типичните стойности са 300 секунди при преместване, 3600 за обичайни записи и 86 400 за стабилни като NS и MX. По наша сметка по данни на кешът на стабилен запис живее 288 пъти по-дълго от този при миграция (86 400 : 300). Затова срокът на стария запис определя колко чакате, а при Netlify горната граница остава 48 часа.