giovedì 24 settembre 2020

DNSSEC: una guida ragionata all’implementazione - Parte II

Reissblog riprende dopo la pausa estiva. Sempre con "viva e vibrante soddisfazione" ospito la seconda parte di un lungo post su DNSSEC, scritto dal mio amico Antonio PRADO, brillante e appassionato networker, con grande esperienza teorica e pratica maturata su reti in produzione. Antonio è un personaggio ben conosciuto nell'ambiente, ha un suo blog, collabora con molti enti internazionali (es. MANRS), è l'autore della collana "Internet per le Nonne", insieme a Max Stucchi è l'animatore di ITNOG-on-the-Web, e molto altro.

La prima parte del post la trovate qui.

Dalla teoria alla pratica ...

Se è chiara la teoria, passiamo alla pratica. Non navigheremo tutti i rivoli nei quali si ramifica il processo decisionale che conduce alla progettazione prima, alla scelta poi degli strumenti, alla finale configurazione di una infrastruttura di risoluzione dei nomi, poiché al di là delle finalità di questo documento.

Ci concentreremo piuttosto sulla porzione dedicata all’implementazione del DNSSEC (sia dal punto di vista dell’autorità, sia dal punto di vista di un risolutore), partendo necessariamente da uno scenario nel quale alcune scelte sono tuttavia già state fatte. Tenteremo comunque quanto più possibile di agganciare le operazioni (che andremo a dettagliare) ai concetti espressi in precedenza così che, mutatis mutandis, sarà possibile riportare l’esperienza su altri scenari.

Iniziamo a tracciare un perimetro attorno alla nostra implementazione e conosciamo gli strumenti che andremo a usare:

  • Sistema operativo: FreeBSD12.1-RELEASE amd64
  • Pacchetto software DNS autorità: nsd-4.3.1
  • Pacchetto software DNS risolutore ricorsivo: unbound-1.10.1
  • Pacchetto software DNSSEC: opendnssec2-2.1.6
  • Pacchetto software HSM: softhsm2-2.6.1

Il sistema operativo FreeBSD è gratuito e a sorgente aperta, di tipo UNIX.

NSDName Server Daemon, è un software (usato a esempio anche dal Root Server K) scritto da NLnet Labs per funzionare come servizio di risoluzione dei nomi e gestisce come autorità le zone, cioè non ha funzioni di cache o di risoluzione ricorsiva. Funzione quest’ultima delegata al programma Unbound (di NLnet Labs) che useremo anche per controllare la catena della fiducia.

La gestione delle operazioni connesse alla firma delle zone viene offerta da OpenDNSSEC che usa la libreria di crittografia Botan e si appoggia su una base di dati SQLite o MySQL. Anche OpenDNSSEC è usato da grandi e complesse organizzazioni come quelle responsabili, tra gli altri, dei nomi a dominio “se. “ (Svezia) e “uk.” (Regno Unito).

Strettamente legato a questo software è il programma SoftHSM che di fatto fa le veci delle macchine dedicate alle operazioni di firma digitale e alla gestione delle chiavi crittografiche. Quindi, invece di acquistare un apposito calcolatore per queste funzioni, è possibile usare SoftHSM che ben si interfaccia con OpenDNSSEC.

Individuiamo ora nel filesystem le posizioni degli elementi utili ai nostri ragionamenti.

Usando NSD, i file delle zone andrebbero di regola in /usr/local/etc/nsd/, tuttavia, allo scopo di questa breve trattazione preferiremo archiviarli nella posizione predefinita di OpenDNSSEC, cioè /usr/local/var/opendnssec/unsigned .

Ed è proprio in questa collocazione che andremo a salvare la nostra zona dimostrativa: /usr/local/var/opendnssec/unsigned/mia.demo .


$ORIGIN mia.demo.
       3600 SOA ns1.mia.demo. ( 
              admin.mia.demo. ; address of responsible party 
              2020061301 ; serial number 
              3600 ; refresh period 
              600 ; retry period 
              604800 ; expire time 
              1800    ) ; minimum ttl 
       86400 NS ns1.mia.demo. 
       86400 NS ns2.mia.demo. 
       3600 MX 10 mail.mia.demo. 
           60 A 192.0.2.10 
           60 AAAA 2001:db8:a:b:c::a 
          ns1 3600 A 192.0.2.1 
          ns1 3600 AAAA 2001:db8:c:d:e::1 
          ns2 3600 A 198.51.100.2 
          ns2 3600 AAAA 2001:db8:f:1:2::12 
          mail 14400 A 203.0.113.20 
          mail 14400 AAAA 2001:db8:c:1:2::14 
          www 43200 CNAME @ 


