Ubuntu

DNS Resolves everything to 1.0.0.0 intermittently on some ADSL Routers

Reported by Mac on 2007-01-23
44
This bug affects 4 people
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Undecided
thqmas

Bug Description

Heaps of people all over the net are having issues with certain models of router sending back 1.0.0.0 for any DNS request. (Not only on Ubuntu)

***
wget www.google.com ---13:43:44-- http://www.google.com/ => `index.html.2' Resolving www.google.com... 1.0.0.0 Connecting to www.google.com|1.0.0.0|:80...
****

Usual answers include (that actually work)
- Set DNS in the router manually
- Set DNS in the computer manually (and lock/stop changing of resolv.conf)

also

- Disabling ipv6. (not proven to work)

These solutions are not actually solutions at all, they are workarounds, I'm unable to find a fix for it that does not involve setting manual DNS in the PC or router, but without this I can't use Ubuntu for my clients !!!

In my situation I have a standard build that needs to go worldwide with no editing or setting of manual DNS in the PC. (This also means that I can't access a clients ADSL modem to put the DNS settings in there).

Windows machines work fine.

It may be something about the router purporting to be a DNS Server when actually it's a DNS Forwarder?

On some of the routers, installing later firmware fixes it. (But not always). Using Windows always fixes it!

Why can't we do whatever windows does and have it "just work".

Do a google search for Ubuntu 1.0.0.0 and you'll see how many times this issue is happening !

(One forum suggested it could it be an MTU too high / iptables issue?)

This bug may be what people are meaning in Launchpad Bug #'s 24818 and 23183, but it was not explained in enough detail.

Mac (mac-jones) wrote :

http://hellewell.homeip.net/phillip/blogs/comments.php?y=06&m=03&entry=entry060319-000000&PHPSESSID=623cb6b4900902dd95f2a7484f0662a5

says...
Problem:
Actiontec GT701-WG DSL Modem has a dumb DNS issue. When you try to connect to a website from a computer running Linux, you may see "Trying 1.0.0.0" in the status bar and a failure to resolve the hostname.

Cause:
The router, which runs busybox Linux, has a DNS server program called dproxy that has a bug that exhibits itself when you try to resolve hosts from a Linux machine with IPv6 turned on. Unfortunately, you cannot disable the dproxy program and the router always sends its own IP address as the nameserver to a client that obtains an IP address via DHCP.

Fix:
Well, you could hard-code the nameservers on your computer or router that connects to the DSL modem. But here is a solution that I came up with two years ago for hard-coding the nameservers into the DSL modem itself.

Mac (mac-jones) wrote :

http://whirlpool.net.au/forum-replies-archive.cfm/476006.html

says......

The solution was that I for some reason had Microsoft TCP/IP version 6 installed under the internet connection properties. By uninstalling this it all started to work!
....

Mac (mac-jones) wrote :

similar...

http://forums.whirlpool.net.au/forum-replies-archive.cfm/461625.html

So maybe it is IPV6 causing these routers to spit back 1.0.0.0?

Mac (mac-jones) wrote :

Turning of IPv6 did not work here, but the ping thing is weird !!
-------------------------------------------------------------------------------------
http://www.ubuntuforums.org/archive/index.php/t-78271.html
---

I have also been having trouble with my DSL-604T router. I disabled ipv6 in the aliases file (changed alias net-pf-10 to alias-net-pf-10 off), which has fixed web browsing.

With apt-get, I get a failure to connect, as it seems to resolve gb.archive.ubuntu.com to 1.0.0.0. However, if I ping gb.archive.ubuntu.com and then immediately run apt-get, it works:

root@redbug:~# apt-get update
66% [Connecting to gb.archive.ubuntu.com (1.0.0.0)]
root@redbug:~# ping gb.archive.ubuntu.com
PING gb.archive.ubuntu.com (82.211.81.182) 56(84) bytes of data.
64 bytes from gb.archive.ubuntu.com (82.211.81.182): icmp_seq=1 ttl=46 time=14.1 ms
64 bytes from gb.archive.ubuntu.com (82.211.81.182): icmp_seq=2 ttl=46 time=14.1 ms

--- gb.archive.ubuntu.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 14.122/14.151/14.180/0.029 ms
root@redbug:~# apt-get update
Get:1 http://gb.archive.ubuntu.com breezy Release.gpg [189B]
Hit http://gb.archive.ubuntu.com breezy Release
Hit http://gb.archive.ubuntu.com breezy/universe Packages
Fetched 189B in 0s (782B/s)
Reading package lists... Done
root@redbug:~#

This works for a short time, then apt-get seems to "forget" the address, and I'm back to square one; another ping and it starts working again (by short time, I mean no longer than the time it has taken to compose this post; maybe five minutes or so?)

My router software version is 1.00B02T02.UK.20040618. I'm reluctant to upgrade it on the grounds that it is working perfectly with my PC when booted into Windows XP and Mandrake 10.1 (using ftp, pop and smtp); so far it is only Ubuntu that has a problem (of course, the same issue might occur with other bang up to date distros).

The problem could be that even with ipv6 disabled many softwares still request AAAA records, you can double check with tcpdump or wireshark:

apt-get source xxx
DNS AAAA archive.ubuntu.com

firefox http://google.com
DNS A google.com

cf bug: 80571

Jens (jens.timmerman) wrote :

I've seen this problem a couple of times where some routers just don't seem to resolve dns query's right,
but setting the dns servers manually in the network options work.

indeed, the strange thing about is, ping seems to be able to get the right dns record, but I haven't found any other program working except ping

confirmed on:
linksys ADSL2MUE
DI-614+

both latest firmware

Can you try Feisty liveCD which shouldn't request AAAA record if there's no IPV6 router?

Shirish Agarwal (shirishag75) wrote :

[quote=didier]
The problem could be that even with ipv6 disabled many softwares still request AAAA records, you can double check with tcpdump or wireshark:

apt-get source xxx
DNS AAAA archive.ubuntu.com

firefox http://google.com
DNS A google.com

cf bug: 80571[/quote]

Can u be more specific. Btw I do have the same issue but not with feisty but with gusty & that too in a VM setup. Doing the ping though resolves the issue. The Router is a D-Link 502T.

Shirish Agarwal (shirishag75) wrote :

Wish I could edit. I forgot to say that the DNS was working when it was updating from feisty to gusty as well as quite a bit of time in gusty also without the ping workaround. It might be a temp. issue or permanent one but will know about it l8ter.

KeKc (kekcfx) wrote :

Hardware problem, as I understand. Routers DNS can't work with IPv6.

//For example, V3 firmware for DLINK DSL-G604T solve the problem.

Shirish Agarwal (shirishag75) wrote :

seems to be the getting the same issue, it was not in feisty but is there in gusty tribe 1 :(

Shirish Agarwal (shirishag75) wrote :

because of this I cannot use pidgin as well as any p2p programs :(

Don Michel (michel-matos) wrote :

I use Kurumin, a debbian based system and it has the same bug...

As someone posted above, it dosen't happen with Mandriva...

Maybe a Debian bug wich dosen't act as windows and mandriva when usign DNS iPv6??

cornbread (corn13read) wrote :

I have this same issue on two of my gt701-wg adsl modems... Any fixes?

Simos Xenitellis (simosx) wrote :

A workaround that might be even better to use anyway, is to configure with the IP of a third-party DNS server.
Such a server is OpenDNS, http://www.opendns.com/start/ubuntu.php
What OpenDNS does is it offers DNS services for free so that you can use instead of the DNS server of your provided. In addition to this, they also block websites of spammers, etc through the filtering of DNS resolutions.

Alvin Abdagić (alvin.abdagic) wrote :

Hi all,

I have disabled IPv6, and I am using OpenDNS for my DNS servers, and still when i wget www.google.com I get:
Connecting to www.google.com|1.0.0.0|:80... failed: Connection timed out.

pinging www.google.com and then wget makes it work for some amount of time, also firefox works, and browsing a site has same effect as pinging it, i.e. makes that wget works for some time...

Same behavior as wget have Pidgin and apt-get, probably other programs, but I haven't test any more ...

Is there some way to stop AAAA queries from happening, or somehow redirect them to A queries ?

P.S: I also have a cheap busybox router...

Mac (mac-jones) wrote :

OK so here's my theory and how i fixed it (on 100+ Ubintu machines).

There is some low level incompatibility between the Ubuntu dns requests and specific models of router. (I've heard this happens on a few other distros as well, so it's not Ubuntu specific)

Some models of router are absolutely fine, and some models resolve to 1.0.0.0 just about all the time.

Some success can be had by disabling ipv6 on some routers, but on most of my DSL connections with these faulty DSL routers, this had no effect.

The only fix guaranteed fix I have found is to avoid asking these routers for DNS information, because they LIE!

To do this I install a small package called "dnsmasq", this is a caching DNS proxy service that sits on your local machine and passes requests upstream to real DNS servers, and also caches the results.

(apt-get install dnsmasq)
(man dnsmasq)

I then set the .conf file of dnsmasq to pass DNS requests directly to opendns (http://en.wikipedia.org/wiki/OpenDNS). You could also use the DNS IP of your ISP's dns servers.

Your local machine is then set to use 127.0.0.1 (localhost) for DNS queries where dnsmasq will answer them from cache if it can (very fast) or go out to the DNS server you set in the .conf file.

This approach totally avoids the need to ask these buggy DSL routers DNS queries.

As I mentioned earlier I've got this running on 100+ ubuntu machines, and 60+ DSL routers, and it has not missed a beat.

Regards
Mac
New Zealand

Mac (mac-jones) wrote :

The other option I should have mentioned is that manually putting the IP addresses of good DNS servers directly into your router often fixes the problem (usually by unticking / unticking a box like "use ISP's DNS Servers / use Manual DNS servers".

The reason I did not use this approach for my machines is that I usually have no access to log into my clients DSL router, so I needed a solution that would work on the client PC.

Mac
NZ

Alvin Abdagić (alvin.abdagic) wrote :

Hi Mac,

Thanks for suggestions...
I did install dnsmasq, and it didn't help... I configured dnsmasq bu adding server=208.67.222.222 and server=208.67.220.220 in dnsmasq.conf file... And nothing changed, I still have all the same problems. The weirdest this is happening now... I installed wireshark to track down what is going on, and here is what happens when I run wget archive.ubuntu.com:

1313 538.863556 192.168.1.100 208.67.222.222 DNS Standard query AAAA archive.ubuntu.com
1314 538.924475 208.67.222.222 192.168.1.100 DNS Standard query response
1315 538.924831 192.168.1.100 208.67.222.222 DNS Standard query A archive.ubuntu.com
1316 538.928503 208.67.222.222 192.168.1.100 DNS Standard query response A 1.0.0.0

192.168.1.100 is ip address of my computer.

Is it possible that my router is somehow modifying the contents of the DNS response ?

Best regards,
Alvin

Mac (mac-jones) wrote :

Alvin,

A couple more bits...

cat /etc/resolv.conf

my says 127.0.0.1

if yours does not then edit /etc/dhcp3/dhclient.conf

and uncomment the line
#prepend domain-name-servers 127.0.0.1;

when you reboot or restart your networking do

cat /etc/resolv.conf again you should now have 127.0.0.1

Did you put your DNS servers in dnsmasq.conf, I keep mine in a seperate text file, if yours are in the conf file, did you uncomment the line "#no-resolv"

I also edit /etc/dnsmasq.conf and uncomment the line
#resolv-file=
changing it to
resolv-file=/home/mac/dns_servers.txt

my /home/mac/dns_servers.conf looks like

--
nameserver 208.67.222.222
nameserver 208.67.220.220
--

Also try removing the package resolvconf if you have it and the above does not work...

Regards
Mac

Alvin Abdagić (alvin.abdagic) wrote :

Hi Mac,

First thanks for trying to help me :)

I did all you suggested, and no change :(

Looking in wireshark my computer (actually dnsmasq) makes queries to the OpenDNS's server, but somehow OpenDNS returns 1.0.0.0... I am guessing router somehow changes it, as I doubt that OpenDNS's server could return this...

Maybe I could try configuring a DNS server on a remote computer, and catching packages on that computer, and on my computer to see if they are really modified by my router...

Best regards,
Alvin

Matt Zimmerman (mdz) wrote :

This sounds like it might be bug 24828

Alexey Ten (Lynn) (alexeyten) wrote :

Fix has been released. See bug 156720

tkj (tkjones) wrote :

How would one go about applying the fix described in that bug?

Sorry, I didn't notice that the fix is pre-released. It's available in
gutsy-proposed updates.

To get it you should enable gutsy-proposed updates in System >
Administration > Software sources on "Updates" tab. Then update
manager will tell you that update for libc6 package available and you
could install it.

On 10/27/07, tkj <email address hidden> wrote:
> How would one go about applying the fix described in that bug?
>
> --
> DNS Resolves everything to 1.0.0.0 intermittently on some ADSL Routers
> https://bugs.launchpad.net/bugs/81057
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Алексей

Brian Murray (brian-murray) wrote :

Does the fix released in bug 156720 resolve this for anyone? Thanks in advance.

Alvin Abdagić (alvin.abdagic) wrote :

I can confirm that it solved all the problems on two Gutsy machines I had issues with.

Brian Murray (brian-murray) wrote :

I'm going to mark this as Fix Released as it is fixed for one person and no one else has responded, but leave it assigned to myself in case anyone still has this bug.

Chris Frost (chris-frostnet) wrote :

I started encountering this bug on 2008/05/30 with exim in Ubuntu 8.04.

To connect to the smarthost, exim first causes an AAAA lookup.
(Oddly, an error response to this lookup that the name does not exist seems to cause my machine to repeat te AAAA lookup. Only when the server sends an empty response does my machine move on and ask for the A record.)
After the AAAA lookup(s) my machine sends an A lookup; the qwest actiontec nat box sends an A response of 1.0.0.0.

Only my lo interface has an ipv6 address, and telnet, wget, and firefox do not generate AAAA lookups.tu

andre (andrew-dorrell) wrote :

Was this fix ever sent up-stream? I'm encountering exactly the same problem with a new Arch linux install.

Thanks

pjahead (pjahead) wrote :

This bug appeared in Ubuntu 9.10 beta again

ivan (igotelli) wrote :

I have this problem in the final version of kubuntu 9.10.
I disabled ipv6 and can use firefox and konqueror without problems, but apt-get and konsole sometimes get 1.0.0.0 when downloading packages.
i installed dnsmasq, but still have the problem. is there a fix for this?

nunks (nunks-lol) wrote :

Same thing here, after a Karmic fresh install (update from 9.04 failed mid-process 'cause it started resolving everything to 1.0.0.0 during package installation.)
Pinging br.archive.ubuntu.com works it around for apt as said above...

I've got the same bug after the upgrade from Kubuntu 9.04 to Kubuntu 9.10. I have added ipv6.disable=1 to kernel options on boot to disable ipv6 since it prevented me from using Firefox. Now Firefox runs nicely but synaptic which is used by me to install packages as well as KDE's PackageKit both fail to reach *.archive.ubuntu.com as they try to connect to 1.0.0.0. Sometimes the Synaptics's problem can be resolved by running something like ping ru.archive.ubuntu.com in terminal. An sometimes cannot. This does not help PackageKit to get a correct ip address.

Changed in glibc (Ubuntu):
status: Fix Released → New
Jsimantov (joseph-simantov) wrote :

I am facing exactly the same problem after having upgraded from 9.04 to 9.10 on more than one machines. The problem is, I believe, definitely not linked with the router, since resolving works fine on all machines I kept on 9.04.

Two additional details here, in case they might be of help:
- The 'aptitude' command worked fine from the command line, but only once...
- Exactly the same problem appears with Debian 5 on i386 machines. Oddly enough, the same problem (1.0.0.0) appeared consistently also on Debian 5.0 installed on Sparc machines, but only when they were connected directly to the router. When the connection was made through a local DNS/DHCP server the address was resolved just fine...

Brian Murray (brian-murray) wrote :

This bug was fixed by the patch included in bug 156720. People currently experiencing this bug should follow bug 417757.

Changed in glibc (Ubuntu):
assignee: Brian Murray (brian-murray) → nobody
status: New → Fix Released
toTem (totem1979) wrote :

Some workarounds that "solves" this stupid bug:
1) disable IPv6 in linux kernel: echo "1" > /proc/sys/net/ipv6/conf/all/disable_ipv6
2) disable IPv6 for the wget: edit /etc/wgetrc and add line "inet4_only = on"

Pavel Rousar

thqmas (thqmas) on 2010-01-25
Changed in glibc (Ubuntu):
assignee: nobody → thqmas (thqmas)
dylan digges (digges5457) wrote :

this is horrible

Am I right? Did this bug reappear in the newest 10.04 release?

I first encountered this bug after upgrading to v9.10. First solution was to disable IPv6, but soon after release some sort of fix was issued, and I set IPv6 on again.

Recently I upgraded to v10.04 and began to experience problems similar to discussed above. Many out-of-package programs are affected including Firefox and Evolution (but, luckily, not Google Chrome).

troglodyt (learnedheron) wrote :

I get this exact bug in 10.04 !
How can it be fixed -in this distro?

Tharakan (tharakan) wrote :

RESOLVED (for me).

I had this same bug troubling me in this 10.04 install (WUBI) installed only a month back. The apt-get update works, but for some reason, the flashplugin-installer (when installing flash download from adoboe), resolved archive.canonical.com -> 1.0.0.0 which was very annoying.

The way I solved this is that I updated /etc/resolv.conf with Google's nameserver (on first priority).

So i put this line as the first line in /etc/resolv.conf

nameserver 8.8.8.8
(... and then everything else was kept the same).

running apt-get after this worked flawlessly, and since i didn't want to do round-trips to Google, I removed that first line after this update was installed successfully.

Hope this helps... (It still doesn't explain why it all happened in the first place).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers