Consideraciones sobre el nombre de dominio en soluciones multiinquilino

2025-07-14

En muchas aplicaciones web multiinquilino, puede usar un nombre de dominio para proporcionar las siguientes funcionalidades:

Para distinguir un inquilino de otro
Para ayudar con el enrutamiento de solicitudes a la infraestructura correcta
Para proporcionar una experiencia de marca a sus clientes

Puede usar subdominios o nombres de dominio personalizados. En este artículo se proporcionan instrucciones para los responsables de la toma de decisiones técnicas sobre los enfoques de nombres de dominio y sus ventajas.

Subdominios

Puede asignar a cada inquilino un subdominio único en un nombre de dominio compartido común mediante un formato como tenant.provider.com.

Considere un ejemplo de solución multiinquilino compilada por Contoso. Los clientes compran el producto de Contoso para ayudar a administrar la generación de facturas. Contoso asigna a todos los clientes su propio subdominio bajo el dominio contoso.com. Si Contoso usa implementaciones regionales, podrían asignar subdominios bajo los dominios us.contoso.com y eu.contoso.com.

En este artículo se hace referencia a estos dominios regionales como dominios principales. Cada cliente obtiene su propio subdominio en el dominio troncal. Por ejemplo, Tailwind Toys podría recibir tailwind.contoso.com. Si usa un modelo de implementación regional, Adventure Works podría recibir adventureworks.us.contoso.com.

Nota:

Muchos servicios de Azure usan este enfoque. Por ejemplo, al crear una cuenta de Almacenamiento de Azure, Azure asigna un conjunto de subdominios, como <your account name>.blob.core.windows.net.

Administración del espacio de nombres del dominio

Al crear subdominios en su propio nombre de dominio, podría tener varios clientes con nombres similares. Comparten un único dominio raíz, por lo que el primer cliente para reclamar un dominio específico recibe su nombre preferido. Los clientes posteriores tienen que usar nombres de subdominios alternativos porque los nombres de dominio completos deben permanecer únicos globalmente.

DNS con caracteres comodín

Utilice entradas del sistema de nombres de dominio (DNS) comodín para simplificar la administración de subdominios. En lugar de crear entradas DNS para tailwind.contoso.com o adventureworks.contoso.com, podría crear una entrada comodín para *.contoso.com. Dirija todos los subdominios a una sola dirección IP mediante un registro A o un nombre canónico mediante un registro CNAME. Si usa dominios raíz regionales, es posible que necesite varias entradas comodín, como *.us.contoso.com y *.eu.contoso.com.

Nota:

Asegúrese de que los servicios de nivel web admiten DNS comodín si planea usar esta característica. Muchos servicios de Azure, como Azure Front Door y Azure App Service, admiten entradas DNS con caracteres comodín.

Subdominios basados en dominios raíz de varias partes

Muchas soluciones multiinquilino abarcan varias implementaciones físicas. Este enfoque es común cuando es necesario cumplir los requisitos de residencia de datos o mejorar el rendimiento mediante la implementación de recursos geográficamente más cerca de los usuarios.

Incluso dentro de una sola región, es posible que reparta los inquilinos entre implementaciones independientes, para respaldar la estrategia de escalado. Si tiene previsto usar subdominios para cada inquilino, considere la posibilidad de usar una estructura de subdominios de varias partes.

Por ejemplo, Contoso publica una aplicación multiinquilino para sus cuatro clientes. Adventure Works y Tailwind Traders están en la Estados Unidos y sus datos se almacenan en una instancia compartida de EE. UU. de la plataforma de Contoso. Fabrikam y Worldwide Importers están en Europa y sus datos se almacenan en una instancia europea.

En el diagrama siguiente se muestra un ejemplo de Contoso que usa el dominio de un solo tallo contoso.com para todos sus clientes.

Contoso puede usar las siguientes entradas DNS para admitir esta configuración.

Subdominio	CNAME a
`adventureworks.contoso.com`	`us.contoso.com`
`tailwind.contoso.com`	`us.contoso.com`
`fabrikam.contoso.com`	`eu.contoso.com`
`worldwideimporters.contoso.com`	`eu.contoso.com`

Cada nuevo cliente incorporado requiere un nuevo subdominio. El número de subdominios aumenta con cada cliente.

Como alternativa, Contoso podría usar dominios raíz específicos de la implementación o región.

Usando DNS comodín, las entradas DNS de esta implementación podrían tener un aspecto similar al siguiente.

Subdominio	CNAME a
`*.us.contoso.com`	`us.contoso.com`
`*.eu.contoso.com`	`eu.contoso.com`