Non ci resta che decidere quali criteri desideriamo usare per le procedure di firma, ma non troppo in fretta. Questo passaggio, oserei dire, è di cruciale importanza per l’efficacia di una implementazione ragionata di DNSSEC. Perciò è necessario che approfondiamo insieme alcuni degli aspetti preponderanti, rispondendo a questi interrogativi:

  • quanto tempo desideriamo che le firme rimangano valide?
  • quale algoritmo desideriamo usare per la chiave utile a firmare le zone e le altre chiavi?
  • qual è l’intervallo di tempo che è opportuno attendere affinché, dopo aver pubblicato una chiave nella zona, l’autorità sovraordinata pubblichi la firma digitale?


Curiamo i rapporti con i superiori

Se abbiamo compreso bene tutti i precedenti passaggi, ci sarà chiaro che dobbiamo rapportarci con l’autorità sovraordinata così da cementare i rapporti di fiducia. E dunque avere le idee chiare sui dettagli è indispensabile.

Riepilogando i passaggi necessari:

  • l’autorità DNS (noi), attraverso una chiava privata, firma i Resource Record (RR) di una zona;
  • la firma viene pubblicata in un apposito record chiamato RRSIG;
  • la chiave pubblica viene pubblicata in un apposito record chiamato DNSKEY;
  • viene generato un altro record chiamato Delegation Signer (DS) che poi l’autorità sovraordinata andrà a firmare e pubblicare.

Ecco allora le risposte alle domande che abbiamo formulato poche righe fa.

Algoritmo. Il consiglio è di usare l’algoritmo numerato da IANA come 13 cioè ECDSA [RFC 6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC] con curva ellittica data da numeri primi lunghi 256 bit e Secure Hash Algorithm con digest da 256 bit (SHA-256). Si tratta di un compromesso tra sicurezza, velocità di firma e verifica.

Validità. La scelta sulla durata della validità di una firma può essere complessa e dipendere da alcuni fattori specifici di una organizzazione e dunque non possiamo dare un valore di riferimento basato su parametri oggettivi. In questo documento stabiliamo un periodo di 30 giorni.

Propagazione. Chiediamo alla nostra autorità superiore quanto tempo necessita per far sì che il nostro DS record venga firmato e pubblicato. Occorre poi calcolare quanto tempo occorra affinché quel record diventi visibile ai risolutori su Internet. In questo documento stabiliamo un periodo di 1 giorno.

Un ulteriore utile consiglio: per rendere conoscibili a tutti i criteri con i quali intendiamo gestire le estensioni di sicurezza del DNS, sarebbe auspicabile redigere e pubblicare un particolare documento conosciuto come DNSSEC Policy & Practice Statements (DPS) [RFC 6841 - A Framework for DNSSEC Policies and DNSSEC Practice Statements]. Un buon esempio è rintracciabile sul sito di RIPE NCC.

Tornando alla nostra implementazione, abbiamo le conoscenze e i dati per poter continuare la configurazione di OpenDNSSEC.


Prepariamo OpenDNSSEC

Vale la pena a questo punto gettare uno sguardo sull’architettura del software OpenDNSSEC così da avere le idee più chiare durante l’iter di gestione.

Tre sono i macro-componenti: SoftHSMEnforcer Signer.


Passiamoli velocemente in rassegna.

  • SoftHSM è il modulo che si occupa di ricevere i dati da firmare, di firmarli e di restituirli firmati senza che la chiave privata debba mai uscire dal modulo.
  • Enforcer sbriga tutte le pratiche delle zone e dei loro criteri, cioè da una parte verifica che le chiavi necessarie siano disponibili presso il modulo SoftHSM, dall’altra dà disposizioni al Signer su come firmare le zone.
  • Signer è il componente che gestisce i dati delle zone: riceve quelli non firmati (ma da firmare), li firma (facendo uso di SoftHSM), li archivia in un file o li trasferisce a un server DNS (via XFR).

