Registro DNS wildcard

Ir a: navegación, búsqueda de

A registro DNS comodín es un registro en un Zona DNS coincidirá con las solicitudes de nombres de dominio inexistentes. Un comodín registro DNS se especifica utilizando un "*" como la etiqueta de la izquierda (parte) de un nombre de dominio, por ejemplo *. ejemplo.com. Las reglas exactas para cuando coincidirá con una wild card se especifican en RFC 1034, pero las reglas no son ni intuitivo ni claramente especificado. Esto ha resultado en implementaciones incompatibles y resultados inesperados cuando se utilizan.

Contenido

  • 1 Definiciones de DNS comodines
  • 2 Usos ejemplo comodín
  • 3 Clientes de comodines
  • 4 Comodines en la práctica
  • 5 Registros/ISP que emplean caracteres comodín
  • 6 Haciendo caso omiso de comodines empleadas por otros
  • 7 Referencias
  • 8 Enlaces externos

Definiciones de DNS comodines

Un comodín DNS grabar en un archivo de zona es similar a este ejemplo:

*. ejemplo.com.   3600 IN MX 10 identifica.

Este registro DNS comodín hará consultas DNS sobre nombres de dominio terminados en Example.com No existen para tener registros MX sintetizados para ellos. Entonces, una búsqueda para el registro MX para somerandomname.example.com Devuelve un registro MX apuntando a identifica.

Los comodines en el DNS son mucho más limitados que otros caracteres comodín utilizado en otros sistemas informáticos. Los registros DNS Wildcard tienen una sola "*" (asterisco) como el de la izquierda Etiqueta de DNS, tales como *. ejemplo.com. Asteriscos en otros lugares en el dominio no funcionará como comodín, así tampoco *ABC.example.com ni ABC.*.example.com trabajo como registros DNS comodín. Por otra parte, el comodín se empareja sólo cuando no existe un dominio, no sólo cuando no hay coincidencia registros del tipo que se ha consultado para. Incluso la definición de "no existe" como definido en el algoritmo de búsqueda de RFC 1034 Sección 4.3.2 puede resultar en el wild card no se corresponden a casos que uno podría esperar que con otros tipos de comodines.

La definición original de cómo se comporta un comodín DNS especificada en RFC 1034 las secciones 4.3.2 y 4.3.3, pero sólo indirectamente por ciertos pasos en un algoritmo de búsqueda y como resultado, las reglas no son ni intuitivo ni claramente especificado. Como resultado, 20 años después, RFC 4592, "El papel de comodines en el Domain Name System" fue escrito para ayudar a aclarar las reglas.

Para cotizar RFC 1912, "Un error común es pensar que un comodín MX de una zona se aplicará a todos los hosts en la zona. Un comodín MX se aplicará sólo a los nombres en la zona que no figuran en el DNS en absoluto". Es decir, si hay una wild card MX para *. ejemplo.comy un registro (pero no registro MX) para www.example.com, la respuesta correcta (como por RFC 1034) para solicitar un MX www.example.com "ningún error, pero no hay datos"; Esto está en contraste con la respuesta esperada posiblemente del registro MX adjunta a *. ejemplo.com.

Usos ejemplo comodín

En el siguiente ejemplo es de RFC 4592 Sección 2.2.1 y es útil en la aclaración de cómo funcionan los comodines.

Dicen que hay un Zona DNS con los siguientes registros de recursos:

$ORIGIN ejemplo.
 ejemplo.                 Ejemplo en SOA < SOA RDATA > 3600.                 3600 NS ns.example.com.
 ejemplo.                 3600 NS ns.example.net.
 * .example.               3600 TXT "este es un comodín" * .example.               3600 MX 10 host1.example.
 Sub.*.example.           3600 TXT host1.example "esto no es un comodín".           3600 un 192.0.2.1 _ssh.tcp.host1.example.  3600 SRV < SRV RDATA > _ssh.tcp.host2.example.  3600 SRV < SRV RDATA > subdel.example.          3600 NS ns.example.com.
 subdel.example. 3600 NS ns.example.net.

Un vistazo a los nombres de dominio en una estructura de árbol es útil:

ejemplo ├─ * │ └─ sub ├─ host1 │ └─ tcp │ └─ _ssh ├─ host2 │ └─ tcp │ └─ _ssh └─ subdel

Las respuestas siguientes podría ser sintetizadas a partir de uno de los comodines en la zona:

Dominio consultado Consultado tipo RR Resultados
host3.example. MX la respuesta será un "host1.example. EN MX..."
host3.example. A la respuesta reflejará "ningún error, pero no hay datos" porque no hay "Un" recurso récord (RR) en *.ejemplo.
foo.bar.example. TXT la respuesta será "foo.bar.example. TXT..."porque bar.example. No existe, pero el comodín hace.

