You can use many different tools to find out if DNSSec is enabled in the zones that are pertinent to you. One of my online GUI favorites is SecSpider, which tracks DNSSec-enabled zones; it shows that more than 287,000 DNS zones are now signed. Via its search feature, you'll find that InfoWorld.com and many other zones aren't signed, but Comcast.com is.

You can't control other people's DNS servers, but at least make sure your own clients and DNS servers are DNSSec enabled. You can be prepared to support and use DNSSec as it becomes more widely available. DNSSec, once enabled, is almost invisible. You get all the possible benefits and no disadvantages.

Microsoft Windows operating systems have been supporting DNSSec since Windows Vista/Windows Server 2008, though there is no built-in backward support for XP or 2003. Mainly, you want Windows 8 and Windows Server 2012 to get widely usable and easily configurable DNSSec. The previous versions supported older protocols and weren't compatible with most of the Internet; additionally, the server component was much harder to configure. Setting up DNSSec in Windows 2012 is a dream.

BIND DNS has been DNS capable since at least version 9. Most open source operating systems have supported DNSSec for many years, but check each distro for details; older versions won't always work with newer versions. I know that DNSSec has been available on the Mac OS X platform for a few years, but I haven't tried to enable it on the iPad or iPhone; I suspect DNSSec can be enabled on these platforms as well. Android devices support DNSSec, but many mobile platform users interested in DNSSec employ apps or browsers that specifically look for and validate DNSSec on the website in question. See the following video as an example.

DNSSec pushbackNot everyone loves DNSSec. It has been around for almost 10 years and still is not widely deployed. It used to be hard to configure, and the top-level domains weren't signed. Now it's easier to configure, and the root- and top-level domain servers participate. There is no excuse for not deploying DNSSec.

Dr. Daniel J. Bernstein got tired of waiting for DNSSec to take over the world and created his own competing standard known as DNSCurve. It functions a lot like DNSSec, but it uses ECC (Elliptical Curve Cryptography), which is considered more secure for smaller key sizes.

There are two other common critiques about DNSSec besides its lack of general availability. One: it doesn't encrypt the answers. DNSSec is about integrity and making sure the client resolver is not spoofed or tricked. It doesn't protect the network channel against sniffing. If you want that, you'll need to overlay DNSSec with another network protection channel protocol such as IPsec.

Lastly, there's talk about how DNSSec can make DNS reflection attacks worse. Because DNSSec-enabled servers always respond with signed records, the digital signature itself is usually much bigger than the answer. In short, a DNSSec-enabled server can amplify a spoofed DNS packet many times larger than a non-DNSSec-enabled packet. I have three answers for that:

You shouldn't have an open recursive DNS relay. They are all bad, whether DNSSec is enabled or not. I have to believe that the incidences of open recursive DNS DNSSec-enabled servers is far less than non-DNSSec-aware DNS servers.

It's possible to make larger DNS packets matching the size of DNSSec-enabled packets without using DNSSec. DNSSec makes it easier, but the hackers can do it regardless.

DNSSec usage is growing. There's a learning curve when you first get into it, as well as a moderate amount of configuration to both servers and clients. But repeat after me: You cannot rely on DNS without DNSSec. Get ahead of the curve and get your clients and servers ready. Disappoint a black-hat hacker today.