Как работят домейните и DNS: ръководство за нетехнически хора

Домейнът е името, което хората въвеждат, за да стигнат до сайта ти, като example.com, а DNS (Domain Name System) е интернет указателят, който превежда това име в мястото, където сайтът ти реално се намира. Наемаш домейна от регистратор, после добавяш DNS записи, които казват „уебсайтът е там“ и „имейлът е насам“. Свързването на персонализиран домейн към приложение е най-вече въпрос на добавяне на правилния запис на правилното място и изчакване да поеме действие.

Защо има значение, когато строиш с AI

AI конструкторът може да напише и да хостне приложението ти, но домейнът ти живее извън него – често при отделна компания, в контролен панел, пълен с непознати типове записи. Тук много пускания спират: приложението е готово, но домейнът показва грешка, или имейлът неочаквано спира да работи след промяна в DNS.

Малко разбиране върши голяма работа. Ще знаеш кой запис иска хостингът ти, защо още не работи и как да не счупиш нещата (като имейла), които вече зависят от домейна ти.

Ежедневна аналогия

Представѝ си списъка с контакти на телефона си.

Не помниш телефонния номер на приятеля си; докосваш името му и телефонът го търси. DNS прави същото за интернет: въвеждаш example.com, а DNS търси номера (IP адреса) на сървъра, към който да се свържеш.

• Домейнът е името на контакта.
• Регистраторът е компанията, която официално записва, че името е твое.
• DNS записите са данните, запазени под името: телефонен номер, имейл адрес, домашен адрес.
• Name сървърите са кой указател е официалният за това име.
• Кеширането е телефонът да помни номер известно време. Ако приятелят ти смени номера си, някои телефони ще продължават да звънят на стария, докато запазеното копие се обнови – това е DNS „разпространението“.

Частите на името на домейн

Взимаме app.example.com:

Не купуваш домейн завинаги; регистрираш го за период (обикновено година или повече) и го подновяваш. Ако изтече, някой друг може да го регистрира.

Как работи DNS търсенето

Когато някой въведе app.example.com:

1. Браузърът пита DNS resolver – обикновено на доставчика на интернет или на публична услуга – за адреса.
2. Ако resolver-ът има актуален кеширан отговор, отговаря веднага.
3. Ако няма, върви по йерархията: root сървърите го насочват към .com сървърите, които го насочват към name сървърите на твоя домейн.
4. Твоите name сървъри връщат записа, който си задал, например CNAME към хостинга или A запис с IP адрес.
5. Resolver-ът кешира отговора за TTL (time to live) на записа и го предава на браузъра, който се свързва със сървъра.

Цялото това обикновено се случва за милисекунди.

DNS записите, които ще използваш

Няколко правила, които си заслужава да знаеш:

• CNAME не може да споделя име с други записи. Затова стандартният CNAME не може да е на корена на домейна, който винаги има NS и други записи. Много DNS доставчици предлагат заобиколни решения, наречени ALIAS, ANAME или CNAME flattening.
• TXT записите вършат много работа с имейла. SPF изброява кой може да изпраща поща от твоя домейн; DKIM публикува ключ за проверка на подписите; DMARC казва на получателите какво да правят с поща, която не минава тези проверки.
• По-ниските MX числа означават по-висок приоритет. Пощата се опитва първо с най-ниското.

Разпространение и TTL

„Разпространението“ звучи така, сякаш промените бавно се разпространяват из интернет. Реално става дума за кеширане: resolver-ите пазят копие на всеки отговор за неговия TTL и питат отново само след като изтече. Затова:

• Нов запис, който никога не е търсен, често работи за минути.
• Промяна на съществуващ запис отнема до старото му TTL, докато се види навсякъде.
• Смяната на name сървъри може да отнеме до ден-два, защото тези записи се кешират по-дълго на ниво TLD.

Полезен трик: преди планирана промяна намали TTL на записа (например до няколко минути), изчакай да изтече старото TTL и тогава направи промяната.

Примерен случай: свързване на приложение за резервации с домейн

Имаш yoursalon.com. Сайтът ти и имейлът на Google Workspace вече го ползват. Изградил си приложение за резервации и искаш да е на book.yoursalon.com.

1. Намери къде се управлява DNS-ът. Може да е при регистратора или при отделен DNS доставчик. NS записите ти казват.
2. Добави CNAME за book, който сочи към целта, която хостът на приложението ти даде.
3. Добави TXT запис, ако хостът иска такъв за потвърждение на собственост.
4. Не пипай MX и TXT записите за имейл. Имейлът продължава да работи, защото не си ги докосвал.
5. Потвърди в хоста, след като DNS се обнови. Хостът тогава издава HTTPS сертификат за book.yoursalon.com.
6. Тествай на телефон с мобилни данни, които използват различен resolver и кеш от домашния ти Wi-Fi.

Ако искаш приложението на корена yoursalon.com, ще ти трябват A записи или функцията ALIAS/flattening на DNS доставчика – и щеше да замениш сегашния си уебсайт там. За повече стъпки виж как да свържеш персонализиран домейн.

Често срещани грешки и заблуди

• „Домейнът и хостингът са едно и също.“ Домейнът е името; хостингът е мястото, където работи приложението. DNS ги свързва.
• Използване на A запис, когато хостът иска CNAME (или обратното). Следвай точно инструкциите на хоста.
• Печатни грешки в целта. Един грешен символ в CNAME целта и потвърждението се проваля.
• Смяна на name сървъри без прехвърляне на записите. Преместване на DNS към нов доставчик без да създадеш наново MX и TXT записите е класически начин да счупиш имейла.
• Проксиране, когато не трябва. Някои DNS доставчици, като Cloudflare, могат да проксират трафика. Някои хостове изискват записът да е „DNS only“, за да издават сертификати.
• Изтриване на „непознати“ TXT записи. Често са записи за потвърждение или за сигурност на имейла, от които нещо зависи.
• Домейнът изтича. Включи автоматично подновяване и дръж картата за плащане актуална.

Какво да поискаш от AI конструктора

DNS е извън кода ти, затова става дума повече за това за какво да питаш:

• „Какъв точно DNS запис ми трябва за app.mydomain.com – тип, име и стойност?“
• „Ще засегне ли тази промяна имейла ми?“
• „След добавянето на записа домейнът показва грешка. Какво да проверя?“
• „Добави правилния canonical URL и пренасочвания, така че www и без www да не показват сайта два пъти.“
• „Настрой изпращането на имейл от моя домейн – кои SPF, DKIM и DMARC записи ще ми трябват?“ Виж как да изпращаш имейли от приложението си.

Персонализирани домейни в Mythex

Всяко публикувано приложение в Mythex получава адрес yourname.mythex.app. В Pro можеш да използваш собствен домейн: купи го директно в Mythex (регистрацията се таксува отделно, а DNS за купените домейни се управлява вместо теб) или свържи вече притежаван домейн, като добавиш CNAME от поддомейн, например app.example.com, към адреса yourname.mythex.app на приложението си, и натиснеш Verify. HTTPS се издава автоматично. Ако DNS-ът ти е при Cloudflare, задай записа на „DNS only“. Препоръчват се поддомейни; за корен на домейна зависи от това дали DNS доставчикът ти поддържа ALIAS или flattening. Документацията за персонализирани домейни преминава през всяка стъпка, а цените показват какво включва Pro.

Въпроси