Las siguientes respuestas no podría sintetizarse de cualquiera de los comodines en la zona:

Dominio consultado Consultado tipo RR Resultados
host1.example. MX No hay comodín coincidirán porque host1.example. existe. En cambio, usted recibirá una respuesta de "no hay error, pero no hay datos". El registro MX de comodín no proporciona registros MX para dominios que existen otra forma.
Sub.*.example. MX No hay comodín coincidirán porque Sub.*.example. existe. El dominio Sub.*.example. Nunca actuará como comodín, aunque tiene un asterisco.
_telnet.TCP.host1.example. SRV No hay comodín coincidirán porque TCP.host1.example. existe (sin datos).
host.subdel.example. A No hay comodín coincidirán porque subdel.example. existe y es una zona de corte, poniendo host.subdel.example. en una manera diferente Zona DNS. Incluso si host.subdel.example. No existe en la otra zona, una wild card no se utilizará de la zona principal.
Ghost.*.example. MX No hay comodín coincidirán porque * .example. existe, es un dominio de comodín, pero todavía existe.

El último ejemplo pone de relieve una idea falsa común sobre comodines. Un comodín "bloquea" en el sentido que un comodín no coincide con sus propios subdominios. Es decir * .example. No coincide con todos los nombres en la ejemplo. zona; No coinciden con los nombres abajo * .example.. Para cubrir los nombres bajo * .example., otro nombre de dominio comodín es necesario —*. * .example.— que cubre todo pero sus propios subdominios.

Clientes de comodines

Comodín dominios son ampliamente utilizados por blogs sitios web que permiten a los usuarios crear sub-dominios bajo demanda, e.g. sitios tales como WordPress o Blogspot. Otro uso popular es por libre DNS dinámico sitios web que permite a los usuarios crear un nombre DNS que cambia para que coincida con su IP de host como la dirección IP cambia periódicamente por el servidor DHCP de su ISP.

Comodines en la práctica

Citando RFC 4592, muchas implementaciones DNS divergen, de diferentes maneras, desde la definición original de comodines. Algunas de las variantes incluyen:

  • Con djbdns, además de comprobar comodines en el nivel actual, el servidor comprueba si hay comodines en todos superdomains envolventes, todo el camino hasta la raíz.[citación necesitada] En los ejemplos mencionados, la consulta de _telnet._tcp.host1.example.com para un MX record coincidiría con una wild card a pesar del dominio _tcp.host1.example.com existentes.
  • Servidor DNS de Microsoft (si está configurado para hacerlo[1]) y MaraDNS (por defecto) tiene caracteres comodín también emparejar todas las solicitudes de establece récord recursos vacía, es decir, los nombres de dominio para que allí no son registros del tipo deseado. En los ejemplos mencionados, la consulta de Sub.*.example.com para un MX record coincidiría *. ejemplo.com, a pesar de Sub.*.example.com explícitamente existentes con sólo un Registro TXT.

Registros/ISP que emplean caracteres comodín

Varios registradores de nombre de dominio en varias ocasiones, implementaron registros comodines para el Dominios de nivel superior, en particular VeriSign para .com y .net con su (ahora retirado) Sitio Finder sistema. El .Museum TLD también tuvo un récord de comodín que ahora se ha eliminado. A partir de julio de 2013, utilizando un comodín A registro de dominios de nivel superior son .kr, .pH, .St, .Sy y .ws, mientras que .MP utiliza un registro de comodín NS.

También se ha vuelto común a los ISPs sintetizar registros de direcciones para redirigir errores a sus sitios de publicidad, una práctica llamada "Cajón de sastre" typosquatting, pero estos no son verdaderos comodines, pero bastante modificado caché servidores de nombre.[2]

Haciendo caso omiso de comodines empleadas por otros

El Internet Software Consortium produjo una versión de la BIND Software DNS que puede ser configurada por los administradores del sistema para filtrar los registros DNS comodín de determinados dominios. Varios desarrolladores han producido parches de software para BIND y para djbdns.

Otros programas de servidor de DNS han seguido el ejemplo, proporcionando la capacidad de ignorar los registros DNS comodín como se ha configurado.

Referencias

  1. ^ Microsoft Corporation
  2. ^ Cuando la monetización de tráfico ISP sale horriblemente mal - parche de seguridad

Enlaces externos

  • Comentario del IAB: Arquitectura preocupaciones sobre el uso de comodines de DNS
  • Anuncio Internet Software Consortium de ""delegación-sólo característica que puede utilizar para filtrar comodines
  • Microsoft Knowledgebase: KB193844: Explicación del DNS comodines

Otras Páginas

Obtenido de"https://en.copro.org/w/index.php?title=Wildcard_DNS_record&oldid=624443072"