Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a Bind 9 DNS server sitting behind a NAT firewall, assume the Internet facing IP is

There are no restrictions on outgoing traffic, and port 53 (TCP/UDP) is forwarded from to the internal DNS server ( There are no IP Tables rules on either the VPS or the internal Bind 9 server.

From a remote Linux VPS located elsewhere on the internet, nslookup works fine

# nslookup


However, when using the host command on the remote VPS, I receive the following output:

# host
;; reply from unexpected source:, expected
;; reply from unexpected source:, expected
;; connection timed out; no servers could be reached.

From the VPS, I can establish a connection (using telnet) to

From the internal DNS server (, the host command appears to be fine:

# host
Using domain server:
Aliases: has address

Any suggestions as to why the host command on my VPS is complaining about the reply coming back from another port, and what can I do to fix this?

Further info:

From a windows host external to the network

DNS request timeout
    timeout was 2 seconds
Server: UnKnown

DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
DNS request timed out.
    timeout was 2 seconds
*** Request to UnKnown timed-out

This is a default install of bind from Ubuntu 12.04 LTS, with around 11 zones configured.

$ named -v
BIND 9.8.1-P1

TCP Dump (filtered) from internal DNS server

20:36:29.175701 IP > 1+ PTR? (45)
20:36:29.175948 IP > 1 Refused- 0/0/0 (45)
20:36:31.179786 IP > 2+[|domain]
20:36:31.179960 IP > 2 Refused-[|domain]
20:36:33.180653 IP > 3+[|domain]
20:36:33.180906 IP > 3 Refused-[|domain]
20:36:35.185182 IP > 4+ A? (45)
20:36:35.185362 IP > 4*- 1/1/1 (95)
20:36:37.182844 IP > 5+ AAAA? (45)
20:36:37.182991 IP > 5*- 0/1/0 (119)

TCP Dump from client during query

21:24:52.054374 IP > 6142+ A? (45)
21:24:52.104694 IP > UDP, length 95
share|improve this question
It looks a bit like your NAT rules for UDP were broken. Can you check with a packet sniffer if the UDP DNS answer packets leaving your network are really mangled to carry a different source port number than 53? – the-wabbit Sep 10 '12 at 19:27
Thanks @syneticon-dj, I've updated the question to show a TCP dump, so it looks like it is the NAT rules that are broken on our DSL router, however I don't claim to understand the details at the end of each line of the tcpdump output. – Bryan Sep 10 '12 at 19:42
the tcpdump trace on your DNS server looks alright - it hands out responses as it should. As I suspect that your NAT would be misconfigured or broken, a tcpdump trace from the router's external interface or another device in the routing path to the client (including the client itself) would be needed to verify this. – the-wabbit Sep 10 '12 at 20:02
@syneticon-dj I've updated the question again to show the client tcpdump output. There are no other points at which I can examine the traffic, but I think the results are pretty conclusive wouldn't you agree? p.s. Please post your comment as an answer, so I can accept. Time to go shopping for a new router I guess! – Bryan Sep 10 '12 at 20:29
up vote 2 down vote accepted

To sum up what has been previously written in comments with some further explanation:

It looks a bit like your NAT rules for UDP were broken. An indication is the error message reply from unexpected source:, expected and your trace taken from the client where the response looks like > UDP, length 95. The source port for the response packet should be 53, it is correct in your dump taken from the DNS server (where resolves to domain for display purposes).

While some (especially historic) resolvers may accept DNS responses from different ports / IPs, most would not - mainly due to security reasons to impede DNS spoofing and cache poisoning attacks.

At any rate, for connectionless UDP NAT traffic, your router should preserve state data from the previously received UDP DNS query packet and re-map the IP:port tuple for the response packet back to - which it apparently does not. It may be a configuration error or a bug in the way the router is handling the UDP state table for port forwarding cases - so your best bet would be to open a case with the manufacturer's customer support (having upgraded the code to the latest/greatest beforehand - such an issue is likely to have been noticed by other users previously and thus likely to already be fixed).

share|improve this answer
I get the error even though my ports are correct. > 10937+ A? – glochild Jan 18 at 6:00
@nathan it looks like your use case is different than the one described here. I'd suggest opening a new question with more details. – the-wabbit Jan 18 at 14:26

Your Answer


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.