The time has arrived!  Malware Monday, as some have labeled it.  The FBI has shut off the DNS servers it maintained to allow those infected with the malware to continue to operate and provide additional time for cleanup.  The malware re-directed web site requests to sites where the its authors could make money off of advertising — so called “click hijacking.”  And make money they did — supposedly about $14 million USD. (more…)


For about as long as I can remember, every serious DNS administrator has always advocated the use of dig (Domain Information Groper) over nslookup.  There’s no need for me to rehash all of the arguments — I’ll just say that dig returns information in a manner consistent with what a protocol analyzer might provide.  That’s great, but isn’t it only for Un*x systems?  I need to be able to debug from a Windows system. (more…)

DNS has been a source of concern for security practitioners for years.  I think of the domain name system as the language center of the Internet brain.  Without it, we’re reduced to pantomime and smoke signals.  The major news of last year was the practical method of poisoning DNS caches of remote servers discovered by Dan Kaminsky. Most recently, we’ve seen news of a trojan that seems to be a variant of Trojan.Flush.M, first seen last December, that targets your entire LAN by leveraging another commonly-used protocol.

For some reason, DNS scares a lot of people — and the most frightening of all is probably zone delegation in the in-addr.arpa space on non-octet boundaries. That’s probably why most small organizations leave this entirely to an ISP, and then deal with some web-based tool for making changes to the zone, rather than operating their own master nameserver for these zones and leaving the ISP to provide secondary service.

RFC2317 outlines the technique thoroughly, based on a trick described by Glen Herrmannsfeldt on comp.protocols.tcp-ip.domain. Below is a brief description of how this works. Read the RFC for the complete details. (more…)