Исследование попытки создания собственного EdgeDNS

8 min

conohadnsnginxhttp雑記vps
language: ja bn en es hi pt ru zh-cn zh-tw

Привет, я бездарь.

Конечно, в последнее время у ConoHa были сбои, но серверы бэкенда иногда умирают (что, кстати, было решено миграцией хост-машины), и это вызывает беспокойство, поэтому я пытаюсь выяснить, как создать свой собственный Edge DNS.

Регистрация двух A-записей для записи, зарегистрированной в CNAME

Вот как это делается:

$ dig www.soulminingrig.com

; <<>> DiG 9.20.16 <<>> www.soulminingrig.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33051
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.soulminingrig.com.         IN      A

;; ANSWER SECTION:
www.soulminingrig.com.  300     IN      CNAME   edge.soulminingrig.com.
edge.soulminingrig.com. 300     IN      A       91.98.169.80
edge.soulminingrig.com. 300     IN      A       163.44.113.145

;; Query time: 94 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Mon Apr 06 20:40:33 JST 2026
;; MSG SIZE  rcvd: 101

Согласно правилам RFC, для корневого домена можно зарегистрировать только одну запись CNAME, поэтому фактически это невозможно. Поэтому мы регистрируем CNAME для www.soulminingrig.com с содержимым edge.soulminingrig.com. и регистрируем две A-записи для edge.soulminingrig.com..

Возможно, вы спросите, почему бы просто не указать несколько A-записей для корня, но я зарегистрировал их как CNAME для будущей расширяемости.

Я попробовал посмотреть, что произойдет, и подумал, что DNS ConoHa использует PowerDNS, но я проверил следующее:

  • Остановка сервера 91.98.169.80

  • Работает только 163.44.113.145

Если бы это был просто Round Robin, я бы ожидал, что трафик будет равномерно распределяться на 91.98.169.80, но он чисто идет только на 163.44.113.145. Это наводит на мысль, что там может быть проверка работоспособности, и, возможно, используется PowerDNS.

※Пожалуйста, не полагайтесь на это, так как официально это просто Round Robin.

GeoDNS, это сложно

Это для доставки контента клиентам из наиболее подходящего региона, но чем больше я думаю об этом, тем сложнее кажется простая реализация.

Даже на FreeBSD слишком мало пакетов, и файл базы данных GeoIP.bat, похоже, больше не распространяется, но, возможно, где-то он все еще доступен?

https://gist.github.com/denji/9487759

На практике, похоже, что распределение на стороне Nginx становится довольно реалистичным для личной среды. Итак, как легко распределить на стороне Nginx...?

Тогда разница в скорости между регионами...

Сервер, который я добавил на этот раз, находится в Германии и был запасным.

Это 91.98.169.80. Задержка ответа из Японии довольно плохая.

Поэтому я попытаюсь сделать все возможное, изменив настройки параметров ядра. Добавил следующее, включая TCP Fast Open.

TCP BBR был включен при первоначальной настройке, но я чувствую, что стало лучше, возможно, потому, что я также правильно настроил KeepAlive.

net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_intvl=10
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_no_metrics_save=1
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_fastopen=3

Если бы я измерил это правильно, не было бы никаких сомнений...

Путь к GeoIP кажется довольно долгим, так что это временное решение.

Распределение сертификатов для HTTP-серверов с несколькими A-записями

Это действительно заставило меня поломать голову.

Я обновлял с помощью certbot и думал, что если я использую DNS-аутентификацию с certbot, то смогу обновить сертификаты на обоих серверах с двумя A-записями, но это оказалось не так просто.

В итоге я довольно грубо синхронизирую сертификаты с помощью rsync от специального пользователя.

0 0 1,15 * * /usr/local/bin/certbot renew --nginx --deploy-hook "/usr/local/bin/rsync -azL --no-perms --no-owner --no-group --omit-dir-times --no-times /usr/local/etc/letsencrypt/live/ certsync@10.1.0.999:/usr/local/etc/letsencrypt/live/"

Я не хотел этого делать, но, похоже, можно выполнить под-оболочку после обновления с помощью --deploy-hook.

Изначально я думал, что при ACME-запросе для сертификатов на серверах с несколькими A-записями certbot будет распределять запросы между ними, и один из них будет успешным, а другой — нет. Но почему-то он проходил только на сервере, который изначально выдал сертификат? (Это немного нелогично с точки зрения спецификации, так что, возможно, есть что-то еще). В случае с certbot по умолчанию, он использует файловую аутентификацию, временно размещает файл, и как только ACME-запрос проходит, он немедленно удаляет временный файл. Так что в среде Round Robin он должен был бы распределяться между ними.

И что касается аутентификации DNS, я отказался от нее, потому что нельзя использовать опцию --nginx, которая автоматически добавляет файлы сертификатов на стороне nginx. Но на самом деле путь к сертификату не меняется, поэтому теперь я думаю, что аутентификация DNS была бы лучше, и это было полное недоразумение с моей стороны...

На самом деле, можно отправлять уведомления об изменении DNS-записей через ConoHa API, так что это решило бы проблему...

Related Posts