You could then use a health monitor (such as the included dns.pl) to check the operation of the real DNS server and mark it as down if it has failed or times out after a short period. The virtual server could inspect the DNS traffic and route blacklist lookups to the local cache, and other requests to a real DNS server. All locally-generated DNS requests would be delivered to that virtual server, which would then forward them to the real DNS server. Use Traffic Manager to manage the DNS traffic?Ī potential solution would be to configure Traffic Manager to use itself (127.0.0.1) as a DNS resolver, and create a virtual server/pool listening on UDP:53. If you are hosting a local cache of the blacklist, you'd want to separate DNS traffic accordingly. In addition, Traffic Manager uses a single system-wide resolver for all DNS operations. In normal usage, a single delay of 100ms or so against the very first request is acceptable, but a DNS failure (Stingray times out after 12 seconds by default) or slowdown is more serious. Each unrecognised (or expired) IP address needs to be matched against the DNS server, and the connection is blocked while this happens. One undesired consequence of this configuration is that it makes the DNS server a single point of failure and a performance bottleneck. What if my DNS server is slow, or fails? What if I want to use a different resolver for the blacklist lookups? You may wish to increase the dns!negative_expiry setting because DNS lookups against non-blacklisted IP addresses will 'fail'.Ī more sophisticated implementation may interpret the response codes and decide to block requests from proxies (the Spamhaus XBL list), while ignoring requests from known spam sources. Traffic Manager DNS settings in the Global configuration This implementation will issue a DNS request on every request, but Traffic Manager caches DNS responses internally so there's little risk that you will overload the target DNS server with duplicate requests: