Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 see entries like this in my router logs:

src= dst=108.x.y.z ipprot=17 sport=53 dport=54789 
Unknown inbound session stopped is a DNS server.

A few questions regarding this:

  1. Why is the DNS server trying to contact me?

  2. Do I need to be concerned that it can't reach it's destination?

  3. If so, what can I do to allow it access?

I'll add an update for why a DNS server might be trying to contact me. In this case, after some digging, I found the failure detection in the router behind this one is set to use DNS servers to figure out if one or the other connections to it is down.

Update 2:

One of the suggestions was to run DNS locally. Actually, DNS is being run locally, and I just encountered a problem related to it and came back to update the question.

You see, I am seeing "no address associated with hostname" errors in application code that is trying to reach paypal.

So now I'm wondering if these logs are showing up telling me the local DNS is trying to update from the main DNS, but can't get updates, which means it can't find the external APIs the app depends on.


share|improve this question
As for update 2: find out what the hostname/A record the API is trying to resolve and do some investigating: is the authoritative name server for the domain in question under heavy load/experiencing issues at the moment? Your API is probably timing out waiting for a response, hence the update issue and the stale return packets in the firewall log. – gravyface Mar 15 '12 at 15:04
up vote 4 down vote accepted

This is scatter back from queries that you sent, but which weren't answered in time for your stateful firewall to recognise them as being part of your own traffic.

For UDP traffic, every stateful firewall must remember which outbound traffic was seen, so that when the return traffic is seen it knows that it's part of the same flow and is then permitted.

After a short amount of time (or if it runs out of state table entries) it expires the records for the outbound flows.

If the return packet is too late, the firewall may have forgotten about the original outbound traffic, so it thinks the inbound packet is part of a new inbound (and unsolicited) flow, and blocks it.

It's very common, nothing to see here, etc. etc.

share|improve this answer
Consider setting up an internal DNS server, and pointing your clients there, and then only allowing that server out for DNS, it would probably clear this up. However... I'd ignore it myself :) – SpacemanSpiff Mar 15 '12 at 14:28
@SpacemanSpiff that won't remove the errors, though - all it'll do is obscure which internal IP address was using Google DNS. – Alnitak Mar 15 '12 at 14:30
I would do it just to cut down on egress traffic for security reasons, latency, etc. – gravyface Mar 15 '12 at 14:36
Given the "Update 2" I just posted, and how application code is unable to find external APIs it depends on, it's looking like a bigger problem for me. Is there any suggestion given this new information? – Sammy Larbi Mar 15 '12 at 14:51
@SammyLarbi the error message was from Google DNS ( Are your internal DNS resolvers forwarding queries to Google? – Alnitak Mar 15 '12 at 15:23

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.