DNS name resolution doesn't work on systems without a direct connection to the internet

[Austin S. Hemmelgarn]

This is currently the only program that I am having this problem with, and it doesn't appear to be a problem for the 64-bit version that I have installed on my laptop. The computer itself is connected to the internet through a wired connection to an Apple AirPort Extreme which is in turn connected to a cable modem. The AirPort is configured to act as a DNS server, and it works for everything else on the system. The problem appears to go away when I connect the system directly to the cable modem. I have also been able to reproduce this problem inside a virtual machine with a standard install of 32-bit Xubuntu 11.10

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: distributed-net 2.9107.516-1
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic i686
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Mon Apr 16 21:02:30 2012
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111011)
ProcEnviron:
 LC_TIME=mul.UTF-8
 LANG=en_US.UTF-8
 SHELL=/bin/bash
 LC_NUMERIC=mul.UTF-8
SourcePackage: distributed-net
UpgradeStatus: No upgrade log present (probably fresh install)

[James E. Stark (jstark-ieee)]

That is strange. With your machine that isn't directly connected to the net could you take a look at your /etc/resolv.conf and make sure that it has at least one DNS server listed. Assuming that it does test it by running the following on the command line:

host ubuntu.com <ip address found in resolv.conf>

Distributerd.net generally needs old school dns settings, and generally doesn't play well with multicast DNS. My suspicion is that your airport is trying to do multicast DNS, and it's breaking distributed.net. If the host command above works, and distributed.net doesn't, then things get interesting.

James

[Austin S. Hemmelgarn (ahferroin7)]

I've played around a little with the contents of resolv.conf, currently it's configured so that it will query itself if unbound is running, otherwise it uses Google's public recursive DNS server at 8.8.8.8, and it only queries the AirPort if the first two fail.
As far as the AirPort goes, it's configured to preferentially use multicat, but it still works fine for unicast DNS as well.
What really has me confused though is that I don't have the same problem on my laptop, which uses the same network and DNS configuration. Also the problem occurs regardless of whether or not I have things lik libnss-mdns or avahi-daemon installed, and when I query any of the name servers directly with the hostname it is trying to access (us.v29.distributed.net.), I get back the correct results.

[Austin S. Hemmelgarn (ahferroin7)]

I think I have figured out what is wrong, I tried removing the default search domain line, and it started working just fine. After looking further into the name resolution code, it appears that libc is adding the default search domain to all queries; it would appear that the criteria for doing so has changed to any domain name that isn't fully qualified. I threw together a small program to test this, and resolving 'us.v29.distributed.net' fails but 'us.v29.distributed.net.' succeeds. Both however succeed when the computer is connected to the modem instead of the router, I think this may have something to do with the router using '.local.' as the top level domain for the local network. As for why this only affects the distributed.net client and not anything else, I have no idea.