I file di configurazione di OpenDNSSEC, nell’architettura prescelta, giacciono in /usr/local/etc/opendnssec/ e sono:

  • addns.xml, se si desidera ricevere e inviare i dati delle zone via AXFR o IXFR a un server DNS, occorre inserire in questo file l’input e l’output che Signer leggerà per sapere da chi ricevere le zone da firmare e a chi trasmettere quelle firmate;
  • conf.xml, riporta le impostazioni generali del demone come archiviazione dei log, posizione del database ecc.;

# cat conf.xml
<?xml version="1.0" encoding="UTF-8"?>

<Configuration>

  <RepositoryList>

      <Repository name="SoftHSM">
          <Module>/usr/local/lib/softhsm/libsofthsm2.so</Module>
          <TokenLabel>OpenDNSSEC</TokenLabel>
          <PIN>1234</PIN>
          <SkipPublicKey/>
          <!--
          <AllowExtraction/>
          -->
      </Repository>
<!--
      <Repository name="sca6000">
          <Module>/usr/lib/libpkcs11.so</Module>
          <TokenLabel>Sun Metaslot</TokenLabel>
          <PIN>test:1234</PIN>
          <Capacity>255</Capacity>
          <RequireBackup/>
          <SkipPublicKey/>
      </Repository>
-->
      </RepositoryList>
      <Common>
          <Logging>
            <!-- Command line verbosity will overwrite configure file             -->
            <Verbosity>3</Verbosity>
            <Syslog><Facility>local0</Facility></Syslog>
         </Logging>
         <PolicyFile>/usr/local/etc/opendnssec/kasp.xml</PolicyFile
         <ZoneListFile>/usr/local/etc/opendnssec/
                                          zonelist.xml</ZoneListFile>
      </Common>

      <Enforcer>

      <Datastore><SQLite>/usr/local/var/opendnssec/kasp.db</SQLite>                                                        </Datastore>

                                    <!-- <ManualKeyGeneration/> -->

     <AutomaticKeyGenerationPeriod>P1Y</AutomaticKeyGenerationPeriod>
      <!-- <RolloverNotification>P14D</RolloverNotification> -->

      <!-- the <DelegationSignerSubmitCommand> will get all current
DNSKEYs (as a RRset) on standard input (with optional CKA_ID) -->

      <!-- <DelegationSignerSubmitCommand>/usr/local/sbin/simple-dnskey-mailer.sh</DelegationSignerSubmitCommand> -->

      <WorkingDirectory>/usr/local/var/opendnssec/enforcer</
                                                    WorkingDirectory>
          <!--<WorkerThreads>4</WorkerThreads>-->

      </Enforcer>

      <Signer>

      <WorkingDirectory>/usr/local/var/opendnssec/signer</
                                                    WorkingDirectory>
        <WorkerThreads>4</WorkerThreads>
<!--
        <SignerThreads>4</SignerThreads>
-->
<!-- Multiple interfaces can be specified in the <Listener> section. OpenDNSSEC will bind() to the first interface. I.e. outgoing packets will have the source address of the first mentioned interface. -->

<!--
        <Listener>
            <Interface><Port>53</Port></Interface>
        </Listener>
-->
<!-- the <NotifyCommmand> will expand the following variables:
%zone the name of the zone that was signed
%zonefile the filename of the signed zone
-->
<!--
       <NotifyCommand>/usr/local/bin/my_nameserver_reload_command</
                                                       NotifyCommand>
-->
<!--
       <NotifyCommand>/usr/sbin/rndc reload %zone</NotifyCommand>
-->

</Signer>

</Configuration>

kasp.xml, elenca i criteri che Enforcer deve rispettare come l’algoritmo da usare per la firma, i parametri temporali che abbiamo descritto qualche paragrafo più su.

# cat kasp.xml
<?xml version="1.0" encoding="UTF-8"?>

<KASP>

<Policy name="default">
<Description>Criterio di default</Description>
<Signatures>
<Resign>PT2H</Resign>
<Refresh>P3D</Refresh>
<Validity>
<Default>P30D</Default>
<Denial>P30D</Denial>
</Validity>
<Jitter>PT12H</Jitter>
<InceptionOffset>PT3600S</InceptionOffset>
<MaxZoneTTL>P1D</MaxZoneTTL>
</Signatures>

