Cómo Agregar un Subdominio a Su Dominio

Un subdominio es un prefijo añadido a un dominio raíz que crea un espacio de nombres distinto e independientemente direccionable bajo el mismo nombre de dominio. Por ejemplo, dado el dominio raíz example.com, el nombre de host blog.example.com es un subdominio completamente calificado donde blog es la etiqueta de tercer nivel. Los subdominios se resuelven a través de registros DNS — normalmente un registro A que apunta a una dirección IPv4, un registro AAAA para IPv6, o un registro CNAME que crea un alias de otro nombre de host — y no requieren ninguna tarifa adicional de registro de dominio.

Desde un punto de vista práctico, los subdominios le permiten ejecutar aplicaciones web separadas, entornos de staging, sitios regionales o microservicios bajo un único dominio registrado, con raíces de documentos independientes, certificados SSL y configuraciones de servidor. Esta guía cubre el proceso técnico completo: creación de registros DNS, configuración de alojamiento, aprovisionamiento de SSL, verificación de propagación y modos de fallo comunes que la mayoría de los tutoriales omiten.

Qué Es un Subdominio y en Qué Se Diferencia de un Subdirectorio

Antes de tocar el DNS, vale la pena entender la diferencia arquitectónica entre un subdominio y un subdirectorio, porque la elección afecta al SEO, la configuración del servidor y el alcance del SSL.

John Mueller de Google ha confirmado que Google generalmente trata los subdominios como parte del mismo sitio cuando el contenido está claramente relacionado, pero el presupuesto de rastreo, la indexación y el comportamiento de la equidad de enlaces pueden diferir. Para contenido estrechamente integrado, como el blog de una empresa, un subdirectorio suele ser la opción de menor fricción. Para una aplicación separada — un portal de clientes, una puerta de enlace API o un entorno de staging — un subdominio es la decisión arquitectónica correcta.

Casos de Uso Comunes para Subdominios

• Entornos de staging y QA: staging.example.com o dev.example.com — aislados de producción, a menudo protegidos por HTTP Basic Auth o listas de IP permitidas.
• Endpoints de API: api.example.com — permite despliegue independiente, limitación de velocidad y terminación TLS.
• Portales de clientes o paneles SaaS: app.example.com — contexto de autenticación separado y cookies de sesión.
• Sitios regionales o específicos por idioma: de.example.com, us.example.com — admite orientación hreflang y enrutamiento de servidor específico por región.
• Documentación y soporte: docs.example.com, support.example.com — a menudo servidos desde plataformas como GitBook, Zendesk o una wiki autoalojada.
• CDN o entrega de medios: cdn.example.com, static.example.com — apuntados mediante CNAME a una red de borde CDN.
• Infraestructura de correo: mail.example.com — utilizado como nombre de host para servicios SMTP/IMAP, distinto de los registros MX.

Paso 1: Acceder a la Interfaz de Gestión de DNS

Los registros DNS de un dominio se gestionan donde están alojados los servidores de nombres autoritativos del dominio. Esto no siempre es el mismo lugar que su alojamiento web. El servidor de nombres autoritativo está definido por los registros NS en su registrador de dominios.

Determine dónde se gestiona su DNS:

dig NS example.com +short

Si la salida muestra servidores de nombres pertenecientes a su registrador (p. ej., ns1.registrar.com), gestione el DNS en el registrador. Si muestra servidores de nombres pertenecientes a un proveedor de alojamiento o un servicio como Cloudflare, gestione el DNS allí en su lugar.

Una vez que haya identificado el panel de control correcto:

1. Inicie sesión en la interfaz de gestión de DNS.
2. Localice la sección Editor de Zona DNS, Gestión de DNS o Archivo de Zona.
3. Seleccione el dominio para el que desea crear el subdominio.

Si su dominio está registrado a través del Registro de Dominios de AlexHost, el editor de zona DNS es accesible directamente desde el panel de su área de cliente.

Paso 2: Crear el Registro DNS para el Subdominio

Creará uno de tres tipos de registros dependiendo de su infraestructura.

Registro A — Apuntando a una Dirección IPv4

Use un registro A cuando el subdominio resuelva a una dirección IP de servidor específica. Este es el escenario más común para subdominios alojados en un VPS o Servidor Dedicado.

