Hi! Thanks for a useful resource. If you change your DNS lookup method, I think you'll have fewer false positives where you list domains as being available, w

Hi! Thanks for a useful resource. If you change your DNS lookup method, I think you'll have fewer false positives where you list domains as being available, when they actually aren't. For example: readia.com is not available, but the wordoid site says it is. If you do a DNS lookup at the .com core servers, rather than your local resolver, you'll get a list of NS servers for the domain - if it's blank there, then you know the entry doesn't exist. The current problem is occurring because your resolver library is trying to walk the DNS tree all the way to the DNS servers that are supposed to manage the domain. When those servers are down or unresponsive, wordoid is marking the domain as "available" - even when it's not. Here's an example that I think demonstrates the problem, and a potential way around it: dig ns readia.com. @a.gtld-servers.net. ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22290 Note that it indicates no error. For a nonexistant domain the results are different. The NXDomain means "no such domain". dig ns this-really-does-not-exist-at-all-1321.com. @a.gtld-servers.net. ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43679 Of course, you'll need to switch between the relevant gtld-servers so that you're a good network citizen, and cache results. See "dig ns com." for a current list of GTLD servers. Also, I'd like to echo the comments of other readers - if you place a "go" button near the input form, rather on the top left, it'll improve the user-interface significantly. Thanks again, and I hope the above helps you. Oskar Pearson