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

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.

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.

¿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;
    [...]
    }

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.

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 ).

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á?

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.

¿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.

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/