<Denial>
<NSEC3>
<!-- <TTL>PT0S</TTL> -->
<!-- <OptOut/> -->
<Resalt>P100D</Resalt>
<Hash>
<Algorithm>1</Algorithm>
<Iterations>5</Iterations>
<Salt length="8"/>
</Hash>
</NSEC3>
</Denial>

<Keys>
<!-- Parameters for both KSK and ZSK -->
<TTL>PT3600S</TTL>
<RetireSafety>PT3600S</RetireSafety>
<PublishSafety>PT3600S</PublishSafety>
<!-- <ShareKeys/> -->
<Purge>P14D</Purge>

<!-- Parameters for KSK only -->
<KSK>
<Algorithm length="2048">13</Algorithm>
<Lifetime>P1Y</Lifetime>
<Repository>SoftHSM</Repository>
</KSK>

<!-- Parameters for ZSK only -->
<ZSK>
<Algorithm length="2048">13</Algorithm>
<Lifetime>P90D</Lifetime>
<Repository>SoftHSM</Repository>
<!-- <ManualRollover/> -->
</ZSK>
</Keys>

<Zone>
<PropagationDelay>PT43200S</PropagationDelay>
<SOA>
<TTL>PT3600S</TTL>
<Minimum>PT3600S</Minimum>
<Serial>unixtime</Serial>
</SOA>
</Zone>

<Parent>
<PropagationDelay>PT9999S</PropagationDelay>
<DS>
<TTL>PT3600S</TTL>
</DS>
<SOA>
<TTL>PT172800S</TTL>
<Minimum>PT10800S</Minimum>
</SOA>
</Parent>

</Policy>

</KASP>

Procediamo con l’inizializzazione di SoftHSM: dobbiamo far sì che il software si predisponga a interfacciarsi con OpenDNSSEC a cui andremo poi a comunicare i PIN usati in questa fase nel file di configurazione /usr/local/etc/opendnssec/conf.xml.

~ # softhsm2-util --init-token --slot 0 --label "OpenDNSSEC"
=== SO PIN (4-255 characters) ===
Please enter SO PIN: 1234
Please reenter SO PIN: 1234
=== User PIN (4-255 characters) ===
Please enter user PIN: 1234
Please reenter user PIN: 1234
The token has been initialized and is reassigned to slot 1698931229
~ #

Andiamo ora a inizializzare anche il database del software OpenDNSSEC:

~ # ods-enforcer-db-setup
*WARNING* This will erase all data in the database; are you sure? [y/N] y
Database setup successfully.
~ # 

A questo punto abbiamo preparato il terreno per fare in modo che OpenDNSSEC possa cominciare a gestire le zone da firmare con l’ausilio di SoftHSM.

Fuoco alle polveri:

~ # ods-control start
Starting enforcer...
OpenDNSSEC key and signing policy enforcer version 2.1.6
Engine running.
Starting signer engine...
OpenDNSSEC signer engine version 2.1.6
Engine running.
~ #

Tiriamo dentro i criteri impostati precedentemente:

~ # ods-enforcer policy import
Created policy default successfully
~ #

Ora il demone è attivo ed è consapevole dei criteri che ci piace applicare, dunque aggiungiamo la nostra zona dimostrativa al database di OpenDNSSEC agendo sull’Enforcer:

~ # ods-enforcer zone add -z mia.demo
input is set to /usr/local/var/opendnssec/unsigned/mia.demo. 
output is set to /usr/local/var/opendnssec/signed/mia.demo. 
Zone mia.demo added successfully
~ #

Se ci va di curiosare su come la zona appaia dopo che i dati sono stati firmati:

~ # cat /usr/local/var/opendnssec/signed/mia.demo 
mia.demo. 3600 IN SOA ns1.mia.demo. admin.mia.demo. 2020061302 3600 600 604800 3600
mia.demo. 3600 IN RRSIG SOA 13 2 3600 20201014051848 20200914151954 15169 mia.demo. Sdq+ayF7VoRrY1Jxuek3THwA64rQat4G2vsMBxgedk1Qzog6JW1Gt8cxnpTUVw7KBJWAlBeBGa0xyMXZTKUM+A==
mia.demo. 3600 IN DNSKEY 256 3 13 eqXEAFh4h4SdVkzdxacUtpGj7o9DN/Q7lL+itf0rKBTwqrB/U+7OlFKgCfQZ7MZN/oJt0G2ayAzjzr9EKejQMA== ;{id = 15169 (zsk), size = 256b}
mia.demo. 3600 IN DNSKEY 257 3 13 s/j9BRMVu5Og1X/fg/NW1Yfj+4TTarMbmpuvjIStXec6CcSJfzYiMFppfBH/M39IEnV/oj5Amwzmo7AYIIIAkg== ;{id = 52741 (ksk), size = 256b}
mia.demo. 3600 IN RRSIG DNSKEY 13 2 3600 20201015022324 20200914151954 52741 mia.demo. E9vrb0uZi9HJ6PMZSnMysl3xihTc2h+pCLfI0OoVuImwU2hz9IgFI1b/tihd1wh7oIe8BvXbhLNMdwhnMRcKBw==
mia.demo. 0 IN NSEC3PARAM 1 0 5 d829907b6bec953f 
mia.demo. 0 IN RRSIG NSEC3PARAM 13 2 0 20201014192251 20200914151954 15169 mia.demo. F3fTQJ1x6lH0tg9veR5iuBHOrFGQTFxsGfNGqvdHqPkaHiDhpDhGRHxLGXs3nsiYR9y+KJjn7x5zgqkJh+txTQ==
mia.demo. 86400 IN NS ns1.mia.demo.
mia.demo. 86400 IN NS ns2.mia.demo.
mia.demo. 86400 IN RRSIG NS 13 2 86400 20201015031430 20200914151954 15169 mia.demo. 7qJ7PZr95lFPN4/74BtGIJUgkks/EUO1fMPBjEvSu7bRmKJLcqlrdjJblk8FfXUhXsJcYqnDYKAapeMPTFUEOw==
mia.demo. 3600 IN MX 10 mail.mia.demo.
mia.demo. 3600 IN RRSIG MX 13 2 3600 20201014135914 20200914151954 15169 mia.demo. iDATdOPp60MY+ec5i9wacBfXUuWKtej/TMXYPN+uXfBb0puTbP9bvm2j6p70ZrLowIXTKKP/d3azdIPNz/BaRg==
mia.demo. 60 IN A 192.0.2.10
mia.demo. 60 IN RRSIG A 13 2 60 20201014175400 20200914151954 15169 mia.demo. flSrOyAfvAEfJpJqN2cZ3TnCPqEK8ptRZjvvdcWXBIfLLZUnOKNp5O1H7gBjdXeH/Ph/wrY8S5/s7bfNHIH3ww==
mia.demo. 60 IN AAAA 2001:db8:a:b:c::a
mia.demo. 60 IN RRSIG AAAA 13 2 60 20201014052852 20200914151954 15169 mia.demo. PmckX/H3s+K1w2vudcUjU0b2dRmy/ehZaPt8x9gmlKtQvrelKg4UaBocUVwMpE1V7LKRWEQXSffsiPlU+f+MNw==
gs6mu9olg23q09jujle3grf8ei2rv96u.mia.demo. 3600 IN NSEC3 1 0 5 d829907b6bec953f  ml5avhdktgn9tv85u4rcd0dmdfe2fqbu A NS SOA MX AAAA RRSIG DNSKEY NSEC3PARAM 
gs6mu9olg23q09jujle3grf8ei2rv96u.mia.demo. 3600 IN RRSIG NSEC3 13 3 3600 20201014104536 20200914151954 15169 mia.demo. g1mxPy24pNzTi1kDocOky11KsVHWX+fHhUffX+nX+ByV0Q5VOgMTLWhwwvowc3qEwOWaxGSJHJ0Zw4RgXU06Vg==
mail.mia.demo. 14400 IN A 203.0.113.20
mail.mia.demo. 14400 IN RRSIG A 13 3 14400 20201014101557 20200914151954 15169 mia.demo. hG6uzzha5vvSxlQYk9XSII9iuWNlM2K+Ryfwz/U4sutF1lqjDjj9guD3XgOy2q6XHIuGWOk2ohcrpwK077TNxA==
mail.mia.demo. 14400 IN AAAA 2001:db8:c:1:2::14
mail.mia.demo. 14400 IN RRSIG AAAA 13 3 14400 20201014184645 20200914151954 15169 mia.demo. bBE9YvSFIGCEgjDFlJU7Kl5cBdWd8MHo9ceGnJkJYzC17OrL8cmL/9y80YnjKRhVg6w88XA6gJ95hLlDthH9iA==
ml5avhdktgn9tv85u4rcd0dmdfe2fqbu.mia.demo. 3600 IN NSEC3 1 0 5 d829907b6bec953f  tfpr7r4261tosbcd1qhaanrd1eglisin A AAAA RRSIG 
ml5avhdktgn9tv85u4rcd0dmdfe2fqbu.mia.demo. 3600 IN RRSIG NSEC3 13 3 3600 20201014102910 20200914151954 15169 mia.demo. 7b0A7rdv5RwQ/+9x6p2jv0APrndoKD6dWKhUXGxmOUkbsbVQQFak0OfmTWw3OJCLU+vMfVbg+cj56Fi7JJq3vg==
ns1.mia.demo. 3600 IN A 192.0.2.1
ns1.mia.demo. 3600 IN RRSIG A 13 3 3600 20201015010820 20200914151954 15169 mia.demo. vOZqFgVBMU06dSZVBTtyMEGggVfRw9cCp0B39nrIMpLSm8r1/C+mK4B066nSfqwEXft/EqELOd72Is62MFFr6A==
ns1.mia.demo. 3600 IN AAAA 2001:db8:c:d:e::1
ns1.mia.demo. 3600 IN RRSIG AAAA 13 3 3600 20201014140919 20200914151954 15169 mia.demo. uF0rKUWy3d4g1UG9bkmBplOWHQ6dSpBLvzdt5stEn5MxMl8LtSD/jdLtkWIRjknM9f9pgyyxBpn87zhAqeL+PA==
d1e40rfjbt1u4g8bcotp8fki55t2fct7.mia.demo. 3600 IN NSEC3 1 0 5 d829907b6bec953f  gs6mu9olg23q09jujle3grf8ei2rv96u A AAAA RRSIG 
d1e40rfjbt1u4g8bcotp8fki55t2fct7.mia.demo. 3600 IN RRSIG NSEC3 13 3 3600 20201014120047 20200914151954 15169 mia.demo. vpExWVrr6rivuzWOMD1ZayyRDMZBUOxZnjVqjCn4cUQ5zsUvtErT4M81lNZbXy4ee3Yo86Fzki+6tp3vG4pLTA==
ns2.mia.demo. 3600 IN A 198.51.100.2
ns2.mia.demo. 3600 IN RRSIG A 13 3 3600 20201014194301 20200914151954 15169 mia.demo. mFnQmYIrmkeJ2uyEjliPFWABcQNUE+2nyr/6k0762ZwByJfTrSCuEA35S+MrB9LhCXYrZBliZeBCh62uXCnGVQ==
ns2.mia.demo. 3600 IN AAAA 2001:db8:f:1:2::12
ns2.mia.demo. 3600 IN RRSIG AAAA 13 3 3600 20201015010541 20200914151954 15169 mia.demo. FKPzZPMsOp3e1jBTAjI2Km3LMHVvK5XxVVnJlHZ0l0pWqhtNnJ7ktojN8nD28QT279kQrPrNHbDqTiZHp84Duw==
2v67v172d619g065a8b034gj6qm2ndul.mia.demo. 3600 IN NSEC3 1 0 5 d829907b6bec953f  d1e40rfjbt1u4g8bcotp8fki55t2fct7 A AAAA RRSIG 
2v67v172d619g065a8b034gj6qm2ndul.mia.demo. 3600 IN RRSIG NSEC3 13 3 3600 20201014070103 20200914151954 15169 mia.demo. rjeZTJX+rSfDnf+bfL/xYanN2wpW+DcHGaLn9KIFi44C6vMuNtAEHVJMOw6GBKNemYP+dcWbEEAgiZ4SocuwZA==
www.mia.demo. 43200 IN CNAME mia.demo.
www.mia.demo. 43200 IN RRSIG CNAME 13 3 43200 20201014091916 20200914151954 15169 mia.demo. FXrqcUHFCR87ZHUby9FkNgA96Zhf0mUX3w0j5PpfveyMwEIR3au89pC2dkQhv6vnxHpAMPMAsDWQDMc2Rd1Dzw==
tfpr7r4261tosbcd1qhaanrd1eglisin.mia.demo. 3600 IN NSEC3 1 0 5 d829907b6bec953f  2v67v172d619g065a8b034gj6qm2ndul CNAME RRSIG 
tfpr7r4261tosbcd1qhaanrd1eglisin.mia.demo. 3600 IN RRSIG NSEC3 13 3 3600 20201014212258 20200914151954 15169 mia.demo. XJ/9/qJmsCxhOJ2cCU6tdlTx42FBcS8neqbPxZa9whTTA/EdGWr5RbVwGqUMqfZYaM8UbWXLzkulrkz6ep4eJQ==
~ # 

