Динамический DNS через AWS Route 53 для домашнего сервера

Быстрые ссылки

• Динамический DNS прост

• Настройка AWS

• Написание скрипта

• Настроить crontab

Что такое динамический DNS и зачем он нужен

Динамический DNS (DDNS) — это способ поддерживать актуальную связь между доменным именем и устройством с меняющимся публичным IP. Для домашнего сервера это значит: даже если провайдер выдаёт вам новый IP каждые несколько часов, домен продолжит указывать на ваш сервер.

Как это работает, в одном предложении: агент на машине периодически получает текущий публичный IP и отправляет обновление в DNS‑провайдера, если адрес сменился.

Важно: если у вас инфраструктура в AWS, чаще разумнее использовать балансировщик и авто‑масштабирование. Но для домашнего сервера или отдельного устройства, не находящегося в AWS, собственный скрипт на Route 53 — почти всегда дешевле и быстрее, чем сторонние DDNS‑сервисы.

Преимущества и ограничения подхода

• Преимущества: низкая стоимость (плата за hosted zone небольшая), прямой контроль, отсутствие сторонних сервисов.
• Ограничения: требуется учетная запись AWS и безопасная настройка учётных данных; задержка обновления DNS зависит от TTL; Route 53 — не сервис, специально ориентированный на DDNS, но позволяет обновлять записи через API.

Important: уменьшите TTL для записи (например, 60 секунд) только если действительно нужно быстрое переключение. Низкий TTL повышает количество DNS‑запросов.

Настройка части AWS

1. Откройте консоль AWS Route 53.
2. Если у вас ещё нет домена, зарегистрируйте его в Registered Domains или перенесите в Route 53.
3. Найдите или создайте hosted zone для домена. Запишите Hosted Zone ID — он понадобиться в скрипте.

4. Создайте заглушечную A‑запись, чтобы скрипту было с чем работать. Для теста можно поставить очевидный некорректный IP, например:

255.255.255.255

5. Установите AWS CLI (пример для Linux, как в исходном материале):

curl "https://d1vvhvl2y92vvt.cloudfront.net/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

unzip awscliv2.zip

sudo ./aws/install

6. Настройте учётные данные IAM для CLI:

aws2 configure

Подсказка по безопасности: создайте отдельного IAM‑пользователя с минимальными правами вместо использования root‑ключей.

Политика IAM — какие права нужны

Для обновления записей Route 53 вашему IAM‑пользователю требуется минимум прав на действия с hosted zone. Пример минимальной политики (JSON):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListResourceRecordSets",
        "route53:ChangeResourceRecordSets",
        "route53:GetHostedZone"
      ],
      "Resource": "arn:aws:route53:::hostedzone/CHANGE_ME_HOSTED_ZONE_ID"
    }
  ]
}

Замените CHANGE_ME_HOSTED_ZONE_ID на реальный ID / либо используйте более общий ресурс, если необходимо. Принцип «least privilege» — даём только то, что нужно.

Написание скрипта — как это работает

Идея скрипта простая:

1. Получаем текущий публичный IP (через checkip.amazonaws.com или api.ipify.org).
2. Валидируем корректность IP простым регулярным выражением.
3. Запрашиваем текущую A‑запись в Route 53 и сравниваем с полученным IP.
4. Если IP изменился, формируем JSON‑пакет с UPSERT и отправляем change‑request в Route 53.

Ниже — исходные фрагменты и итоговый скрипт. Перед использованием замените HOSTED_ZONE_ID и NAME (NAME должен заканчиваться точкой).

Пример получения IP:

IP=$(curl https://api.ipify.org/)

Валидация IP (простая, защищает от мусорных ответов):

if [[ ! $IP =~ ^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$ ]]; then

exit 1

fi

Получение текущего значения записи из Route 53 (jq используется для парсинга JSON):

aws2 route53 list-resource-record-sets --hosted-zone-id Z1VCYR76DBUXPL | 

jq -r '.ResourceRecordSets[] | select (.Name == "'""$NAME"'"") | select (.Type == "'""$TYPE"'"") | .ResourceRecords[0].Value' > /tmp/current_route53_value

Проверка совпадения и выход, если IP не изменился:

if grep -Fxq "$IP" /tmp/current_route53_value; then

echo “IP Has Not Changed, Exiting”

exit 1

fi

Формирование JSON‑изменения и отправка запроса:

