I have a wget 'http://xxxx.net/somepage.asp?params@abc' in a bash file.

When I run it, four out of five times it says:

Resolving xxxx.net (xxxx.net)... failed: No address associated with hostname.
wget: unable to resolve host address 'xxxx.net'

Thinking that there was a problem with my DNS server, I added a ping -c 2 xxxx.net before wget. Ping is 100% positively resolved all the time.

What could be the cause? Does wget have its own method of resolving names? This is on a Raspberry Pi.

migrated from serverfault.com Nov 18 '14 at 4:04

This question came from our site for system and network administrators.


Technically they should both use the same way of resolving addresses, however ping is likely not going to try resolving IPv6 addresses at all (AAAA records) and query directly A records as it's an IPv4-only tool (ping6 does IPv6 ICMP requests).

A configuration issue I've seen in some load-balancing DNS servers backed by named (the same should apply no mater what backs the dymamic DNS resolver) is that when there is an A record in the load-balancing configuration and nothing for the same name in named, a request for the AAAA record falls back to named which respond with an NXDomain error (no such domain), preventing the resolver from attempting any other requests. One fix is adding an A, TXT or other compatible record for that name so when named catches an AAAA request it will not return an address nor return NXDomain, so the the client will go on and look for an A record.

If you have no control over the DNS server, using wget --inet4-only option may help. If that solves your issue you should also tell the domain owner about the DNS issue.

  • Thanks. wget -4 ... works, for all the times I tested. Are you saying that wget by default uses IPv6 first? BTW: the domain is on 1and1. – Old Geezer Nov 18 '14 at 5:01
  • I meet the same problem with 1and1's smtp server. In Python, smtplib.SMTP('smtp.1and1.com'), which instantiates the Smtp server, can't find the host three quarters of the time. – Old Geezer Nov 18 '14 at 5:09
  • @OldGeezer if -4 works, then likely there is a problem with the DNS server when resolving IPv6 addresses. You can check with dig AAAA <name> vs dig A <name>. On a good server you will see no answer to AAAA but you will see somewhere status: NOERROR. On a broken server you will see status: NXDOMAIN instead. The A lookup should return an ANSWER SECTION:. NXDomain must not be returned when there is a valid record of a different type for the name. – Thomas Guyot-Sionnest Nov 18 '14 at 5:15
  • Are you referring to the DNS server of my running client (which is the router firmware on the home network I am connected to) or the authoritative name server for that domain name? – Old Geezer Nov 18 '14 at 9:26
  • 1
    @OldGeezer I'm talking about the authoritative dns, but you may be able to get the answer from your local dns server too. It's true that if your local server cached an address already it may not show the behavior, but if you do an AAAA lookup on a clean cache you should see the NXDomain error there too. You can get the DNS servers from the parent domain with dig NS <domain>, and you can direct dns queries at those servers with: dig AAAA <name> @<nameserver> (no space between @ and the nameserver). – Thomas Guyot-Sionnest Nov 19 '14 at 2:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.