Contoso no necesita crear registros de subdominio para cada cliente. En su lugar, un único registro DNS con caracteres comodín para la implementación de cada zona geográfica permite que los clientes nuevos debajo de ese dominio troncal hereden automáticamente el registro CNAME.

Cada enfoque tiene ventajas y desventajas. Al usar un solo dominio troncal, debe crear un registro DNS para cada inquilino que integre, lo que aumenta la carga operativa. Sin embargo, tiene más flexibilidad para mover inquilinos entre implementaciones. Puede cambiar el registro CNAME para dirigir su tráfico a otra implementación. Este cambio no afecta a ningún otro inquilino.

Los dominios de varios tallos tienen una menor sobrecarga de administración. Puede reutilizar los nombres de los clientes en varios dominios raíz regionales, ya que cada dominio raíz representa eficazmente su propio espacio de nombres.

Nombres de dominio personalizados

Es posible que quiera permitir que los clientes traigan sus propios nombres de dominio. Algunos clientes ven esta característica como un aspecto importante de su personalización de marca. Los clientes también pueden requerir nombres de dominio personalizados para cumplir los requisitos de seguridad, especialmente si necesitan proporcionar sus propios certificados de seguridad de la capa de transporte (TLS). Este enfoque puede parecer sencillo, pero algunas complejidades ocultas requieren una consideración cuidadosa.

Resolución de nombres

En última instancia, cada nombre de dominio debe resolverse en una dirección IP. Como se ha mostrado anteriormente, el proceso de resolución de nombres depende de si implementa una sola instancia o varias instancias de la solución.

Para volver a visitar el ejemplo, uno de los clientes de Contoso, Fabrikam, solicita que se use invoices.fabrikam.com como su nombre de dominio personalizado para acceder al servicio de Contoso. Contoso tiene varias implementaciones de su plataforma multiinquilino, por lo que deciden usar subdominios y registros CNAME para lograr sus requisitos de enrutamiento. Contoso y Fabrikam configuran los siguientes registros DNS.

Nombre	Tipo de registro	Importancia	Configurado por
`invoices.fabrikam.com`	CNAME	`fabrikam.eu.contoso.com`	Fabrikam
`*.eu.contoso.com`	CNAME	`eu.contoso.com`	Contoso
`eu.contoso.com`	A	(Dirección IP de Contoso)	Contoso

Desde la perspectiva de la resolución de nombres, esta cadena de registros resuelve con precisión las solicitudes de invoices.fabrikam.com en la dirección IP de la implementación europea de Contoso.

Resolución de encabezados de host

La resolución de nombres es solo una parte del problema. Todos los componentes web de la implementación europea de Contoso deben saber cómo controlar las solicitudes que incluyen el nombre de dominio de Fabrikam en su Host encabezado de solicitud. En función de las tecnologías web específicas que usa Contoso, el nombre de dominio de cada inquilino podría requerir más configuración, lo que agrega una sobrecarga operativa adicional a la incorporación de inquilinos.

También puede reescribir los encabezados de host para que, independientemente del encabezado Host de la solicitud entrante, el servidor web vea un valor de encabezado consistente. Por ejemplo, Azure Front Door permite volver a escribir Host encabezados para que, independientemente de la solicitud, el servidor de aplicaciones reciba un único Host encabezado. Azure Front Door propaga el encabezado de host original en el X-Forwarded-Host encabezado para que la aplicación pueda inspeccionarlo y, a continuación, buscar el inquilino. Sin embargo, la reescritura de un encabezado Host puede causar otros problemas. Para más información, consulte Conservación del nombre de host HTTP original entre un proxy inverso y su aplicación web de back-end.

Validación del dominio

Debe validar la propiedad de los dominios personalizados antes de incorporarlos. De lo contrario, un cliente podría reclamar accidental o malintencionadamente un nombre de dominio, lo que a veces se denomina aparcar un nombre de dominio.

Considere el proceso de incorporación de Contoso para Adventure Works, que solicitó usar invoices.adventureworks.com como su nombre de dominio personalizado. Desafortunadamente, alguien cometió un error tipográfico cuando intentó incorporar el nombre de dominio personalizado y olvidó escribir la letra s. Así que lo configuran como invoices.adventurework.com. Como resultado, el tráfico no fluye correctamente para Adventure Works. Pero cuando otra empresa denominada Adventure Work intenta agregar su dominio personalizado a la plataforma de Contoso, se les indica que el nombre de dominio ya está en uso.

Para evitar este problema, especialmente dentro de un proceso de autoservicio o automatizado, puede requerir un paso de comprobación de dominio. Es posible que necesite que el cliente cree un registro CNAME antes de que se pueda agregar el dominio. Como alternativa, puede generar una cadena aleatoria y pedir al cliente que agregue un registro TXT dns que incluya el valor de cadena. El nombre de dominio no se puede agregar hasta que la comprobación se realice correctamente.

