¿Es un registro DNS comodín una mala práctica?

18

Le pedí a mi proveedor de alojamiento que agregara tres subdominios, todos apuntando a la IP del registro A. Parece que simplemente agregó un registro DNS comodín porque cualquier subdominio aleatorio se resuelve en mi IP ahora. Esto está bien para mí desde un punto de vista técnico, ya que no hay subdominios apuntando a ningún otro lado. Por otra parte, no me gusta que no haga lo que le pedí. Y entonces me pregunto si hay otras razones para decirle que cambie eso. ¿Hay alguna?

Lo único negativo que encontré es que alguien podría vincular a mi sitio usando http://i.dont.like.your.website.mywebsite.tld.

problema oficial
fuente
8
Alguien podría vincularse a su servidor usando " i.dont.like.your.website.mywebsite.tld " pero su servidor no debería responder a menos que esté configurado para responder a él (a través de hostheders o virtualhosts).
joeqwerty
66
En algunos casos se pueden requerir comodines. Por ejemplo, las aplicaciones web de múltiples inquilinos como Wordpress se pueden configurar para generar automáticamente nuevas instancias utilizando subdominios, por ejemplo, sitio1.blog.example.com, sitio2.blog.example.com, con el comodín en su lugar *.blog.example.com, usted no No es necesario configurar cada uno de estos individualmente.
jscott

Respuestas:

16

Si alguna vez coloca una computadora en ese dominio, obtendrá fallas de DNS extrañas, donde cuando intenta visitar algún sitio aleatorio en Internet, llega a la suya.

Considere: usted es dueño del dominio example.com. Configura su estación de trabajo y asígnele un nombre. ... digamos de let, yukon.example.com. Ahora notará en su /etc/resolv.conftiene la línea:

search example.com

Esto es conveniente porque significa que puede hacer búsquedas de nombres de host, por ejemplo, wwwque luego lo buscarán www.example.comautomáticamente. Pero tiene un lado oscuro: si visita, por ejemplo, Google, entonces buscará www.google.com.example.com, y si tiene DNS comodín, eso se resolverá en su sitio, y en lugar de llegar a Google, terminará en su propio sitio.

¡Esto se aplica igualmente al servidor en el que está ejecutando su sitio web! Si alguna vez tiene que llamar a servicios externos, las búsquedas de nombres de host pueden fallar de la misma manera. Entonces, api.twitter.compor ejemplo, de repente se convierte en api.twitter.com.example.comrutas directamente de regreso a su sitio y, por supuesto, falla.

Es por eso que nunca uso el comodín DNS.

Michael Hampton
fuente
3
@ChrisLively Culpe a los sistemas Linux modernos por ser "útiles" y agregarlos. Por cierto, usar ".local" es realmente una mala práctica, y no solo en entornos Windows.
Michael Hampton
66
De hecho, escribí en un blog sobre esto en lo que respecta a un entorno de Windows . Sin mencionar que al menos tres grupos han ofertado por el TLD .local ahora que ICANN los está vendiendo a cualquier persona con una billetera lo suficientemente sustancial. .localno está reservado y no debe usarse. Hacerlo viola los RFC y no es necesario en absoluto. La mejor práctica es usar un subdominio delegado de tercer nivel para recursos internos como internal.company.com. El hecho de que vea mucho algo no lo hace correcto.
MDMarra
2
¿Podría indicarme la sección de RFC 2606 que se reserva .local? He leído este RFC al menos una docena de veces con personas que lo usan en este argumento y puedo decirles con certeza que no está allí.
MDMarra
2
@Zypher En realidad, Microsoft nunca lo recomendó (eso también fue desacreditado en la publicación de mi blog. Vaya a leerlo, es bueno), pero el hecho de que SBS enviado .localpor defecto realmente hizo que MS pareciera un desastre en ese sentido. SBS se envió con esa configuración porque estaba destinada a clientes no tecnológicos con poco conocimiento técnico. Era el camino de menor resistencia, pero los documentos de AD reales recomiendan un subdominio de tercer nivel en la era W2K.
MDMarra
3
Ah, y dentro de unos años va a ser muy difícil obtener certificados para .local, lo que significa que los certificados UCC / SAN para Lync / Exchange deberán estar firmados por una CA interna, lo que hace que sea doloroso si tienes un dominio externo no unido usuarios.
MDMarra
14

