Pesquisa sobre a implementação de um Edge DNS próprio

8 min

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

Olá, sou o Incompetente.

É claro que houve interrupções recentes no ConoHa, mas os servidores de backend morrem inesperadamente (resolvido com a migração da máquina host, a propósito), o que é problemático, então estou tentando descobrir como criar meu próprio Edge DNS.

Registrando dois registros A para um registro CNAME

Faço assim:

$ 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

De acordo com as regulamentações da RFC, apenas um CNAME pode ser registrado para um domínio raiz, tornando-o praticamente impossível de registrar. Portanto, registramos um CNAME para www.soulmingrig.com com o conteúdo edge.soulminingrig.com. e registramos dois registros A para edge.soulminingrig.com..

Você pode perguntar por que não especificar vários registros A para a raiz, mas estou registrando-o como um CNAME para futura escalabilidade.

Tentei ver o que aconteceria neste caso, e me perguntei se o DNS do ConoHa usa PowerDNS? Verifiquei o seguinte:

  • Parar o servidor 91.98.169.80

  • Manter apenas 163.44.113.145 em funcionamento

Se fosse apenas um round-robin simples, eu esperava que o tráfego fluísse para 91.98.169.80 em alguma medida, mas ele flui apenas para 163.44.113.145. A sensação de que há uma verificação de saúde me fez pensar se eles poderiam estar usando PowerDNS.

※A documentação oficial menciona apenas round-robin, então não confie nesta minha especulação.

GeoDNS, é difícil

É para entregar conteúdo aos clientes a partir da região ideal para cada um, mas quanto mais penso nisso, mais difícil parece ser uma implementação fácil.

Mesmo no FreeBSD, há poucos pacotes, e parece que até mesmo o banco de dados para arquivos GeoIP.bat não é mais distribuído, mas talvez ainda esteja sendo distribuído em algum lugar?

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

Realisticamente, parece que distribuir pelo lado do Nginx se torna bastante viável em um ambiente pessoal. Então, como posso distribuir facilmente pelo lado do Nginx...?

Então, a diferença de velocidade por região...

O que adicionei desta vez foi um servidor que tinha sobrando na Alemanha.

É o 91.98.169.80. E o atraso na resposta do Japão é bastante severo.

Portanto, farei o possível para mitigar isso alterando as configurações nos parâmetros do kernel. Adicionei o seguinte, incluindo TCP Fast Open.

O TCP BBR já estava ativado durante a configuração, mas mesmo assim, sinto que melhorou porque também incluí corretamente o 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

Se eu medisse corretamente, não haveria erro, mas...

O caminho para o GeoIP parece bastante longo, então esta é uma medida provisória.

Distribuição de certificados para servidores HTTP com múltiplos registros A

Isso, sabe, me deu bastante dor de cabeça.

A razão é que estou atualizando com o certbot, e pensei: 'Se eu usar a autenticação DNS com o certbot, poderei atualizar em ambos os servidores com registros A, certo?', mas não foi tão fácil.

Em conclusão, estou forçando a sincronização dos certificados via rsync a partir de um usuário 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/"

Eu não queria fazer isso, mas parece que posso executar algo como um subshell após a renovação com --deploy-hook.

A questão é que, no caso de certificados quando o certbot realiza um desafio ACME em um servidor com múltiplos registros A, eu pensei que seria distribuído para um ou outro, então um teria sucesso e o outro falharia, mas por alguma razão, só funcionou no servidor que o emitiu originalmente? (Isso não faz muito sentido em termos de especificação, então sinto que há algo mais acontecendo). E no caso do certbot padrão, ele é projetado para colocar um arquivo por um momento para autenticação de arquivo e, se o desafio ACME for aprovado, ele exclui imediatamente o arquivo temporário quando não é mais necessário, então, em um ambiente round-robin, ele deveria ser alocado para um ou outro.

E quanto à autenticação DNS, parei de usá-la porque a opção --nginx, que adiciona automaticamente e dinamicamente os arquivos de certificado ao lado do nginx, não pode ser usada. Mas, na verdade, os caminhos dos certificados não mudam, então perceber agora que a autenticação DNS teria sido melhor significa que eu estava completamente sonolento...

Como é possível notificar as alterações de registro DNS via API do ConoHa, na verdade, é algo que poderia ser resolvido dessa forma, mas...

Related Posts