DNS BIND traffic capture ICMP/UDP

Fri Jan 15 17:35:23 UTC 2016

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: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Warren Kumari
Sent: Friday, January 15, 2016 11:32 AM
To: Daniel Dawalibi; bind-users at lists.isc.org
Subject: Re: DNS BIND traffic capture ICMP/UDP

On Fri, Jan 15, 2016 at 8:49 AM Daniel Dawalibi <daniel.dawalibi at idm.net.lb<mailto:daniel.dawalibi at idm.net.lb>> 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
bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160115/0c9a9532/attachment.html>