Перейти к содержимому 
Конфигурация DNS Hetzner чтобы сайт, поддомены и почта работали без сбоев, а изменения быстро вступали в силу. В этом руководстве я покажу вам необходимые настройки в Hetzner DNS, проверенный пример конфигурации и практические методы тестирования, чтобы вы могли избежать ошибок на ранних этапах и сохранить вашу зону чистой.
Центральные пункты
Следующие ключевые моменты дадут вам краткий обзор того, что важно для надежной зоны DNS.
- Сервер имен правильно вводить данные с помощью регистратора
- A/AAAA для Web, MX/TXT для почты
- TTL Выберите подходящий вариант и ждите распространения
- SPF/DKIM против спама и подмены
- Мониторинг и тесты после изменений
DNS в двух словах: что вам действительно нужно
Я назначаю домен через Записи конкретные места назначения, чтобы браузеры и почтовые серверы могли найти мои услуги. A A-Record указывает на IPv4-адрес, AAAA - на IPv6, а MX определяет доставку электронной почты. CNAME образует псевдоним, указывающий на другое имя, а TXT содержит информацию для SPF или проверки. Чистая базовая зона состоит из A/AAAA для основного домена, CNAME для www, MX для почты и SPF-TXT. Таким образом, я сохраняю зону чистой, быстро обслуживаемой и открытой для последующих расширений.
Добавьте домен в консоль Hetzner DNS
В консоли DNS я сначала создаю новый Зона и проверьте правильность написания домена. Затем я активирую ручное обслуживание Записичтобы я мог создавать и изменять определенные записи. Совет: я заранее записываю IP-адреса и почтовые адреса, чтобы потом вводить все без перерыва. Таким образом я избегаю опечаток и располагаю записи в спокойном порядке. Как только зона готова, я планирую смену серверов имен и последующие проверки.
Правильно укажите сервер имен у регистратора
После создания зоны я ввожу команду Сервер имен от Hetzner, чтобы администрирование было сосредоточено в консоли DNS. Обычные записи ns1.first-ns.de, robotns2.second-ns.de и robotns3.second-ns.com. Для доменов .de или .at я устанавливаю собственные серверы имен с Клейкие записичтобы сохранить ссылки и IP-адреса. Если вы никогда не делали этого раньше, вы можете найти отдельные шаги в руководстве по Установите клейкие пластинки. Затем мне требуется некоторое время для переключения, поскольку обновление может приходить с разной скоростью по всему миру.
Пример конфигурации: создание исполняемого веб-сайта и электронной почты
Для типичного веб-представительства я использую A-Record для корневого домена, CNAME для www и соответствующие почтовые записи. SPF-TXT не позволяет внешним серверам отправлять электронные письма от имени домена. Дополнительно я добавляю запись AAAA, если веб-сервер IPv6 предоставляет. Для внешних почтовых служб, таких как ForwardMX, я настраиваю MX и сохраняю их спецификации. В следующей таблице показана надежная отправная точка для многих настроек.
| Имя | Тип | Значение | Подсказка |
|---|---|---|---|
| @ | A | 195.201.210.43 | Веб-сервер IPv4 |
| @ | AAAA | Дополнительно: 2a01:4f8:xxxx:xxxx::1 | Веб-сервер IPv6 |
| www | CNAME | @ | Псевдоним на root |
| @ | MX | mx1.forwardmx.net | Прио 10 |
| @ | TXT | "v=spf1 include:_spf.forwardmx.net -all" | SPF против спуфинга |
Активируйте DNSSEC и установите DS-запись
Если для меня важна безопасность манипуляций, я активирую DNSSEC для зоны. В консоли Hetzner я генерирую ключи подписи для этого и затем получаю необходимые Данные DSкоторый я передаю на хранение регистратору. Я проверяю, правильно ли переданы алгоритм и дайджест. Затем я жду, пока цепочка от регистратора до зоны не подтвердится должным образом. Перед крупными сменами ключей я снижаю TTL и планирую временное окно, чтобы разрешители своевременно увидели новые подписи. Важно: если во время изменения произойдет ошибка, валидация не пройдет для получателей - поэтому я готовлю откат (не удаляйте старые ключи слишком рано) и тестирую с помощью валидационных резолверов.
Правильная установка TTL и понимание распространения
Die TTL определяет, как долго резолверы будут кэшировать запись. Для преобразований я выбираю короткое время TTL (например, 300 секунд), чтобы изменения стали заметны быстро. После окончательной настройки я снова увеличиваю значения, чтобы сэкономить запросы и добиться последовательного разрешения. Те, кто часто развертывает систему, предпочитают придерживаться 600-1200 секунд, а те, кто редко вносит изменения, используют 3600-14400. Практический обзор этого решения представлен в моем обзоре Оптимальный выбор TTL.
Домен Apex, CAA и сертификаты под контролем
Для целей SaaS на Зона Апекс Я помню, что CNAME не разрешается на @. Поэтому я использую A/AAAA провайдера или устанавливаю перенаправление на www на уровне веб-сервера. Для назначения сертификата я управляю с помощью Рекорды CAAкакие центры сертификации уполномочены выдавать сертификаты. Например, я поддерживаю только тот ЦС, который действительно использую, и дополнительно добавляю почтовый адрес для отчетов. Если я меняю CA, я ненадолго увеличиваю TTL и обновляю CAA перед выпуском. Для подстановочных знаков через ACME DNS-01 я убеждаюсь, что TXT-записи под _acme-challenge можно быстро установить и автоматически очистить, чтобы не оставалось старых проблем.
Создавайте поддомены и службы без лишних усилий
Для каждого поддомена я создаю соответствующий A- или CNAME-запись, в зависимости от того, указывает ли поддомен непосредственно на IP или на имя. Пример: blog.example.de как A-запись на блог VM, cdn.example.de как CNAME на имя CDN. Для API я провожу строгое различие между внутренними и публичными именами, чтобы избежать рисков. Стандартизированные имена, такие как api, app, img, помогают в обслуживании и мониторинге. Таким образом, я сохраняю структуру зоны и могу четко распределять изменения.
Дикие символы, SRV и специальные типы записей
Я использую Wildcard Records (*.example.de), например, для многоклиентских установок. Я слежу за тем, чтобы точные записи всегда имели приоритет над подстановочными знаками. Для таких служб, как SIP, Matrix или Autodiscover, я создаю SRV-записи и проверьте формат и приоритеты. TXT-записи с длинным содержимым (например, 2048-битный DKIM) разбиваются на несколько сегментов цитат, чтобы парсеры могли правильно их объединить. Я избегаю множественных записей SPF и объединяю записи в один правильный SPF, чтобы не нарушать лимит поиска.
Надежная доставка электронной почты: SPF, DKIM и DMARC
Для доверительной электронной почты я использую MX чистый SPF-TXT, который покрывает мои системы отправки. Я также активирую DKIM на используемом почтовом сервисе и опубликовать селектор DKIM в формате TXT под selector._domainkey. Я использую DMARC для определения того, как получатели обрабатывают письма, не прошедшие SPF/DKIM. Я часто начинаю с "p=none", оцениваю отчеты и позже переключаюсь на "карантин" или "отклонить". Такая последовательность снижает риски и постепенно повышает качество доставки.
Углубление SPF/DKIM/DMARC на практике
Я максимально сокращаю количество SPF: только необходимое включить-механизмы и никогда не более одного SPF на имя хоста. Чтобы соблюсти ограничение в 10 DNS-поисков, я сокращаю цепочки или использую механизмы IP4/IP6, если они стабильны. Для Ротация DKIM Я использую два активных селектора (старый/новый), публикую новый ключ, переключаю почтовый сервис и удаляю старый только через несколько дней. С помощью DMARC Изначально я устанавливаю адреса отчетов (rua/ruf) и проверяю выравнивание (aspf/adkim). Для поддоменов я могу использовать sp= определить отдельную политику, если они отправляются отдельно. Таким образом, я реагирую на реальные данные о трафике, а не на предположения.
Обратный DNS (PTR) для чистой доставки почты
В дополнение к MX, SPF и DKIM, я настроил Обратный DNS (PTR) для серверов исходящей почты. PTR IP указывает на имя хоста, которое, в свою очередь, корректно разрешается в тот же IP через A/AAAA (Согласование прямого и обратного хода). Я устанавливаю PTR для IP непосредственно у владельца IP (например, в интерфейсе сервера) - не в управлении зоной домена. Я использую формат nibble для IPv6. Подходящий PTR снижает классификацию спама и помогает с репутацией. Если почта отправляется через внешний сервис, я оставляю его PTR как есть и избегаю смешанных источников отправителей без настройки SPF.
Типичные ошибки и быстрые решения
Если домен не разрешается, я сначала проверяю TTLзаписи сервера имен и правильность написания записей. Второй взгляд направляется на РаспространениеНекоторые распознаватели кэшируют дольше, особенно после увеличения TTL. Я сравниваю разрешение с помощью различных программ проверки DNS, чтобы выявить региональные различия. В случае локальных проблем я временно переключаюсь на публичные резолверы, такие как 1.1.1.1 или 8.8.8.8. Если ошибка возникает только во внутренних сетях, я проверяю внутренние разрешители и правила в контейнерах, Kubernetes или конфигурациях CoreDNS.
Методы тестирования: dig, nslookup и end-to-end
Я проверяю не только записи, но и весь путь:
- копать A/AAAA/CNAME/MX/TXT: проверка ответов, TTL и авторитетности
- копать +следитьСм. цепочку делегирования и поведение сервера имен
- Тесты SMTPПроверьте HELO/EHLO, TLS и баннер
- Настоящий HTTPSЦепочка сертификатов, имя хоста, перенаправления
Таким образом я также распознаю ошибки, которые не видны в чистых ответах DNS, например неправильное сопоставление VirtualHost или истекающий срок действия сертификатов. После внесения изменений я жду как минимум один TTL, прежде чем делать окончательные выводы.
Эффективная работа с консолью Hetzner
Я объединяю связанные Записи время, устанавливаю короткий TTL перед внесением серьезных изменений и затем публикую все за один раз. Перед сохранением я еще раз проверяю MX-приоритеты, синтаксис SPF и целевой IP-адрес записи A. Для администрирования сервера и процессов можно воспользоваться компактными инструкциями по адресу Советы по использованию робота Hetzner. После развертывания я тестирую http, https и почту с помощью реальных запросов, а не только через ping. Это позволяет мне распознать ошибки, которые не показывают чистые DNS-запросы.
Автоматизация: API, шаблоны и ACME
Я экономлю время за счет автоматизации. Для регулярного развертывания я использую API консоли DNS для создания, изменения или удаления записей. Я работаю с шаблонами повторяющихся шаблонов (например, Web + Mail + DMARC) и вставляю только специфические для проекта значения. Для Let's Encrypt DNS-01 я включаю автоматическую запись TXT-записей и интегрирую ее в рабочий процесс обновления. Важно: я отношусь к API-токенам как к паролям, назначаю их определенным проектам и отзываю доступ, когда они больше не нужны.
Расширенные настройки: Split-Horizon, CDN и ACME
При необходимости я разделяю внутренних и внешних пользователей DNS-просмотров, чтобы внутреннее приложение указывало на частные IP-адреса, а посетители - на публичные. Использую ли я CDNЯ направляю поддомены на имя CDN через CNAME и активирую там TLS. Для автоматических сертификатов через ACME/Let's Encrypt я опционально устанавливаю DNS-01 вызовы через TXT, если HTTP-01 не подходит. Автоматизация здесь важна для своевременного обновления. Журналы и уведомления помогают своевременно распознавать сбои.
Модели производительности и доступности
Я повышаю доступность с помощью простых средств: Несколько Записи A/AAAA (round robin) распределяют нагрузку без дополнительных услуг, при условии, что бэкенды не имеют статусов или разделяют сессии. Во время обслуживания я временно удаляю отдельные IP-адреса, а затем снова поднимаю запись. Слишком короткий TTL может создавать нагрузку на резолверы; я нахожу баланс между скоростью отклика и частотой попадания в кэш. Я устанавливаю четкие процессы для отказов без проверки работоспособности: В случае сбоя я меняю записи местами, активно слежу за ними и снова сбрасываю их после восстановления.
Безопасность и гигиена зон
Я деактивирую ненужные Передача зон (AXFR) и публиковать только NSкоторые действительно авторитетны. Я регулярно удаляю старые или бесхозные поддомены, чтобы не создавать теневых поверхностей. Для ИДИ я проверяю Punycode-орфография, чтобы избежать опечаток и ошибок в специальных символах. Ролевой доступ в консоли гарантирует, что только нужные люди будут менять зоны. И совсем прагматично: я кратко документирую изменения в командном инструменте - это значительно сокращает количество запросов во время работы.
Стратегия миграции и отката
Перед переездом я снижаю TTL (за 24-48 часов), зеркально отображаю все Записи в новую зону и протестировать разрешение непосредственно через новые серверы имен. Только когда все будет правильно, я установлю параметр Сервер имен у регистратора. После делегирования я отслеживаю трафик и ошибки. Если что-то идет не так, я контролируемо откатываюсь назад или исправляю отдельные записи. Я планирую миграцию DNSSEC особенно консервативно и оставляю старую цепочку подписей на месте до тех пор, пока новая не будет надежно закреплена. Наконец, я сбрасываю TTL до значений, соответствующих требованиям производства.
Краткое сравнение поставщиков по производительности и гибкости
Производительность, функции и Свобода DNS решать, насколько гибко я буду реализовывать проекты. На практике крупные хостеры предоставляют надежные Время реагированияно отличаются по принципу работы, функциям и поддержке. Я оцениваю выбор по производительности, набору функций, качеству помощи и возможностям DNS. Следующий обзор показывает сжатую картину, которую я могу использовать для принятия решения. В конце концов, важно то, что действительно нужно моему проекту, а не самый большой список функций.
| Поставщик | Производительность | Объем функций | Поддержка | Гибкость DNS | Рейтинг |
|---|---|---|---|---|---|
| веб-сайт webhoster.de | Высокий | Очень обширный | Топ | Максимальный | 1 |
| Hetzner | Высокий | Обширный | Хорошо | Высокий | 2 |
| Contabo | Средний | Стандарт | O. K. | Средний | 3 |
Краткое резюме
Я установил Хетцнер DNS-зоны в структурированном виде: Создайте зону, введите сервер имен у регистратора, установите основные записи для веб и почты, затем протестируйте. С подходящим TTL Я сокращаю время переключения и снова увеличиваю его после завершения работы для снижения нагрузки. SPF, DKIM и DMARC усиливают доставку и защищают домен от неправомерного использования. Я поддерживаю согласованность поддоменов и разделяю внутренние и публичные направления. Благодаря этой примерной конфигурации и ежедневным проверкам ваша конфигурация hetzner dns остается надежной, быстрой и простой в обслуживании.
