We’ve announced OpenDNS CacheCheck, available at http://cache.opendns.com. If you wonder what’s in the OpenDNS cache for a domain, take a look. If you want OpenDNS to refresh its cache for a domain, use CacheCheck to do it yourself.

Background on CacheCheck

Because we’ve seen such vibrant adoption (thanks!), OpenDNS has established itself as the leader in recursive DNS services. People expect more from a leader, as they should. So, when a domain doesn’t resolve — especially one they’ve visited successfully before — users are quick to ask us “What’s wrong? Why does ‘insert-domain-name-here’ not resolve?”

We welcome these questions: our entire company is built around getting you where you want to go on the Internet as fast as possible and as reliably as possible. If there’s a problem we can fix, we want to know about it immediately.

But we’re not responsible for the entire DNS; we’re just a visible link in the chain. When a valid domain is not resolving, there are two common possibilities:

1. the domain is being moved, and the old address is still cached since the Time-To-Live (TTL) has not expired
2. the domain’s nameservers are not responding

For #1, CacheCheck lets you fix the problem immediately. OpenDNS has a huge cache to help make your Internet experience faster. OpenDNS usually holds an address for the full TTL (never longer!!). So, if a domain has been moved without lowering the TTL first, we may have the old address cached. CacheCheck, please! (groan)

We can’t do anything about #2 yet, but we can make the situation clear both to the domain owner and the would-be website visitor.

CacheCheck came from an internal tool we built to let us peek into our cache, and selectively clear it. Today, that unique functionality is available to everyone. No one else offers this kind of control and insight. You can ask any recursive DNS server for an address, but if the answer is wrong, there’s no recourse and little information.

Domain owners, especially, should find this first-of-its-kind tool valuable for domain management. Everything we do at OpenDNS is aimed at making the Internet better through DNS. CacheCheck is our first feature aimed squarely at domain owners. Fortunately, anyone who visits a website benefits, too.

P.S. Terri Wells at Devshed got some early insight into this tool for her article “OpenDNS on Mission to Improve Domain Name System” published last week. See page 4.

P.P.S. For the record, OpenDNS always suggests lowering TTL before migrating a domain to a new server. But we understand that domain migrations are not always planned, so CacheCheck can help domain owners out of a BIND (bad DNS humor).

I’ve just posted about this on the OpenDNS System Status site, but the OpenDNS.com website (and blog.opendns.com, etc.) were unavailable due to authoritative DNS failure for about 90 minutes earlier today, starting around 1pm PT (21:00 UTC). Here are the details.

I will repeat myself on a few key points.

First, OpenDNS’s speedy, reliable DNS was not affected. Our website is treated separately from our DNS, for this reason among others.

Second, the cause of the failure was a Denial of Service (DOS) attack on EveryDNS. David Ulevitch, CEO of OpenDNS, also owns and operates EveryDNS, but the two companies are separate. OpenDNS has used EveryDNS services, although we’ve now spread the authoritative DNS for OpenDNS more broadly as a result of this incident.

Third, the DOS attack on EveryDNS continues. It’s being actively worked on, as you can imagine. As we learn more, we’ll share it in this post, since I know other EveryDNS customers are interested, too.

Update: As of 9:30pm PT, December 1 (05:30 UTC December 2), EveryDNS is recovering. Still under attack, but mitigated. Status report on the EveryDNS home page. I’ll leave it to EveryDNS for updates from here on.

Note: you can bookmark or save our OpenDNS System Status site at http://208.67.219.60/ just for rare events like this, whether there is an authoritative or recursive DNS issue.

While I’ve publicly speculated before, I now have official confirmation from Hughes that HughesNet customers cannot use OpenDNS — or any other alternate DNS service — at this time.

In HughesNet’s terms:

Every remote [computer] uses the HughesNet turbo page servers, which only use HughesNet DNS.

The “turbo page servers” are the proxy which HughesNet uses to limit the latency imposed by satellite connnections.

