[{"data":1,"prerenderedAt":218},["ShallowReactive",2],{"seo-verification":3,"blog-rollover-ksk-raiz-dnssec-2026-revisar-resolver-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-rollover-ksk-raiz-dnssec-2026-revisar-resolver-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":162,"ctaBody":163,"ctaButton":164,"ctaUrl":165,"relatedPosts":166},493,"rollover-ksk-raiz-dnssec-2026-revisar-resolver",{"fr":12,"en":13,"ar":14,"es":10},"rollover-ksk-racine-dns-2026-dnssec-resolveurs","root-dnssec-ksk-rollover-2026-check-your-resolver","تغيير-مفتاح-الجذر-dnssec-2026-فحص-المحلل","Rollover de la KSK raíz de DNSSEC: revise su resolver","La raíz DNS ya está firmada por KSK-2024 (key tag 38696). Compruebe el ancla de confianza de Unbound, BIND, Knot Resolver, systemd-resolved o dnsmasq y corríjala.",12,0,false,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Frollover-ksk-racine-dns-2026-dnssec-resolveurs-poster.svg","Desde el 11 de octubre de 2026, la zona raíz del DNS está firmada por una nueva clave, KSK-2024, con key tag 38696. Un resolver validador que no conoce esta clave ya no puede construir la cadena de confianza DNSSEC: responde SERVFAIL, incluso para nombres que funcionan en otros sitios, y la avería parece un corte de red. Esta guía muestra cómo comprobar en diez minutos el ancla de confianza de Unbound, BIND, Knot Resolver, systemd-resolved y dnsmasq, demostrarlo con `dig` y `delv`, y después corregirlo.",[35,39,49,52,55,80,116,140,143,147,150,159],{"type":36,"title":37,"body":38},"h2","Qué cambió el 11 de octubre de 2026","DNSSEC se apoya en una única raíz de confianza: la clave de firma de claves (KSK) de la zona raíz. Cada resolver validador guarda una copia local, llamada ancla de confianza, y verifica todo lo demás a partir de ella. Según IANA, KSK-2024 (key tag 38696) se publicó en la zona raíz el 11 de enero de 2025 y empezó a firmar la raíz el 11 de octubre de 2026, en lugar de KSK-2017 (key tag 20326).\n\nEl 15 de octubre de 2026, ICANN anunció que el cambio de clave había concluido según lo previsto. El anuncio menciona informes que afectan a un número limitado de sistemas y precisa que ICANN aún evalúa si están relacionados con el cambio: no da ni cifra ni causa, y esta guía tampoco las sugiere. El calendario no ha terminado: IANA prevé revocar KSK-2017 el 11 de enero de 2027 y retirarla de la zona el 22 de marzo de 2027.",{"type":40,"title":41,"items":42},"ul","Lo que hay que recordar",[43,44,45,46,47,48],"**La clave que buscar** — KSK-2024, key tag 38696, algoritmo 8 (RSA\u002FSHA-256). La anterior, KSK-2017, tiene el key tag 20326.","**El síntoma** — un resolver que solo confía en 20326 ya no puede validar la raíz. Verisign e ICANN advierten que entonces deja de resolver, esté firmado o no el nombre solicitado.","**El mecanismo normal** — el RFC 5011 permite a un resolver adoptar por sí solo una nueva clave tras observarla 30 días, siempre que esté en marcha y pueda escribir su archivo de ancla.","**Los casos de riesgo** — una imagen de sistema o una instantánea más antigua que la clave, un archivo de ancla de solo lectura, un ancla estática en dnsmasq o en BIND.","**Lo que no cambia** — el registro DS de su dominio en el registro: el cambio afecta a la clave de la raíz, no a la de su zona.","**Lo que viene** — revocación de KSK-2017 prevista para el 11 de enero de 2027, retirada el 22 de marzo de 2027. Un resolver que ya confía en 38696 valida la raíz firmada con esa clave.",{"type":36,"title":50,"body":51},"Propietario de dominio o administrador de servidor: quién debe actuar","Dos funciones se confunden a menudo en los tickets. El propietario de un dominio firmado publica un registro DS en el registro, que designa la clave de SU zona. Ese DS no depende de la clave de la raíz: no hay nada que cambiar por este rollover, ni en la zona de `example.com` ni en su registrador. Si solo gestiona sus registros (consulte \u003Ca href=\"\u002Fblog\u002Fajouter-enregistrement-dns-domaine\">añadir un registro DNS\u003C\u002Fa>), no le afecta.\n\nAl administrador de un servidor que ejecuta un resolver validador, sí. Unbound detrás de un servidor de correo, BIND en un servidor de supervisión, Knot Resolver en un contenedor, systemd-resolved con DNSSEC activado, dnsmasq o Pi-hole con la validación activada: cada uno lleva su propia ancla. En un VPS con acceso root, ese administrador es usted. Un servidor que simplemente reenvía sus consultas a un resolver público sin validar depende del ancla de ese resolver, no de la suya.",{"type":36,"title":53,"body":54},"Requisitos previos del diagnóstico","Reserve diez minutos y acceso root o sudo al servidor. Bastan dos herramientas: `dig` y `delv`, incluidas en Debian y Ubuntu en el paquete `bind9-dnsutils` (`sudo apt install bind9-dnsutils`), y en AlmaLinux o Rocky Linux en `bind-utils`. No se necesitan recursos particulares: las consultas pesan unos pocos kilobytes.\n\nAnote la dirección de escucha de su resolver, normalmente `127.0.0.1`, o `127.0.0.53` para systemd-resolved, y tenga a mano la dirección de un resolver público validador para comparar, por ejemplo `9.9.9.9`. Las salidas descritas a continuación son ejemplos de forma, no mediciones de su servidor: solo cuentan los campos nombrados. Las pruebas apuntan a la raíz y a `com.`, dos zonas firmadas, así que no dependen de ningún dominio concreto.",{"type":56,"title":57,"steps":58},"steps","Diagnosticar su resolver en siete pasos",[59,62,65,68,71,74,77],{"title":60,"body":61},"Identificar el resolver que responde","`cat \u002Fetc\u002Fresolv.conf` muestra la dirección que consulta el sistema, `resolvectl status` indica si systemd-resolved se interpone, y `sudo ss -lunp 'sport = :53'` nombra el proceso que escucha en el puerto 53: `unbound`, `named`, `kresd`, `dnsmasq` o `pihole-FTL`. Ese es el proceso que va a examinar.",{"title":63,"body":64},"Consultar la raíz con dig +dnssec","Ejecute `dig +dnssec . SOA @127.0.0.1` y después `dig +dnssec com. SOA @127.0.0.1`. Fíjese en dos campos de la cabecera: `status:` y `flags:`. Un `status: NOERROR` con la bandera `ad` significa que la respuesta se ha validado. Un `status: SERVFAIL` en la propia raíz es la señal más clara de un ancla obsoleta.",{"title":66,"body":67},"Aislar la validación con +cd","`dig +dnssec +cd com. SOA @127.0.0.1` pide al resolver que responda sin validar (checking disabled). Si esta consulta devuelve `NOERROR` mientras la anterior falla con `SERVFAIL`, la red y los servidores superiores funcionan: lo que bloquea es la validación DNSSEC, es decir, el ancla o el reloj.",{"title":69,"body":70},"Comparar con un resolver público validador","`dig +dnssec com. SOA @9.9.9.9` debe responder `NOERROR` con `ad`. Si el resolver público valida y el suyo no, el problema es local. Compruebe de paso la hora del servidor con `timedatectl`: un reloj desfasado también hace fallar la verificación de las firmas y produce el mismo SERVFAIL.",{"title":72,"body":73},"Ver qué clave firma la raíz","`dig +dnssec +multi . DNSKEY @9.9.9.9` muestra las claves publicadas. Las de flag `257` son las KSK; con `+multi`, dig añade su `key id` como comentario. En la fase actual, KSK-2017 sigue publicada, pero la firma (RRSIG) del conjunto de claves lleva el key tag 38696: esa es la clave que su ancla debe conocer.",{"title":75,"body":76},"Leer el ancla realmente cargada","Unbound: `sudo grep 'id = 38696' \u002Fvar\u002Flib\u002Funbound\u002Froot.key` (ruta de Debian; en otros sistemas, `unbound-checkconf -o auto-trust-anchor-file` da la suya) debe devolver una línea marcada `VALID`. BIND: `sudo rndc secroots -` debe listar `.\u002FRSASHA256\u002F38696 ; managed`, y `sudo rndc managed-keys status` una entrada `keyid: 38696` seguida de `trusted since`. Knot Resolver: llame a `trust_anchors.summary()` desde su consola de control. dnsmasq: busque una línea `trust-anchor=.,38696,8,2,…` en la configuración cargada.",{"title":78,"body":79},"Confirmar con delv","`delv @127.0.0.1 com. SOA` valida la respuesta por sí mismo y muestra `; fully validated` cuando la cadena está completa. Atención: delv usa el ancla compilada en su propio binario, no la de su resolver. Un delv antiguo puede, por tanto, fallar por su cuenta: actualice el paquete antes de sacar conclusiones sobre el resolver.",{"type":81,"title":82,"headers":83,"rows":87},"comparison","Dónde vive el ancla de confianza, resolver por resolver",[84,85,86],"Resolver","Dónde mirar","Actualización de la clave",[88,92,96,100,104,108,112],[89,90,91],"Unbound","Directiva `auto-trust-anchor-file` (Debian: `\u002Fvar\u002Flib\u002Funbound\u002Froot.key`)","RFC 5011 si el archivo y su directorio admiten escritura; si no, `unbound-anchor`",[93,94,95],"BIND","`rndc secroots -` y `managed-keys.bind`; ancla integrada con `dnssec-validation auto`","RFC 5011 con `auto`, `initial-key` o `initial-ds`; ninguna con `static-key`",[97,98,99],"Knot Resolver","`trust_anchors.add_file()` en v5, `dnssec\u002Ftrust-anchors-files` en v6","RFC 5011, salvo si el archivo se declara de solo lectura",[101,102,103],"systemd-resolved","Ancla integrada en el binario; archivos `*.positive` de `\u002Fetc\u002Fdnssec-trust-anchors.d\u002F`","Ninguna por DNS: hace falta un paquete systemd actualizado",[105,106,107],"dnsmasq","Líneas `trust-anchor=` de la configuración cargada","Ninguna: línea estática que se edita a mano",[109,110,111],"Pi-hole v6","`\u002Fetc\u002Fpihole\u002Fdnsmasq.conf`, generado por FTL","Reescrito por FTL, que inscribe las claves 20326 y 38696",[113,114,115],"delv (herramienta)","Ancla compilada en el binario","Actualización del paquete que lo proporciona",{"type":56,"title":117,"steps":118},"Corregir según su resolver",[119,122,125,128,131,134,137],{"title":120,"body":121},"Unbound: refrescar el ancla","Actualice primero el sistema (`sudo apt update && sudo apt upgrade`). En Debian, el paquete `dns-root-data` proporciona `\u002Fusr\u002Fshare\u002Fdns\u002Froot.key`, y el script de arranque de Unbound copia ese archivo a `\u002Fvar\u002Flib\u002Funbound\u002Froot.key` cuando es más reciente; la versión `2024071801~deb12u1` publicada para Debian 12 ya contiene KSK-2024. Después fuerce la comprobación con `sudo -u unbound unbound-anchor -a \u002Fvar\u002Flib\u002Funbound\u002Froot.key -v` y `sudo systemctl restart unbound`. La clave integrada en `unbound-anchor` incluye KSK-2024 desde Unbound 1.21.0.",{"title":123,"body":124},"Unbound: hacer posible el RFC 5011","Si la clave sigue faltando, compruebe que el usuario `unbound` puede escribir el archivo Y su directorio: la documentación lo exige para crear un archivo temporal. `ls -ld \u002Fvar\u002Flib\u002Funbound \u002Fvar\u002Flib\u002Funbound\u002Froot.key` basta para verlo. Un archivo montado en solo lectura en un contenedor bloquea la actualización automática sin ningún error visible para el cliente.",{"title":126,"body":127},"BIND: auto o ancla declarada","Con `dnssec-validation auto;`, BIND parte del ancla incluida en el software y la mantiene al día mediante el RFC 5011 en `managed-keys.bind`. Actualice el paquete, compruebe que `named` puede escribir en `managed-keys-directory` y ejecute `sudo rndc managed-keys refresh`. Con `dnssec-validation yes;` y un ancla declarada a mano, añada al bloque `trust-anchors` la línea `. initial-ds 38696 8 2 \"683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16\";` y retire cualquier ancla `static-key` que solo conozca 20326.",{"title":129,"body":130},"Knot Resolver: revisar el archivo de ancla","Actualice el paquete y mire cómo se declara el archivo de ancla. Si es de solo lectura (segundo argumento `true` de `trust_anchors.add_file()` en v5, `read-only: true` en v6), el resolver nunca lo modifica: es el paquete de su distribución el que debe aportar la clave. Si no, compruebe que `kresd` puede escribir el archivo. La documentación indica que, si el archivo no existe, el resolver intenta inicializar por sí mismo el ancla de la raíz.",{"title":132,"body":133},"systemd-resolved: actualizar systemd","systemd-resolved no actualiza su ancla por DNS: solo una actualización del paquete aporta la nueva clave. El código original la integra, en particular desde systemd 256.12 y 257.4, y el paquete `systemd-resolved` actual de Debian 12 también la contiene. Revise `\u002Fetc\u002Fdnssec-trust-anchors.d\u002F`: un archivo `*.positive` que declara una clave raíz desactiva el ancla integrada. Elimínelo o añádale la clave 38696, y después ejecute `sudo systemctl restart systemd-resolved` y `resolvectl flush-caches`.",{"title":135,"body":136},"dnsmasq: añadir la línea estática","dnsmasq no aplica el RFC 5011: el ancla es una línea fija. Añada `trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16` junto a la línea 20326 y reinicie el servicio. En Debian 12, el archivo `\u002Fusr\u002Fshare\u002Fdnsmasq-base\u002Ftrust-anchors.conf` del paquete `dnsmasq-base` 2.90-4~deb12u2 solo contiene la clave 20326, mientras que el de Debian 13 contiene las dos: compruebe qué archivo carga realmente su configuración. Pi-hole v6 escribe él mismo las dos líneas en `\u002Fetc\u002Fpihole\u002Fdnsmasq.conf` cuando la validación DNSSEC está activada.",{"title":138,"body":139},"Automatizar para la próxima vez","Un ancla solo caduca en un servidor que ha dejado de actualizarse. Active las actualizaciones automáticas de seguridad de los paquetes de resolver (consulte \u003Ca href=\"\u002Fblog\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu\">actualizaciones automáticas en Debian y Ubuntu\u003C\u002Fa>) y añada a su supervisión una sonda `dig +dnssec com. SOA @127.0.0.1` que alerte ante un `SERVFAIL`. Si su DNS local pasa por Pi-hole, la guía \u003Ca href=\"\u002Fblog\u002Fpihole-v6-dns-bloquer-pubs-vps-2026\">Pi-hole v6 en un VPS\u003C\u002Fa> muestra cómo colocar Unbound por encima.",{"type":36,"title":141,"body":142},"Después de la corrección: qué vigilar","Una vez que la bandera `ad` vuelve a las respuestas, tres puntos merecen una comprobación.\n\nPrimero, las imágenes y las instantáneas. Una máquina restaurada desde una copia de seguridad antigua arranca con el archivo de ancla de entonces. Si ese archivo solo conoce 20326, el RFC 5011 ya no puede ponerlo al día: solo acepta una nueva clave si el conjunto de claves está firmado por una clave ya aprobada, y la raíz ya no está firmada por 20326. Hay que refrescar el ancla a mano, como se indica más arriba.\n\nDespués, las imágenes de contenedores. Una imagen construida con un ancla estática la conserva en cada redespliegue: reconstrúyala a partir de una base actualizada.\n\nPor último, la revocación. El 11 de enero de 2027 está previsto publicar KSK-2017 con el bit de revocación. Un resolver que sigue el RFC 5011 la marcará como revocada: en el archivo de Unbound, la línea 20326 pasará al estado `REVOKED`. Es el estado esperado, no una avería.",{"type":144,"title":145,"body":146},"tip","No desactive la validación para silenciar el error","Pasar a `dnssec-validation no`, `val-permissive-mode: yes` o `DNSSEC=no` hace desaparecer el SERVFAIL, pero también elimina toda protección contra respuestas falsificadas. Corrija el ancla y después pruebe. No pegue nunca una clave encontrada en un foro: la fuente de referencia es `https:\u002F\u002Fdata.iana.org\u002Froot-anchors\u002Froot-anchors.xml`, cuya firma se verifica con `root-anchors.p7s` e `icannbundle.pem`, publicados en el mismo lugar por IANA. El resumen SHA-256 de KSK-2024 figura allí: `683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16`.",{"type":36,"title":148,"body":149},"Solución de problemas: los mensajes que verá","Los mensajes siguientes proceden del código fuente o de la documentación de los programas afectados. Permiten distinguir un ancla obsoleta de un problema de red, de un reloj desfasado o de una herramienta de diagnóstico demasiado antigua. En Unbound, aumente primero el detalle de los registros con `val-log-level: 2` en la sección `server:` y reinicie: cada consulta rechazada quedará registrada con su motivo y el servidor que proporcionó el dato erróneo.",{"type":40,"title":151,"items":152},"Mensajes de error y soluciones",[153,154,155,156,157,158],"**`failed to prime trust anchor -- DNSKEY rrset is not secure`** (registro de Unbound, seguido de `. DNSKEY IN`) — Unbound obtuvo las claves de la raíz pero no pudo validarlas con su ancla: ancla obsoleta o reloj incorrecto. Refresque `root.key`.","**`failed to prime trust anchor -- could not fetch DNSKEY rrset`** — Unbound ni siquiera obtiene las claves de la raíz: red, cortafuegos o fragmentación UDP, no el ancla. Pruebe `dig +dnssec . DNSKEY` contra el servidor superior.","**`status: SERVFAIL` con `+dnssec`, `NOERROR` con `+cd`** — la firma de un fallo de validación. Con `ede: yes` en Unbound, el cliente recibe además un código de error extendido (RFC 8914).","**`resolution failed: broken trust chain`** o **`no valid RRSIG`** (delv) — delv no pudo remontar hasta un ancla válida. Compruebe primero que delv está actualizado.","**`; initializing managed`** en `rndc secroots -` — BIND conoce la clave pero nunca la confirmó con una consulta de actualización. Ejecute `rndc managed-keys refresh` y revise los permisos de `managed-keys-directory`.","**`unbound-anchor` termina con el código 0 sin cambiar nada** — según su página de manual, 0 significa tanto «no hacía falta actualizar» como «error». Vuelva a ejecutarlo con `-v` y relea el archivo.",{"type":36,"title":160,"body":161},"En resumen","El cambio de clave de la raíz no exige nada a los propietarios de dominios, ni a los servidores cuyos paquetes siguen las actualizaciones. Penaliza a los resolvers congelados: una imagen antigua, un archivo de ancla sin permiso de escritura, un ancla estática en dnsmasq o BIND. Tres acciones bastan para decidir: `dig +dnssec com. SOA` contra su resolver, la misma consulta con `+cd` y la lectura del ancla cargada. Tenga presente la fecha del 11 de enero de 2027: la revocación de KSK-2017 aparecerá en sus archivos de ancla, y es un estado esperado. En un servidor con acceso root, esta comprobación lleva diez minutos y se programa de una vez por todas en su supervisión.","Su resolver, su ancla de confianza","En un VPS ServOrbit.com, usted dispone de acceso root: elige su sistema, actualiza sus paquetes de resolver cuando lo decide y lee usted mismo los registros de validación. Si prefiere no ocuparse de ello, existe la opción de administración del VPS.","Descubrir los VPS","\u002Fvps-cloud",[167,183,200],{"id":168,"slug":169,"slugs":170,"title":174,"excerpt":175,"readTime":176,"views":18,"isPinned":19,"publishedAt":177,"updatedAt":178,"category":179,"categories":180,"featuredImage":30,"bgImage":31,"posterImage":182,"relatedSolution":30},416,"pihole-v6-dns-bloquear-publicidad-vps-2026",{"fr":171,"en":172,"ar":173,"es":169},"pihole-v6-dns-bloquer-pubs-vps-2026","pihole-v6-dns-block-ads-vps-2026","pihole-v6-dns-حجب-الإعلانات-vps-2026","Pi-hole v6 en un VPS: bloquea anuncios y rastreadores a nivel DNS","Despliega Pi-hole v6 en tu VPS con Docker Compose, asegura tu resolver DNS y bloquea anuncios y rastreadores para todos tus servicios autoalojados.",13,"2026-10-05T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[181],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fpihole-v6-dns-bloquer-pubs-vps-2026-poster.svg",{"id":184,"slug":185,"slugs":186,"title":190,"excerpt":191,"readTime":192,"views":193,"isPinned":19,"publishedAt":194,"updatedAt":195,"category":196,"categories":197,"featuredImage":30,"bgImage":31,"posterImage":199,"relatedSolution":30},382,"actualizaciones-seguridad-vps-debian-ubuntu",{"fr":187,"en":188,"ar":189,"es":185},"securite-vps-mises-a-jour-automatiques-debian-ubuntu","vps-automatic-security-updates-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","Actualizaciones de seguridad automáticas en VPS Debian\u002FUbuntu","Configure unattended-upgrades en sus VPS Debian\u002FUbuntu para automatizar los parches de seguridad y reducir la superficie de ataque en su flota de clientes.",10,2,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[198],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",{"id":201,"slug":202,"slugs":203,"title":207,"excerpt":208,"readTime":193,"views":18,"isPinned":19,"publishedAt":209,"updatedAt":210,"category":211,"categories":215,"featuredImage":30,"bgImage":31,"posterImage":217,"relatedSolution":30},447,"anadir-registro-dns-dominio",{"fr":204,"en":205,"ar":206,"es":202},"ajouter-enregistrement-dns-domaine","add-edit-dns-record-domain","إضافة-أو-تعديل-سجل-dns-للنطاق","Añadir o modificar un registro DNS (A, CNAME, MX, TXT)","Cree, modifique o elimine un registro DNS (A, AAAA, CNAME, MX, TXT) en la zona gestionada de su dominio, desde el área de cliente.","2026-10-16T00:00:00+00:00","2026-10-16T01:57:35+00:00",{"id":17,"name":212,"slug":213,"color":214,"icon":213},"Guías","guides","bg-emerald-500\u002F10 text-emerald-400",[216],{"id":17,"name":212,"slug":213,"color":214,"icon":213},"\u002Fblog\u002Fcovers\u002Fajouter-enregistrement-dns-domaine-poster.svg",1792763326812]