I professionisti della sicurezza per decenni hanno consigliato alle persone di limitare le query DNS rispetto ai loro server DNS per utilizzare solo la porta UDP 53. La realtà è che le query DNS possono anche utilizzare la porta TCP 53 se la porta UDP 53 non è accettata. Ora con l’imminente distribuzione di DNSSEC e l’eventuale aggiunta di IPv6 avremo bisogno di consentire ai nostri firewall per inoltrare sia i pacchetti TCP che UDP port 53.

DNS può essere utilizzato dagli aggressori come una delle loro tecniche di ricognizione., Le informazioni pubbliche contenute nei server di un obiettivo sono preziose per un utente malintenzionato e li aiutano a focalizzare i loro attacchi. Gli aggressori possono utilizzare una varietà di tecniche per recuperare le informazioni DNS tramite query. Tuttavia, gli hacker spesso cercano di eseguire un trasferimento di zona dai server DNS autorevoli per ottenere l’accesso a ancora più informazioni. È possibile utilizzare il comando dig per raccogliere informazioni da un server per un file di zona specifico.,

dig @192.168.11.24 example.org -t AXFR

I trasferimenti di zona avvengono sulla porta TCP 53 e per impedire ai nostri server DNS di divulgare informazioni critiche agli aggressori, la porta TCP 53 è in genere bloccata. Se il firewall dell’organizzazione che protegge il server DNS autorevole consentiva i pacchetti TCP port 53 e il server DNS era configurato per consentire trasferimenti di zona a chiunque, questo comando dig avrebbe avuto successo. Tuttavia, la maggior parte delle organizzazioni ha configurato i propri server DNS per impedire trasferimenti di zona da server DNS non intenzionali., Questo può essere configurato nel file di zona BIND utilizzando una qualsiasi di queste forme del comando allow-transfer come mostrato di seguito.

allow-transfer {"none";}; allow-transfer { address_match_list }; allow-transfer {192.168.11.11;};

Inoltre, la maggior parte delle organizzazioni ha utilizzato anche firewall per bloccare la porta TCP 53 da e verso i propri server DNS e Internet. Questa è una doppia protezione nel caso in cui il server DNS abbia permesso accidentalmente trasferimenti.

Configurare i server DNS per consentire trasferimenti di zona solo ai server DNS legittimi è sempre stata e continua ad essere una best practice., Tuttavia, la pratica di negare la porta TCP 53 da e verso i server DNS sta iniziando a causare alcuni problemi. Ci sono due buone ragioni per cui vorremmo consentire entrambe le connessioni TCP e UDP port 53 ai nostri server DNS. Uno è DNSSEC e il secondo è IPv6.

DNSSEC Crea risposte DNS più grandi

Amo leggere il diario IP e l’ho letto dal primo numero nel 1998.

Nella recente edizione di the IP Journal c’era un articolo di un mio amico, Stephan Lagerholm, di Secure64 e della Task force IPv6 del Texas, intitolato “Sfide operative quando si implementa DNSSEC”., Questo articolo ha coperto molte delle avvertenze che le organizzazioni si imbattono in mentre si muovono per distribuire DNSSEC.

Uno dei problemi chiave menzionati è che DNSSEC può causare risposte DNS più grandi di 512 byte. DNSSEC (definito in RFC 4033, RFC 4034 e RFC 4035) richiede la possibilità di trasmettere messaggi DNS più grandi a causa delle informazioni chiave aggiuntive contenute nelle risposte alla query. Porta TCP 53 può essere utilizzato nei casi in cui le risposte DNS maggiore di 512 byte., Tuttavia, l’utilizzo di messaggi UDP è preferibile all’utilizzo di TCP per messaggi DNS di grandi dimensioni è dovuto al fatto che le connessioni TCP possono consumare risorse di calcolo per ogni connessione. I server DNS ottengono numerose connessioni al secondo e l’utilizzo di TCP può aggiungere troppo sovraccarico. Per risolvere questo problema, IF RFC 2671 ” Meccanismi di estensione per DNS (EDNS0)” definisce un metodo per estendere la dimensione del buffer UDP a 4096 byte per consentire DNSSEC e risposte di query più grandi., Per abilitare EDNS0 nella configurazione di BIND 9 è possibile utilizzare la seguente istruzione BIND operations

edns-udp-size 4096 ;

La consapevolezza del DNSSEC è aumentata a causa delle vulnerabilità divulgate 2 anni fa e delle recenti notizie sul governo degli Stati Uniti che si sforzano di implementarlo. Molte organizzazioni hanno pianificato le loro implementazioni DNSSEC. DNSSEC sta diventando più ampiamente distribuito ora che i domini di primo livello chiave (TLD) vengono firmati. Il TLD. org è stato ora firmato. La zona radice di Internet è stata firmata solo 2 mesi fa in una cerimonia in Virginia., VeriSign ha dichiarato il desiderio di supportare DNSSEC per. com e. net entro il 2011. Comcast ha creato un sito DNSSEC Information Center che può aiutare a tenersi aggiornati sulle ultime stato DNSSEC.