El infierno de configurar DNS en GoDaddy + Firebase Hosting: Guía de Supervivencia

 

Cualquiera que haya vendido la promesa de la "computación en la nube moderna" te dirá que desplegar un sitio estático y mapear un dominio personalizado toma diez minutos. Te muestran un video de YouTube con música chill-hop donde un presentador hace tres clics, sonríe y mágicamente el sitio está arriba con SSL verde.

Eso es marketing. La realidad en las trincheras de la infraestructura web es otra.

El siguiente documento es el post-mortem técnico de cómo una tarea trivial —vincular el dominio deladrillo.com (registrado en GoDaddy) al backend de Firebase Hosting (deladrillo.web.app)— se transformó en un infierno de 72 horas de degradación de servicio, loops de verificación de interfaz y estados fantasmas. Si estás leyendo esto porque tu consola de Firebase dice "Conectado" pero tu navegador escupe un código de error de certificado o un 500, bienvenido al club. Acá tenés la radiografía de qué falló y cómo solucionarlo sin perder la cordura.

1. La Bitácora del Desastre: Cronología de 3 Días Perdidos

Día 1: La trampa de la automatización y la confianza ciega

El despliegue del contenido estático vía Firebase CLI tomó exactamente 12 segundos. Excitado por la velocidad de la herramienta, procedí a configurar el dominio personalizado en la consola web de Firebase. La interfaz arrojó los valores estándar: dos registros A y un token TXT para validar la propiedad.

Entré a GoDaddy, pegué los registros y activé la redirección automática (forwarding) que GoDaddy ofrece alegremente en su página principal para que www.deladrillo.com apunte a la raíz. Sistema guardado. nslookup resolvió las nuevas IPs en menos de cinco minutos. Pensé: "Listo, voy a buscar un café". Al volver, el dominio principal arrojaba ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Firebase consola indicaba: “Certificado de creación”. Decidí esperar; los manuales corporativos dicen que el aprovisionamiento SSL toma tiempo.

Día 2: Entrando en la dimensión desconocida de los estados fantasma

Catorce horas después, el SSL seguía roto. Peor aún, al ingresar sin www, el servidor respondía con un error de transporte aleatorio. Decidí rehacer la configuración: borré el dominio en Firebase para reintroducirlo. Grave error. La consola de Firebase entró en un race condition: la UI web me decía que el dominio ya no existía, pero al intentar agregarlo de nuevo, saltaba un cartel rojo: "Este dominio ya está asignado a un sitio". El sistema backend de Google y su frontend de usuario se habían desincronizado. Pasé seis horas refrescando la pestaña y probando comandos de la CLI de Firebase que ya ni siquiera existen en las versiones modernas, buscando limpiar un caché invisible.

Día 3: El diagnóstico forense y la luz al final del túnel

Con las herramientas de diagnóstico de bajo nivel (dig, curl -Iv) descubrí la verdad: GoDaddy estaba resolviendo el registro de redirección interna inyectando IPs fantasmas que colisionaban con los registros A oficiales de Firebase. Además, descubrí que GoDaddy permite guardar configuraciones incompatibles bajo el capó sin validar la sintaxis de los RFCs de internet.

Tras limpiar a fondo la zona DNS, remover cada automatismo de GoDaddy, esperar a que el backend de Firebase se destrabara de su loop de bloqueo y reconfigurar todo en una secuencia de orden crítico estricta, el sitio finalmente revivió con su certificado SSL válido a última hora de la noche. Tres días de desarrollo devorados por malas abstracciones de UX.

2. Tabla de Estados: Firebase Console vs. La Realidad

Uno de los mayores dolores de cabeza durante este incidente fue la total desconexión entre lo que la interfaz de Firebase reportaba de manera amigable y lo que realmente ocurría a nivel de red.

Estado en Firebase Console	Estado Real del Servicio	Comportamiento del Navegador	Causa de Fondo
"Requires Setup" (Requiere configuración)	DNS propagando correctamente según dig @8.8.8.8	NXDOMAIN o apunta al hosting viejo.	El scraper interno de Firebase corre en intervalos fijos (15-60 min) y no lee el cambio en tiempo real.
"Certificado de creación" (Provisioning SSL)	Handshake TLS fallido en el balanceador de carga de Google.	ERR_SSL_VERSION_OR_CIPHER_MISMATCH	Let's Encrypt / Google Trust Services intentan validar el reto HTTP/DNS pero colisionan con registros viejos.
"Conectado" (Verde)	Error 500 / Transport Error	Pantalla en blanco con código de error de infraestructura.	La capa de ruteo reconoce el dominio pero el contenedor de Hosting o el balanceador no terminó de propagar los endpoints de distribución locales.
Dominio eliminado de la lista	Registro bloqueado en la base de datos central de Firebase.	deladrillo.web.app funciona; el custom da timeout.	Sincronización asincrónica lenta entre la UI y el clúster de aprovisionamiento de Edge Network.

3. Arquitectura DNS: Flujo Incorrecto vs. Flujo Correcto

Para entender por qué se rompe la configuración, hay que mirar cómo interactúan los registros a nivel de servidor. GoDaddy permite romper el protocolo DNS de forma nativa a través de su interfaz.

El Flujo Incorrecto (Lo que rompe el SSL y genera loops)

Cuando activás el "Forwarding" clásico de GoDaddy y metés registros a ciegas, obligás al servidor DNS a intentar resolver dos comportamientos contradictorios en el mismo nodo raíz:

[Usuario de Internet] 
       │
       ├───► deladrillo.com ──► [GoDaddy DNS Apex (@)] ──► DETECTA: 4 Registros A (Firebase)
       │                                                        AND DETECTA: Redirección Web Interna de GoDaddy
       │                                                        (Resultado: Conflicto / IPs aleatorias / SSL Muere)
       │
       └───► www.deladrillo.com ──► [CNAME] ──► deladrillo.web.app
                                       │
                                       └───► Envía tráfico, pero Firebase rechaza la petición 
                                             porque el dominio raíz (@) no completó el handshake SSL.

El Flujo Correcto (Soberanía y Aislamiento Estricto)

El tráfico del dominio raíz va directo y limpio a los terminales de Google a través de cuatro registros A complementarios (dos de balanceo de carga y dos de respaldo dinámico). El subdominio www se mapea limpiamente como un alias canónico (CNAME), dejando que Firebase gestione el enrutamiento interno sin la interferencia de los servidores proxy de GoDaddy.

[Usuario de Internet]
       │
       ├───► deladrillo.com ──► [DNS Apex (@)] ──► Solo 4 Registros A Directos ──► [Edge Server Google] ──► SSL Ok!
       │
       └───► www.deladrillo.com ──► [CNAME] ──► deladrillo.web.app ───────────────► [Firebase Hosting] ──► SSL Ok!

4. Problemas Estructurales Desarrollados

A. GoDaddy: UI engañosa y registros fantasma

El panel de control de GoDaddy está diseñado para usuarios que quieren comprar un dominio y delegarlo inmediatamente, no para ingenieros que requieren control granular de su infraestructura.

• Falta de Validación Estricta de Sintaxis: GoDaddy te permite configurar un registro CNAME apuntando al @ (raíz). Según la norma RFC 1034, esto es un error grave (un nombre de dominio que es un alias no puede tener otros registros asociados, y la raíz obligatoriamente necesita registros SOA y NS). GoDaddy lo acepta en su interfaz web sin lanzar una sola alerta, rompiendo la resolución de correos (MX) y del hosting de forma silenciosa.

• El Purgatorio del Forwarding: Si en algún momento activaste la opción de "Redirección de dominio" desde su menú principal, GoDaddy inyecta de forma invisible configuraciones en su zona DNS que no aparecen en la tabla estándar de registros. Aunque agregues las IPs de Firebase abajo, el reenvío de GoDaddy sigue interceptando las peticiones del puerto 443, destruyendo cualquier intento de Firebase de emitir un certificado SSL válido.

• El TTL Inamovible: Bloquear el TTL (Time To Live) en 1 hora para las cuentas estándar impide realizar pruebas ágiles. Si cometés un error en una IP, estás obligado a esperar 3600 segundos para que los resolvedores intermedios limpien la caché, ralentizando un despliegue de emergencia.

• Pestañas secundarias y falta de atomicidad: Los registros TXT de validación crítica muchas veces quedan relegados a vistas paginadas o no se aplican de manera atómica. Al no existir un botón explícito de "Confirmar cambios globales de zona", es extremadamente común guardar un registro mientras otro quedó en estado transitorio en la UI. Por favor, dejen de esconder y segmentar las tablas de configuración DNS.

B. Firebase Hosting: Falsos positivos y la caja negra del SSL

Del otro lado del puente, el ecosistema de Google no se queda atrás en problemas de experiencia de usuario.

• La Consola Miente: Ver un indicador verde que dice "Conectado" en la pestaña de Hosting es el peor falso positivo de la plataforma. Ese indicador solo significa que el validador automático de Google detectó las IPs correctas en el último escaneo que realizó. No significa que las rutas de los balanceadores edge estén actualizadas, ni que el certificado SSL se haya inyectado correctamente en los servidores proxy de distribución.