¿Es un registro DNS comodín una mala práctica?

Personalmente no me gusta. Especialmente cuando hay máquinas en ese dominio. Los errores tipográficos no se controlan, los errores son menos obvios ... pero no tiene nada de fundamental.

Lo único negativo que encontré es que alguien podría vincular a mi sitio usando http: //i.dont.like.your.website.mywebsite.tld .

Haga que su servidor http redirija todas esas solicitudes a las direcciones canónicas adecuadas o no responda en absoluto. Para nginx eso sería algo como :

server {
    listen 80;
    server_name *.mywebsite.tld;
    return 301 $scheme://mywebsite.tld$request_uri;
    }

y luego el regular

server {
    listen  80;
    server_name mywebsite.tld;
    [...]
    }
Maldita terminal
fuente
7

Todo es cuestión de opinión. Para mí no es una mala práctica.

Estoy creando una aplicación multiinquilino que utiliza una base de datos por inquilino. Luego selecciona la base de datos que se utilizará en función del subdominio.

Por ejemplo milkman.example.comusará la tenant_milkmanbase de datos.

Como no me he separado tablas para cada inquilino, como, tenant_milkman.users, tenant_fisherman.users, tenant_bobs_garage.users, que en mi opinión es un enorme mucho más fácil de mantener para esta aplicación específica, en lugar de tener todos los usuarios de todas las empresas en la misma tabla.

[edit - Michael Hampton has a good point]

Dicho esto, si no tiene una razón específica para aceptar un subdominio (variable), como yo, entonces no debe aceptarlos.

Pedro Moreira
fuente
44
Tiene una buena razón técnica para usar DNS comodín. La mayoría de la gente no lo hace.
Michael Hampton
1
De hecho, esto me parece muy peligroso: le permite acceder a una base de datos arbitraria cambiando el nombre de dominio. Yo diría que este es un tipo de vulnerabilidad a la inyección. Es cierto que no es necesariamente explotable, pero ¿por qué arriesgarse?
sleske
1
@sleske No lo es, porque el usuario debe autenticarse en ese subdominio (para esa base de datos). Si cambia, necesitará autenticarse nuevamente, ya que es visto como un "sitio" completamente diferente.
Pedro Moreira
@PedroMoreira: Sí, eso reduce la superficie de ataque. Aún así, proporcionar acceso a bases de datos arbitrarias parece peligroso. Por ejemplo, ¿qué pasa si hay una base de datos de respaldo con credenciales idénticas, pero datos que se purgaron de la base de datos principal? Esto permitiría el acceso a cualquiera que conozca el nombre. Aún así, me doy cuenta de que la seguridad siempre es una compensación, solo quería señalar el peligro inherente.
sleske
1
@sleske Es por eso que todas las bases de datos accesibles tienen el prefijo tenant_. Me aseguré de que la aplicación ni siquiera pueda conectarse a ellos.
Pedro Moreira
2

