Skip to main content
Resources

Actualización de los resolutores de validación del DNS con el ultimo anclaje de confianza

Esta página está disponible en:

Este documento ha sido traducido a varios idiomas como información únicamente. El texto original y válido (en inglés) se puede obtener en: https://www.icann.org/dns-resolvers-updating-latest-trust-anchor

Esta página está destinada a los administradores de resolutores del DNS (en ocasiones, denominados "resolutores recursivos"). La información que se incluye aquí es útil si:

  • los operadores de dichos resolutores descubren que no tienen instalado la nueva KSK
  • esos resolutores están dando errores para todas las solicitudes del DNS después del traspaso de KSK

Estas instrucciones probablemente conduzcan al uso del último anclaje de confianza para la validación de DNSSEC.

Hay un documento complementario que describe cómo verificar si está utilizando los últimos anclajes de confianza; puede encontrarlo aquí. Puede encontrar más información sobre el traspaso de KSK aquí.

Para probar si el resolutor que opera está o no realizando la validación de DNSSEC, puede utilizar el dominio especial "dnssec-failed.org" que Comcast utiliza como servicio público. Este dominio especial hará que los resolutores validados deliberadamente no den una respuesta. Especifique el siguiente comando en una línea de comandos de shell:

dig @ADDRESS dnssec-failed.org a +dnssec

En ese comando, reemplace la cadena de caracteres ADDRESS con la dirección IPv4 o IPv6 del resolutor que opera.

Si la respuesta incluye lo siguiente:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

el resolutor está realizando la validación de DNSSEC. (La indicación de estado de SERVFAIL aquí indica que la validación falló, lo que significa que la validación, de hecho, está ocurriendo).

Si, en cambio, la respuesta incluye lo siguiente:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

el resolutor no está realizando la validación de DNSSEC.

El resto de esta página enumera diversas implementaciones del resolutor y las instrucciones necesarias para actualizarlas.


BIND

Las versiones 9.9, 9.10 y 9.11 de BIND admiten la validación de DNSSEC con la actualización automática de RFC 5011. Las últimas subversiones de estas versiones vienen con KSK2017 como parte de los anclajes de confianza.

Primero verifique que la validación de DNSSEC esté establecida en su archivo de configuración. Debería ver una línea en la sección options que indica dnssec-validation auto; o dnssec-validation yes;. Si tiene dnssec-validation configurado en auto, no necesita actualizar su software o configuración. Simplemente debe reiniciar el software, mediante cualquier comando que utilice normalmente para detener e iniciar BIND; esto incorporará los últimos anclajes de confianza para dnssec-validation auto.

Si su configuración muestra dnssec-validation yes;, usted debe cambiarla a dnssec-validation auto; y reiniciar el servidor antes de realizar los pasos que se indican a continuación.

Si puede actualizar su software:

  1. Actualice a la última subversión de BIND 9.9, BIND 9.10 o BIND 9.11 con el método que utilizó para instalar el software. Si está ejecutando BIND 9.8, ya no es un software compatible, y necesita actualizar a BIND 9.9 o posterior. Desea una subversión de al menos:
    • BIND 9.9.10
    • BIND 9.10.5
    • BIND 9.11.1
  2. En su archivo de configuración, asegúrese de que la sección options tenga una línea que dice dnssec-validation auto;.
  3. Detenga la versión anterior de BIND e inicie la nueva versión, con cualquier comando que utilice normalmente para detener e iniciar BIND.

Si no puede actualizar su software:

  1. Actualice el archivo bind.keys para incluir el nuevo anclaje de confianza. El archivo bind.keys debería almacenarse en el mismo directorio donde se crean los otros archivos de BIND. De forma alternativa, si su archivo named.conf tiene una sección managed-keys que enumere los anclaje de confianza, puede actualizar esa sección. El archivo revisado o la sección de configuración debería contener lo siguiente:

    managed-keys { 
    . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF 
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX 
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD 
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz 
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS 
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq 
    QxA+Uk1ihz0="; 
    
    . initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    R1AkUTV74bU="; 
    };
    

Si la configuración tiene dnssec-validation definido en auto, el contenido del archivo bind.keys se combinará con el contenido del bloque managed-keys en la configuración. Se puede obtener más información sobre Microsoft en https://www.isc.org/downloads/bind/bind-keys/.

ISC, los creadores de BIND, tienen información adicional sobre los anclajes de confianza de DNSSEC para BIND en https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html.


Unbound

Sin embargo, todas las versiones de Unbound anteriores a 1.6.5 tienen una limitación que les impide aceptar el nuevo anclaje de confianza si la versión se inicia por primera vez 30 días o más antes del traspaso.

