Agenda: dnssec-bind-firmado-manual.txt

        *** EN SU SERVIDOR AUTORIZADO ***

1. MuŽvase al directorio donde se encuentra la zona, y haga una copia
   de respaldo (asuminedo que se llame "MITLD"), por si acaso

    # cd /etc/namedb/master
    # cp MITLD MITLD.backup

  TambiŽn cree un directorio para guardar las claves

    # mkdir /etc/namedb/keys
    # chown bind /etc/namedb/keys

    # cd /etc/namedb/keys

2. Genere el primer par de claves (ZSK - Clave para firmar la zona)

    # dnssec-keygen -a RSASHA1 -b 1024 -n ZONE MITLD
    KMITLD.+005+51333

3. Genere el segundo par (KSK - Clave para firmar la otra clave)

    # dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE MITLD
    KMITLD.+005+52159

4. Let's look at the keys:

    # ls -l KMITLD.+005+5*
    -rw-r--r--  1 root  wheel   203 Nov 29 00:07 KMITLD.+005+51333.key
    -rw-------  1 root  wheel   937 Nov 29 00:07 KMITLD.+005+51333.private
    -rw-r--r--  1 root  wheel   247 Nov 29 00:07 KMITLD.+005+52159.key
    -rw-------  1 root  wheel  1125 Nov 29 00:07 KMITLD.+005+52159.private

5. Agregue las claves pœblicas en la zona:

    Edite el fichero de zona "MITLD" y agregue las claves al final:

    ; Claves para publicar como records DNSKEY

    $include "/etc/namedb/keys/KMITLD.+005+51333.key"     ; ZSK
    $include "/etc/namedb/keys/KMITLD.+005+52159.key"     ; KSK
        
    Incremente el nœmero de serie

    Grabe y salga.

6. Firme la zona con las claves:

    # cd /etc/namedb/keys
    # dnssec-signzone -o MITLD -k KMITLD.+005+52159 ../master/MITLD KMITLD.+005+51333
    Verifying the zone using the following algorithms: RSASHA1.
    Zone signing complete:
    Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                        ZSKs: 1 active, 0 stand-by, 0 revoked
    MITLD.signed

    La copia firmada se ha guardado en el directorio master/, as’ que vamos
    a mirarla:

    # cd /etc/namedb/master/
    # ls -l MITLD*

    -rw-r--r--  1 root  wheel   292 Nov 29 00:08 MITLD
    -rw-r--r--  1 root  wheel  4294 Nov 29 00:20 MITLD.signed

    Eche un vistazo al contenido de la zona, y observe los nuevos records.

7. Note que se ha generado una lista de records DS, y Žstos est‡n listos
   para enviar a la zona superior:

    # cd /etc/namedb/keys/
    # ls -l dsset-*

    -rw-r--r--  1 root  wheel  155 Nov 29 00:22 dsset-MITLD.

   Mire el contenido del dsset:

    # cat dsset-MITLD.

8. En /etc/namedb/named.conf cambie la definici—n de la zona para apuntar
   al fichero nuevo:

    zone "MITLD" {
            type master;
            file "/etc/namedb/master/MITLD.signed"; // cargar la zona firmada
    };

9. TambiŽn, en named.conf, active DNSSEC (para la parte autorizada):

    ... En la secci—n options { .. }; agregue:

    dnssec-enable yes;

10. Reconfigure o reinicie BIND:

    # rndc reconfig

11. Pruebe que el servidor est‡ respondiendo con rŽcords DNSSEC:

    # dig @127.0.0.1 MITLD SOA +dnssec

12. Ahora deber’a revisar que su esclavo TAMBIEN ha configurado su servidor
    para habilitar DNSSEC (paso 8). Deber’an haberlo hecho porque est‡n
    trabajando en el mismo ejercicio, pero compruebe de todas formas!

    Para probar:

    # dig @10.10.Y.1 MITLD SOA +dnssec

    ... donde Y es el grupo donde se encuentra el servidor esclavo.

13. Ahora debe enviar el DS a su dominio superior

   Pregunte al administrador del ra’z sobre c—mo transferir el record DS.
   Podr’a ser usando SCP o un formulario web con SSL.

   Si el administrador del ra’z le indica usar SCP, haga lo siguiente:

   # cd /etc/namedb/keys
   # scp dsset-MITLD. adm@a.root-servers.net:

   ... Esto copiar‡ el fichero "dsset-MITLD." en el directorio de usuario "adm" 
   del servidor a.root-server, donde el administrador lo incluir‡ en la zona
   ra’z para despuŽs firmar.

14. Pruebe que el bit AD est‡ activado:

    # dig @10.10.0.230 +dnssec www.MITLD.

    Lo est‡ ?

    Si no, puede que el administrador del ra’z no haya firmado la zona ra’z
    con sus DS incluidos todav’a, O que por causa del *negative TTL*, puede 
    que el record DS no estŽ aœn en la cachŽ del resolver. Puede que tenga, 
    que esperar, pero confirme con el administrador del ra’z, y en cualquier
    caso, puede comprobar en el ra’z directamente: 

    # dig @a.root-servers.net DS MITLD.

    ... que el rŽcord DS est‡ publicado. Entonces es cuesti—n de esperar que
    la cachŽ caduque en el resolver para poder comprobar sus firmas.