I would also recommend looking deeper into the packet capture to determine what
queries were being responded to. As Warren pointed out, if the initiator times
out its original query, it will either fail the whole lookup, or at least move
to another resolver, so in either case the original socket is closed and your
caching server get an “ICMP Port Unreachable” when it sends its response. But
this resolution slowness might not be for *everything* that a particular
caching server tries to resolve; it might only be for certain names.
Selectively-slow resolution can have multiple causes, but it might be worth
checking into.
If this were a DoS attack/attempt, then the volume of actual query/response
traffic – which has a much greater resource impact on your server -- would be
greater than the ICMP traffic, so it would be pretty obvious that that’s what
it was. Occasional or sporadic “ICMP Port Unreachable”s are more likely to be
an unintentional effect of an infrastructure problem, or possibly just bad
client behavior (e.g. not waiting long enough for the lookup to finish).
- Kevin
From: [email protected]
[mailto:[email protected]] On Behalf Of Warren Kumari
Sent: Friday, January 15, 2016 11:32 AM
To: Daniel Dawalibi; [email protected]
Subject: Re: DNS BIND traffic capture ICMP/UDP
On Fri, Jan 15, 2016 at 8:49 AM Daniel Dawalibi
<[email protected]<mailto:[email protected]>> wrote:
Hello
We observed an unusual traffic combining ICMP and UDP packets while running the
tcpdump command on the DNS caching server
Kindly note that only UDP DNS traffic is allowed on this server (ICMP is not
allowed from outside to DNS server)
Any help regarding this issue? Why we are getting ICMP and UDP requests? Could
it be an attack?
Logs:
# tcpdump –n icmp
15:41:05.054237 IP 10.151.130.74 > DNSIP: ICMP 10.151.130.74 udp port 52003
unreachable, length 52
15:41:05.064449 IP 10.75.6.36 > DNSIP: ICMP 10.75.6.36 udp port 50162
unreachable, length 52
15:41:05.067953 IP 10.33.10.155 > DNSIP: ICMP 10.33.10.155 udp port 50233
unreachable, length 52
15:41:05.067958 IP 10.75.15.162 > DNSIP: ICMP 10.75.15.162 udp port 53847
unreachable, length 52
15:41:05.072727 IP 10.33.12.219 > DNSIP: ICMP 10.33.12.219 udp port 51024
unreachable, length 52
….
Example: 10.151.130.74 (client source IP)
DNSIP: DNSServer IP
Your description is either incomplete, or incorrect (or at least sine set of
things is misconfigured) -- without additional information it will be difficult
/ impossible to assist.
1: You state that you observe traffic while running tcpdump **on the caching
server**.
2: You state that "ICMP is not allowed from outside **to** DNS server"
(emphasis mine) - this implies that ICMP is supposed to be filtered before
reaching the server, not e.g iptables *on the server*.
3: The tcpdump output shows traffic from client IPs (presumably "outside") to
the DNS server.
I do not see how all of the above can simultaneously be true
A: What are the actual IPs involved?
B: What are you counting as "outside" (are the client IPs "inside" or
"outside"?)?.
C: Where are you filtering the ICMP, and, more importantly, why are you
filtering ICMP (it is needed to make IP work properly...)
D: How busy is the server / what percentage of ICMP responses to DNS queries?
E: What is the connectivity of the server? It is likely that resolutions are
taking significant time, and the clients have a: given up or b: already gotten
the replies from another recursive?
This could be an attack (e.g spoofed packets as part of a cache poisoning
attempt).... or it could be perfectly normal operation -- eliding the IP
addresses and not providing more information makes it imposs^W hard to tell....
W
Regards
Daniel
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]<mailto:[email protected]>
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
