My company's ISP has implemented what I'll term DNS "grey listing" (or they have a configuration problem) - they are blocking inbound DNS queries between [resolver IP, server IP] pairs that haven't attempted a query in the last 60 seconds. So the if the first query fails, further queries succeed so long as less than 60 seconds have passed since the previous attempt. I assume this is to hide hosts from scans, under the assumption that a legitimate resolver will retry the query. They may even be blocking all UDP packets to combat port scans, but I haven't found a way to test this yet.

It turns out that Cisco IronPort devices generally have a retry interval longer than 60 seconds. (15 seconds to try each secondary DNS server, then 60 seconds before retrying the primary) My company can't receive email from most organizations with IronPort devices.

My feeling is that at least one of these behaviors is just wrong. So my questions are:

1) What are the recommended retry intervals for DNS resolvers? Can you reference an RFC or other source, or is it a de facto industry standard?

2) Is DNS or UDP "grey listing" a standard practice? References?

EDIT - Some additional background details:

Both of my company's DNS servers are affected, as is our ISP's primary nameserver. Their secondary nameservers, which actually reside outside their network, and nameservers upstream from any affected hosts are not affected. We also have a second ISP, and DNS queries that come in through that route are not blocked. Packet traces on our external firewall shows that we answer all DNS queries received - the dropped queries aren't delivered to our networks. My main goal in asking this question is to have a standards document to show our ISP (or less likely, Cisco) that their behavior is broken and needs to be fixed.

  • I haven't found any standards on these, but I did find someone trying to do UDP grey listing: serverfault.com/questions/644869/… Looks like serverfault users are against this practice
    – adipy
    Commented Nov 19, 2014 at 15:40
  • Is this device in line with the ISP's recursive/caching DNS servers, their authoritative servers (ones that host domains for their customers), or both? This isn't really specified.
    – Andrew B
    Commented Nov 19, 2014 at 17:46
  • @AndrewB My company's servers and our ISP's servers are authoritative for their respective domains. I'm not sure which device you're referring to? The IronPort devices are outside these networks.
    – adipy
    Commented Nov 19, 2014 at 18:51

1 Answer 1


DNS servers fall into a few different groups:

  • Authoritative server
  • Public recursor
  • Non-public recursor

In none of those cases will it make any sense to try to hide their existence. The authoritative DNS servers have to be publicly reachable in order to do the task they were set up for in the first place. A public recursor is pointless if you try to hide its existence. And if you run a recursor which is not supposed to be public, then instead of trying to hide it, simply block requests to it from an unauthorized client IP.

From your question it sounds like the DNS server you are asking about is authoritative for your zone. So I assume it is an authoritative DNS server.

Both authoritative DNS servers and public recursors receive queries from arbitrary client IP addresses, and that means they could potentially be used in amplification attacks.

Unfortunately the DNS protocol offers no good protection against such attacks. The behavior you describe might be a very poor attempt at protecting against such attacks.

There are ways in which a DNS server can protect against amplification attacks without as much of an impact as what you describe.

  • Don't apply countermeasures when no attack is happening. Instead look for the ICMP error responses that an attack would cause, and apply countermeasures when a possible attack has been detected.
  • Don't drop requests, instead send a reply with no answer section and set the truncated bit. This will cause any proper DNS client to retry using TCP.
  • Since TCP is more resistant to spoofing, replies can be send without worrying about amplification attacks.
  • Remember IP addresses which successfully queried over TCP. Those can be allowed to query over UDP in the future.

What I describe here is not some official best practices, it is to the best of my knowledge the best you can do to protect against amplification attacks with the DNS protocol as it looks today. I am not aware of any actual implementation of this approach.

  • I'm leaning towards the idea that this is actually a UDP policy to combat port scanning, rather than being specific to DNS. However I can't think of another UDP port that generates a response that is likely to be open.
    – adipy
    Commented Nov 19, 2014 at 18:32
  • @adipy If the goal is to slow down port scans, then a rate limit on ICMP errors would be sufficient. Moreover since packets to open ports don't generate ICMP errors, they won't be negatively impacted by such a rate limit.
    – kasperd
    Commented Nov 19, 2014 at 18:40
  • That would be better - I should have said I suspect it's a misguided UDP policy. But at this point I'm taking shots in the dark. We have a service request open with the ISP now, I'll know soon enough what they're doing.
    – adipy
    Commented Nov 19, 2014 at 18:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .