I'm having an argument with someone over the correctness of
something they are doing on a linux firewall. They are capturing all
DNS forwarding requests and redirecting them to a local cache
only server that then responds to the original internal request.
Here is what the dump looks like from the requesting internal
linux workstation:
15:33:29.084642 0:90:27:ce:52:98 0:0:b4:92:32:e8 0800
88: 10.0.0.10.1435 > 194.46.0.60.53: 5219+ (46) (ttl 64, id 50750)
15:33:29.085633 0:0:b4:92:32:e8 0:90:27:ce:52:98 0800
145: 10.127.13.1.53 > 10.0.0.10.1435: 5219 NXDomain
q: home.netscape 0/1/0 (103) (ttl 64, id 2844)
15:33:29.085701 0:90:27:ce:52:98 0:0:b4:92:32:e8 0800
173: 10.0.0.10 > 10.127.13.1:
icmp: 10.0.0.10 udp port 1435
unreachable [tos 0xc0] (ttl 255, id 50751)
As you can see, the dns request goes out from port 1435 to
a real DNS server; but the reply comes back to that port
from the cache serving on the firewall via it's internal
REDIRECT. The linux workstation then seems to reject it.
I can see some sense in this, ie the return IP is not
the same as the one on the request. This brings up two
questions.
1) Is this indeed the way the tcp stack is supposed to
operate? Is it intentional security, accidental security
or a bug?
2) How do you convince some one they are doing the wrong thing? :-)
The workstation that the dump comes from is a 2.2.14 with
international patches btw.
------------------------------------------------------
Use Linux: A computer Dale Amon, CEO/MD
is a terrible thing Village Networking Ltd
to waste. Belfast, Northern Ireland
------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:16 EST