Route 53 Files: como os tipos de registros DNS aparecem como arquivos

Você pode publicar um registro DNS no Route 53 executando echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A. Route 53 Files, lançado em 27 de agosto de 2026 por Colin Percival, monta uma zona hospedada do Route 53 sobre NFS: cada nome de registro é um diretório, cada conjunto de registros é um arquivo, e escrever naquele arquivo muda o DNS ao vivo em cerca de 90 segundos. O post de lançamento é escrito inteiramente na voz de um blog de lançamento da AWS — a piada é a prosa, não o artefato. O console, os papéis IAM e os comandos de montagem são reais e funcionam.

O que é Route 53 Files?

É um serviço que converte uma zona hospedada em um sistema de arquivos montável. A proposta de Percival: “With Route 53 Files, it becomes possible to use standard UNIX software to edit your DNS without needing any additional steps.”

Aí está toda a carga útil. grep, sed, find, diff, git — cada ferramenta que você já tem no terminal se torna uma ferramenta de DNS, sem SDK e sem um CLI intermediário.

Como os tipos de registros DNS se parecem com arquivos?

O mapeamento é a ideia central. Um nome de registro é um diretório; um conjunto de registros é um arquivo com o nome de seu tipo:

  • /mnt/r53fs/example.com/www/A — o registro A de www
  • /mnt/r53fs/example.com/www/CNAME — o CNAME do mesmo nome
  • /mnt/r53fs/example.com/vixie/TXT — um registro TXT

As regras que fazem o mapeamento funcionar:

  • Valores múltiplos em um conjunto de registros são múltiplas linhas dentro do arquivo.
  • O apex da zona usa o nome especial @, então o registro A raiz vive em @/A.
  • O TTL vive em um arquivo irmão: @/A.TTL. O valor padrão é 300 segundos.
  • Os registros alias aparecem como links simbólicos, então readlink faz exatamente o que você espera.
  • Os arquivos que não correspondem a um nome de registro DNS são ignorados, o que tem uma consequência que Percival aponta: “So you could absolutely have a git checkout and update your DNS with git pull.” Sua zona sob controle de versão, aplicada com um pull. Não é uma função de piada: sai de graça do design.

Por que é possível montar uma zona DNS sobre NFS?

Porque a AWS já construiu a parte difícil. S3 Files é um serviço real da AWS, disponível de forma geral desde abril de 2026, que expõe buckets do S3 como sistemas de arquivos NFS montados com o cliente amazon-efs-utils (sudo mount -t s3files $FS:/ /mnt/s3files, NFS 4.2 sobre TLS 1.2, de acordo com a documentação da AWS).

Route 53 Files é montado em cima disso: sua zona é projetada em um bucket em sua própria conta, e esse bucket é o que você monta. Percival explica isso no FAQ e esclarece tanto o timing quanto o design:

Por que não lançou em 1º de abril? “Because S3 Files launched in early April and I didn’t want to wait until April 2027.”

Por que expor zonas DNS por NFS em vez de um sistema de arquivos FUSE? “Because it’s funnier. Also, because that’s what S3 Files does (but I repeat myself).”

Isso também explica os números de propagação. Uma escrita chega ao DNS ao vivo em cerca de 90 segundos; uma mudança feita a partir do console ou da API da AWS leva até 6 minutos para aparecer em seu mount. Edições concorrentes são resolvidas com a última escrita vence.

Como instalar?

Cinco passos, a partir do console em https://www.daemonology.net/r53fs/:

1. Gere o bundle de papéis IAM. Executa inteiramente no navegador, sem acesso à rede. Você fornece seu ID de conta AWS (12 dígitos) e seus IDs de zona hospedada (separados por vírgulas, ou * para todas).

2. Instale os papéis. Descompacte o bundle, leia README.txt e execute create-roles.sh com suas credenciais da AWS. Cria quatro papéis, mais um quinto opcional para desprovisionamento atrás da flag --deprovisioning.

3. Registre a zona. Este é o único passo que envia algo para Route 53 Files: ID da conta, um ID de zona hospedada, a região onde o filesystem será criado, e o ID Externo do seu bundle. Esse ID Externo não pode ser recuperado se você o perder.

