Registros DNS comodín: la conveniencia que silenciosamente rompe cosas (y soluciones)

Qué hace realmente el DNS comodín (y qué no hace)

Un registro comodín es un registro DNS cuyo nombre de propietario comienza con *., como *.example.com. No es “coincidir con cualquier cosa
en cualquier parte”. Es “coincidir con una etiqueta en este punto del árbol, cuando no existe un registro más específico”.

Definición operativa

Si un resolvedor pregunta por foo.example.com y la zona no tiene un registro para foo.example.com, pero sí tiene un comodín
*.example.com, entonces el comodín puede responder.

Si la zona tiene foo.example.com de forma explícita (incluso como un no-terminal vacío en algunos casos), el comodín no lo sobrescribe.
Los comodines son “último recurso”, no “sobrescribir”.

Lo que no hará

• No coincidirá a través de múltiples etiquetas. *.example.com no coincide con a.b.example.com. Para eso necesitarías
  *.b.example.com (y ahí ya estás en el negocio de gestionar toda una taxonomía de arrepentimientos).
• No crea una delegación DNS. Si delegas dev.example.com a otra zona, el comodín en example.com
  no se aplica dentro de la zona hija delegada.
• No “arreglará” servicios faltantes. Solo hace que nombres inexistentes resuelvan. Tu pila TCP aún te dará la mala noticia.

La conveniencia es real

Los comodines son excelentes para:

• Entornos efímeros con nombres desconocidos de antemano (aplicaciones preview, despliegues por rama).
• Enrutamiento multi-inquilino donde la aplicación lee el encabezado Host y selecciona un inquilino.
• Puertas de entrada de CDN donde el origen no se preocupa por nombres de host específicos.
• UX de catch-all (“si tecleas mal, igual te llevamos a algo útil”).

Pero la compensación es sutil: los comodines hacen que DNS deje de ser una fuente de verdad sobre lo que existe. Está bien si tienes otras barreras.
Si no las tienes, será una larga noche.

Hechos interesantes y contexto histórico

Algunos puntos cortos y concretos que importan en la práctica:

1. Las reglas de coincidencia de comodines se estandarizaron temprano y se fueron precisando con el tiempo; RFC 1034 describió los comodines conceptualmente, y RFCs posteriores aclararon
   casos límite alrededor de no-terminales vacíos y respuestas negativas.
2. Los comodines DNS existen desde antes de la web. Eran útiles para nomenclaturas genéricas y enrutamiento de correo mucho antes de que “subdominios para todo” se volviera la norma.
3. “NXDOMAIN” es una señal fuerte en DNS: significa que el nombre no existe. Los comodines reducen intencionalmente el número de NXDOMAINs que emites,
   lo que cambia el comportamiento de caché y la detección de errores.
4. El caché negativo (RFC 2308) significa que un NXDOMAIN puede ser cacheado. Los comodines reducen los NXDOMAINs, así que errores tipográficos y escaneos pueden generar muchas respuestas “válidas”
   en su lugar—en ocasiones estresando tu borde.
5. DNSSEC añade una complicación: probar la no existencia usa registros NSEC/NSEC3. Los comodines interactúan con las pruebas de “closet encloser”; las malas configuraciones
   pueden crear fallos de validación que solo aparecen para nombres “aleatorios”.
6. La automatización de certificados cambió las apuestas. Los retos ACME DNS-01 hicieron que los certificados comodín sean fáciles, lo que fomentó que comodines DNS y certificados comodín
   se desplegaran juntos—a veces con demasiada ligereza.
7. Algunos proveedores implementan “alias”/“flattening” en el ápice de la zona como una extensión no estándar. Mezclarlos con comodines puede producir sorpresas
   porque no son registros DNS clásicos.
8. Los modos “proxied” de los CDN a menudo terminan TLS y responden HTTP para cualquier nombre de host que apuntes a ellos. Combina eso con comodines y puedes
   “servir” accidentalmente nombres que nunca pretendías publicar.

Por qué la gente usa comodines (y cuándo tienen sentido)

En producción, la mayoría de decisiones sobre comodines se toman por tres razones: velocidad, escala y pereza. Solo dos de esas son defendibles, y la pereza
ocasionalmente se disfraza de velocidad.

Casos de uso legítimos

Los casos sólidos se ven así:

• Entornos preview: pr-1847.preview.example.com aparece y desaparece bajo demanda. DNS no debería necesitar un ticket.
• Enrutamiento por inquilino: tenant-a.app.example.com, tenant-b.app.example.com llegan al mismo ingress, y tu
  app enruta según el hostname.
