practicienii de securitate de zeci de ani au sfătuit oamenii să limiteze interogări DNS împotriva serverele DNS pentru a utiliza numai UDP port 53. Realitatea este că interogările DNS pot utiliza și portul TCP 53 dacă portul UDP 53 nu este acceptat. Acum, cu implementarea iminentă a DNSSEC și eventuala adăugare a IPv6, va trebui să permitem firewall-urile noastre pentru a transmite atât pachetele TCP cât și portul UDP 53.DNS poate fi folosit de atacatori ca una dintre tehnicile lor de recunoaștere., Informațiile publice conținute de serverele unei ținte sunt valoroase pentru un atacator și îi ajută să-și concentreze atacurile. Atacatorii pot utiliza o varietate de tehnici pentru a prelua informații DNS prin interogări. Cu toate acestea, hackerii încearcă adesea să efectueze un transfer de zonă de pe serverele DNS autoritare pentru a avea acces la și mai multe informații. Puteți utiliza comanda dig pentru a aduna informații de la un server pentru un anumit fișier zonă.,

dig @192.168.11.24 example.org -t AXFR

transferurile de Zone au loc pe portul TCP 53 și pentru a împiedica serverele DNS să divulge informații critice atacatorilor, portul TCP 53 este de obicei blocat. Dacă firewall-ul organizației care protejează serverul DNS autoritar a permis port TCP 53 pachete și serverul DNS a fost configurat pentru a permite transferuri de zonă oricui, atunci această comandă dig ar avea succes. Cu toate acestea, majoritatea organizațiilor și-au configurat serverele DNS pentru a preveni transferurile de zone de la serverele DNS neintenționate., Aceasta poate fi configurată în fișierul BIND zone folosind oricare dintre aceste forme ale comenzii allow-transfer, așa cum se arată mai jos.mai mult, majoritatea organizațiilor au folosit firewall-uri pentru a bloca portul TCP 53 către și de la serverele DNS și Internet. Aceasta este o protecție dublă în cazul în care serverul DNS a permis accidental transferuri.configurarea serverelor DNS pentru a permite transferurile de zone numai către serverele DNS legitime a fost întotdeauna și continuă să fie o bună practică., Cu toate acestea, practica de a refuza portul TCP 53 către și de la serverele DNS începe să provoace unele probleme. Există două motive întemeiate pentru care am dori să permitem atât conexiunile TCP, cât și portul UDP 53 la serverele noastre DNS. Unul este DNSSEC, iar al doilea este IPv6.

DNSSEC creează răspunsuri DNS mai mari

îmi place să citesc Jurnalul IP și l-am citit de la primul număr din 1998.în ediția recentă a IP Journal a existat un articol al unui prieten de-al meu, Stephan Lagerholm, de la Secure64 și Texas IPv6 Task Force, intitulat „provocări operaționale la implementarea DNSSEC”., Acest articol a acoperit multe dintre avertismentele pe care organizațiile le întâlnesc în timp ce se deplasează pentru a implementa DNSSEC.una dintre problemele cheie menționate este că DNSSEC poate determina ca răspunsurile DNS să fie mai mari de 512 octeți. DNSSEC (definit în RFC 4033, RFC 4034 și RFC 4035) necesită capacitatea de a transmite mesaje DNS mai mari datorită informațiilor cheie suplimentare conținute în răspunsurile la interogare. Portul TCP 53 poate fi utilizat în cazurile în care răspunsurile DNS mai mari de 512 octeți., Cu toate acestea, utilizarea mesajelor UDP este preferabilă utilizării TCP pentru mesajele DNS mari se datorează faptului că conexiunile TCP pot consuma resurse de calcul pentru fiecare conexiune. Serverele DNS obțin numeroase conexiuni pe secundă și folosind TCP se poate adăuga prea mult deasupra capului. Pentru a rezolva această problemă, IETF RFC 2671 „mecanisme de extensie pentru DNS (EDNS0)” definește o metodă de extindere a dimensiunii tamponului UDP la 4096 octeți pentru a permite răspunsuri de interogare DNSSEC și mai mari., Pentru a permite EDNS0 pe BIND 9 configurare puteți utiliza următoarele LEGA operațiuni declarație

edns-udp-size 4096 ;

Conștientizare a DNSSEC a crescut ca urmare a unei vulnerabilități a dezvăluit în urmă cu 2 ani și cu știri recente despre guvernul sua străduindu-se să-l pună în aplicare. Multe organizații și-au planificat implementările DNSSEC. DNSSEC devine din ce în ce mai larg implementat acum că domeniile cheie de nivel superior (TLD) sunt semnate. TLD. org a fost semnat acum. Zona de rădăcină a Internetului a fost semnat doar 2 luni în urmă într-o ceremonie în Virginia., VeriSign și-a declarat dorința de a sprijini DNSSEC pentru .com și.net până în 2011. Comcast a creat un site DNSSEC Centrul de informare care vă poate ajuta să fiți la curent cu cele mai recente starea DNSSEC.