Fin qui sembra funzionare tutto, ma come possiamo ben sospettare, anche alla luce di quanto illustrato precedentemente, la nostra maglia di metallo non è credibile se non la saldiamo a una più lunga catena che proviene dall’alto.

Dunque riprendiamo le fila del ragionamento e analizziamo il nostro nome a dominio mia.demo. dove, con neanche tanta approssimazione, possiamo riconoscere:
  • . → il root server
  • demo → il TLD
  • mia → il nome a dominio di secondo livello che ricade nella nostra responsabilità.
Atteso che esista già una catena di fiducia tra il root server e il TLD demo (cosa che, se l’esempio fosse realistico, avremmo facilmente modo di verificare), dovremo comunicare al Registrar (cioè a chi gestisce il TLD demo in questione) il valore del record Delegation Signer (DS) affinché il Registrar possa firmarlo e pubblicarlo nella propria zona.

Osserviamo comunque la lista delle chiavi per la nostra zona dimostrativa:

~ # ods-enforcer key list
Keys:
Zone:                           Keytype: State:    Date of next transition:
mia.demo                        ZSK      ready     2020-09-15 08:19:53
mia.demo                        KSK      publish   2020-09-15 08:19:53
~ #

Per un output più dettagliato:

~ # ods-enforcer key list -d
Keys:
Zone:            Key role:     DS:    DNSKEY:   RRSIGDNSKEY: RRSIG:  Pub: Act: Id:
mia.demo          ZSK           NA   rumoured   NA   rumoured    1    1    4a63f9d162b7ce251901015f9e2b5306
mia.demo          KSK       hidden   rumoured     rumoured   NA  1    1    945381db723d1237ee8b7a63a326d783
~ # 