• Malla de servicios / abstracción de gateway: Todo pasa por una puerta API que sabe qué hacer. DNS es solo el letrero de entrada.
• Experiencia de desarrollador: Los humanos escriben cosas raras. Los comodines reducen fricción cuando el sistema está diseñado para aceptarlo de forma segura.

Malas motivaciones disfrazadas de ingeniería

• “No queremos gestionar registros DNS.” Claro. Pero entonces solo transferiste la complejidad al debugging, monitoreo y revisión de seguridad.
• “Es más fácil que rastrear inventario.” DNS no es un sistema de inventario. Si lo usas como tal, te mentirá de la manera más educada posible.
• “Podemos apuntar todo al mismo balanceador y arreglarlo después.” No lo arreglarás después. Tu incidente lo arreglará por ti.

Una verdad seca: si no puedes explicar qué se supone que coincide tu comodín, no estás listo para ejecutarlo.

Broma #1: Un registro comodín es como una carpeta “miscelánea”: útil hasta que se convierte en todo tu sistema de archivos.

Dónde los comodines silenciosamente rompen cosas

Los comodines fallan de maneras previsibles. Rara vez rompen el camino feliz. Sabotean los casos límite—los que solo encuentras durante incidentes,
migraciones, renovaciones de certificados o revisiones de seguridad. En otras palabras: los momentos en que menos quieres sorpresas.

1) Retos ACME y automatización de certificados

Si emites certificados vía ACME (Let’s Encrypt o ACME interno), existen distintos tipos de reto:
HTTP-01, TLS-ALPN-01, DNS-01. Los comodines en DNS y los comodines en certificados se confunden, y ahí es donde la gente empieza a hacer suposiciones.

Falla común: añades *.example.com apuntando a un nuevo ingress, pero _acme-challenge.example.com o
_acme-challenge.foo.example.com necesita registros TXT especiales. Si además tienes automatización que crea TXT dinámicamente,
tu comodín puede no ser la causa directa, pero cambia los caminos de resolución y puede exponer huecos en delegación o DNS de horizonte partido.

2) Correo y “dominios de correo sorpresa”

Los comodines no controlan directamente los registros MX del ápice de la zona (correo para example.com), pero pueden crear la ilusión de que
existen dominios de correo para cada subdominio. Algunos sistemas de correo tratan los subdominios como identidades separadas y consultarán MX en
sub.example.com.

Si tienes *.example.com A 203.0.113.10 y ningún MX explícito para sub.example.com, el comportamiento varía por implementación: algunos recurrirán a A/AAAA
según las reglas RFC si no existe MX. Ahora tu IP web es el destino de correo. Eso no es “DNS roto”. Eso es DNS haciendo exactamente lo que pediste.

3) Sombreado de tráfico y filtración entre entornos

Un comodín apuntando a producción puede capturar silenciosamente nombres de staging. Si tu zona de staging tiene horizonte partido (interno vs externo) y alguien
olvida añadir un registro internamente, el resolvedor puede recurrir al DNS público. Entonces tu app de staging llama a servicios de producción porque DNS dice
“claro, eso existe”.

4) Los errores tipográficos resuelven y el monitoreo miente

Con comodines, los errores tipográficos no dan NXDOMAIN. Resuelven. Eso cambia la experiencia de usuario (a veces para bien) y el monitoreo (a menudo para mal).
Las comprobaciones de salud que dependen de “¿resuelve DNS?” se vuelven inútiles. Los escáneres de seguridad que buscan DNS colgante también se comportan distinto, porque nada cuelga si
todo resuelve a algo.

5) Comportamientos de CDN y proxies

Si tu comodín apunta a un proveedor CDN que sirve una página por defecto para hostnames desconocidos, puedes “publicar” accidentalmente hostnames que nunca
pretendiste. Eso puede confundir clientes, filtrar patrones de nombres internos y crear comportamientos desordenados de certificados/SNI si el CDN no tiene un certificado
para ese hostname.

6) Delegaciones y zonas parciales

La gente asume que *.example.com cubre todo bajo example.com, luego delega dev.example.com a otro conjunto de servidores de nombres.
Ahora foo.dev.example.com lo responde la zona hija, no el comodín del padre. Si la zona hija está vacía o mal configurada, obtendrás NXDOMAIN para “algunos” hosts,
y el comodín seguirá respondiendo felizmente para otros. El diagnóstico se vuelve una lección de geografía.

Coincidencia, precedencia y “¿por qué está resolviendo?”