4. Crie um alvo de montagem, um para cada zona de disponibilidade de sua VPC:

$ aws s3files create-mount-target \
    --file-system-id fs-0123456789abcdef0 \
    --subnet-id <a subnet in that VPC> \
    --security-groups <a group allowing TCP 2049 from your clients> \
    --region <your region>

Leva cerca de cinco minutos para ficar disponível.

5. Monte o filesystem. Você precisa de amazon-efs-utils versão 3.0.0 ou superior, e o papel de sua instância precisa da política AmazonS3FilesClientFullAccess:

$ sudo mkdir -p /mnt/r53fs/example.com
$ sudo mount -t s3files -o nodirects3read \
    fs-0123456789abcdef0 /mnt/r53fs/example.com

TLS e autenticação IAM são obrigatórios e não podem ser desativados. Se a montagem falhar com “Failed to resolve”, aguarde dez minutos antes de tentar novamente.

Como editar um registro?

Um registro A no apex:

$ echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A

Um segundo valor no mesmo conjunto de registros — use append, não sobrescreva:

$ echo 5.6.7.8 | sudo tee -a /mnt/r53fs/example.com/@/A

Um novo nome, apontando para o apex como alias:

$ sudo mkdir /mnt/r53fs/example.com/www
$ sudo ln -s ../@/A /mnt/r53fs/example.com/www/A

Um TTL de 60 segundos, no arquivo irmão:

$ echo 60 | sudo tee /mnt/r53fs/example.com/@/A.TTL

Como criar um wildcard DNS?

O asterisco é um nome de diretório real, então você precisa escapá-lo do seu shell:

$ sudo mkdir /mnt/r53fs/example.com/\*
$ echo www.example.com | sudo tee /mnt/r53fs/example.com/\*/CNAME

E a demonstração que defende a ideia melhor que qualquer argumento: um cron que reescreve um registro TXT a cada cinco minutos.

$ echo "*/5 * * * * root date > /mnt/r53fs/daemonology.net/vixie/TXT" | sudo tee -a /etc/crontab
$ sleep 600
$ dig +short -t txt vixie.daemonology.net

O que não é suportado?

Políticas de roteamento. Tipos de registro DNSSEC. Registros alias com EvaluateTargetHealth. E o plano de controle do Route 53 fica em us-east-1, então uma falha regional lá congela suas atualizações não importa onde seu filesystem esteja montado.

Vale a pena apontar para produção?

Não, e o autor é o primeiro a dizer isso. Do FAQ:

É um serviço oficial da AWS? “Of course not; but I’d be happy to let them have it if they’re crazy enough to want to maintain it.”

Alguém na Amazon sabia que você estava fazendo isso? “Absolutely not. If they knew, they would have had to try to stop me.”

O que acontece se você executar rm -rf *? “Route 53 Files attempts to delete all of your DNS records, of course; what else would it do?”

Esse último não é uma piada. A semântica do filesystem é honesta nas duas direções, o que significa que um glob descuidado apaga sua zona.

Três advertências práticas, em 28 de agosto de 2026: o serviço é gratuito e está disponível em todas as regiões comerciais da AWS, exceto Bahrein e Emirados Árabes Unidos — tanto a disponibilidade quanto a gratuidade dependem de uma pessoa continuá-lo mantendo. É um terceiro segurando um papel IAM em sua conta contra seu DNS, uma decisão de confiança que convém tomar deliberadamente; o caminho de desprovisionamento existe justamente para poder revertê-la. E a rota de escrita é uma projeção, não uma transação: 90 segundos de ida, 6 minutos de volta, a última escrita vence.

Onde realmente se ganha espaço é no que foi construído para demonstrar. Se você sempre quis fazer diff entre duas zonas, grep em seu DNS procurando um IP antigo, ou manter seus registros em git sem adotar Terraform para isso, este é o caminho mais curto que existe para lá — construído sobre um serviço real da AWS, por alguém que passou vinte anos lendo posts de lançamento da AWS e finalmente escreveu um.