Problema

En entornos Fedora (y, en general, cualquier distribución basada en RPM) es frecuente ejecutar dnf upgrade --refresh para mantener el sistema actualizado. Cuando el gestor de paquetes intenta descargar un paquete de un repositorio externo y la resolución DNS falla, la operación se interrumpe. El síntoma típico es un mensaje similar a:

Curl error (6): Could not resolve hostname for http://ciscobinary.openh264.org/...
Librepo error: Cannot download ... All mirrors were tried

Aunque el resto de los repositorios (Fedora, RPM Fusion, Brave, VS Code, etc.) funcionan sin problemas, uno o dos repositorios externos pueden quedar inaccesibles. El fallo no está limitado a OpenH264; cualquier URL que dependa de un servidor externo puede presentar el mismo comportamiento.

Causa

Los errores de resolución de host pueden deberse a varias causas, y es importante descartarlas en orden lógico:

  1. Problemas de DNS local

    • El resolvedor configurado (systemd‑resolved, NetworkManager o un DNS estático) no puede contactar al servidor DNS o recibe una respuesta REFUSED.
    • Algunas redes Wi‑Fi aplican filtros DNS o redirigen peticiones a servidores internos que bloquean dominios externos.

  2. Bloqueo a nivel de red

    • Firewalls de la red (router, ISP, o política de empresa) pueden bloquear el dominio o la IP del servidor.
    • En entornos con captive portal, la primera petición HTTP se redirige a una página de autenticación y la resolución DNS parece fallar.

  3. Problemas en el servidor remoto

    • El propio host ciscobinary.openh264.org puede estar caído, sobrecargado o haber cambiado de IP sin actualizar los registros DNS.
    • Cambios de certificación o de política de acceso pueden hacer que el servidor responda con REFUSED a consultas de ciertos rangos IP.

  4. Cache DNS corrupta

    • systemd‑resolved mantiene una caché en memoria; una entrada errónea persiste hasta que expira o se reinicia el servicio.
    • Herramientas como dnsmasq o unbound pueden almacenar respuestas negativas.

  5. Configuración de proxy

    • Si el entorno usa un proxy HTTP/HTTPS y la variable http_proxy está mal definida, dnf intentará resolver el host directamente y fallará.

Solución

A continuación se describe un proceso genérico que cubre la mayoría de los escenarios. Cada paso es opcional; se detiene cuando el problema desaparece.

1. Verificar la conectividad básica

ping -c 3 8.8.8.8
curl -I https://ciscobinary.openh264.org

Si el ping a una IP pública funciona pero curl a la URL falla, el problema está en la resolución DNS, no en la conectividad IP.

2. Comprobar la resolución DNS

dig +short ciscobinary.openh264.org
nslookup ciscobinary.openh264.org
  • Si la respuesta es vacía o muestra REFUSED, el servidor DNS está rechazando la consulta.
  • Prueba con un DNS público diferente (Google 8.8.8.8, Cloudflare 1.1.1.1) para descartar problemas locales:
systemd-resolve --set-dns=1.1.1.1 --interface=$(nmcli -t -f DEVICE,TYPE dev status | grep wifi | cut -d: -f1)

Luego repite dig.

3. Limpiar la caché DNS

sudo systemctl restart systemd-resolved

En sistemas que usan dnsmasq o unbound:

sudo systemctl restart dnsmasq
# o
sudo systemctl restart unbound

4. Forzar una actualización del repositorio

sudo dnf clean all
sudo dnf makecache --refresh

Esto elimina metadatos corruptos y fuerza a dnf a volver a descargar los archivos de índice.

5. Desactivar temporalmente el repositorio problemático

Si la falla persiste y necesitas completar la actualización, puedes excluir el paquete o desactivar el repo:

sudo dnf upgrade --refresh --exclude=mozilla-openh264
# o
sudo dnf config-manager --set-disabled openh264

Una vez que el resto del sistema esté actualizado, vuelve a habilitar el repo y vuelve a intentar la descarga.

6. Revisar la configuración de proxy

echo $http_proxy $https_proxy

Si aparecen variables, verifica que apunten a un proxy activo. En caso de duda, elimínalas temporalmente:

unset http_proxy https_proxy

7. Cambiar de red o interfaz

Como indica el caso original, cambiar de Wi‑Fi resolvió el problema. Esto sugiere que la red original tenía filtrado DNS o bloqueos a nivel de ISP. Si la solución es viable, usa una red alternativa o solicita al administrador de red que desbloquee el dominio.

8. Verificar el estado del servidor remoto

Accede a la página de estado de Cisco OpenH264 o revisa foros oficiales. Si el dominio está caído, la única opción es esperar o usar un espejo alternativo (por ejemplo, descargar el RPM manualmente y colocarlo en /var/cache/dnf).

Cuándo aplicar esta solución

  • Síntomas: dnf se detiene en un paquete, muestra “Could not resolve hostname” o “REFUSED”. Otros repositorios funcionan.
  • Entorno: Fedora, RHEL, CentOS, Rocky Linux u otras distros basadas en dnf/yum que usan repositorios externos.
  • No aplicar: Si el error es “Checksum mismatch” o “GPG key error”, el problema no es DNS y esta guía no cubre esas causas.
  • Escenarios válidos: redes corporativas con DNS interno, conexiones móviles con DNS sobre TLS, entornos domésticos donde el router usa DNS de ISP que bloquea ciertos dominios.

Código

# 1. Verificar conectividad
ping -c 3 8.8.8.8
curl -I https://ciscobinary.openh264.org

# 2. Diagnóstico DNS
dig +short ciscobinary.openh264.org
nslookup ciscobinary.openh264.org

# 3. Cambiar a DNS público
sudo systemd-resolve --set-dns=1.1.1.1 --interface=$(nmcli -t -f DEVICE,TYPE dev status | grep wifi | cut -d: -f1)

# 4. Limpiar caché DNS y dnf
sudo systemctl restart systemd-resolved
sudo dnf clean all
sudo dnf makecache --refresh

# 5. Excluir temporalmente el paquete problemático
sudo dnf upgrade --refresh --exclude=mozilla-openh264

Verificación

  1. Ejecuta sudo dnf upgrade --refresh.
  2. La salida debe avanzar más allá del paquete OpenH264 sin detenerse.
  3. Confirma que la resolución DNS devuelve una dirección IP válida con dig.
  4. Opcional: verifica que el paquete se haya descargado correctamente inspeccionando /var/cache/dnf o ejecutando dnf info mozilla-openh264.

Notas adicionales

  • Cache de navegador: si descargaste el RPM manualmente, colócalo en /var/cache/dnf y ejecuta sudo dnf install mozilla-openh264-*.rpm. Esto evita una nueva consulta DNS.
  • Política de DNSSEC: algunos routers bloquean dominios que fallan la validación DNSSEC. Desactivar temporalmente DNSSEC en el router puede ser una solución rápida, aunque reduce la seguridad.
  • Automatización: incluye un script de diagnóstico en tu toolbox de sysadmin para ejecutar los pasos de 1 a 4 automáticamente y obtener un informe rápido.
  • Registro de cambios: mantén un registro de cuándo cambias de DNS o desactivas repositorios; facilita la trazabilidad en auditorías.