Aprendendo um pouco sobre DNS com Minecraft
Após ler o post Usando Oracle Cloud para criar um ambiente de desenvolvimento (gratís) no meio do semestre, fiquei interessado em criar algumas stacks para hospedar algumas aplicações ou só brincar de DevOps, foi aí que decidir subir algo muito melhor do que um banco de dados, um cache ou qualquer coisa do tipo, um servidor de Minecraft 😎, admita, muito mais proveitoso.
Optei por utilizar o servidor via Docker mesmo, por ser muito mais fácil de configurar, o projeto docker-minecraft-server foi excelente para isso, com uma documentação boa e features legais, como instalar automaticamente o modpack do CurseForge, instalar os plugins apenas enviando para o diretório /plugins, enfim, fica realmente muito fácil de configurar.
Após a configuração do servidor, com detalhes aqui e alí, criei um registro no DNS para apontar para o endereço do servidor e pimba, entrei no mundo e já saí buscando madeira.
No outro dia, fui dar uma olhada no site mcsrvstat.us pra verificar alguns status do servidor e achei um negócio diferente, SRV Record não fazia ideia do que era e pra que servia, fui pesquisar e acabei aprendendo um pouco mais sobre DNS.
O que são SRV Records?
São registros de “serviço” que especificam endpoint para um serviço específico, permitindo a descoberta de serviços no DNS, especificando, host, porta e até controle de carga.
Os campos do registro são:
| Campo | Valor |
|---|---|
| Serviço | Minecraft |
| Protocolo | TCP |
| Nome | example.com |
| TTL | 86400 |
| Classe | IN |
| Tipo | SRV |
| Prioridade | 10 |
| Peso | 5 |
| Porta | 25565 |
| Alvo (host) | mserver.example.com |
_service._proto.name. TTL classe tipo de registro prioridade peso porta destino
A classe sempre será IN.
É possível ter mais de um registro por serviço, podendo aplicar para hosts diferentes e balanceando a carga, é possível também alterar o host e a porta sem a necessidade de mudar no cliente (precisando aguardar o TTL, obviamente).
Para que serve esse registro SRV?
Permite flexibilidade e até balanceamento de carga. No exemplo da tabela acima, conseguimos acessar o servidor apenas com o endereço example.com, o host, porta e protocolo são definidos após a consulta ao registro SRV no DNS. Para o balanceamento de carga utilizaremos os registros abaixo:
_minecraft._tcp.example.com 3600 SRV 1 100 25565 mserver1.example.com.
_minecraft._tcp.example.com 3600 SRV 1 50 25565 mserver2.example.com.
_minecraft._tcp.example.com 3600 SRV 2 100 25565 mserver3.example.com.
São três registros para 3 servidores, os dois primeiros servidores tem prioridade 1, os clientes acessam primeiro ao invés do terceiro que possui prioridade 2, servindo de fallback.
O peso do primeiro servidor é 100 enquanto do segundo é 50, logo o primeiro vai ter mais requisições que o segundo na proporção de 2/3 ao primeiro e 1/3 ao segundo.
Vendo um pouco na prática, é possível verificar o serviço LDAP (Lightweight Direction Access Protocol) do Google com o seguinte comando:
$ dig SRV _ldap._tcp.google.com
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> SRV _ldap._tcp.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23796
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_ldap._tcp.google.com. IN SRV
;; ANSWER SECTION:
_ldap._tcp.google.com. 86400 IN SRV 5 0 389 ldap.google.com.
;; ADDITIONAL SECTION:
ldap.google.com. 73997 IN A 216.239.32.58
ldap.google.com. 73997 IN AAAA 2001:4860:4802:32::3a
;; Query time: 80 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Sun Jul 28 19:44:13 -03 2024
;; MSG SIZE rcvd: 129
Foi uma pesquisa rápida e não muito aprofundada, caso alguem queira compartilhar alguma experiência ou informação importante, por favor não deixe de comentar 😉.