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!

As of Dec 31, 2006, London is online.

On our network map, we show our four current network nodes in the United States, and provide insight into our future locations. The map, dated July 7, is still accurate as I type this.

The first location online from our “Coming soon” contingent will be London, England. Our hardware is racked and powered in the London facility. But we’ve been held up by bandwidth discussions, as we have some specific network requirements that complicate the matter beyond just the cost of connectivity.

The delay is frustrating to us, too. My apologies to the several folks who have inquired and been told (by me personally, or by my colleagues) that London would be online by this time. I’m not going to promise a new date right now, but we’re working on this, and will announce more details on our blog as we have them. Once the London location is online, we’ll focus more attention on our next locations.

Fortunately, many customers are finding that OpenDNS is faster for them in the UK already, despite any network latency. That’s proof positive that DNS speed is the combination of two factors: network latency and software speed/cache size. Even when we’re “farther” away on the network, OpenDNS often delivers results back to the end user faster. We want to accelerate the experience again, by removing the network latency concern — which is the whole point of London.

Is it only me, or does this post beg for The Clash’s London Calling? Or is that just too much of a cliché?

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/.

Cameroon is at it again, wildcarding all of the .cm namespace so they can put advertisements up when you typo .com domains like http://www.google.cm. Since August 9, OpenDNS users have had the option to undo this change and decide how they want it handled. There is an option on our preferences page where you can decide how you want this dealt with for your computer or network.

As a reminder, if you do turn on .cm to .com wildcard filtering, all real .cm domains will still work!. That includes domains like airfrance.cm and others that we listed.

We don’t know why Cameroon (or its operator) is flip-flopping on this one, but I’d encourage you to turn this preference on and leave it on.

CNET just rehashed a report (pdf of report) that our friends over at Nominum commissioned to look at the speed and reliability of ISP DNS servers. The verdict won’t shock any of you: ISPs are pretty bad at providing DNS.

Some of the numbers they put in the report are surprising. The report says that Verizon drops 3.14% of all DSL subscribers’ DNS requests. That is some messed up DNS!

The report goes on to talk about other ISPs including SBC, RoadRunner, Comcast, who all do relatively poor jobs at providing such a critical service. I’m bummed they didn’t review Speakeasy, an ISP I’ve always really liked and whose DNS servers have always performed reasonably. The report states that Comcast only drops 0.51% of queries which is amusing because most people tend to attribute bad DNS service with Comcast. We know that the reliability of the DNS is important and we keep our system reliability statistics totally open and accessible. I challenge Verizon or Comcast to do the same.

What’s the point of all this? This report really shows that there is a lot of room for improvement in the DNS space and it clearly starts with reliability and performance, two things we cover well. Reporters still don’t understand the importance of DNS because it’s much more than just about speed. That’s one important part but the other is that DNS is a major part of the Internet and just like there are firewalls and anti-spam solutions, users needs tools to manage their DNS too.

Bringing this issue to light is a good thing. Even though we didn’t pay for or commission this report, I can’t help to think it was made to open ISPs’ eyes to our service. We’ve created an opportunity for ISPs where there was none before. OpenDNS provides these kinds of tools to users.

As much as I would love an ISP like Verizon to work with OpenDNS to make their users’ Internet better I would be upset if it was done arbitrarily and not on an opt-in basis. If I were a Verizon user currently using their three-percent-query-dropping DNS I’d switch to OpenDNS in a heartbeat. It’s easy to get started with OpenDNS right now.