Si está ejecutando la versión 1.6.5 de Unbound o una posterior:

  1. Elimine los anclajes de confianza actuales con:

    rm root.key
  2. Obtenga la última versión de los anclajes de confianza con:

    unbound-anchor
  3. Reinicie Unbound para que vuelva a cargar la nueva configuración, con cualquier comando que utilice normalmente para iniciar Unbound.

Si está ejecutando la versión 1.6.4 de Unbound o una anterior, y puede actualizar su software:

  1. Actualice a la versión 1.6.5 de Unbound o alguna posterior.

  2. Elimine los anclajes de confianza actuales con:

    rm root.key
  3. Obtenga la última versión de los anclajes de confianza con:

    unbound-anchor
  4. Reinicie la nueva versión de Unbound para que vuelva a cargar la nueva configuración, con cualquier comando que utilice normalmente para iniciar Unbound.

Si está ejecutando la versión 1.6.4 de Unbound o una anterior, y una de las claves en el archivo root.key no aparece como [ VALID ], y no puede actualizar su software:

  1. Consulte la página https://www.unbound.net/root-11sep-11oct.html para obtener información sobre cómo obtener un nuevo archivo root.key de NLnet Labs con ambas claves configuradas en [ VALID ].
  2. Reinicie Unbound para que vuelva a cargar la nueva configuración, con cualquier comando que utilice normalmente para iniciar Unbound.

PowerDNS Recursor

PowerDNS Recursor versión 4 admite la validación de DNSSEC, pero aún no admite la validación de DNSSEC con la actualización automática de RFC 5011. Esto significa que para PowerDNS Recursor, necesita obtener un nuevo conjunto de anclajes de confianza cada vez que cambien los anclajes de confianza. La versión 4.0.5 y posteriores de PowerDNS Recursor vienen con KSK2017 como parte de los anclajes de confianza instalados.

Si puede actualizar su software:

  1. Actualice a la última subversión de PowerDNS Recursor con el método que utilizó para instalar el software. Asegúrese de que la versión obtenida sea 4.0.5 o posterior.
  2. Salga de la versión actual de Recursor PowerDNS e inicie la nueva, con el método que utilice normalmente para detener e iniciar el servidor.

Si no puede actualizar su software:

  1. Si aún no tiene una línea lua-config-file en la configuración principal de su PowerDNS, debe agregarla. La línea apunta a un archivo que contiene configuración adicional de PowerDNS. Esta línea podría verse así:

    lua-config-file=/etc/pdns/luaconf.txt
  2. En el archivo señalado por la línea lua-config-file, agregue las siguientes dos líneas:

    addDS('.', "19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5")
    addDS('.', "20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")
    
  3. Reinicie PowerDNS Recursor con cualquier método que normalmente utilice para detener e iniciar el servidor.


Resolutor Knot

El Resolutor Knot admite la validación de DNSSEC utilizando la actualización automática RFC 5011 en todas las versiones. Para obtener la última versión de los anclajes de confianza, puede eliminar su versión actual del archivo con las claves e iniciar de nuevo el Resolutor Knot. Por lo tanto, no necesita actualizar su versión del Resolutor Knot; simplemente necesita obtener los últimos anclajes de confianza y reiniciar el Resolutor Knot.

  1. En el archivo de configuración, asegúrese de que haya una línea que diga:

    trust_anchors.file = 'root.keys'
  2. Si ese archivo no contiene una línea que contenga 19036 y 20326, detenga el servidor utilizando cualquier método que utilice normalmente, elimine el archivo root.keys y vuelva a iniciar el servidor. Esto hará que el Resolutor Knot recree el archivo con los últimos anclajes de confianza de la IANA.


Windows Server 2012R2 y 2016

Windows Server, tanto 2012R2 como 2016, admite la validación de DNSSEC con la RFC 5011 automática. Para obtener la última versión de los anclajes de confianza, puede actualizar su versión actual del archivo e iniciar de nuevo Windows Server. Los comandos debajo del usuario Windows PowerShell.

Los anclajes de confianza normalmente se actualizan automáticamente. Para verificar el tiempo de actualización de un anclaje de confianza, utilice:

Get-DnsServerTrustPoint

Mostrará:

TrustPointName   TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------   ---------------   ---------------------   ---------------------
.                Active            9/11/2017 7:45:03 PM    9/12/2017 7:45:03 PM

Las horas expresadas son UTC. Si el anclaje de confianza no se actualiza correctamente, puede reemplazarlo por:

Add-DnsServerTrustAnchor -Root