La resolución DNS es una cadena de autoridad, caché y reglas. Los comodines encajan en esa cadena de una manera que se siente intuitiva hasta que estás de guardia.
Entonces se siente como si el archivo de zona te estuviera manipulando.

Precedencia: lo explícito vence al comodín

Si api.example.com existe de forma explícita, gana. Incluso si es de un tipo diferente. Eso suena obvio—hasta que te das cuenta de que tu automatización
podría estar creando registros explícitos que olvidaste.

“Closest encloser” y respuestas negativas

Cuando un nombre no existe, los servidores autorizados no se quedan de brazos cruzados. Prueban la no existencia (especialmente con DNSSEC) basándose en el ancestro existente
más cercano y las reglas de comodín. Aquí es donde obtienes fenómenos divertidos como:

• Algunos nombres aleatorios resuelven vía comodín, otros devuelven NXDOMAIN porque existe un nombre más cercano que bloquea la expansión del comodín.
• Los resolvedores cachean NXDOMAIN por un periodo (TTL de caché negativo). Si luego creas registros explícitos, algunos clientes seguirán fallando hasta que expire el caché negativo.

Los comodines no eliminan la necesidad de inventario

Un comodín no es descubrimiento. Es una respuesta por defecto. Si necesitas saber qué servicios existen, regístralos en otro sitio:
registro de servicios, estado de IaC, configuración del gateway, CMDB (si te gustan ese tipo de dolores).

Una idea sobre confiabilidad parafraseada de John Allspaw: “Las fallas rara vez son causadas por un solo error; emergen del trabajo normal y sistemas complejos.”
(idea parafraseada)

Así es exactamente cómo ocurren los incidentes con comodines. Nadie “rompió DNS”. Todo el mundo tomó decisiones razonables que se intersectaron.

Tres micro-historias del mundo corporativo

Micro-historia #1: Un incidente causado por una suposición equivocada

Una empresa SaaS mediana usaba *.app.example.com para enrutar inquilinos a través de un ingress compartido. Funcionó bien. Los nuevos inquilinos no necesitaban
cambios en DNS, solo configuración en la aplicación. Alguien sugirió extender el mismo patrón a herramientas internas: *.tools.example.com.

La suposición equivocada fue sutil: “Los comodines son seguros porque los registros explícitos los sobrescriben.” Cierto, pero incompleto. Su DNS interno usaba horizonte partido:
zona pública para externo, zona privada para interno. La zona privada tenía algunos registros explícitos de herramientas pero no todos, y la zona pública tenía el comodín.

Durante una ventana de mantenimiento del centro de datos, los resolvedores internos fallaron brevemente hacia resolvers recursivos públicos (un reenviador mal configurado).
De repente, hosts internos que carecían de registros privados empezaron a resolverse vía el comodín público hacia la IP del ingress externo.
Las solicitudes que debían permanecer en redes internas salieron a Internet, chocaron con reglas WAF y devolvieron 403s. El incidente pareció una caída de red,
luego una caída de la aplicación, luego un “¿por qué staging llama a prod?”.

La solución no fue “quitar el comodín”. La solución fue robustecer el horizonte partido: fijar los resolvedores internos, añadir monitoreo de cambios en la ruta de resolvedores, y
aplicar “no respuestas comodín para tools” mediante bloqueos explícitos estilo NXDOMAIN (más adelante se explica) y registros internos explícitos.

La lección duradera: los comodines no son solo una característica de DNS; son una política. Si no sabes qué resolvedores usan realmente tus clientes durante un failover,
tu política es fantasía.

Micro-historia #2: Una optimización que salió mal

Otra compañía operaba miles de entornos preview. La gestión de DNS era un cuello de botella, así que introdujeron un comodín:
*.preview.example.com apuntando a un único borde Anycast que enruta solicitudes según el hostname. Gran simplificación. Su IaC
dejó de saturar proveedores de DNS con actualizaciones de registros.

Luego optimizaron el caché: aumentaron el TTL del comodín a una hora para reducir la carga de consultas DNS. El efecto fue inmediato y malo.
Los entornos preview se desprovisionaban con frecuencia, y la capa de enrutamiento actualizaba su mapa en segundos. Pero los clientes—especialmente proxies corporativos y
redes móviles—mantuvieron la respuesta DNS durante una hora. Así que entornos “eliminados” siguieron siendo accesibles (a veces alcanzando el inquilino equivocado si se reutilizaban hostnames).

Peor aún, su respuesta a incidentes dependía de poder enrutear a null ciertos hostnames de preview durante abuso. Con un TTL alto en el comodín, podían bloquear en el borde,
pero DNS seguía estable, y algunos componentes upstream seguían golpeando la misma IP con hostnames malos. Los registros estaban ruidosos, se activaron límites de tasa, y
todo el sistema de preview pareció inestable.

