Resumen
- El asterisco DNS no es una expresión regular: identifica un RRset fuente y solo interviene después de que la coincidencia exacta de etiquetas resulte imposible.
- El RFC 4592 obliga a calcular el ancestro existente más cercano y a mirar un solo candidato,
*.<ancestro-más-cercano>; no hay búsqueda de un comodín alternativo. - En una zona firmada, validar la respuesta exige autenticar los datos y demostrar que no existía un nombre exacto o más próximo con prioridad.
Una respuesta concreta nacida de una regla
Si una zona guarda una dirección en *.example y no contiene azul.example, puede devolver un registro cuyo propietario visible sea azul.example. El TTL y la dirección proceden del comodín. La respuesta se adapta a la pregunta, pero el propietario exacto no estaba almacenado.
El RFC 1034 llamó a los comodines instrucciones para sintetizar registros. Entre sus usos históricos figuraba dirigir correo para nombres desconocidos dentro de una zona. El diseño no reservaba todos los descendientes posibles ni convertía el asterisco en un lenguaje de patrones. Permitía una acción condicional de la autoridad.
Por eso una respuesta positiva no demuestra que alguien aprovisionó, revisó o quiso ese nombre concreto. Demuestra que la consulta satisfizo la regla publicada por la zona. La intención y la confianza de la aplicación viven en otros planos.
Lo que existe manda antes que el valor por defecto
La autoridad primero intenta igualar las etiquetas exactas. Si el nombre existe, el comodín no aporta un tipo ausente. Un nodo con AAAA pero sin MX produce una respuesta sin datos MX; no toma el MX de *.example.
La existencia tampoco exige un RRset en el propio nodo. Un nombre intermedio existe como terminal vacío si tiene descendientes. Esa pieza invisible altera la búsqueda. Crear un registro profundo puede levantar un nuevo límite y hacer desaparecer una respuesta comodín que antes parecía cubrir el mismo texto.
Al borrar el último descendiente ocurre lo contrario: el terminal vacío puede dejar de existir y un comodín más amplio vuelve a ser aplicable. No cambió el RRset comodín. Cambió la estructura que decidía si tenía permiso para actuar.
El ancestro más cercano elimina la improvisación
Las primeras implementaciones y el trabajo de DNSSEC necesitaron una formulación sin ambigüedad. El RFC 4592 definió el ancestro más cercano como el nodo existente que comparte con la consulta la secuencia más larga de etiquetas desde la raíz.
Cuando la búsqueda se sale del árbol, solo se forma un candidato: el nombre comodín situado inmediatamente debajo de ese ancestro, *.<ancestro-más-cercano>. Si no existe, no hay síntesis. Si existe pero carece del tipo solicitado, el resultado es ausencia de datos bajo el comodín. El servidor no retrocede hasta encontrar otro asterisco más conveniente.
Así, para cada consulta hay como máximo una fuente. Los comodines anidados dejan de ser un problema de intuición y se vuelven una decisión reproducible. También queda claro que “cubre todo lo de abajo” no es una descripción estable: un nodo explícito más próximo recalcula la única fuente admisible.
Un asterisco literal sigue siendo una etiqueta
Solo un primer label que sea exactamente * confiere carácter comodín al nombre. Un asterisco en otra posición carece de ese efecto. Una consulta que incluya literalmente * no solicita coincidencias múltiples: se procesa como cualquier etiqueta y puede localizar el propietario comodín.
Tras sintetizar, vuelven las reglas normales del tipo de registro. Un CNAME comodín puede dar paso al procesamiento ordinario de alias. Eso no transforma DNS en un redirector de aplicación, una política de certificados o una herramienta de coincidencia parcial.
La delegación cambia quién puede definir el defecto
El RFC 1034 ya prohibía que el valor por defecto de una zona cruzara una delegación. Al llegar al corte, el padre remite al hijo. El hijo puede establecer su propio comodín, pero bajo sus datos y su autoridad.
La frontera evita que el delegante conserve una respuesta de reserva oculta bajo un espacio que ya entregó. También obliga al nuevo operador a publicar explícitamente cualquier comportamiento por defecto que quiera mantener; el comodín del padre no viaja con la delegación.
DNSSEC autentica también la ausencia necesaria
Una respuesta comodín depende de una premisa: nada más exacto tenía derecho a responder. El RFC 4035 la hizo comprobable. La respuesta firmada incluye el RRset expandido y su firma, además de evidencia NSEC autenticada de que no existía una coincidencia exacta o más cercana.
El número de etiquetas de RRSIG permite reconstruir el propietario comodín original durante la verificación, aunque el usuario vea el nombre consultado. El validador confirma tanto la fuente como el vacío estructural que permitió usarla.
El alcance termina ahí. DNSSEC no afirma que el destino sea seguro, que la grafía fuese intencionada ni que una capa superior deba conceder identidad o privilegios. Autentica la decisión de una zona firmada según el árbol definido.
Fuentes y límites
El conjunto cerrado es RFC 1034, RFC 4592 y RFC 4035. Sustenta el mecanismo, las reglas de precedencia y la prueba DNSSEC; no mide uso actual, cuota de resolutores, abusos, consultas ni productos.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