There is one workaround, but it doesn’t sound like an improvement, and no one (not Hughes, not me) recommends it. Still…for curious technical folks, you may choose to not use the HughesNet turbo page servers. If you do that, then you may use an alternate DNS provider, including OpenDNS. However, given the latency of satellite broadband, I can’t imagine that faster DNS will counteract slower download speeds, as much as I might hope it would.

I don’t have official answers/confirmation from other satellite ISPs, but I expect the story is similar.

Update: We’ve gotten great response from D-Link and Actiontec customers. No need to send anymore. Still waiting on confirmation about Blackberry.

We realize there are lots of popular (and not-so-popular) routers and modems we don’t have instructions for on our site. But it’s hard writing instructions for a device you don’t have in front of you. That’s why we’re calling on you to help us build out our Get Started library. At the top of our wish list are instructions for these models:

* D-Link DGL-4300
* D-Link DI-604
* Actiontec GT701
* Actiontec GT704

Inititally we thought we could write instructions based on user manuals. We found the manuals, but they didn’t provide enough information to teach others how to change DNS settings.

This just in: For Verizon users and others, we added instructions for the very popular Westell 327w today.

If you are so kind as to help us (and other OpenDNS users who share in your router or modem taste) out with instructions, please send a few bulleted steps based on any of the instructions we already have. Screenshots to accompany the steps would be great, too. Anyone who sends in accurate instructions will get a shout-out on our Web site and will forever be known as the helpful author of the [insert your router/modem model here] instructions.

Don’t worry about perfection. At this point anything will help us. And, of course, it’s our job to polish up the instructions and make them look pretty for the site.

There is also the possibility that some routers/modems don’t allow users to change DNS settings. That information is as helpful, if not more, than instructions.

Just send an e-mail with the instructions and screenshots, or other feedback, to contact at opendns dot com.

Oh, and if you have a Blackberry and can verify that these instructions work, we’d really appreciate it.

1. Go to Start->Network Connections->Show All Connections
2. Right-click your BlackBerry Internet icon, select Properties.
3. A window will open. Click the Server Types tab.
4. Click TCP/IP Settings.
5. Select “Use the following DNS server addresses:”
6. Enter 208.67.222.222 and 208.67.220.220.

I’m doing this blog post in two pieces; a short explanation up top and then a more technical explanation down below. Pick one or read both and learn a bit.

Just the facts

If you want to use OpenDNS nameservers and DNSBLs (DNS real-time Blacklists) on the same server, computer or network, go right ahead. We’ve rolled out a new feature today that allows you to use our much-loved typo-correction service without worrying about blocking email if you’re running a mail server, too. We went ahead and rolled this out as as a system upgrade so there’s no new preference for it. We’ve updated the FAQ entry on mail servers accordingly. Now DNSBL spam prevention and typo-correction go together like peanut butter and jelly (or chocolate… your choice).

If you were previously not using the typo-correction service because you also ran a mail server then head on over to the preferences page and re-enable it.

Talk nerdy to me

DNSBLs carry information about known IP addresses in their zone of DNS. This is often used to combat spam because a mail server can ask a DNSBL “Do you know anything about this IP?” They cleverly use the DNS to make this process quick and seamless. A mail server that gets a request to deliver mail from 192.168.1.2 asks a DNSBL: “Do you know anything about 2.1.168.192.in.yourdnsbl.tld?” and the DNSBL either says “yes I do” or “no I don’t.” The problem is created because when a mail server is using OpenDNS and asks us to correct typos, we interpret the “no I don’t” answer (called RCODE=3 or NXDOMAIN) as a typo that should be forwarded off to our typo-correction service. This causes a mail server to not see the “no I don’t” and instead believe that the answer was “yes I do” which can cause a mail server to block a message thinking it’s from a spam sender. Previously, the only way to fix this was to disable typo correction, one of the benefits of using OpenDNS.

Our solution has been to disable typo-correction for DNSBL-matching requests. What’s a DNSBL-matching request? Any request greater than six labels which has four numerical octets within the IPv4 addressing space for the last-most labels is considered a DNSBL-style request. This wasn’t offered as a preference as turning this off would only lead to confusion, especially with typo-correction enabled.

End of the story? You can get the typo-correction you want and run a mail-server that uses DNSBLs without worrying. Enjoy!