Ataques de DNS pendiente y toma de control de subdominio

Al trabajar con nombres de dominio personalizados, expone su plataforma a una clase de ataques denominados DNS pendientes o toma de control de subdominio. Estos ataques se producen cuando los clientes desasocian su nombre de dominio personalizado del servicio, pero no eliminan el registro de su servidor DNS. A continuación, esta entrada DNS apunta a un recurso inexistente y es vulnerable a una adquisición.

Considere cómo puede cambiar la relación de Fabrikam con Contoso si se produce el siguiente escenario:

Fabrikam decide dejar de trabajar con Contoso, por lo que finalizan su relación empresarial.
Contoso desincorpora al arrendatario de Fabrikam y deshabilita fabrikam.contoso.com.
Fabrikam olvida eliminar el registro CNAME de invoices.fabrikam.com.
Un actor malintencionado crea una nueva cuenta de Contoso y le asigna el nombre fabrikam.
El atacante incorpora el nombre de dominio personalizado invoices.fabrikam.com a su nuevo inquilino.
Contoso comprueba el servidor DNS de Fabrikam durante la validación de dominio basada en CNAME. Ven que el servidor DNS devuelve un registro CNAME para invoices.fabrikam.com que apunta a fabrikam.contoso.com. Contoso considera que la validación de dominio personalizada se ha realizado correctamente.
Si los empleados de Fabrikam intentan acceder al sitio, las solicitudes parecen funcionar. Si el atacante configura su inquilino de Contoso con la personalización de marca de Fabrikam, es posible que los empleados accedan engañados al sitio y proporcionen datos confidenciales a los que el atacante pueda acceder.

Use las siguientes estrategias para protegerse frente a ataques DNS pendientes:

Requerir que el registro CNAME se elimine antes de que se pueda quitar el nombre de dominio de la cuenta del inquilino.
Prohibir la reutilización de identificadores de inquilino. Y requieren que cada inquilino cree un registro TXT con un nombre que coincida con el nombre de dominio y un valor generado aleatoriamente que cambie para cada intento de incorporación.

Certificados TLS

TLS es un componente esencial de las aplicaciones modernas. Proporciona confianza y seguridad a las aplicaciones web. Considere cuidadosamente la propiedad y administración de certificados TLS para aplicaciones multiinquilino.

Normalmente, el propietario de un nombre de dominio emite y renueva sus certificados. Por ejemplo, Contoso emite y renueva certificados TLS para us.contoso.com y un certificado comodín para *.contoso.com. De forma similar, Fabrikam administra los registros del fabrikam.com dominio, incluido invoices.fabrikam.com.

Un propietario de dominio puede usar el tipo de registro DNS de autorización de entidad de certificación (CAA). Los registros CAA garantizan que solo determinadas entidades puedan crear certificados para el dominio.

Si permite que los clientes traigan sus propios dominios, considere si planea emitir certificados en su nombre o exigirles que traigan sus propios dominios. Cada opción tiene ventajas y desventajas:

Si emite un certificado para un cliente, puede controlar la renovación del certificado, por lo que el cliente no necesita mantenerlo. Sin embargo, si los clientes tienen registros CAA en sus nombres de dominio, es posible que deban autorizarle para emitir certificados en su nombre.
Si los clientes emiten y proporcionan sus propios certificados, recibirá y administrará de forma segura las claves privadas. Para evitar una interrupción en su servicio, es posible que tenga que recordar a los clientes que renueven el certificado antes de que expire.

Varios servicios de Azure admiten la administración automática de certificados para dominios personalizados. Por ejemplo, Azure Front Door y App Service proporcionan certificados para dominios personalizados y controlan automáticamente el proceso de renovación. Esta característica elimina la carga de administrar certificados del equipo de operaciones. Sin embargo, usted todavía debe considerar la propiedad y la autoridad. Confirme que los registros de CAA están en su lugar y configurados correctamente. Asegúrese también de que los dominios de los clientes permitan los certificados que administra la plataforma.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autor principal:

John Downs | Ingeniero principal de software

Otros colaboradores:

Daniel Scott-Raynsford | Partner Technology Strategist
Arsen Vladimirskiy | Ingeniero de clientes principal, FastTrack for Azure

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Muchos servicios usan Azure Front Door para administrar nombres de dominio. Para más información, consulte Uso de Azure Front Door en una solución multiinquilino.

Vuelva a Consideraciones de arquitectura para una solución multiinquilino. O bien, consulte Marco de buena arquitectura de Azure.