Rebajaron el TTL, pero no al valor original mínimo. Segmentaron: *.preview.example.com mantuvo TTL bajo, mientras que hostnames estables obtuvieron TTLs más largos. Y añadieron
una lista de denegación basada en host en el borde que devolvía rápido 451/404 con cabeceras de caché cortas, para que los “hostnames muertos” murieran rápido incluso cuando DNS no lo hacía.

Micro-historia #3: Una práctica aburrida pero correcta que salvó el día

Un equipo de servicios financieros tenía un proceso estricto de cambios DNS. No era glamuroso. Cada comodín tenía un responsable, un diagrama y un plan de pruebas. También tenían
una política: cada zona con comodín debía tener un hostname “canario” con un registro explícito que nunca debía ser respondido por el comodín.

Una noche, migraron proveedores de hosting DNS. La zona se transfirió limpiamente, pero el nuevo proveedor interpretó un ALIAS en el ápice más un CNAME comodín de forma distinta
al anterior. La mayoría de nombres resolvieron bien, pero un puñado de nombres “inexistentes” empezó a resolverse cuando deberían haber sido NXDOMAIN.
Este era el tipo de fallo que normalmente toma días en llegar vía reportes de usuarios.

Su monitoreo lo detectó en minutos: el hostname canario, que debía devolver NXDOMAIN, empezó a devolver un registro A. Eso activó un pager con un mensaje muy específico:
“Ámbito del comodín cambiado.” El on-call comparó inmediatamente las respuestas autoritativas entre los servidores de nombres antiguos y nuevos, encontró la diferencia en
la expansión del comodín y arregló la zona antes del tráfico matutino.

Sin heroísmos. Solo corrección aburrida: canarios, expectativas explícitas y pruebas que validaban la ausencia de registros—no solo la presencia.

Guion de diagnóstico rápido

Cuando surgen problemas DNS relacionados con comodines, el camino más rápido es dejar de adivinar y establecer tres hechos:
(1) qué servidor de nombres es autoritativo, (2) qué responde realmente, y (3) qué está cacheando el cliente.

Primero: confirma si estás viendo la verdad autoritativa o caché

• Consulta directamente a los servidores de nombres autoritativos. Si no puedes, estás depurando un rumor.
• Consulta desde un resolvedor “limpio” (o usa +norecurse) para evitar que la caché recursiva oculte cambios.

Segundo: determina la ruta de coincidencia y los límites de delegación

• Sube por las etiquetas: ¿dev.example.com está delegado en otro lado? ¿Estás cruzando zonas?
• Comprueba si existe un registro explícito que bloquee el comodín (incluyendo registros inesperados creados por automatización).

Tercero: identifica qué está roto (DNS vs enrutamiento vs TLS)

• Si DNS devuelve una IP pero HTTP falla, puede que tengas un DNS comodín “funcionando” pero sin un virtual host, certificado SNI o ruta de ingress correspondiente.
• Si algunos clientes funcionan y otros no, sospecha del TTL y del caché negativo.
• Si clientes internos se comportan diferente a los externos, sospecha de horizonte partido y failover de resolvedores.

Broma #2: DNS es el único sistema donde “resolvió” puede significar “está equivocado más rápido”.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas ejecutables que puedes hacer durante diseño, revisión de cambios o respuesta a incidentes. Cada una incluye qué significa la salida y qué decisión tomar.
Reemplaza example.com y las IPs de servidores de nombres según sea necesario.

Task 1: See what a wildcard returns from your default resolver

cr0x@server:~$ dig +short totallymadeup-12345.example.com A
203.0.113.10

Qué significa: El nombre resuelve a un registro A, probablemente debido a un comodín (o a un catch-all en un proveedor).

Decisión: Si esperas NXDOMAIN para hosts desconocidos, debes eliminar/limitar el comodín o bloquear con registros explícitos.

Task 2: Prove whether the answer is coming from a wildcard (query authoritative)

cr0x@server:~$ dig @ns1.example.net totallymadeup-12345.example.com A +noall +answer +authority
totallymadeup-12345.example.com. 300 IN A 203.0.113.10
example.com. 300 IN NS ns1.example.net.
example.com. 300 IN NS ns2.example.net.

Qué significa: El servidor autoritativo devuelve un registro A para un nombre que probablemente no existe de forma explícita.

Decisión: Inspecciona la zona buscando un registro comodín en el nivel de coincidencia más cercano (a menudo *.example.com).

