Forum Discussion
Excessive lookup queries from DNS
Hello Experts, From last 2 weeks or so we have been getting a lot of DNS lookup queries and events are being generated since the endpoints are trying to connect to random suspicious domains via t...
The primary cause of too many DNS requests is TTLs that are too low. Yours are low but not insanely low. (I've seen 60 and 1 as TTLs in production systems.)
digitaldawn.net. 1800 IN A 109.73.163.166
http://www.digitaldawn.net. 3600 IN A 208.94.146.71
http://www.digitaldawn.net. 3600 IN A 208.94.146.70
http://www.digitaldawn.net. 3600 IN A 208.94.146.80
http://www.digitaldawn.net. 3600 IN A 208.94.146.81
cdn.digitaldawn.net. 1800 IN CNAME wpc.7b5c.edgecastcdn.net.
wpc.7b5c.edgecastcdn.net. 3600 IN CNAME gs1.wpc.edgecastcdn.net.
gs1.wpc.edgecastcdn.net. 14400 IN A 93.184.221.133
Unless you are changing the IP address that these domains point to more often than once per day, you will be better off changing the TTL to something like 86400 (24 hours). You can go higher if you can be confident of having at least the time period in the TTL of advance waning that you might need to change the IP address.
For the cdn.digitladawn.net subdomain, even if you set that TTL to 86400, only that line in the above output will be cached for 24 hours. If the wpc.7b5c.edgecastcdn.net response changes, all clients should have picked up the new value after a maximum of one hour (ignoring for now those DNS servers that ignore your TTLs.)
The other two causes of too many DNS requests that I have seen are too many clients (say, thousands of edge CDN servers that are all hitting your authoritative name servers) or a single misbehaving client (possibly a script on your own server) that is doing lookups dozens of times per second. An example of this could be a reverse proxy that uses backend.digitaldawn.net as its upstream server and makes a DNS request for that domain for every HTTP request it has to proxy. Adding DNS caching to that server or running your own authoritative name server inside your production environment can solve this problem.
If you can get hold of better statistics for your name servers (such as the IP addresses of all the clients that did lookups) then you might be able to diagnose this sort of problem.
digitaldawn.net. 1800 IN A 109.73.163.166
http://www.digitaldawn.net. 3600 IN A 208.94.146.71
http://www.digitaldawn.net. 3600 IN A 208.94.146.70
http://www.digitaldawn.net. 3600 IN A 208.94.146.80
http://www.digitaldawn.net. 3600 IN A 208.94.146.81
cdn.digitaldawn.net. 1800 IN CNAME wpc.7b5c.edgecastcdn.net.
wpc.7b5c.edgecastcdn.net. 3600 IN CNAME gs1.wpc.edgecastcdn.net.
gs1.wpc.edgecastcdn.net. 14400 IN A 93.184.221.133
Unless you are changing the IP address that these domains point to more often than once per day, you will be better off changing the TTL to something like 86400 (24 hours). You can go higher if you can be confident of having at least the time period in the TTL of advance waning that you might need to change the IP address.
For the cdn.digitladawn.net subdomain, even if you set that TTL to 86400, only that line in the above output will be cached for 24 hours. If the wpc.7b5c.edgecastcdn.net response changes, all clients should have picked up the new value after a maximum of one hour (ignoring for now those DNS servers that ignore your TTLs.)
The other two causes of too many DNS requests that I have seen are too many clients (say, thousands of edge CDN servers that are all hitting your authoritative name servers) or a single misbehaving client (possibly a script on your own server) that is doing lookups dozens of times per second. An example of this could be a reverse proxy that uses backend.digitaldawn.net as its upstream server and makes a DNS request for that domain for every HTTP request it has to proxy. Adding DNS caching to that server or running your own authoritative name server inside your production environment can solve this problem.
If you can get hold of better statistics for your name servers (such as the IP addresses of all the clients that did lookups) then you might be able to diagnose this sort of problem.