6. Integrità della zona

Assicurare l'integrità dei dati di zona trasferiti è critico per mantenere la sicurezza e l'affidabilità dell'infrastruttura DNS. Questa sezione discute le considerazioni sull'integrità per AXFR e raccomanda le migliori pratiche.

Minacce all'integrità

I trasferimenti di zona sono soggetti a diverse minacce all'integrità:

1. Attacchi man-in-the-middle: Un aggressore posizionato tra il client AXFR e il server potrebbe intercettare e modificare i dati di zona in transito.

2. Attacchi di spoofing: Un aggressore potrebbe impersonare un server AXFR e inviare dati di zona falsificati a un client AXFR.

3. Attacchi di replay: Un aggressore potrebbe catturare un trasferimento di zona legittimo e riprodurlo successivamente, causando potenzialmente il ripristino del client a dati di zona obsoleti.

4. Modifiche non autorizzate: Senza autenticazione e controlli di integrità appropriati, un aggressore potrebbe iniettare, eliminare o modificare record di risorse durante un trasferimento di zona.

Meccanismi di protezione dell'integrità

Per proteggersi da queste minacce, le implementazioni AXFR DOVREBBERO impiegare uno o più dei seguenti meccanismi di protezione dell'integrità:

TSIG (Transaction Signature)

TSIG [RFC2845] fornisce autenticazione e protezione dell'integrità a livello di messaggio utilizzando chiavi segrete condivise e algoritmi HMAC.

Come funziona TSIG per AXFR:

1. Il client AXFR include un RR TSIG nel suo messaggio di query, firmato con una chiave pre-condivisa.

2. Il server AXFR valida la firma TSIG sulla query. Se la validazione fallisce, il server risponde con RCODE NOTAUTH o REFUSED.

3. Se la query è valida, il server AXFR include RR TSIG nei suoi messaggi di risposta:

   • Il primo messaggio di risposta DEVE includere un RR TSIG.
   • I messaggi intermedi POSSONO omettere TSIG (per efficienza), ma la sequenza è comunque protetta dal TSIG sui primi e ultimi messaggi.
   • L'ultimo messaggio di risposta DEVE includere un RR TSIG.

4. Il client AXFR valida le firme TSIG sui messaggi di risposta. Se una validazione fallisce, il client DEVE scartare l'intero trasferimento di zona.

Vantaggi: TSIG fornisce forte protezione dell'integrità e autenticazione mutua. È ampiamente supportato nelle implementazioni DNS.

Limitazioni: Richiede chiavi pre-condivise, che devono essere distribuite e gestite in modo sicuro.

SIG(0) (Signature)

SIG(0) [RFC2931] fornisce autenticazione dei messaggi basata su chiave pubblica utilizzando firme in stile DNSSEC.

Come funziona SIG(0) per AXFR:

1. Il client AXFR firma il suo messaggio di query con la sua chiave privata e include il RR SIG(0) risultante nella query.

2. Il server AXFR valida la firma utilizzando la chiave pubblica del client (recuperata tramite DNS o da un'ancora di fiducia locale).

3. Il server AXFR PUÒ firmare i suoi messaggi di risposta con la propria chiave privata, consentendo al client di verificare l'autenticità della risposta.

Vantaggi: Elimina la necessità di segreti pre-condivisi. Adatto a scenari in cui la distribuzione delle chiavi è impegnativa.

Limitazioni: Più complesso da implementare e configurare rispetto a TSIG. Si basa sull'infrastruttura a chiave pubblica.

DNSSEC

Per le zone che sono firmate DNSSEC, il client AXFR può validare l'integrità dei dati di zona trasferiti utilizzando firme DNSSEC (record RRSIG).

Come DNSSEC protegge AXFR:

1. Il server AXFR trasferisce la zona, includendo tutti i record RRSIG, DNSKEY e NSEC/NSEC3.

2. Il client AXFR valida le firme RRSIG sugli RRset trasferiti utilizzando i record DNSKEY nella zona.

3. Se la validazione DNSSEC fallisce, il client NON DOVREBBE servire i dati di zona.

Vantaggi: Fornisce protezione dell'integrità end-to-end per i dati di zona, non solo durante il trasferimento ma anche quando i dati sono serviti ai resolver.

Limitazioni: Richiede che la zona sia firmata DNSSEC. Non protegge il protocollo AXFR stesso (ad esempio, contro client non autorizzati).

Sicurezza a livello di rete

Oltre ai meccanismi di sicurezza a livello di applicazione, i trasferimenti AXFR POSSONO essere protetti utilizzando la sicurezza a livello di rete:

1. TLS/SSL: Crittografare la connessione TCP utilizzando TLS o SSL fornisce protezione della riservatezza e dell'integrità per il trasferimento di zona. (Nota: DNS-over-TLS per i trasferimenti di zona non è standardizzato al momento della stesura.)

2. IPsec: I trasferimenti di zona condotti su connessioni protette da IPsec beneficiano della riservatezza, integrità e autenticazione fornite da IPsec.

3. VPN o reti private: Condurre trasferimenti di zona su una rete privata (come una VPN) può fornire un ulteriore livello di sicurezza.

Raccomandazioni

1. Utilizzare TSIG o SIG(0): I server e client AXFR DOVREBBERO supportare e utilizzare TSIG o SIG(0) per proteggere i trasferimenti di zona. TSIG è la soluzione più comunemente distribuita ed è RACCOMANDATA per la maggior parte delle distribuzioni.

2. Validare i dati trasferiti: I client AXFR DOVREBBERO validare l'integrità dei dati di zona ricevuti prima di impegnarli nel loro database di zona locale. Per le zone firmate DNSSEC, questa validazione include la verifica delle firme DNSSEC.

3. Gestione sicura delle chiavi: Per le distribuzioni basate su TSIG, gli operatori DEVONO assicurarsi che le chiavi condivise siano generate utilizzando generatori di numeri casuali crittograficamente forti e siano conservate e distribuite in modo sicuro.

4. Monitorare le anomalie: Gli operatori DOVREBBERO monitorare i trasferimenti di zona per anomalie, come cambiamenti inaspettati nella dimensione della zona, frequenze di trasferimento insolite o controlli di integrità falliti.

5. Utilizzare algoritmi forti: Quando si utilizza TSIG, gli operatori DOVREBBERO utilizzare algoritmi HMAC forti, come HMAC-SHA256 o HMAC-SHA512, piuttosto che algoritmi più deboli come HMAC-MD5. Vedere [RFC4635] e [RFC5702] per indicazioni sulla selezione degli algoritmi.

Gestione dei fallimenti di integrità

Se un client AXFR rileva un fallimento di integrità (ad esempio, fallimento della validazione TSIG, fallimento della validazione DNSSEC), DEVE:

1. Scartare tutti i dati ricevuti dal trasferimento di zona fallito.
2. Registrare il fallimento per scopi di audit e risoluzione dei problemi.
3. Opzionalmente, riprovare il trasferimento di zona dopo un ritardo appropriato (con backoff).

Un client AXFR NON DEVE committare dati di zona parzialmente ricevuti o falliti nell'integrità nel suo database di zona autoritativo, poiché farlo potrebbe risultare nel servire dati errati o malevoli ai client DNS.