Detalle crítico: Introduzca solo la etiqueta del subdominio en el campo Nombre — blog, no blog.example.com. La mayoría de las interfaces DNS añaden el dominio raíz automáticamente. Introducir el FQDN completo creará un registro para blog.example.com.example.com.

Registro AAAA — Apuntando a una Dirección IPv6

Estructura idéntica al registro A, pero el valor es una dirección IPv6 completa:

Registro CNAME — Creando un Alias de Otro Nombre de Host

Use un registro CNAME cuando el subdominio deba resolver a otro nombre de host en lugar de una IP directa. Los escenarios comunes incluyen apuntar a un CDN, una plataforma de terceros (Shopify, HubSpot, Netlify) u otro nombre de host interno.

Restricción arquitectónica: Un registro CNAME no puede coexistir con ningún otro tipo de registro en la misma etiqueta. No puede crear un CNAME para example.com en sí mismo (el vértice de la zona) — solo para subdominios. En el vértice, use un registro A o, si su proveedor de DNS lo admite, un registro propietario ALIAS o ANAME.

Registro de Subdominio Comodín

Un registro A comodín resuelve cualquier subdominio no definido a una única IP:

Esto es útil para aplicaciones SaaS multiinquilino donde cada cliente obtiene un subdominio (p. ej., customer1.example.com). Tenga en cuenta que un registro comodín no aprovisiona automáticamente SSL para cada subdominio — necesita un certificado SSL comodín o un cliente ACME que admita desafíos DNS-01.

Paso 3: Configurar el Servidor Web o el Panel de Alojamiento

Crear un registro DNS hace que el subdominio sea resoluble, pero no sirve contenido automáticamente. Debe configurar el servidor web o el panel de alojamiento para aceptar y enrutar solicitudes para el nuevo nombre de host.

Configurar un Subdominio en cPanel

Si su alojamiento usa cPanel — disponible en los planes de VPS con cPanel — el proceso es:

1. Inicie sesión en cPanel.
2. Navegue a Dominios > Subdominios.
3. En el campo Subdominio, introduzca la etiqueta (p. ej., blog).
4. Seleccione el dominio raíz del menú desplegable.
5. Establezca la Raíz del Documento — cPanel usa por defecto public_html/blog, pero puede especificar cualquier ruta.
6. Haga clic en Crear.

cPanel crea automáticamente el registro DNS A en la zona BIND de WHM si el DNS del dominio se gestiona localmente. Si el DNS se gestiona externamente (p. ej., Cloudflare), debe añadir el registro allí manualmente como se describe en el Paso 2.

Configurar un Subdominio en Nginx

Para un VPS que ejecuta Nginx, cree un nuevo bloque de servidor:

server {
    listen 80;
    listen [::]:80;
    server_name blog.example.com;

    root /var/www/blog;
    index index.html index.php;

    access_log /var/log/nginx/blog.access.log;
    error_log  /var/log/nginx/blog.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Guarde el archivo en /etc/nginx/sites-available/blog.example.com, luego actívelo:

sudo ln -s /etc/nginx/sites-available/blog.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Configurar un Subdominio en Apache

Cree un nuevo archivo de host virtual en /etc/apache2/sites-available/blog.example.com.conf:

<VirtualHost *:80>
    ServerName blog.example.com
    DocumentRoot /var/www/blog

    <Directory /var/www/blog>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/blog.error.log
    CustomLog ${APACHE_LOG_DIR}/blog.access.log combined
</VirtualHost>

Active y recargue:

sudo a2ensite blog.example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Paso 4: Aprovisionar un Certificado SSL para el Subdominio

Cada subdominio que sirve tráfico web debe estar asegurado con TLS. Un subdominio es un nombre de host distinto y no está cubierto por el certificado de dominio único del dominio raíz a menos que use un certificado comodín.

Opción 1 — Let’s Encrypt con Certbot (Subdominio Único)

sudo certbot --nginx -d blog.example.com

O para Apache:

sudo certbot --apache -d blog.example.com

Certbot modifica la configuración del host virtual automáticamente y configura un trabajo cron para la renovación.

Opción 2 — Certificado Comodín de Let’s Encrypt (Desafío DNS-01)

Un certificado comodín cubre *.example.com, asegurando todos los subdominios actuales y futuros con un único certificado. Esto requiere verificación mediante desafío DNS-01:

sudo certbot certonly 
  --manual 
  --preferred-challenges dns 
  -d "*.example.com" 
  -d "example.com"

Certbot le pedirá que cree un registro TXT (_acme-challenge.example.com) en su zona DNS. Después de añadir el registro y verificar la propagación, Certbot emite el certificado. Los certificados comodín deben renovarse cada 90 días; automatice la renovación con un plugin DNS para su proveedor (p. ej., certbot-dns-cloudflare).

Opción 3 — Certificado SSL Comercial

Para organizaciones que requieren validación extendida (EV) o un período de validez más largo, un certificado comercial de una CA de confianza es apropiado. AlexHost ofrece Certificados SSL que incluyen opciones validadas por dominio, validadas por organización y comodín. Tras la compra, instale el certificado colocando los archivos .crt y .key en el servidor y referenciándolos en la configuración del host virtual.

Paso 5: Verificar la Propagación de DNS

Los cambios de DNS no surten efecto globalmente en el instante en que los guarda. Cada resolvedor almacena en caché los registros durante la duración del valor TTL. Con un TTL de 3600, los resolvedores pueden servir el registro antiguo hasta una hora después de realizar un cambio.

Compruebe la propagación desde múltiples puntos de observación globales:

# Check from a specific DNS resolver
dig A blog.example.com @8.8.8.8 +short
dig A blog.example.com @1.1.1.1 +short

# Check authoritative answer directly
dig A blog.example.com +trace

Para una comprobación visual multirregional, use whatsmydns.net o dnschecker.org. La propagación global completa normalmente se completa en 15 minutos a 2 horas para TTLs de 3600 o inferiores. Las frecuentemente citadas “hasta 48 horas” se aplican principalmente a valores TTL de 86400 (24 horas) establecidos en el registro anterior — un valor predeterminado común en muchos registradores.

Consejo profesional: Antes de realizar cambios de DNS, reduzca el TTL del registro existente a 300 (5 minutos) al menos un ciclo TTL de antelación. Esto reduce drásticamente el tiempo de espera de propagación durante el cambio real.

Paso 6: Probar la Funcionalidad de Extremo a Extremo

Después de la propagación, realice una prueba funcional completa:

# Confirm DNS resolution
dig A blog.example.com +short

# Confirm HTTP response
curl -I http://blog.example.com

# Confirm HTTPS and certificate validity
curl -I https://blog.example.com

# Inspect the TLS certificate
openssl s_client -connect blog.example.com:443 -servername blog.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -subject -dates

Verifique que:

• La respuesta curl -I devuelve 200 OK o el código de redirección esperado.
• El sujeto del certificado TLS coincide con blog.example.com o *.example.com.
• La fecha de vencimiento del certificado es correcta.
• No aparecen advertencias de contenido mixto en la consola de desarrollador del navegador.

Errores Comunes y Cómo Evitarlos

CNAME en el vértice de la zona: Intentar crear un registro CNAME para example.com en sí mismo interrumpirá la entrega de correo y otros registros DNS. Use un registro A o un registro ALIAS/ANAME en el vértice.

Subdominio no servido por el servidor web: El DNS resuelve correctamente, pero el navegador devuelve un 404 o conexión rechazada. Causa: el servidor web no tiene un host virtual que coincida con el nombre de host del subdominio. Solución: añada el bloque de servidor o host virtual como se describe en el Paso 3.

Discrepancia del certificado SSL: El navegador muestra un error de certificado. Causa: el certificado existente cubre solo example.com, no blog.example.com. Solución: emita un nuevo certificado específicamente para el subdominio o reemplácelo con un certificado comodín.

cPanel crea un registro DNS local pero el DNS se gestiona externamente: Al usar Cloudflare u otro proveedor de DNS externo con alojamiento cPanel, el asistente de subdominios de cPanel crea un registro en la zona BIND local de WHM, que nunca se consulta. Debe añadir el registro A manualmente en Cloudflare (o su proveedor de DNS externo). Esta es una de las fuentes de confusión más comunes para los usuarios de alojamiento compartido.

DNS comodín sin SSL comodín: Un registro DNS *.example.com resuelve todos los subdominios a su servidor, pero cada nuevo subdominio activará una advertencia de certificado a menos que tenga instalado un certificado SSL comodín. No confíe únicamente en el DNS comodín para subdominios de producción.

Fuga del alcance de cookies: Si su aplicación establece cookies en .example.com (note el punto inicial), esas cookies se envían a todos los subdominios. Esto puede exponer tokens de sesión de un subdominio de alta seguridad a uno menos seguro. Defina el alcance de las cookies explícitamente al nombre de host previsto.

Gestión de Subdominios en Diferentes Entornos de Alojamiento

Para aplicaciones de alto tráfico que requieren acceso root completo y configuraciones de servidor personalizadas, un Servidor Dedicado le brinda control completo sobre el DNS, el software del servidor web y la gestión de certificados sin las restricciones de un entorno compartido.

Lista de Verificación de Decisiones Técnicas

Antes de crear un subdominio, revise lo siguiente:

• ¿Dónde están los servidores de nombres autoritativos? Ejecute dig NS example.com +short para confirmarlo antes de iniciar sesión en cualquier panel.
• ¿Registro A o CNAME? Use A/AAAA para una IP de servidor. Use CNAME para un nombre de host de plataforma de terceros. Nunca use CNAME en el vértice de la zona.
• ¿Está el servidor web configurado para aceptar el nuevo nombre de host? Un registro DNS por sí solo no sirve contenido.
• ¿Necesita el subdominio su propio certificado SSL? Sí, a menos que ya esté instalado un certificado comodín.
• ¿Está el TTL establecido en un valor bajo antes del cambio? Redúzcalo a 300 al menos un ciclo TTL antes de realizar cambios para minimizar el retraso de propagación.
• ¿Está cPanel gestionando el DNS localmente mientras un proveedor externo es autoritativo? Si es así, añada el registro en el proveedor externo, no en cPanel.
• ¿Necesita el subdominio estar bloqueado para la indexación por motores de búsqueda? Si es un entorno de staging o interno, añada X-Robots-Tag: noindex a nivel de servidor o use HTTP Basic Auth.
• ¿Están los alcances de las cookies definidos correctamente? Establezca explícitamente el atributo Domain en las cookies para evitar el intercambio no deseado entre subdominios.

Preguntas Frecuentes

¿Puedo crear un subdominio sin acceso al DNS del dominio raíz?

No. Un subdominio requiere un registro DNS (A, AAAA o CNAME) en la zona del dominio raíz. Sin acceso de escritura a la zona DNS autoritativa, no puede crear un subdominio resoluble públicamente.

¿Afecta un subdominio al SEO del dominio raíz?

Depende de la relación del contenido y los enlaces internos. Google puede asociar un subdominio con el dominio raíz, pero la equidad de enlaces no fluye tan libremente como entre URLs de subdirectorios. Para contenido estrechamente integrado con el sitio principal, un subdirectorio es generalmente preferible desde el punto de vista del SEO. Para aplicaciones separadas o entornos de staging, un subdominio es la elección correcta y debe ser noindex si no está destinado a la búsqueda pública.

¿Cuántos subdominios puedo crear bajo un dominio?

La especificación DNS no impone ningún límite práctico en el número de subdominios. Los registradores y paneles de alojamiento pueden imponer límites flexibles, pero estos son administrativos, no técnicos. Un único dominio puede tener cientos de subdominios.

¿Cuál es la diferencia entre un registro DNS comodín y un certificado SSL comodín?

Un registro DNS comodín (*.example.com) enruta todos los subdominios no definidos a una única dirección IP en la capa DNS. Un certificado SSL comodín (*.example.com) asegura todos los subdominios de primer nivel en la capa TLS. Son independientes: puede tener uno sin el otro, pero ambos son necesarios para servir todos los subdominios a través de HTTPS sin aprovisionamiento individual de certificados.

¿Por qué mi subdominio resuelve correctamente en dig pero devuelve un error en el navegador?

La resolución DNS y el servicio HTTP son capas separadas. Si dig devuelve la IP correcta pero el navegador muestra un error, el servidor web en esa IP no está configurado para manejar solicitudes para ese nombre de host (server_name en Nginx o ServerName en Apache). Añada el bloque de host virtual apropiado y recargue el servidor web.