BIND 9: query DNS non funzionanti ed errore “named: error (no valid DS)”

Se anche a voi capita che il vostro DNS caching server basato di BIND non riesca più a risolvere gli indirizzi e nei log è presente un errore simile a:

Oct 26 18:37:10 squid named[1536]: error (no valid DS) resolving ‘www.google.com/A/IN’: 192.168.1.1#53

la causa è da ricercare nel fatto che l’upstream DNS non riesce a soddifare le richieste DNSSEC del nostro caching DNS: se potete, quindi, cambiate DNS upstream.
Per disattivare le query DNSSEC da BIND, è sufficiente rimuovere, o commentare, da named.conf l’opzione “dnssec-enable yes“.

 

Windows7: come ottimizzare le performance del file sharing di SMB

Windows7 può essere usato, in una LAN casalinga o in un piccolo ufficio, anche come file server offrendo buone prestazione: è tuttavia possibile ottimizzare e migliorare le performance di SMB per l’utilizzo specifico come file server, a patto di “consumare” un po’ più memoria RAM.
L’impostazione di default del sottosistema server di SMB, infatti, non prevede l’utilizzo di caching per i file e minimizza l’utilizzo della memoria dedicata al file sharing.

Per attivare il caching dei file è sufficiente editare il parametro di registry:

HKLMSYSTEMCurrentControlSetControlSession ManagerMemoryManagementLargeSystemCache

e settare LargeSystemCache a valore “1“.

Per allocare un maggiore quantitativo di memoria per il file sharing è inoltre necessario editare il paramentro di registry:

HKLMSYSTEMCurrentControlSetServicesLanmanServerParametersSize

e settare Size a valore “3“.

 

[reblog] TCP Tricks to Detect Rogue Wireless Access Points

tratto da http://isc.sans.edu/diary.html?storyid=10615

…If rogue APs are plugged into your network, they will decrease the TTL value in all packets by one that traverse through the access point.  This can make it easy to detect the presence of those by using p0f/tcpdump/snort to look for packets that have TTL values that are lower than expected.  This also works for unauthorized routers, virtual images, bad network stack configurations, etc.  It won’t detect APs that aren’t plugged into your network and has some gaps (for instance, a savvy individual could modify the TTL they use before sending packets out), but again it is a “dirty” method of detection.  The advantage of looking for bad “TTLs” is that you will also have advance detection of network problems as well.
You can profile your network and find legitimate TTL values by running tcpdump -v and verifying the information with a network diagram (each router, NAT device, etc will lower TTL by 1).