Otro problema aquí es el SEO: si todos *.example.commuestran el mismo contenido, su sitio web estará mal referenciado, al menos por Google ( https://support.google.com/webmasters/answer/66359 ).

Clément Moulin - SimpleRezo
fuente
Ambos puntos son ortogonales. Incluso si todos los nombres apuntan a la misma IP, el servidor web obtiene el nombre solicitado y puede entregar contenido completamente diferente.
Patrick Mevzek
Es por eso que he descartado "si todos * .example.com muestran el mismo contenido" ... El riesgo de SEO me parece algo interesante para mencionar.
Clément Moulin - SimpleRezo
"El riesgo de SEO me parece algo interesante para mencionar". Tal vez, pero no tienen ninguna relación con el uso de un comodín o no. Puede tener muchos nombres separados, todos resueltos en una sola dirección IP sin ningún tipo de comodines y, por lo tanto, tener (o no) los riesgos de SEO de los que habla. El uso de un comodín no cambia nada en ninguna dirección aquí.
Patrick Mevzek
0

Esto es realmente una mala idea, supongamos que si desea alojar un subdominio a.company.com en un servidor web y b.company.com en otro servidor web, puede ser otro ISP. Qué harás ?. Por lo tanto, el DNS comodín no es una opción, debe ser preciso, crear un registro A para cada subdominio y puntos a IP relevante. Hay posibilidades de mover su servidor web de un ISP a otro ISP, en este caso, ¿qué hará?

vembutech
fuente
0

Sé que esta es una vieja pregunta, sin embargo, me gustaría compartir un ejemplo del mundo real de dónde usar dominios comodín puede causar problemas. Sin embargo, voy a cambiar el nombre de dominio y también ocultar el registro completo de SPF para ahorrar vergüenza.

Estaba ayudando a alguien que tenía problemas con DMARC, como parte de los controles siempre busco el registro DMARC con DIG

;; ANSWER SECTION:
_dmarc.somedomain.com. 21599 IN      CNAME   somedomain.com.
somedomain.com.      21599   IN      TXT     "v=spf1 <rest of spf record> -all"

También obtuve el mismo resultado al buscar su registro DKIM.

En consecuencia, los correos electrónicos enviados desde este dominio recibirán un error DKIM ya que el módulo DKIM intentará analizar el registro SPF para una clave DKIM y fallará, y también obtendrá un Permerror para DMARC por la misma razón.

Los dominios comodín pueden parecer una buena idea, pero configurados incorrectamente pueden causar todo tipo de problemas.

Ravenstar68
fuente
-2

¿Es un registro DNS comodín una mala práctica?

No, y al contrario de otros, creo que es una buena práctica.

La mayoría de los usuarios de Internet señalan un nombre DNS en algún momento. Teclearán ww.mycompany.como wwe.mycompany.com ¿Qué preferirías que ocurriera como "¡Uy, no pudimos encontrar ese sitio" o para que accedan a tu página de inicio principal? En la mayoría de los casos, es preferible que abra su página de inicio principal. Que es lo que hace MUCHA gente.

Incluso si alguien le pusiera un enlace i.dont.like.your.website.whatever.com, accedería a su página de inicio, que en realidad es lo que desea. Después de todo, no pueden hacer que ese i.dont....sitio vaya a su servidor, usted todavía controla el enrutamiento DNS para que vaya al suyo.

Yo no
fuente
55
El problema que tengo con este razonamiento es que 1. rompe el manejo de errores, 2. está completamente centrado en www, mientras que sus registros comodín afectarán también a otros protocolos. El resultado es que has roto el manejo de errores para otras cosas en las que no has hecho ningún esfuerzo para arreglar las cosas.
Håkan Lindqvist
-2

Creo que la mejor razón para no tener un registro DNS comodín en primer lugar es evitar regalar la dirección IP de su servidor a un atacante potencial y reducir la exposición a los ataques DDOS. Cloudflare también recomienda esta configuración: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/

Michael Rogers
fuente
2
El uso de dominios comodín no cambia la exposición a tales ataques. Y el enlace no admite sus reclamos incorrectos. Todo lo que dice el enlace es que Cloudflare está cobrando un precio más alto por los dominios comodín. Eso solo dice algo sobre los modelos de negocio de Cloudflare y nada sobre la práctica de usar dominios comodín.
Kasperd
Si usa dns comodín con cloudflare, ya que no pasa por cloudflare (a menos que pague a la empresa, la mayoría no) cualquiera puede hacer ping a cualquier subdominio inventado y encontrar su IP real. Sin comodín no pueden. Eso es todo al respecto.
Michael Rogers
Sí, en caso de dicho servicio, pueden cobrarle más por la protección con comodines. Aunque esta pregunta no se trata de ese tipo de servicios, se trata de dns comodín y si debe hacerse o no en situaciones normales.
Chris