Tras agregar el anclaje de confianza, debería ver un LastActiveRefreshTime actualizado en el resultado del comando Get-DnsServerTrustPoint.

Nota: Si Add-DnsServerTrustAnchor -Root falla, asegúrese de que el DNSSEC esté activado en el servidor. Utilice los tres comandos:

$a = Get-DnsServerSetting -All 
$a.EnableDnsSec = 1 
$a | Set-DnsServerSetting

Puede verificar que RootTrustAnchorsURL esté señalando a https://data.iana.org/root-anchors/root-anchors.xml con el comando:

(Get-DnsServerSetting -All).RootTrustAnchorsURL

Si el comando Add-DnsServerTrustAnchor -Root aún no funciona, puede que un cortafuegos esté bloqueando el transporte. Esto puede suceder en algunos entornos altamente seguros. Para agregar el anclaje de confianza de DS manualmente, necesita conocer la compilación, el algoritmo y la keytag. Para agregar un anclaje de confianza DNSKEY, necesita la DNSKEY pública (Base64Data). De forma alternativa, puede importar el anclaje de confianza si tiene acceso al conjunto de claves (para un anclaje de DNSKEY) o al archivo DSSET (para un anclaje de DS). La compilación, el algoritmo (tipo de compilación) y la keytag para el anclaje de confianza raíz se pueden ver en https://data.iana.org/root-anchors/root-anchors.xml .

Los siguientes comandos demuestran la adición manual de un anclaje de confianza de DS para la zona raíz.

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType SHA256 -KeyTag 19036 -ComputerName localhost -PassThru 

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D -DigestType SHA256 -KeyTag 20326 -ComputerName localhost -PassThru

No es necesario reiniciar el servicio del DNS después de actualizar los anclajes de confianza. Sin embargo, es posible que desee borrar la memoria caché del servidor del DNS con el comando:

Clear-DnsServerCache -Force

Se puede obtener más información sobre Microsoft en https://technet.microsoft.com/en-us/itpro/powershell/windows/dnsserver/add-dnsservertrustanchor.


Akamai DNSi Cacheserve

Akamai Cacheserve (versiones iguales o superiores a: 7.1.2.3, 7.2.0.3, 7.2.1.2) admite la validación de DNSSEC con las claves administradas de RFC5011. Aunque la capacidad también existe en versiones anteriores, no debe utilizarse porque había un problema con el código de traspaso.

Si puede actualizar su software:

  1. La forma más fácil de llegar a la última clave raíz de DNSSEC es utilizar claves administradas y actualizar a la versión Akamai DNSi Cacheserve:

    • 7.1.2.3
    • 7.2.0.3
    • 7.2.1.2

    o una versión posterior en las series respectivas, que tienen la nueva clave raíz ya integrada y en funcionamiento.

Si no puede actualizar su software:

  1. Consulte la información en https://support.nominum.com/view-article/965 o póngase en contacto con Akamai en https://support.nominum.com/.

Infoblox NIOS

Infoblox NIOS admite la validación de DNSSEC, pero aún no admite la validación de DNSSEC con la actualización automática de RFC 5011. Esto significa que para Infoblox NIOS, necesita configurar un nuevo conjunto de anclajes de confianza cada vez que cambien los anclajes de confianza.

Los pasos para agregar la nueva clave para la firma de la llave de la zona raíz como anclaje de confianza en NIOS son:

  1. Inicie sesión en la interfaz gráfica de NIOS
  2. Vaya a Administración de datos → DNS
  3. Haga clic en "Propiedades de cuadrícula del DNS" desde la barra de herramientas
  4. Active "Modo avanzado"
  5. Seleccione la pestaña "DNSSEC"
  6. Desplácese hacia abajo hasta "Anclajes de confianza"
  7. Haga clic en el botón "Agregar" e introduzca los detalles de la clave. La zona es "." y el algoritmo es "RSA/SHA-256(8)".
  8. Pegue la clave en la columna "Clave pública". La clave pública es:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    R1AkUTV74bU=
    

Si se agrega desde el nivel de miembro:

  1. Inicie sesión en la interfaz gráfica de NIOS
  2. Vaya a Administración de datos → DNS → Miembros/Servidores
  3. Seleccione el servidor del DNS
  4. Haga clic en "Editar"
  5. Active "Modo avanzado"
  6. Seleccione "DNSSEC"
  7. Desplácese hacia abajo hasta "Anclajes de confianza"
  8. Haga clic en el botón "Agregar" e introduzca los detalles de la clave. La zona es "." y el algoritmo es "RSA/SHA-256(8)".
  9. Pegue la clave en la columna "Clave pública". La clave pública es:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    R1AkUTV74bU=
    
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."