Expect any Internet-facing DNS service to be attacked immediately that it is up and running.
Caution:
There is no good reason to ever make an instance of dnscache Internet-facing.
Its back-end should be able to act as a client of content DNS servers on Internet, but its front-end should never serve clients from Internet.
Common attacks that you may see take an extensive range of forms. Here are but a few:
You will generally see these logged as ANY (00FF) type queries, sent on DNS/UDP, with a large EDNS0 response buffer size (to get maximum benefit from the attack), using domain names that have a large amount of data, with the reply-to IP address and port set to those of the intended attack victim.
It is also a secondary attack on the content DNS servers whose domain name is used.
(For example, in 2025 the total amount of data served up by the Free Software Foundation's own DNS servers in response to an ANY query against fsf.org. was over 4KiB.)
Attackers rely upon DNS servers being vain wearing-all-the-hats-at-once servers that provide both proxy DNS and content DNS service, and that will thus go and ask the Free Software Foundation's content DNS servers and return with what they answer. This ends up with the proxy DNS servers sending over 4KiB of FSF data, unsolicited, over UDP to the attack target's IP address and port. djbdns has several defensive measures in place against this.
Its primary defence is that tinydns from its original Bernstein version onwards has defaulted to simply not responding to queries about domain names that its database does not record it as authoritative for.
Nothing is reflected back to the primary target.
Note:
Although it might seem that making tinydns respond as BIND did, for every domain name, is a good idea — and asking how to do this was a particularly common question in the early years of djbdns — this is wrong-headed and should not be done.
tinydns does and always did the right thing out of the box.
Its secondary defence is that it does not vainly try to wear all of the hats at once. It never contacts other content DNS servers in response to incoming queries. That is simply not part of its architecture at all.
A later tertiary defence, introduced in March 2019, is that it does not treat ANY queries as valid uses.
Should an attacker use a domain name that is actually in the data.cdb database and within the designated-authoritative part of the namespace tree, ANY queries yield (small) synthesized error responses, pointing human readers of the response to RFC 8482.
djbdns does not, and never has, supported the fingerprinting system whereby one can send ChaosNet-class DNS requests for special domain names such as version.bind, or authors.bind or version.server or several others and have the server report information about itself and the machine that it is running on to anyone in the world who just asks.
One of the sad things to watch is axfrdns report an overlength DNS request because someone has sent it an HTTP/1.0 GET command, but this is a regular occurrence as attackers target "stealth" HTTP servers where administrators think that merely using a different TCP port, and doing nothing else (sometimes not even putting into place the security measures that are on the standard port), provides a form of security.