AWS Route 53からBunny DNSへ移行した主な動機は、運用コストの大幅な削減でした。AWSのモデルでは、著者にとって、ゾーンごとの月額料金、100万件あたりの位置情報クエリ費用、ヘルスチェックの月額費用に加え、DNSSEC署名のためのKMSキー費用が組み合わさっていました。対照的に、Bunny DNSは最大500ドメインまでほぼ無料のティアを提供しており、ユーザーの所在地に基づいてDNSレコードの返却方法をより細かく制御できるscriptable DNS機能が含まれています。
この移行の技術的な中心となるのは、Bunnyの「scriptable DNS」機能です。この機能により、開発者はすべてのクエリに対してユーザーが提供したJavaScriptを実行し、DNSレスポンスを計算することができます。`RoutingEngine`ヘルパーを使用することで、スクリプトはユーザーの地理的位置から最も近い2つのサーバーを特定します。高価なヘルスチェックのオーバーヘッドなしに高可用性を確保するため、著者は次のようなロジックを実装しました。もし2番目に近いサーバーが1番目より2倍離れており、かつ1番目から1000マイル以上離れている場合、スクリプトは2分という短いTime-to-Live（TTL）で最も近いサーバーのみを返します。これにより、プライマリサーバーが故障した場合でもDNSレコードがすぐに期限切れとなり、ブラウザが別のホストへの接続を試行できるようになります。サーバー間の距離が近い場合は、両方のサーバーを1時間の長いTTLで返します。
コスト面でのメリットや柔軟性がある一方で、この移行には特定の技術的なトレードオフと制限も伴います。BunnyのCDNは現在HTTP/3をサポートしておらず、DNSサービスはDS（Delegation Signer）レコードを直接公開することができません。これらの制約を管理するため、著者はマルチプロバイダー戦略を採用しています。Bunnyが主要な地理認識型ルーティングを処理する一方で、DNS-01 ACMEチャレンジを容易にするために、二次プロバイダー（deSEC）を`luffy.cx`ゾーンのホスティングに使用しています。インフラは、CDK Terrain（TypeScript）とOpenTofuを使用してターゲットの状態を定義およびデプロイするモダンなツールチェーンを通じて管理されており、高度なルーティングロジックの必要性と、より経済的な価格構造のバランスをとっています。