.htaccess и DNS: что настраивается записями DNS, а что в .htaccess

DNS и .htaccess — два разных уровня, которые часто путают. DNS решает, какой сервер отвечает за домен. .htaccess решает, что Apache делает с запросом, уже пришедшим на этот сервер. Классический источник путаницы: «как сделать www-редирект в DNS» — это невозможно, редирект делает только сервер.

Два разных уровня: DNS и .htaccess

Когда браузер открывает https://example.com/page, происходит два принципиально разных шага:

  1. DNS-резолюция: браузер спрашивает у DNS-сервера, какой IP-адрес стоит за example.com. DNS-записи хранятся у регистратора домена или DNS-хостинга (Cloudflare, ns1, 8сек и т.п.). На этом шаге решается: на какой физический сервер идти.
  2. HTTP-запрос на сервер: браузер соединяется с найденным IP и отправляет запрос. Apache на этом сервере читает .htaccess и решает: перенаправить, отдать файл, проверить авторизацию, подставить заголовки.

.htaccess вообще не участвует в DNS-резолюции — он включается только после того, как запрос уже пришёл на ваш сервер.

Что делается только в DNS

Эти задачи решаются записями DNS у регистратора или в DNS-панели — .htaccess не может их выполнить:

  • A / AAAA — указать IP-адрес (v4 / v6) сервера для домена. Если сменили хостинг — меняете A-запись, и трафик идёт на новый сервер.
  • CNAME — «псевдоним» домена на другой домен. Используется для поддоменов (www → основной домен) и для подключения CDN (example.com → xxx.cdn-provider.net).
  • MX — почтовый сервер домена. Где принимать email для @example.com. Никакого отношения к .htaccess не имеет.
  • TXT — текстовые данные: SPF (разрешённые отправители почты), DKIM (подпись письма), DMARC (политика обработки), верификация домена для Google Search Console, подтверждение для SSL-сертификата.
  • CAA — какие центры сертификации могут выдавать SSL для домена.
  • ALIAS / ANAME — у некоторых DNS-провайдеров: CNAME-подобная запись для корневого домена (apex). Про IP, не про редиректы.

Что делается только в .htaccess

Эти задачи решаются в .htaccess (или конфиге Apache) — DNS не может их выполнить:

  • Редирект http → https: DNS не умеет редиректить. Запись A говорит «вот сервер», а уже Apache на этом сервере отвечает на http-запрос кодом 301 и отправляет браузер на https.
  • Склейка www ↔ без-www: CNAME-запись www → example.com лишь говорит «www тоже идёт на тот же сервер». 301-редирект с www на без-www (или наоборот) — это .htaccess.
  • Редиректы страниц и путей: /old-page/ → /new-page/ — только сервер, никакого DNS.
  • Авторизация, доступ по IP, пароль: DNS не знает о пользователях и запросах.
  • HTTP-заголовки: HSTS, CSP, X-Frame-Options, Cache-Control — только сервер.
  • Кэширование статики: ExpiresByType — только сервер.
  • Блокировка ботов по User-Agent: DNS не видит заголовки HTTP-запроса.

Миф: www-редирект в DNS

Один из самых популярных запросов — «как настроить www-редирект в DNS». Краткий ответ: нельзя.

DNS не умеет делать HTTP-редиректы. CNAME-запись www → @ (или www → example.com) означает только: «поддомен www смотрит на тот же IP, что и основной домен». Браузер, открыв www.example.com, всё равно придёт на ваш сервер с запросом, где в заголовке Host стоит www.example.com. Apache увидит www в Host и ответит — но без инструкции в .htaccess никакого редиректа не будет.

Правильная www-склейка (без-www как канонический):

.htaccessкопировать
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

При этом CNAME-запись www → example.com в DNS всё равно нужна — иначе www.example.com просто не резолвится и не доходит до вашего сервера. Но 301-редирект делает .htaccess, а не DNS.

Аналогичная ситуация с «голым доменом» (apex): ALIAS/ANAME у некоторых DNS-провайдеров позволяет указать CNAME для корня — это про то, какой IP у домена, а не про редирект.

Поддомен против подкаталога

Частый вопрос: лучше сделать блог на blog.site.ru или site.ru/blog/?

Поддомен blog.site.ru:

  • Требует отдельной DNS-записи A или CNAME у регистратора.
  • Обычно это отдельный document root (отдельная папка на сервере) или даже отдельный сервер.
  • У поддомена свой .htaccess — он не наследует правила корневого сайта.
  • С точки зрения SEO — для Google это отдельный сайт (хотя Search Console позволяет добавить как часть домена).

Подкаталог site.ru/blog/:

  • Никаких DNS-записей не нужно — это просто папка на том же сервере.
  • Правила из корневого .htaccess действуют и здесь (если нет .htaccess в самом подкаталоге с противоречащими правилами).
  • Нельзя .htaccess-ом «создать поддомен» — это разные уровни.

Переезд на новый домен: DNS + .htaccess вместе

Правильный переезд с old-domain.ru на new-domain.ru требует настройки на обоих уровнях:

  1. DNS нового домена → направить A-запись на тот же (или новый) сервер, где лежит сайт.
  2. На СТАРОМ домене в .htaccess поставить 301-редирект каждого пути на соответствующий путь нового домена.
  3. Держать старый домен и редирект рабочими минимум год.
.htaccessкопировать
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*)$ https://new-domain.ru/$1 [R=301,L,QSA]
</IfModule>

Нельзя «переехать» только записью DNS: если просто перенаправить A-запись старого домена на новый сервер, браузер придёт на новый сервер с заголовком Host: old-domain.ru. Apache отдаст контент нового сайта под старым URL — это дубли, а не переезд. 301-редирект в .htaccess на старом домене — обязательный шаг.

Парковка домена и CDN

Домен «припаркован» у регистратора — заглушка DNS-провайдера. На таком домене нет вашего Apache, .htaccess не работает вообще. Чтобы .htaccess вступил в силу — сначала направьте DNS-записи на хостинг, где лежит ваш сайт.

Сайт за CDN (Cloudflare и другие):

  • DNS-записи домена указывают на CDN (CNAME или специальные NS).
  • CDN принимает запросы, кэширует и передаёт вашему серверу (origin). На origin .htaccess работает, но Apache видит запросы от CDN-узлов, а не от реальных браузеров.
  • CDN сам может делать правила («Page Rules» в Cloudflare, «Transform Rules» и т.п.) — это аналог некоторых .htaccess-возможностей. Не дублируйте: если «Always Use HTTPS» включён в Cloudflare, не ставьте ещё и https-редирект в .htaccess — получите лишний хоп.
  • За CDN %{HTTPS} в mod_rewrite всегда off (CDN сам терминирует TLS). Используйте RewriteCond %{HTTP:X-Forwarded-Proto} !https для https-редиректа.