Task 3: Check for explicit records that should override wildcard

cr0x@server:~$ dig @ns1.example.net api.example.com ANY +noall +answer
api.example.com. 300 IN A 203.0.113.20

Qué significa: Existe un registro A explícito para api.example.com; el comodín no debería afectarlo.

Decisión: Si api.example.com resuelve incorrectamente en algunos clientes, sospecha de caché o horizonte partido, no de precedencia de comodín.

Task 4: Determine delegation boundaries with +trace

cr0x@server:~$ dig +trace foo.dev.example.com A
; <<>> DiG 9.18.24 <<>> +trace foo.dev.example.com A
.                       518400  IN      NS      a.root-servers.net.
...
example.com.            172800  IN      NS      ns1.example.net.
dev.example.com.        3600    IN      NS      ns-dev1.example.net.
foo.dev.example.com.    300     IN      A       198.51.100.44

Qué significa: dev.example.com está delegado a servidores de nombres separados; los comodines del padre no se aplicarán dentro.

Decisión: Corrige registros en la zona hija si el comportamiento difiere en ese subárbol; no persigas el comodín del padre.

Task 5: Confirm wildcard doesn’t match multiple labels

cr0x@server:~$ dig +short a.b.example.com A
203.0.113.10

Qué significa: Si esto resuelve, no es por *.example.com solo; o existe *.b.example.com o b.example.com está delegado/manejado de forma distinta.

Decisión: Busca un comodín más profundo o comportamiento “catch-all” del proveedor; mapea el subárbol.

Task 6: Inspect TXT for ACME DNS-01 challenges

cr0x@server:~$ dig _acme-challenge.example.com TXT +noall +answer
_acme-challenge.example.com. 60 IN TXT "mM9vXkZlKfZy0Q2nq3...redacted..."

Qué significa: Existe un registro TXT para la validación DNS-01.

Decisión: Si la emisión falla, verifica que estés consultando la zona autoritativa correcta y que el TTL se alinee con el tiempo de tu cliente ACME.

Task 7: Check CNAME chains that can confuse validation or routing

cr0x@server:~$ dig www.example.com CNAME +noall +answer
www.example.com. 300 IN CNAME example.com.

Qué significa: www es un alias; el comodín en *.example.com no ayudará si pretendías un comportamiento distinto para www.

Decisión: Decide si quieres registros explícitos para hostnames importantes (recomendado) en vez de confiar en comodines por defecto.

Task 8: Verify whether a name should be NXDOMAIN (and whether it is)

cr0x@server:~$ dig nosuchhost.example.com A +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51142
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

nosuchhost.example.com. 300 IN A 203.0.113.10

Qué significa: El estado es NOERROR con un registro A; esto no es NXDOMAIN. Un comodín (o un registro explícito) está respondiendo.

Decisión: Si los nombres desconocidos deben fallar, rediseña: elimina el comodín, limita el alcance o implementa patrones de denegación explícitos vía la estructura de la zona.

Task 9: Check negative caching TTL (SOA) for NXDOMAIN behavior

cr0x@server:~$ dig example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

Qué significa: El último campo del SOA (aquí 300) se usa comúnmente como TTL de caché negativo (dependiendo del servidor/config).

Decisión: Si dependes de una propagación rápida de nuevos registros tras un NXDOMAIN, mantén el TTL negativo moderado. Si dependes de estabilidad, súbelo con cuidado.

Task 10: Identify split-horizon differences (internal vs external)

cr0x@server:~$ dig @10.0.0.53 api.example.com A +short
10.20.30.40

cr0x@server:~$ dig @1.1.1.1 api.example.com A +short
203.0.113.20

Qué significa: DNS interno devuelve IP privada, resolvedor público devuelve IP pública. Eso es un horizonte partido intencional.

Decisión: Si clientes obtienen a veces la respuesta pública internamente, corrige la configuración de resolvedor y reglas de egress DNS; no «tapes» el problema con más comodines.

Task 11: Validate SNI/certificate mismatch caused by wildcard DNS to shared edge

cr0x@server:~$ openssl s_client -connect 203.0.113.10:443 -servername typoedhost.example.com -brief
depth=0 CN = default.edge.example.net
verify error:num=62:Hostname mismatch
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384

Qué significa: DNS resuelve, TCP conecta, TLS negocia, pero el certificado no coincide con el hostname. Clásico comodín DNS hacia un borde compartido sin cobertura de certificados.

Decisión: O dejas de resolver hostnames desconocidos, o provisiones certificados adecuadamente, o aseguras que el borde rechace SNI desconocido temprano con una respuesta clara.

