¿Cómo aseguro una zona con el servicio DLV de dlv.isc.org?

¿Cómo aseguro una zona con el servicio DLV de dlv.isc.org?

Estoy configurando la validación de dominio. Creo que entendí casi todo correctamente. Seguí las instrucciones aquí:https://dlv.isc.org/about/using. Registré mi dominio y cargué la clave de firma de clave, firmé mi zona con -l dlv.isc.orgla opción, agregué dlv.isc.org como servidor de nombres externo para mi dominio en los archivos de zona. nombrado falla silenciosamente. Incluso cambié /dev/nulla /var/log/named.logpara extraer información de nombre. Verifiqué que se realizaron los cambios pero no funcionó. No sé qué verificar o probar.

Estoy haciendo 2 preguntas:

  1. Estrategias para obtener información de un nombre cuando falla silenciosamente como lo hace
  2. ¿La configuración es correcta? Mi conocimiento limitado de DNS y DNSSEC me dice que esto debería funcionar

archivo de reenvío:

$TTL 3600;

@ IN SOA ns1.sub.db.archives.net. dlv.isc.org. (
2014112100  ; serial
4h      ; refresh
1h      ; retry
7d      ; expiration
1h      ; minimum
)
$INCLUDE Ksub.db.archives.net.+008+07374.key
$INCLUDE Ksub.db.archives.net.+008+24586.key

        IN  NS  ns1.sub.db.archives.net.
        IN  NS  ns1.db.archives.net.
        IN  NS  dlv.isc.org.

dlv.isc.org.    IN  A   149.20.1.5
ns1.db.archives.net.    IN  A   10.103.35.66
ns1     IN  A   10.103.35.64
luke        IN  A   10.103.35.64
bo      IN  A   10.103.35.65
daisy       IN  A   10.103.35.66
sheriff     IN  A   10.103.35.67
boss        IN  A   10.103.35.68
dlv.sub.db.archives.net. 0 IN TXT "DLV:1:blablabla"

dlv.isc.org. IN DNSKEY 257 3 5 BEAAAAPHMu ...TDN0YUuWrBNh

archivo inverso:

$TTL 3600

@ IN SOA ns1.sub.db.archives.net. dlv.isc.org. (
2014112100  ; serial #
4h              ; refresh
1h              ; retry
7d              ; expiration
1h              ; minimum
)

                IN      NS  ns1.sub.db.archives.net.
                IN      NS  ns1.db.archives.net.
        IN  NS  dlv.isc.org.

5.1.20.149  IN  PTR dlv.isc.org.
66.35.103.10    IN  PTR ns1.db.archives.net.
64  IN  PTR ns1.sub.db.archives.net.
64  IN  PTR luke.sub.db.archives.net.
65  IN  PTR bo.sub.db.archives.net.
66  IN  PTR daisy.sub.db.archives.net.
67  IN  PTR sheriff.sub.db.archives.net.
68  IN  PTR boss.sub.db.archives.net.

Comando dnssec-signzone:

dnssec-signzone -l dlv.isc.org -o sub.db.archives.net -k Ksub.db.archives.net.+008+24586.key sub.db.archives.net.fwd Ksub.db.archives.net.+008+07374.key

llamado:

[root@test master]# service named start
Starting named:                                            [FAILED]

Respuesta1

  1. Estrategias para ver por qué namedno se inicia:
    • Verifique named-checkconf -zjla salida. ( named-checkconfy named-checkzoneprobablemente debería ser parte de su flujo de trabajo habitual, no solo para la resolución de problemas)
    • Verifique los registros. ( namedse registra en syslog de forma predeterminada, consulte su named.confpara conocer cualquier configuración de registro que pueda anular esto)
    • Si nada de lo anterior ayuda (es poco probable), también existe la opción de verificar qué parámetros tiene normalmente en su namedlínea de comando e iniciarlo manualmente -gagregando a su conjunto normal de parámetros (esto obliga nameda permanecer en primer plano e iniciar sesión en stderr). ).


  1. Existen numerosos problemas obvios con los datos de zona incluidos en la pregunta que no son de ninguna manera específicos de DNSSEC o DLV. Para ser sincero, le recomendaría que lea sobre los fundamentos del DNS como primer paso.
    Algunos problemas que detecté fueron los siguientes; consulte named-check{conf,zone}}también los registros y/o los resultados.

    • Los SOAregistros tienen valores RNAME muy poco probables ( [email protected])
    • dlv.isc.orgfigura como servidor de nombres, pero dudo mucho que aloje sus zonas.
    • dlv.isc.org. IN A ...No parece que pertenezca a esta zona.
    • ns1.db.archives.net. IN A ...No parece que pertenezca a esta zona.
    • dlv.isc.org. IN DNSKEY ...No parece que pertenezca a esta zona.
    • 5.1.20.149 IN PTR dlv.isc.org.- Haciendo caso omiso de que está escrito incorrectamente, este es otro registro más que no corresponde.
    • 66.35.103.10 IN PTR ns1.db.archives.net.probablemente pertenece pero está escrito incorrectamente.


(Mi impresión de la pregunta es que las dos zonas son sub.db.archives.nety 35.103.10.in-addr.arpa, que es en lo que basé las declaraciones fuera de zona. Ver la configuración real además de los datos de la zona confirmaría esto).

Respuesta2

Los errores reales file not foundse explican por sí solos (¿no existen tales archivos, supongo?).

Sin embargo, DSlos registros se encuentran en la zona principal; alternativamente, DLVlos registros se encuentran en el servidor DLV.

Esto significa que su paso 4 no existe (según la guía que vinculó).

¿Realmente no puedes colocar los registros DS en la zona principal? La DLV fue principalmente una medida provisional desde el principio y no debería ser la primera opción.

Ver tambiénFirma en línea (y mantenimiento automático de DNSSEC), que generalmente es una mejor opción para la firma de zonas y la administración de claves en comparación con llamar manualmente a dnssec-signzone.

información relacionada