Investigación sobre el intento de crear un EdgeDNS propio
Hola, soy un inútil.
Por supuesto, ha habido interrupciones recientes en ConoHa, y los servidores de backend a veces mueren inesperadamente (lo cual, por cierto, se resolvió migrando la máquina host), lo cual es problemático, así que estoy intentando averiguar cómo construir mi propio Edge DNS.
Registro de dos registros A para un registro CNAME
Así es como se hace
$ 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: 101Según las regulaciones de la RFC, solo se puede registrar un CNAME para un dominio raíz, por lo que en la práctica no se puede registrar. Por lo tanto, registré un CNAME para www.soulmingrig.com con el contenido edge.soulminingrig.com., y luego registré dos registros A para edge.soulminingrig.com..
De hecho, quizás se pregunten por qué no especificar varios registros A para el dominio raíz, pero lo registré como CNAME por la escalabilidad futura.
Intenté ver qué pasaría en este escenario, y me pregunté si el DNS de ConoHa podría estar usando PowerDNS. Verifiqué lo siguiente:
Detuve el servidor en 91.98.169.80
Solo 163.44.113.145 estaba funcionando
Si esto fuera solo un round-robin simple, habría esperado que una cantidad considerable de tráfico fluyera a 91.98.169.80, pero solo fluyó limpiamente a 163.44.113.145. Esto me hizo pensar si PowerDNS podría estar siendo utilizado, quizás con comprobaciones de salud.
※Tenga en cuenta que la documentación oficial solo menciona round-robin, así que no se fíe de esta suposición.
GeoDNS, difícil
Es para entregar contenido a los clientes desde la región óptima para cada uno, pero cuanto más lo pienso, más difícil parece implementarlo de forma sencilla.
Incluso en FreeBSD, hay muy pocos paquetes, y parece que la base de datos para el archivo GeoIP.bat ya no se distribuye, pero ¿quizás todavía se distribuye en algún lugar?
https://gist.github.com/denji/9487759
Siendo realistas, parece que distribuir el tráfico desde el lado de Nginx podría volverse bastante factible en un entorno personal. Entonces, si ese es el caso, ¿cómo puedo distribuir el tráfico fácilmente desde el lado de Nginx...?
Entonces, ¿qué pasa con las diferencias de velocidad por región...?
El servidor que agregué esta vez es uno que tenía de sobra en Alemania.
Esa es la dirección 91.98.169.80. Y el retraso en la respuesta desde Japón es bastante severo.
Por lo tanto, estoy realizando cambios en los parámetros del kernel para mitigar esto tanto como sea posible. Agregué lo siguiente, incluyendo TCP Fast Open.
TCP BBR ya estaba habilitado durante la configuración, pero siento que mejoró aún más, quizás porque también incluí correctamente 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=3Si lo midiera correctamente, no habría duda...
El camino hacia GeoIP parece bastante lejano ahora, así que esta es una solución temporal.
Distribución de certificados a servidores HTTP con múltiples registros A
Esto, la verdad, me dio muchos quebraderos de cabeza.
La cuestión es que estoy actualizando con certbot, y pensé que si usaba la autenticación DNS con certbot, podría actualizar en ambos servidores con dos registros A, pero no fue tan sencillo.
En conclusión, lo estoy forzando bastante al hacer rsync de los certificados desde un usuario dedicado.
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/"No quería hacer esto, pero parece que se puede ejecutar un script similar a un subshell después de la renovación usando --deploy-hook.
La cuestión es que, cuando certbot realiza un desafío ACME para un certificado en un servidor con múltiples registros A, pensé que se distribuiría a uno de ellos, por lo que uno tendría éxito y el otro fallaría, pero por alguna razón, solo pasó en el servidor que lo emitió originalmente (esto no tiene mucho sentido en cuanto a las especificaciones, así que siento que hay algo más). Y en el caso de certbot predeterminado, está diseñado para colocar un archivo momentáneamente para la autenticación de archivos, y una vez que el desafío ACME pasa, elimina inmediatamente el archivo temporal si ya no es necesario, por lo que en un entorno round-robin, debería asignarse a uno de ellos.
Y en cuanto a la autenticación DNS, dejé de usarla porque no podía usar la opción --nginx, que añade dinámicamente los archivos de certificado en el lado de nginx. Pero como las rutas de los certificados no cambian en realidad, darme cuenta ahora de que la autenticación DNS habría sido mejor significa que estaba completamente despistado...
Dado que las notificaciones de cambio de registros DNS se pueden realizar a través de la API de ConoHa, en realidad es un asunto que podría resolverse de esa manera...