Task 12: Detect unexpected wildcard expansion by comparing two authoritative servers

cr0x@server:~$ dig @ns1.example.net weirdname.example.com A +short
203.0.113.10

cr0x@server:~$ dig @ns2.example.net weirdname.example.com A +short
198.51.100.77

Qué significa: Los servidores autoritativos no coinciden. Eso es propagación pendiente, split brain o contenido de zona diferente. Con comodines, la divergencia puede esconderse hasta que se consulta un nombre aleatorio.

Decisión: Congela cambios, confirma los seriales de zona y asegura que ambas autoridades sirvan registros idénticos antes de continuar el despliegue.

Task 13: Verify zone serial and propagation (SOA comparison)

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123100 7200 3600 1209600 300

Qué significa: La discrepancia de serial sugiere retraso de replicación o transferencia de zona fallida/publicación incompleta.

Decisión: Arregla la propagación antes de depurar capas superiores. Un cambio de comodín en un servidor es indistinguible de caos para los clientes.

Task 14: Confirm record type conflict (CNAME vs other records)

cr0x@server:~$ dig @ns1.example.net foo.example.com CNAME +noall +answer
foo.example.com. 300 IN CNAME edge.example.net.

cr0x@server:~$ dig @ns1.example.net foo.example.com A +noall +answer
foo.example.com. 300 IN A 203.0.113.55

Qué significa: Si tanto CNAME como A aparecen para el mismo nombre en la UI de tu proveedor, algo anda mal; los estándares no lo permiten. Algunos proveedores lo enmascaran con funciones de “flattening”, pero puede romper resolvedores o herramientas.

Decisión: Normaliza el conjunto de registros: elige CNAME o A/AAAA. Evita combinaciones específicas del proveedor donde se involucren comodines.

Task 15: Catch wildcard effects on service discovery by testing random labels

cr0x@server:~$ for i in 1 2 3 4 5; do host "rand-$RANDOM.example.com"; done
rand-21483.example.com has address 203.0.113.10
rand-1207.example.com has address 203.0.113.10
rand-30061.example.com has address 203.0.113.10
rand-9229.example.com has address 203.0.113.10
rand-18022.example.com has address 203.0.113.10

Qué significa: Las etiquetas aleatorias resuelven de forma consistente. Has hecho que la “existencia” sea irrelevante a ese nivel.

Decisión: Decide si tu monitoreo, inventario y controles de seguridad asumen NXDOMAIN. Si lo hacen, ajústalos o restringe el alcance del comodín.

Errores comunes: síntomas → causa raíz → solución

Mistake 1: “Every subdomain resolves, so everything is deployed”

Síntomas: Un entorno nuevo aparece “activo” en paneles que solo comprueban DNS; los usuarios obtienen 404/502/errores TLS.

Causa raíz: El DNS comodín responde por nombres sin rutas de ingress, virtual hosts o certificados correspondientes.

Solución: Deja de usar “DNS resuelve” como criterio de disponibilidad. Añade comprobaciones HTTP/TLS para el hostname específico y exige configuración de enrutamiento explícita. Considera devolver NXDOMAIN para hosts desconocidos.

Mistake 2: ACME issuance fails “randomly” for some names

Síntomas: Algunas renovaciones de certs tienen éxito, otras se agotan o validan TXT equivocados.

Causa raíz: Zona autoritativa equivocada consultada debido a delegación, horizonte partido o registros TXT obsoletos en caché; las suposiciones sobre comodines oscurecen dónde debe vivir el registro.

Solución: Traza la delegación, consulta servidores autoritativos directamente y asegura que los TXT se creen en la zona correcta con TTL razonables. Separa el manejo de _acme-challenge de la automatización genérica de comodines.

Mistake 3: Email goes to the web server

Síntomas: Correo para tenant.example.com termina en la IP del ingress web; los escáneres de spam se activan; errores SMTP en el borde.

Causa raíz: No hay registro MX para el subdominio; el remitente recurre a A/AAAA; el comodín proporciona A/AAAA, haciendo que la IP web sea el intercambiador de correo de facto.

Solución: Publica MX explícitos para subdominios que deban recibir correo, o bloquea explícitamente el correo publicando MX 0 . (null MX) donde convenga. No dejes que un A comodín se convierta en un endpoint de correo accidentalmente.

Mistake 4: Staging leaks into production during resolver failover

Síntomas: Apps internas de repente golpean IPs públicas; WAF bloquea tráfico interno; picos de latencia por hairpinning.

