Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Last week while going through my log files I noticed that a site started to appear sending multiple A and AAAA requests for their ns1/ns2, www, and two subdomains to my DNS server every few seconds, which are being denied correctly as I have it configured. While not a security risk with the requests being bounced and denied, it is however making my log files grow very quickly and making them difficult to read.

What I found was that this domain put my IP address as their NS1 and NS2 entries, so in addition to people trying to hit their site (from Egypt) they are also hitting me when trying to go to other sites that I presume are hosted by this Egyptian site. Now instead of 4-6 requests per second, I'm getting closer to 15-20. I've tried creating records for this domain and returning 127.0.0.1 with a TTL of 1 year to ease the hits, which worked in eliminating log entries for the main Egyptian domain, but now I'm getting an increase in other domain names trying to hit it as well.

Is there any way to stop this primary domain and the others from attempting to hit the DNS server without disabling BIND (and not serving my zones then) on my Linux/Plesk box? I've emailed the registrant in the domain Whois and the registrar abuse department (Go Daddy, so that won't go anywhere), but have yet to hear anything back. I've also blocked all IP blocks from Egypt, China, etc in my firewall, but a lot of the requests for this domain are from all over the world.

Scratching my head here, any help or ideas would be appreciated.

share|improve this question

2 Answers 2

They'll quickly fix their error if you tell the world that these domain names don't exist.

The main thrust of voretaq7's answer is something that you really should have done already, and probably have. If your DNS server is listening on an IP address that is reachable by the whole of Internet, then it shouldn't be providing proxy DNS service. You need to stop your server from wearing more than one hat, and make sure that it only provides content DNS service.

This leads to the meat of the answer. You simply need to configure your content DNS server to deny the existence of these domain names to the world. The people who've misconfigured their delegations to use your IP address(es) will soon realize their mistake, especially when the end users start complaining that mail, WWW, and other services yield errors about nonexistent domain names, and substitute the correct IP addresses. It's a very simple incentive to give: "Fix your delegations to not erroneously point the world to my servers, and your domain names will magically start existing."

How you do this is simplicity itself. You don't need to watch your logs, enumerate every new domain name as it comes along, and set up a zone covering it. Simply set up a . zone. Your content DNS server will then deny the existence of every domain name that it is randomly queried for, where that domain name isn't covered by one of the zones that you actually intend to serve (and have arranged to be delegated to your server).

Remember to be nice when you do this. This error may well be the result of someone accidentally mistyping a couple of digits in a form. You don't want to annoy people. You only want to give them incentive to fix their error. So don't go setting the MINIMUM field so high on your SOA resource record for . that the negative answers are cached by the world for a week. Enable the people concerned to get things changed quickly. A few hours is probably a good compromise between your need to reduce repeated queries and their need to be able to switch things over to the proper content DNS servers quickly. Don't go setting up wildcard A and AAAA resource records that direct people to nasty places, either. Just return "no such name" answers.

An important note: Don't simply mirror public root DNS data.

You cannot just drop InterNIC's root.zone file into your BIND setup. That database source file has delegations along the zone's bottom edge. Your DNS server will end up sending partial answers ending in delegations for all of these alien domain names that you are being queried about. That will just get it marked as "lame" (for returning upwards delegations) and resolving proxy DNS servers will end up querying it afresh quite often. It doesn't deny the existence of the domain names. You want your server to send complete answers ending in "no such name" for all of those alien domain names, denying their existence. Complete, negative, answers will be cached by the resolving proxies, and they won't come back asking afresh so often.

You therefore need a zone file for . that does not have delegations along its bottom edge. Fortunately, that's actually a lot simpler than InterNIC's file, since for the bare minimum you only need three resource records, looking something akin to this:

@ 86400 IN SOA @ hostmaster 1 2D 1H 2W 3H 
@ 86400 IN NS @
@ 86400 IN A 127.53.0.1

In djbdns format, this is a one-liner:

.:127.53.0.1:.

Further reading

share|improve this answer
    
Brilliant answer. Could have written it better myself. –  Tonny Feb 11 '12 at 15:33

Is this an authoritative nameserver? If so, disable recursion (add recursion no; to your BIND configuration.
Having an authoritative NS also be a recursive resolver is generally considered to be a Bad Thing.

If you are not able to disable recursion entirely, limit it as much as practical (using the allow-recursion {}; directive).

See this page (or the cricket book) for more info on these directives.
If you did not authorize this use of your DNS server you should also notify the originating ISP's abuse contact with an offer to charge them for the unauthorized use of your server and network resources - $0.01 per query seems fair to me :-)

share|improve this answer
    
He already said that his nameserver is rejecting the DNS queries, thus recursion is not on. –  Patrick Feb 11 '12 at 21:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.