I think you may have a conceptual issue with how DNS works.
Only DNS servers performing recursive resolution cache lookups. The DNS servers that the affected users on "verizon DSL, comcast cable, verizon EVDO, site24x7 website" are using are the ones caching lookups.
The root DNS servers, .com servers, and the servers authoritative for your domain aren't caching lookups, because they're not providing recursive resolution service.
It's possible (likely, actually, from what I'm seeing in Google searches) that GoDaddy is sporadically returning NXDOMAINs for your domain, and those NXDOMAINs are being cached by recursive resolvers. (Per RFC2308, they should be cached, at most, either the TTL for the zone as specified in the SOA, or the SOA minimum-- whichever is least.)
Apparently, GoDaddy's "free" DNS service isn't too highly regarded. I don't use it, personally, so I can't comment on it.
There is no central "list" of DNS servers providing recursive resolution for you to "test against". (I have one here in my house, and I could spin a few more up on VMs if I needed to...) You need a reliable provider to be authoritative for your domain, and you just have to hope that everybody else in the world honors TTLs and acts as "good DNS citizens".
Edit:
"Recursive resolution" is the process by which the a DNS server resolves a record for which it is not authoritative. The process starts with the root DNS servers, and proceeds recursively (that is, a process that loops back on itself) through all the authoritative DNS servers for the domains specified in the query until the last DNS server is reached and the desired resource record (or a negative response) is returned.
For a three-level query, like "www.example.com", the following occurs (I am leaving out the fact that, all along the way, the ISP DNS server is checking its cache in lieu of issuing queries to remote DNS servers and putting the results it receives into its cache, to make this clearer and a bit more simplistic):
Your PC issues a query to your specified DNS server (at your ISP, for example).
The ISP DNS server verifies that it doesn't have a response in cache, and then queries one of the root DNS servers.
The root DNS server, only being authoritative for the root, responds with a list of DNS servers authoritative for the gTLD specified in the query (.com, .net, .tv, .fu, etc). The protocol continues as such, w/ the full query always being sent to each successive DNS server throughout this process. Since it's not possible to know which DNS server will be authoritative for any given query and we want to minimize the number of round-trips, we always send the full domain in each query.
The ISP DNS server queries one of the DNS servers returned as authoritative for the gTLD specified.
The gTLD DNS server, being authoritative for the second-level domain (example, microsoft.com, example.com, etc) only, responds with a list of DNS servers authoritative for the second-level domain.
The ISP DNS server queries one of the DNS servers returned as authoritative for the second-level domain.
The DNS server authoritative for the second-level, being for the third-level domain (www.microsoft.com, ftp.example.com, etc), domain returns the record requested.
The ISP DNS server returns the record your PC queried back to your PC.
Typically ISPs offer recursive resolution services to their Customers. The DNS servers at hosting providers that are authoritative for Customer hosted domains generally don't provide recursive service (and will return the root servers if queried for domains they aren't authoritative for).
I don't frequent SF so frequently, but I can see that this question has attracted a fair bit of attention, so let me just summarise my findings here, and hopefully provide something of a solution to those experiencing the same issue:-
It seems that this is a bug with the version of Avahi that ships with Ubuntu Jaunty (http://avahi.org/ticket/284) to do with supplying the UDP payload size, likely as a result in a more reccent change to the mDNS spec (though I haven't read it myself). As I explained in the comments to the original question, I did try to upgrade my version of Avahi, but my Linux skills are not what they should be and I didn't manage to get it to work. (Either way, running a 3 year old unsupported OS is really not recommended anyway...)
In the end, I took the plunge, wiped the SD card of the DreamPlug and installed Debian Squeeze on it, which worked fine (albeit only with iOS 5.0+). A discussion of how to change the DreamPlug OS is out of scope of this question, but what it all boils down to at the end of the day is an out of date version of Avahi. Use a newer version and you should be fine!
Good luck!
Best Answer
Hostname
mytestserver
is not in/etc/hosts
nor local/lan dns setup. This has nothing to do with avahi.This is related to avahi, check below.
In
/etc/nsswitch.conf
, thehosts
line should be as follow:files
means check /etc/hosts, thenmdns4_minimal
means check avahi.There are a few things to check in
/etc/avahi/avahi-daemon.conf
.In
server
section,allow-interfaces
should be unset/commented, or have the interface you intended to use avahi:Use
netstat
to check ifavahi
is listening on all interfaces:I encountered a few cases that line was uncommented and with the wrong interface in it, blocking avahi on the intended network.
In
publish
section, setpublish-workstation
to yes (the default is no):In general,
publish-addresses=yes
, which is the default, should be enough. However, with no share service(vnc/samba/etc) running, sometimes(base on past experience) avahi don't seems to publish/announce machine. So we enablepublish-workstation=yes
to force it.One last note, sometimes it takes 2 to 5min for avahi to pickup others boxes.