Come si intuisce, la nostra zona con record firmati non è ancora nello stato corretto per poter essere usata, poiché non supererebbe i test di validazione della fiducia.

Trascorso il tempo giusto impostato tra i criteri di kasp.conf lo stato del record DS cambia, da “hidden” a “rumoured”:

~ # ods-enforcer key list -d
Keys:
Zone:           Key role:    DS:   DNSKEY:   RRSIGDNSKEY: RRSIG:    Pub: Act: Id:
mia.demo         ZSK         NA    omnipresent  NA    omnipresent    
1    1    4a63f9d162b7ce251901015f9e2b5306
mia.demo         KSK         rumoured   omnipresent  omnipresent  NA  1    1    945381db723d1237ee8b7a63a326d783
~ #

A questo punto possiamo esportare il record DS:

~ # ods-enforcer key export -a -d
;ready KSK DS record (SHA256):
mia.demo. 3600 IN DS 52741 13 2 8fe8214e05c8d03e9da0ddf6d686fe073a6b23b50440e027b0e6257d3ef44fea
~ #

Queste sono le informazioni che è necessario comunicare al Registrar del nostro nome a dominio. Solitamente, almeno i Registrar più strutturati, consentono la compilazione dei campi relativi al DS in modo autonomo, ciascuno attraverso un proprio formulario on-line.

Qui giunti, gran parte del lavoro è fatta; sarà poi OpenDNSSEC a prendersi cura del resto.

Ma il nostro name server autoritativo di cosa dovrà occuparsi precisamente? 

Per adesso ve la lascio come riflessione. Arrivederci alle prossime puntate (almeno due considerata la vastità e complessità dell'argomento).

1 commento: