Puedes publicar un registro DNS en Route 53 ejecutando echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A. Route 53 Files, publicado el 27 de agosto de 2026 por Colin Percival, monta una zona alojada de Route 53 sobre NFS: cada nombre de registro es un directorio, cada record set es un archivo, y escribir en ese archivo cambia el DNS en vivo en unos 90 segundos. El post de lanzamiento está escrito íntegramente con la voz de un blog de lanzamiento de AWS — el chiste es la prosa, no el artefacto. La consola, los roles IAM y los comandos de montaje son reales y funcionan.
¿Qué es Route 53 Files?
Es un servicio que convierte una zona alojada en un sistema de archivos montable. El planteo de Percival: “With Route 53 Files, it becomes possible to use standard UNIX software to edit your DNS without needing any additional steps.”
Ahí está toda la carga útil. grep, sed, find, diff, git — cada herramienta que ya tienes en la terminal se vuelve una herramienta de DNS, sin SDK y sin un CLI intermediario.
¿Cómo se ven los tipos de registros DNS como archivos?
El mapeo es la idea central. Un nombre de registro es un directorio; un record set es un archivo con el nombre de su tipo:
/mnt/r53fs/example.com/www/A— el registro A dewww/mnt/r53fs/example.com/www/CNAME— el CNAME del mismo nombre/mnt/r53fs/example.com/vixie/TXT— un registro TXT
Las reglas que hacen que el mapeo cierre:
- Valores múltiples en un record set son líneas múltiples dentro del archivo.
- El apex de la zona usa el nombre especial
@, así que el registro A raíz vive en@/A. - El TTL vive en un archivo hermano:
@/A.TTL. El valor por defecto es 300 segundos. - Los registros alias aparecen como enlaces simbólicos, así que
readlinkhace exactamente lo que esperas. - Los archivos que no corresponden a un nombre de registro DNS son ignorados, lo cual tiene una consecuencia que Percival señala: “So you could absolutely have a git checkout and update your DNS with
git pull.” Tu zona en control de versiones, aplicada con un pull. No es una función de chiste: sale gratis del diseño.
¿Por qué se puede montar una zona DNS sobre NFS?
Porque AWS ya construyó la parte difícil. S3 Files es un servicio real de AWS, disponible de forma general desde abril de 2026, que expone buckets de S3 como sistemas de archivos NFS montados con el cliente amazon-efs-utils (sudo mount -t s3files $FS:/ /mnt/s3files, NFS 4.2 sobre TLS 1.2, según la documentación de AWS).
Route 53 Files va montado encima: tu zona se proyecta a un bucket en tu propia cuenta, y ese bucket es lo que montas. Percival lo dice en el FAQ, y explica tanto el timing como el diseño:
¿Por qué no lanzó el 1 de abril? “Because S3 Files launched in early April and I didn’t want to wait until April 2027.”
¿Por qué exponer zonas DNS por NFS en lugar de un sistema de archivos FUSE? “Because it’s funnier. Also, because that’s what S3 Files does (but I repeat myself).”
Eso también explica los números de propagación. Una escritura llega al DNS en vivo en unos 90 segundos; un cambio hecho desde la consola o la API de AWS tarda hasta 6 minutos en aparecer en tu mount. Las ediciones concurrentes se resuelven con last-write-wins.
¿Cómo se instala?
Cinco pasos, desde la consola en https://www.daemonology.net/r53fs/:
1. Genera el bundle de roles IAM. Corre enteramente en el navegador, sin acceso a red. Le das tu ID de cuenta AWS (12 dígitos) y tus IDs de zona alojada (separados por comas, o * para todas).
2. Instala los roles. Descomprime el bundle, lee README.txt y ejecuta create-roles.sh con tus credenciales de AWS. Crea cuatro roles, más un quinto opcional para el desaprovisionamiento detrás del flag --deprovisioning.
3. Registra la zona. Este es el único paso que envía algo a Route 53 Files: ID de cuenta, un ID de zona alojada, la región donde se creará el filesystem, y el External ID de tu bundle. Ese External ID no se puede recuperar si lo pierdes.
4. Crea un mount target, uno por cada zona de disponibilidad de tu 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>
Tarda unos cinco minutos en quedar disponible.
5. Monta el filesystem. Necesitas amazon-efs-utils 3.0.0 o superior, y el rol de tu instancia necesita la política AmazonS3FilesClientFullAccess:
$ sudo mkdir -p /mnt/r53fs/example.com
$ sudo mount -t s3files -o nodirects3read \
fs-0123456789abcdef0 /mnt/r53fs/example.com
TLS y autenticación IAM son obligatorios y no se pueden desactivar. Si el montaje falla con “Failed to resolve”, espera diez minutos antes de reintentar.
¿Cómo se edita un registro?
Un registro A en el apex:
$ echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A
Un segundo valor en el mismo record set — usa append, no sobreescribas:
$ echo 5.6.7.8 | sudo tee -a /mnt/r53fs/example.com/@/A
Un nombre nuevo, apuntando al apex como alias:
$ sudo mkdir /mnt/r53fs/example.com/www
$ sudo ln -s ../@/A /mnt/r53fs/example.com/www/A
Un TTL de 60 segundos, en el archivo hermano:
$ echo 60 | sudo tee /mnt/r53fs/example.com/@/A.TTL
¿Cómo se crea un wildcard DNS?
El asterisco es un nombre de directorio real, así que tienes que escaparlo de tu shell:
$ sudo mkdir /mnt/r53fs/example.com/\*
$ echo www.example.com | sudo tee /mnt/r53fs/example.com/\*/CNAME
Y la demostración que defiende la idea mejor que cualquier argumento: un cron que reescribe un registro TXT 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
¿Qué no soporta?
Routing policies. Tipos de registro DNSSEC. Registros alias con EvaluateTargetHealth. Y el control plane de Route 53 vive en us-east-1, así que una caída regional ahí congela tus actualizaciones sin importar dónde esté montado tu filesystem.
¿Conviene apuntarle producción?
No, y el autor es el primero en decirlo. Del FAQ:
¿Es un servicio oficial de AWS? “Of course not; but I’d be happy to let them have it if they’re crazy enough to want to maintain it.”
¿Alguien en Amazon sabía que estabas haciendo esto? “Absolutely not. If they knew, they would have had to try to stop me.”
¿Qué pasa si ejecutas
rm -rf *? “Route 53 Files attempts to delete all of your DNS records, of course; what else would it do?”
Esa última no es un chiste. La semántica del filesystem es honesta en las dos direcciones, lo que significa que un glob descuidado borra tu zona.
Tres advertencias prácticas, al 28 de agosto de 2026: el servicio es gratuito y está disponible en todas las regiones comerciales de AWS excepto Baréin y Emiratos Árabes Unidos — tanto la disponibilidad como la gratuidad dependen de que una persona lo siga manteniendo. Es un tercero sosteniendo un rol IAM en tu cuenta contra tu DNS, una decisión de confianza que conviene tomar deliberadamente; el camino de desaprovisionamiento existe justamente para poder revertirla. Y la ruta de escritura es una proyección, no una transacción: 90 segundos de ida, 6 minutos de vuelta, gana la última escritura.
Donde sí se gana el lugar es en lo que fue construido para demostrar. Si alguna vez quisiste hacer diff entre dos zonas, grep sobre tu DNS buscando una IP vieja, o llevar tus registros en git sin adoptar Terraform para eso, este es el camino más corto que existe hacia ahí — construido sobre un servicio real de AWS, por alguien que lleva veinte años leyendo posts de lanzamiento de AWS y por fin escribió uno.