Causa raíz: Horizonte partido DNS no reforzado; resolvedores internos caen hacia recursion pública; el comodín en la zona pública captura nombres solo internos.

Solución: Asegura la configuración de resolvedores, monitorea la alcanzabilidad del resolvedor y garantiza que nombres internos existan explícitamente en DNS interno (o sean explícitamente NXDOMAIN). Añade reglas de egress que impidan a redes internas usar resolvedores públicos.

Mistake 5: “We increased TTL to reduce DNS load” and things got weird

Síntomas: Entornos eliminados siguen accesibles; tráfico se enruta al backend equivocado tras redeploy; incidentes persisten después de rollback.

Causa raíz: TTL alto en un registro comodín amplifica enrutamiento obsoleto. Los comodines suelen usarse para nombres dinámicos—TTL alto pelea con eso.

Solución: Mantén TTL bajo para comodines donde los backends cambian con frecuencia. Usa TTL más largo solo para nombres estables. Añade controles en la capa de borde para rechazar hostnames desconocidos rápidamente.

Mistake 6: DNSSEC validation failures only for some hostnames

Síntomas: Algunos resolvedores fallan con SERVFAIL; otros funcionan; las fallas se correlacionan con nombres “aleatorios”.

Causa raíz: Pruebas DNSSEC de no-existencia (NSEC/NSEC3) y comportamiento de comodines mal configurados; el servidor autoritativo devuelve respuestas que no validan para ciertas consultas.

Solución: Valida DNSSEC con herramientas autoritativas, asegura el firmado correcto y prueba nombres aleatorios más nombres explícitos. Trata las zonas con comodines como de mayor riesgo para casos límite de DNSSEC.

Listas de verificación / plan paso a paso

Checklist: should you use a wildcard here?

1. Define el objetivo: ¿Qué profundidad de etiqueta está comodinizada (una etiqueta)? ¿Cuál es el comportamiento esperado para errores tipográficos?
2. Decide la política NXDOMAIN: ¿Quieres que “un nombre desconocido falle” o que “un nombre desconocido rote a por defecto”?
3. Enumera hostnames críticos: api, www, mail, _acme-challenge, consolas admin. Hazlos explícitos.
4. Planifica TLS: ¿Tendrá el borde certificados que coincidan con cada hostname servido? Si no, rechaza SNI/Host desconocido de forma temprana y ruidosa.
5. Política de correo: Para subdominios, publica MX explícitos (incluido null MX) para que A/AAAA comodín no se convierta en intercambiador de correo.
6. Chequeo horizonte partido: Si tienes DNS interno, confirma que clientes internos no puedan usar recursion pública accidentalmente.
7. Plan de monitoreo: Añade canarios “debe ser NXDOMAIN” y “debe resolver”.
8. Plan de reversión: Sabe qué romperá quitar el comodín (a menudo apps preview y enrutamiento por inquilino). Documenta eso.

Paso a paso: desplegar un comodín de forma segura

1. Crea registros explícitos para nombres críticos primero. No dejes que tu comodín defina api, www, mail o prefijos de validación.
2. Elige un TTL conservador. Si el servicio de respaldo cambia con frecuencia, comienza en 60–300 segundos.
3. Prueba respuestas autoritativas. Consulta cada servidor de nombres autoritativo directamente para:
   hostnames conocidos, hostnames ausentes, nombres aleatorios y nombres TXT ACME.
4. Prueba desde múltiples puntos de vista de resolvedor. Resolvedor interno, resolvedor público y una VM/red “limpia”.
5. Despliega comportamiento en el borde para hostnames desconocidos. Decide: 404, 410, 451 o redirección. No sirvas una página por defecto “funciona” a menos que lo hagas intencionalmente.
6. Añade pruebas canario. Un hostname que debe resolverse vía comodín, uno que debe NO resolver (NXDOMAIN) y uno que debe resolverse a un objetivo explícito.
7. Vigila logs por errores tipográficos y escaneos. Los comodines pueden convertir ruido de fondo en carga real del backend. Limita la tasa según corresponda.
8. Documenta el alcance. Los humanos olvidan. Los incidentes no.

Paso a paso: quitar o estrechar un comodín sin romperlo todo

1. Inventario de callers. Analiza logs del borde: ¿qué hostnames se usan realmente?
2. Crea registros explícitos para el conjunto activo. Pasa de implícito a explícito cuando sea posible.
3. Introduce un nuevo comodín más estrecho. Por ejemplo, pasa de *.example.com a *.preview.example.com.
4. Acorta TTL antes del cambio. Hazlo al menos una ventana de TTL antes del corte para que las cachés se vacíen.
5. Implementa una respuesta “host desconocido” en el borde. Es una red de seguridad durante la transición.
6. Elimina el comodín y monitoriza las tasas de NXDOMAIN. Un pico es esperado; un pico sostenido puede indicar registros explícitos faltantes.