cat > /tmp/route53_changes.json << EOF

{

“Comment”:”Updated From DDNS Shell Script”,

“Changes”:[

{

“Action”:”UPSERT”,

“ResourceRecordSet”:{

“ResourceRecords”:[

{

“Value”:”$IP”

}

],

“Name”:”$NAME”,

“Type”:”$TYPE”,

“TTL”:$TTL

}

}

]

}

EOF

aws2 route53 change-resource-record-sets –hosted-zone-id $HOSTED_ZONE_ID –change-batch file:///tmp/route53_changes.json

Полный скрипт (как в исходнике). Замените переменные сверху:

#!/bin/bash

#Variable Declaration - Change These

HOSTED_ZONE_ID=”XXXXXXXXXXXX”

NAME=”example.com.”

TYPE=”A”

TTL=60

#get current IP address

IP=$(curl http://checkip.amazonaws.com/)

#validate IP address (makes sure Route 53 doesn’t get updated with a malformed payload)

if [[ ! $IP =~ ^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$ ]]; then

exit 1

fi

#get current

aws2 route53 list-resource-record-sets –hosted-zone-id $HOSTED_ZONE_ID |

jq -r ‘.ResourceRecordSets[] | select (.Name == “‘“”$NAME”‘“”) | select (.Type == “‘“”$TYPE”‘“”) | .ResourceRecords[0].Value’ > /tmp/current_route53_value

cat /tmp/current_route53_value

#check if IP is different from Route 53

if grep -Fxq “$IP” /tmp/current_route53_value; then

echo “IP Has Not Changed, Exiting”

exit 1

fi

echo “IP Changed, Updating Records”

#prepare route 53 payload

cat > /tmp/route53_changes.json << EOF

{

“Comment”:”Updated From DDNS Shell Script”,

“Changes”:[

{

“Action”:”UPSERT”,

“ResourceRecordSet”:{

“ResourceRecords”:[

{

“Value”:”$IP”

}

],

“Name”:”$NAME”,

“Type”:”$TYPE”,

“TTL”:$TTL

}

}

]

}

EOF

#update records

aws2 route53 change-resource-record-sets –hosted-zone-id $HOSTED_ZONE_ID –change-batch file:///tmp/route53_changes.json >> /dev/null

Notes: если вы используете aws cli v1, замените aws2 на aws. Убедитесь, что jq установлен и доступен в PATH.

## Настройка запуска: cron vs systemd

Простой способ — cron. Откройте crontab:

crontab -e

Добавьте задачу для запуска каждую минуту:

• • • • • /home/user/update_dns.sh >/dev/null 2>&1

          
          Альтернатива: systemd‑таймеры. Они дают более точный контроль над временем, рестартом и логированием. Для однократных, редких проверок systemd‑таймер предпочтительнее.
          
          Совет: запуск каждую минуту подходит для большинства домашних сценариев. Если ваш провайдер меняет IP лишь раз в сутки, можно реже.
          
          ## Тесты и критерии приёмки
          
          Критерии приёмки:
          
          - Скрипт корректно получает публичный IP и проходит валидацию.
          - Скрипт корректно читает текущую A‑запись из Route 53.
          - При отличии IP — отправляется change‑request и запись обновляется.
          - Скрипт устойчив к временным ошибкам сети (отдаёт ненулевой код выхода при ошибке и не затирает запись мусором).
          
          Мини‑тесты/acceptance:
          
          - Подмените HOSTED_ZONE_ID и NAME, поставьте в A запись 255.255.255.255 — запустите скрипт ручным запуском и убедитесь, что запись меняется на текущий IP.
          - Запустите скрипт при отсутствии сети — он должен завершиться с ошибкой, не меняя запись.
          - Проверьте, что при повторном запуске с тем же IP никаких изменений не происходит (выход без выполнения операции).
          
          ## Безопасность и эксплуатация
          
          Рекомендации:
          
          - Не храните AWS‑ключи в домашнем каталоге в открытом виде. Используйте aws‑profiles, ~/.aws/credentials с правами 600.
          - Для EC2 используйте IAM role (instance profile) вместо ключей.
          - Ограничьте права IAM‑пользователя до нужного hosted zone и только необходимых действий.
          - Логируйте успешные и неуспешные попытки обновления в файл с ротацией (logrotate).
          - Обновляйте awscli и jq регулярно.
          
          ## Отладка и частые ошибки
          
          1. Ошибка: "InvalidChangeBatch" — обычно из‑за некорректного формата JSON; проверьте route53_changes.json.
          2. Скрипт не видит jq — установите jq: apt install jq или соответствующий пакет для вашей ОС.
          3. Проблемы с IAM — проверьте права и resource ARN в политике.
          4. DNS не обновился — возможно, вы забыли точку в конце NAME (например, example.com.).
          5. Запись обновляется, но клиенты видят старый IP — проверьте TTL и кэш DNS на клиентских устройствах.
          
          ## Альтернативные подходы и когда они лучше
          
          - Lambda + CloudWatch Events: если вы хотите без серверных агентов и можете реагировать на события в AWS, то Lambda удобно. Но отслеживать внешний IP с Lambda сложнее: потребуется внешний периодический запуск (EventBridge) и переменные хранения состояния.
          - Использовать готовые DDNS‑сервисы (DynDNS, DuckDNS, NoIP): быстрее настроить, но это сторонний сервис и может быть платным.
          - Использовать клиентские утилиты типа ddclient: поддерживают множество поставщиков, но для Route 53 их настройка сложнее.
          
          ## Модель принятия решений (простая)
          
          Mermaid‑диаграмма для выбора подхода:
          

          flowchart TD A[Нужен DDNS?] –> B{Устройство в AWS?} B – Да –> C[Использовать ELB/ALB и авто‑масштабирование] B – Нет –> D{Хотите писать код?} D – Да –> E[Скрипт + cron -> Route53] D – Нет –> F[Использовать внешний DDNS сервис] E –> G[Добавить IAM с least privilege]

          
          (Если mermaid не отображается на сайте, приведённая логика всё равно пригодна для принятия решения.)
          
          ## Чеклист перед развёртыванием
          
          Для домашнего пользователя:
          
          - [ ] Зарегистрирован домен и есть hosted zone в Route 53.
          - [ ] Создана заглушечная A‑запись.
          - [ ] Установлен awscli (и jq).
          - [ ] Создан IAM‑пользователь с нужными правами.
          - [ ] Скрипт протестирован вручную.
          - [ ] Настроен cron или systemd‑таймер.
          
          Для системного администратора:
          
          - [ ] Политики IAM в IaC (CloudFormation/Terraform).
          - [ ] Логи с ротацией и мониторинг ошибок.
          - [ ] План отката и ротация ключей.
          
          ## Конфиденциальность и соответствие (GDPR и др.)
          
          IP‑адрес может считаться персональными данными в некоторых юрисдикциях. Если вы собираете и храните исторические IP‑лог‑файлы, учтите следующие принципы:
          
          - Минимизируйте хранение: не держите логи дольше, чем нужно.
          - Уведомите владельцев, если это корпоративная сеть.
          - Защитите доступ к логам и ключам.
          
          Если вы используете этот скрипт только для автоматического обновления Route 53 и не сохраняете историю IP, обычно дополнительная обработка не нужна.
          
          ## Сравнение вариантов (кратко)
          
          - Route 53 + скрипт: полный контроль, низкая стоимость, требует управления ключами.
          - Lambda + EventBridge: без агентов, но сложнее хранить состояние IP.
          - Внешний DDNS: простота, но зависимость от стороннего сервиса.
          
          ## Примеры отказов и что делать
          
          - Скрипт упал из‑за багов: проверьте /var/log/syslog или системный журнал cron/systemd.
          - AWS API временно недоступен: скрипт должен завершиться с кодом ошибки; cron запустит снова по расписанию.
          - Неправильная запись в hosted zone: восстановите из резервной копии или вручную через консоль.
          
          ## Краткое резюме
          
          - Сценарий: домашний сервер с динамическим IP.
          - Решение: скрипт на bash + aws cli + Route 53 + cron/systemd.
          - Безопасность: минимум прав IAM, защищённые ключи, ротация логов.
          
          Summary:
          
          - Настройка Route 53 и IAM — первый шаг.
          - Скрипт получает IP, валидирует, сравнивает и отправляет UPSERT.
          - Cron или systemd запускают скрипт регулярно.
          
          Если нужно, я могу подготовить готовый systemd‑unit и таймер, шаблон Terraform для IAM‑политики, или вариант скрипта на Python с более подробной обработкой ошибок.