We like hearing from our customers, in just about every way possible. Nothing makes us feel more confident that we’re doing the right things than hearing from you. Also, when we make mistakes (it happens), we want to know about it ASAP so we can fix the problem.

Right now, our listening is mostly via email, IM, comments on our blog, comments on external blogs. But we’d like to make our listening an actual audio experience.

So, give us a call and leave a voicemail at…

+1 (415) 344-3130

This number is not toll-free. Sorry. It’s a San Francisco, California, USA number.

No one will answer; you will hear some instructions, with three basic points:

• Speak clearly.
• If you want a response, be sure to tell us how to reach you (phone, email, otherwise).
• Important – we may use your voicemail comment and name on our website so others can hear what you have to say.

Our inspiration for this experiment

PocketMac Reviews. None of us are PocketMac customers, but listening to these comments, we wish we were!

Note: For the more “traditional” (?) contact methods, go to http://www.opendns.com/contact/.

We have a few confirmed reports of ISPs which do not allow their customers to use external DNS services, such as OpenDNS. These reports are from customers, not the companies. You can change your settings all you like on your end (computer, router, etc.), but they will be ignored/overridden.

We are trying to confirm these reports with the companies so our information is accurate and up-to-date. Inquiries via their websites and support lines have gotten no response, so I am making a more public request, both to the companies themselves and to their customers. I’d rather tell potential OpenDNS customers to avoid frustration than try and help them to no avail after they’ve wasted time trying to choose their own DNS.

NTL customers have been the most persistent in their attempts, to no avail. If you work for NTL (very large ISP in the UK), please get in touch.

If you work for a satellite broadband ISP, such as HughesNet (previously known as DirecWay), StarBand, or SkyWay USA, I’d love to hear from you. Satellite providers: if I didn’t mention your name, I’m still curious and interested…just haven’t heard from your customers yet. I know there are some peculiarities regarding latency for satellite access which probably are the reasons for the policy. Would love to brainstorm about technical solutions all the same.

If you are a customer of any of these companies, and you have better information, I’m listening.

My goal? Provide accurate information and instructions to potential OpenDNS customers on the Get Started page. As our FAQ notes, OpenDNS does not host websites, register domains, or act as an ISP.

How to contact us

Use the contact form or call us at +1-415-344-3166.

When we launched three weeks ago, we had a reasonable cross-section of instructions for some of the most popular routers and operating systems. We knew, of course, that there are many, many different devices and scenarios, and we’d have to keep updating our instructions to match the real world.

Our customers couldn’t wait for us (good!). My thanks for these instructions go to individual customers.

• Buffalo AirStation are courtesy of Zach Marshall.
• Windows Vista (Beta) are courtesy of Colton Hilliard.
• SpeedStream 5200 are courtesy of Luis Serrano.
• IPCop (Linux firewall application) are courtesy of James Truesdale.
• BIND9 forwarding instructions (in our FAQ) are courtesy of an early customer (apologies for not remembering whom!)

We’re adding more ourselves, of course, like Windows 98.

I’m not ashamed to continue asking for help, whether corrections or new screenshots and instructions. We’re quite happy to take raw materials and clean them up (add our orange highlights, spell-check, etc.) to help get the word out to others who might have the same equipment or situation.

Email us your instructions and screenshots: contact at opendns dot com. All the credit will be yours!

Additional information about static IP addresses

We’re learning, to our dismay, that some routers will only let their owners set DNS servers if the owner has a static IP address. Most folks connecting from home (i.e., those who would use the router instructions) have a dynamic IP address.

One example, which was confirmed today to a customer by Motorola customer support is the Motorola WR850 wireless broadband router. Both models, the GP and G, only allow DNS settings to be changed for static IP addresses (PDF manual). Frustrating, but good to know. Earlier, we learned that the Linksys WRT54GC Compact Wireless-G Broadband Router (PDF manual available via this page) has the same limitations.

Fortunately, most people can simply use the operating system instructions, and the settings “closest to the customer” are the dominant ones, corporate networks excluded.

All of this information will make its way into the Get Started pages as we learn more.