Preguntas frecuentes

1) ¿Coincide *.example.com con example.com?

No. El ápice example.com no es coincidente con *.example.com. Necesitas registros explícitos en el ápice.

2) ¿Coincide *.example.com con a.b.example.com?

No por sí solo. Coincide una etiqueta: anything.example.com. Si a.b.example.com resuelve, algo más está proporcionando esa respuesta.

3) Si tengo un registro explícito para foo.example.com, ¿puede el comodín sobrescribirlo?

No. Lo explícito vence al comodín. Si ves lo contrario, probablemente estés tratando con horizonte partido, múltiples zonas o inconsistencia de propagación.

4) ¿Son los registros DNS comodín lo mismo que certificados comodín?

Son capas diferentes. El comodín DNS hace que los nombres resuelvan. Los certificados comodín hacen que TLS sea válido para muchos hostnames. Puedes usar uno sin el otro, pero usar
comodín DNS sin cobertura TLS es una fuente común de errores de coincidencia de hostname.

5) ¿Por qué los comodines hacen el debugging más difícil?

Porque la ausencia deja de ser visible. NXDOMAIN es útil: te dice que el nombre no está presente. Con un comodín, todo “existe” en DNS, así que debes depurar en enrutamiento HTTP,
SNI TLS y lógica de aplicación en vez de en DNS.

6) ¿Puede el DNS comodín aumentar carga o coste?

Sí. Errores tipográficos, escaneos y probes aleatorios se convierten en tráfico real hacia tu borde. Si tu borde reenvía hostnames desconocidos upstream, puedes amplificar ruido en carga de backend.
Limita la tasa y rechaza hosts desconocidos pronto.

7) ¿Cómo evito que el correo use A/AAAA comodín para subdominios?

Publica MX explícitos para subdominios que deberían recibir correo. Para subdominios que no deberían, publica un registro MX nulo (MX 0 .) para indicar “no hay correo aquí”. Eso evita
la caída a A/AAAA en muchas implementaciones.

8) ¿Qué TTL debería usar para un registro comodín?

Si el destino cambia o el enrutamiento es dinámico, mantén TTL bajo (60–300 segundos es común). Si el destino es estable y has probado el comportamiento de rollback, puedes subirlo.
No subas el TTL para “optimizar” sin entender cuán rápido necesitas que los cambios surtan efecto.

9) ¿Puedo “bloquear” un comodín para un hostname específico?

Puedes sobrescribirlo creando registros explícitos. Para forzar comportamiento “no existe” para un nombre particular, puede que necesites trucos de diseño de zona o características del proveedor;
el DNS clásico no te permite publicar “NXDOMAIN como un registro”.

10) ¿Los comodines son seguros con DNSSEC?

Pueden serlo, pero prueba a fondo. DNSSEC añade requisitos de validación para la no-existencia y la expansión de comodines. Las malas configuraciones pueden causar fallos en resolvedores específicos que parecen intermitentes.

Conclusión: próximos pasos que realmente puedes hacer

El DNS comodín no es inherentemente maligno. Es inherentemente poderoso. Ese poder es lo que lo hace peligroso: cambia la semántica de “existencia”, enmascara errores tipográficos
y desplaza modos de fallo desde DNS hacia TLS, enrutamiento y comportamiento de la aplicación.

Pasos prácticos:

1. Audita tus zonas en busca de comodines en niveles superiores. Si tienes *.example.com, asume que está afectando todo lo que olvidaste que existía.
2. Crea registros explícitos para nombres críticos (API, login, mail, admin, prefijos de validación) para que el comodín no pueda “responder amablemente” por ellos.
3. Añade dos canarios: un hostname que debe resolverse vía comodín y otro que debe ser NXDOMAIN. Alerta ante cambios.
4. Verifica el comportamiento de horizonte partido con consultas directas a resolvedores internos y públicos. Si clientes internos pueden acceder a DNS público, corrígelo primero.
5. Haz que el borde rechace hostnames desconocidos de forma rápida y clara. Si sirves una página por defecto, hazlo intencionalmente y monitorea el impacto.

Cuando usas comodines con intención y barreras, son una herramienta limpia. Sin ellas, son el tipo de conveniencia que silenciosamente rompe cosas—hasta que arregla tu pipeline de despliegue y olvidas por qué tenías miedo.