Investigation into building my own Edge DNS

8 min

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

Hello, this is Muno.

Of course, there have been recent ConoHa outages, and backend servers sometimes die unexpectedly (by the way, this was resolved by migrating the host machine), which is troublesome, so I'm trying to figure out how to build my own Edge DNS.

Registering two A records for a CNAME record

Here's how it's done:

$ 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

Due to RFC regulations, only one CNAME can be registered for a root domain, so it's practically impossible to register. Therefore, I registered a CNAME for www.soulmingrig.com with its content as edge.soulminingrig.com., and then registered two A records for edge.soulminingrig.com..

You might wonder why I don't just specify multiple A records for the root domain, but I registered it as a CNAME for future scalability.

I tried to see what would happen in this scenario, and I started to wonder if ConoHa's DNS uses PowerDNS. I verified the following:

  • Stopped the server at 91.98.169.80

  • Only 163.44.113.145 was running

If it were just simple round-robin, I would have expected a fair amount of traffic to flow to 91.98.169.80, but it cleanly flowed only to 163.44.113.145. This made me wonder if PowerDNS might be used, possibly with health checks.

(Note: The official documentation only states round-robin, so please don't rely on this assumption.)

GeoDNS, it's tough

It's for delivering content to clients from their respective optimal regions, but the more I think about it, the harder it seems to implement easily.

Even on FreeBSD, there are too few packages, and it seems that even the database via GeoIP.bat files is no longer distributed, but perhaps it's still distributed somewhere?

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

Realistically, it feels like distributing traffic on the Nginx side might become a practical solution in a personal environment. So, how can I easily distribute traffic on the Nginx side in that case...?

So, what about the speed difference per region...?

The server I added this time is one I had spare in Germany.

That's 91.98.169.80. And the response delay from Japan is quite severe.

Therefore, I'm making changes to kernel parameters to mitigate this as much as possible. Added the following, including TCP Fast Open.

TCP BBR was originally enabled during setup, but I feel like it improved even more, perhaps because I also properly included 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

If I measured it properly, there would be no doubt...

The path to GeoIP seems quite long now, so this is a temporary solution.

Certificate distribution to HTTP servers with multiple A records

This really gave me a headache.

The thing is, I'm renewing with certbot, and I thought that if I used DNS authentication with certbot, I could update on both servers with two A records, but it wasn't that simple.

In conclusion, I'm pretty much forcing it by rsyncing certificates from a dedicated user.

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/"

I really didn't want to do this, but it seems that --deploy-hook allows executing a subshell-like command after renewal.

The thing is, I thought that when certbot performs an ACME challenge for a certificate on a server with multiple A records, it would be distributed to one of them, so one would succeed and the other would fail, but for some reason, it only passed on the server that originally issued it? (This doesn't quite make sense spec-wise, so I feel like there's something more to it.) And in the case of default certbot, it's designed to temporarily place a file for file authentication, and once the ACME challenge passes, it immediately deletes the temporary file if it's no longer needed, so in a round-robin environment, it should actually be allocated to one of them.

And regarding DNS authentication, I stopped using it because the --nginx option, which automatically adds certificate files to the nginx side, couldn't be used. But since certificate paths don't actually change, realizing now that DNS authentication would have been better was a complete oversight on my part...

It's possible to notify DNS record changes via the ConoHa API, so it's actually a matter that could be resolved that way...

Related Posts