Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Today I asked my hoster to block all UDP ports except port 53. Due to daily UDP attacks, this was currently the only option to stop flooding my lines.

Now since the block is in place, I cannot wget anything anymore.

[root@s1 wupload]# wget http://www.google.com
--2011-08-15 11:56:28--  http://www.google.com/
Resolving www.google.com... failed: Temporary failure in name resolution.
wget: unable to resolve host address `www.google.com'

Nothing has changed on the server it self. Only at router level. Port 53 is still open, i see hits coming in via iptables.

I run CentOS64 5.6.

Which other ports need to be open for wget and cURL to work properly?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

To resolve a host, you need UDP 53 outgoing (I'm supposing you're behind a stateful firewall). To use wget and curl with default port options, you will need TCP 80 outgoing. You will not be needing any incoming ports for this specific purpose.

To check whether you can resolve hosts, you can use the dig command. If you wished to resolve www.google.com using OpenDNS, you would type the following command :

dig @208.67.222.222 www.google.com

and you should get the following answer :

; <<>> DiG 9.7.3 <<>> @208.67.222.222
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55450
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       516333  IN      NS      d.root-servers.net.
.                       516333  IN      NS      l.root-servers.net.
.                       516333  IN      NS      h.root-servers.net.
.                       516333  IN      NS      k.root-servers.net.
.                       516333  IN      NS      g.root-servers.net.
.                       516333  IN      NS      i.root-servers.net.
.                       516333  IN      NS      f.root-servers.net.
.                       516333  IN      NS      c.root-servers.net.
.                       516333  IN      NS      j.root-servers.net.
.                       516333  IN      NS      a.root-servers.net.
.                       516333  IN      NS      m.root-servers.net.
.                       516333  IN      NS      b.root-servers.net.
.                       516333  IN      NS      e.root-servers.net.

;; Query time: 36 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Mon Aug 15 19:17:11 2011
;; MSG SIZE  rcvd: 228

The dig answer may vary from host to host but you should not get any empty "ANSWER SECTION".

If you can resolve using OpenDNS using dig but not using wget or curl, that means that your system has not reachable DNS server configured. If that is the case, consider editing /etc/resolv.conf

share|improve this answer

They're blocking inbound traffic bound to all UDP ports other than 53 - which is great for internet-facing DNS servers at your location, but not so great for client resolution.

DNS clients send traffic bound for port 53, with a high source port; the DNS server's response has a source port of 53 and a destination port of the high port the client used.

So, your ISP's filter has shot your DNS resolution in the foot. If they open up the whole high range your DNS clients might use, it'll likely allow a lot of flooding back through; likewise, restricting the source port to 53 doesn't guarantee blocking of a well-crafted flood.

The best solution may be to have all of your client resolution done by specific upstream DNS resolvers, and have your provider exempt those systems from the UDP filter.

share|improve this answer
    
That would only be true if they had stateless firewall which is something of a rarity these days... –  Antoine Benkemoun Aug 16 '11 at 6:32
    
@Antoine Sure - but at the provider level, it may just be a simple ACL in a router that doesn't track connection state of TCP (much less UDP). –  Shane Madden Aug 16 '11 at 14:20
    
That's true indeed, good point even though I have never seen such thing. –  Antoine Benkemoun Aug 16 '11 at 14:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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