• La Caja Negra de Let's Encrypt: Cuando Firebase inicia el estado "Certificado de creación", te encontrás en una oscuridad absoluta. No hay una terminal de logs, no hay salida de errores, no hay un botón para forzar una re-verificación o leer el código de error de la entidad certificadora. Si el proceso falla porque encontró un registro DNS viejo remanente, Firebase simplemente se queda esperando en bucle hasta 24 horas antes de reintentar.

# Lo que desearías ver en tu CLI para diagnosticar:
$ firebase hosting:domains:verify deladrillo.com --verbose
[ERROR] Let's Encrypt challenge failed: CACAA record blocks validation or multiple A records detected.

# La realidad de Firebase:
> Estado: "Certificado de creación" (Espera un día a ver qué pasa...)

• La Muerte de la CLI para Dominios: En versiones anteriores de firebase-tools, los desarrolladores tenían cierto control programático. A partir de la versión 13+, los comandos de gestión de dominios personalizados fueron removidos por completo. hosting:sites:list solo te muestra los subdominios internos de la plataforma (*.web.app, *.firebaseapp.com). No hay forma humana de auditar, agregar o renovar un dominio personalizado por fuera de la consola web.

• UI Race Condition: Si debido a la desesperación borrás un dominio para intentar destrabar el proceso e inmediatamente lo volvés a escribir, el sistema colapsa. El backend tarda más tiempo en purgar el registro de sus bases de datos distribuidas que lo que tarda la UI web en enviar la nueva petición HTTP POST. El resultado es el temido error flotante: "Este dominio ya existe", obligándote a cambiar el nombre del sitio o esperar horas a que corra un proceso de recolección de basura en los servidores de Google.

5. La Secuencia Real que Funcionó (Paso a Paso sin Fricción)

Si vas a configurar esto, borrá todo lo que tenés hecho y seguí este orden estricto. No te saltes ningún paso o vas a reiniciar el temporizador de bloqueo de Firebase.

Paso 1: Limpieza Absoluta en GoDaddy

1. Entrá al panel de administración de DNS de deladrillo.com en GoDaddy.

2. Desplázate hasta la sección de Reenvío / Forwarding (tanto de dominio como de subdominio) y eliminala por completo. Si hay alguna regla activa, tu SSL nunca va a compilar.

3. Limpiá tu tabla de registros. Elimina cualquier registro A previo en el @ y cualquier CNAME que apunte a www. Deja la tabla en su estado más básico (solo los registros NS obligatorios y los SOA).

Paso 2: Inyección de la Zona DNS Correcta

Agregá los registros uno por uno. Copiá exactamente estos valores en tu tabla de GoDaddy:

Plaintext

Tipo    Nombre    Valor                                 TTL
─────────────────────────────────────────────────────────────────────
A       @         199.36.158.100                        1 Hora
A       @         199.36.158.101                        1 Hora
A       @         151.101.1.195                         1 Hora
A       @         151.101.65.195                        1 Hora
CNAME   www       deladrillo.web.app                    1 Hora
TXT     @         firebase=tu_codigo_alfanumerico_aqui  1 Hora

Nota: Firebase a veces te da solo dos IPs iniciales. Agrega las cuatro de la red Anycast de Google para asegurar redundancia global y acelerar la validación perimetral.

Paso 3: El Orden Crítico en la Consola de Firebase

1. Andá a Firebase Console -> Hosting -> Añadir dominio personalizado.

2. Ingresá únicamente el dominio raíz: deladrillo.com. No agregues el www todavía.

3. Dale a verificar. Si la tabla DNS del Paso 2 está lista, pasará a "Certificado de creación".

4. No toques nada. Esperá a que el dominio raíz cambie al estado verde de "Conectado". Esto puede tardar desde 15 minutos hasta un par de horas. Probalo abriendo una terminal y tirando: curl -Iv https://deladrillo.com.

5. Solo cuando el raíz esté conectado de verdad, volvé a hacer clic en "Añadir dominio personalizado" y agregá www.deladrillo.com. Seleccioná la opción de redirección automática si la consola te lo ofrece, o dejalo como un mapeo directo. Al estar el raíz ya validado por el backend de Google, el certificado para el subdominio www se emitirá en menos de 10 minutos.

Paso 4: La Duplicación de Validación en Google Search Console

Firebase es de Google y Search Console también, pero operan como empresas distintas que no se hablan entre sí. El token TXT de Firebase no te va a servir para indexar tu sitio.

1. Entrá a Google Search Console.

2. Añadí una nueva propiedad de tipo Prefijo de la URL: https://www.deladrillo.com.

3. Seleccioná el método de verificación por Proveedor de Nombres de Dominio.

4. Copiá el nuevo token provisto (ej. google-site-verification=...).

5. Volvé a GoDaddy y agregá un segundo registro TXT en el @. GoDaddy soporta múltiples registros TXT compartiendo el mismo nombre de host sin problemas de colisión, siempre y cuando los valores sean distintos:

Plaintext

TXT    @    firebase=AbCdEfGh...
TXT    @    google-site-verification=XyZ123...

6. Dale a verificar en Search Console y subí tu archivo sitemap.xml para consolidar el mapeo.

6. Mitos vs. Realidades en el Enrutamiento Cloud

• Mito: "Configurar un CNAME de www apuntando directamente a tu app de Firebase (deladrillo.web.app) es suficiente para resolver todo el sitio."

  • Realidad: Esto solo soluciona el tráfico que explícitamente escriba www. Si un usuario escribe deladrillo.com a secas en el navegador, la petición morirá en un timeout o resolverá a las páginas de parqueo de GoDaddy. El dominio raíz exige imperativamente los registros de tipo A apuntando a la infraestructura física de los servidores perimetrales de Google.

• Mito: "Si el SSL se traba, la mejor solución operativa es borrar el dominio en Firebase Console y volverlo a emparejar para forzar al sistema."

  • Realidad: Hacer esto casi siempre agrava el problema. Gatilla bloqueos internos por concurrencia en la API de aprovisionamiento de Firebase, arrojando errores falsos de "Dominio en uso" y estirando los tiempos de resolución por horas. Si los registros DNS son correctos según las herramientas de consola de red externa, la única solución real es esperar.

• Mito: "Google valida los cambios de DNS al instante porque son los dueños de los resolvedores 8.8.8.8."

  • Realidad: El resolvedor público de Google actualiza rápido, pero el crawler interno que utiliza el backend de Firebase Hosting corre en hilos de baja prioridad. Tu terminal local puede ver el cambio DNS reflejado en dos minutos a través de un comando dig, pero la consola de administración de Firebase puede tardar hasta una hora en enterarse y procesar el cambio.

7. Checklist de Despliegue de Dominios (Para la Próxima Vez)

Antes de mover un solo registro en producción, tacha cada uno de estos casilleros para evitar caer en el loop de los tres días de espera:

• [ ] Desactivar Forwarding: Confirmar que no existan reglas de reenvío HTTP automáticas heredadas en el registrador del dominio.

• [ ] Verificar colisiones de registros: Chequear que no existan registros A o AAAA antiguos apuntando a servidores VPS o hostings anteriores.

• [ ] Limpiar CNAMEs en la Raíz: Asegurar que ningún registro de tipo alias (CNAME) esté operando sobre el host @.

• [ ] Monitorear via herramientas externas de bajo nivel: No usar la interfaz de Firebase para comprobar la propagación. Usar herramientas reales directamente en la consola del sistema:

  Bash

  # Monitorear la propagación real de los registros A
  dig +short deladrillo.com
  
  # Validar que el CNAME del subdominio apunte al hosting base
  nslookup -type=cname www.deladrillo.com
  

• [ ] Planificar ventanas de mantenimiento extendidas: Nunca asumas que Firebase va a emitir un certificado SSL en producción en diez minutos. Configura los DNS siempre con un margen mínimo de 24 horas antes del lanzamiento oficial.

Conclusión

Firebase Hosting ofrece una de las redes de distribución de contenido estático más rápidas y estables del mercado una vez que el sistema está corriendo. Su CLI es impecable para compilar y subir archivos comprimidos en segundos. Sin embargo, su capa de abstracción para la gestión de dominios personalizados y aprovisionamiento TLS sigue operando como una versión beta de caja negra.

Al eliminar el acceso a los comandos de dominio a través de su CLI y no proveer logs detallados de los fallos de certificación, Google obliga a los desarrolladores a depender de una interfaz gráfica lenta que enmascara los errores de infraestructura detrás de etiquetas simplistas. Si combinás esa falta de visibilidad con un registrador clásico como GoDaddy —que prioriza la venta de servicios agregados y botones automatizados por sobre la rigurosidad técnica de los estándares de red— el desastre está garantizado. La única defensa ante estas plataformas es mantener el control manual estricto de tu zona DNS y recordar siempre que, en el desarrollo web moderno, las herramientas que prometen hacer todo con un solo clic son las que más tiempo te van a hacer perder en las trincheras.