Винсент Бернат перевёл инфраструктуру своего блога с Amazon CloudFront и Route 53 на Bunny.net. Основной причиной стала цена: в AWS оплачивались зоны, геолокационные DNS-запросы, проверки состояния и KMS-ключ для DNSSEC. Bunny DNS почти бесплатен для 500 доменов и позволяет вычислять ответ пользовательским JavaScript-кодом.
Блог обслуживают семь небольших NixOS-машин в Париже, Нюрнберге, Ашбурне, Сингапуре, Сан-Хосе, Сан-Паулу и Сиднее. Скрипт Bunny выбирает два ближайших доступных сервера и возвращает их IP-адреса. Второй адрес нужен браузеру как запасной вариант при отказе первого. Расположение пользователя обычно определяется через близкий DNS-resolver или EDNS Client Subnet.
У такого подхода есть недостаток: второй сервер может оказаться намного дальше первого. Например, пользователю из Буэнос-Айреса выдавались Сан-Паулу с задержкой 30 мс и Ашбурн со 140 мс. Поскольку resolver может менять порядок адресов, запрос иногда уходил на удалённый узел.
Бернат рассмотрел HTTPS DNS records из RFC 9460: приоритеты позволили бы указать ближайший сервер основным, а следующий запасным. Но Chrome игнорирует записи с target, отличным от точки, а Bunny не добавляет адреса целевых имён в additional section. Поэтому схема требует дополнительных запросов и пока не решает задачу удобно.
Итоговый компромисс возвращает два адреса, если серверы находятся на сопоставимом расстоянии. Если второй вдвое дальше первого и разница превышает тысячу миль, выдаётся только ближайший адрес с TTL две минуты вместо часа. Это сокращает окно недоступности после сбоя. Полный код также обходит поддержку только IPv4 в RoutingEngine.getClosestServer и обрабатывает нехватку доступных серверов.
Для ACME DNS-01 автор использует Hickory DNS на Rust с DNSSEC и dynamic updates, а родительскую зону размещает у deSEC, поскольку Bunny не публикует DS-записи. CDN Bunny пока не поддерживает HTTP/3. После переезда счёт снизился с $5 до $1 в месяц, а производительность на первых измерениях сопоставима с AWS; для окончательных выводов нужно больше данных.