Posts tagged DNS

BlueCoat ProxySG – Flush DNS and Cache

Oct 2nd

Posted by Michael McNamara in BlueCoat

1 comment

There can be a few occasions where you may need to manually purge the local DNS cache and/or the actual web cache of a Blue Coat ProxySG appliance. While both the DNS cache and web cache will eventually age out it can be helpful to sometimes speed up the process by flushing/purging the DNS and web cache.

While this can all be done from the web interface I generally prefer the CLI (if available). The Blue Coat ProxySG appliances that I managed are setup for SSH access you may need to confirm that SSH is enabled (telnet might be enabled).

Let’s start by connecting to the BlueCoat ProxySG appliance (proxysg.acme.org);

[root@linuxhost etc]# ssh -l admin proxysg.acme.org
admin@proxysg.acme.org's password:

proxysg.acme.org - Blue Coat SG510 Series>

Once we’re connected we need to go into privledged mode to issue the commands;

proxysg.acme.org - Blue Coat SG510 Series>enable
Enable Password:

Now that we’re in privledged mode we can clear the web content cache with the following command;

proxysg.acme.org - Blue Coat SG510 Series#clear-cache
ok

And to clear the DNS cache we can use the following command;

proxysg.acme.org - Blue Coat SG510 Series#purge-dns-cache
ok

And don’t forget to logout when you’re all done.

proxysg.acme.org - Blue Coat SG510 Series#exit
Connection to proxysg.acme.org closed.

Cheers!

, , , , , ,

Domain Name Server patch

Jul 13th

Posted by Michael McNamara in Security

No comments

O'Reilly DNS and BIND Last week there was a flurry of information revolving around a new security flaw in the Domain Name System — software that acts as the central nervous system for the entire Internet.

On Tuesday July 10, 2008 a number of vendors including Microsoft, Cisco, Juniper and RedHat released patches and/or acknowledged the flaw existed. The Internet Software Consortium, the group responsible for development of the popular Berkeley Internet Domain Named (BIND) server from which nearly all DNS offshoots are based, also acknowledged the flaw and released a patch.

I personally spent about 90 minutes on last Wednesday updating several internal and external systems including numerous CentOS v5.2 servers and Windows 2003 Service Pack 2 servers. I was unable to find any mention of the DNS flaw on the Alcatel-Lucent website so I’ll probably need to place a call concerning Alcaltel-Lucent’s VitalQIP product.

I used yum to patch the CentOS Linux servers ["yum update"] and then just restarted the named process ["service named restart"]. On the Windows 2003 Service Pack 2 servers I used Windows Update to download and install KB941672 after which I rebooted the servers.

Here are some references:

http://www.theregister.co.uk/2008/07/09/dns_fix_alliance/
http://www.networkworld.com/news/2008/071008-patch-domain-name-servers-now.html
http://www.networkworld.com/news/2008/070808-dns-flaw-disrupts-internet.html

http://www.networkworld.com/podcasts/newsmaker/2008/071108nmw-dns.html

http://www.us-cert.gov/cas/techalerts/TA08-190B.html
http://www.microsoft.com/technet/security/bulletin/MS07-062.mspx

I would strongly suggest that all network administrators start looking into patching their DNS servers as soon as possible.

Cheers!

UPDATE: July 14, 2008

Here’s an update from RedHat concerning the configuration (named.conf) of BIND;

We have updated the Enterprise Linux 5 packages in this advisory. The default and sample caching-nameserver configuration files have been updated so that they do not specify a fixed query-source port. Administrators wishing to take advantage of randomized UDP source ports should check their configuration file to ensure they have not specified fixed query-source ports.

It seems that a check of the configuration file would be in order. Let me throw in a quick warning though if your DNS server is sitting behind a firewall you may need to check with the firewall administrator to understand how the firewall will behave if you randomize your source ports. I believe there are quite a few firewalls out there that only expect to see DNS traffic sourced from a DNS server on UDP/53.

Good Luck!

, , , ,