As part of a DOOS attack (largely inefectual) I am currently seeing log messages of the form:

<DATE> client <EXTERNAL-IP>#3074 (<NAME>): query: <SAME-NAME> IN RRSIG + (<ONE-OF-MY-IPs>)

My reading of the DNS log suggests that this is a query coming from < EXTERNAL-IP >, with the result to be sent to < ONE-OF-MY-IPs >. Is that correct?

We are running an older BIND, soon to be upgraded, but I was hoping to understand what this query is actually doing (many are sent).

Edit: Also, would be nice to know how they are able to structure it to send the result to another IP.

1 Answer 1


The BIND queries log format

Were you following Alan Clegg's (ISC) slides on BIND Logging? On page 16 it states incorrectly:

The address to which the response is sent (in parenthesis)

The BIND 9 Administrator Reference Manual tells it's actually the address to which the query was sent, i.e. an IP address of your DNS server. The manual structure isn't the easiest to read nor reference, so here's the full path to the related documentation:

  • From Reference Manual version 9.14.11,
    • Chapter 5. BIND 9 Configuration Reference,
      • Configuration File Grammar,

The more clear formatting and the emphasis is mine:

  1. The query log entry first reports a client object identifier in @0x<hexadecimal-number> format.
  2. Next, it reports the client's IP address and port number, and
  3. the query name, class and type.
  4. Next, it reports
  • whether the Recursion Desired flag was set (+ if set, - if not set),
  • whether the query was signed (S),
  • whether EDNS was in use along with the EDNS version number (E(#)),
  • whether TCP was used (T),
  • whether DO (DNSSEC Ok) was set (D),
  • whether CD (Checking Disabled) was set (C),
  • whether a valid DNS Server COOKIE was received (V), and
  • whether a DNS COOKIE option without a valid Server COOKIE was present (K).
  1. After this the destination address the query was sent to is reported.
  2. Finally, if any CLIENT-SUBNET option was present in the client query, it is included in square brackets in the format [ECS address/source/scope].

So in:

info: client @0xf00 (example.com): query: example.com IN RRSIG + (
  • is the IP address and port of the client
  • example.com is the query name, IN the class, and RRSIG the type (RFC 4034, 3)
  • + tells the client asked for recursion
  • is an IP address of your DNS server to which the query was sent to

DNS Amplification Attacks & how to mitigate them

There's no signs of a DDoS attack in this log entry per se, and the response is sent back to the client If the client IP address was spoofed, then the amplification attack is about the response to a RRSIG query being much larger than the original query.

...the attacker causes UDP DNS queries with to be sent to the reflecting resolvers, with the source IP addresses for the queries set to the address of the target (victim.) The reflecting servers process the recursive query and send the response to the IP address from which they believe the queries originated. Because of the spoofed origin, the replies are actually sent to the target. - -

The unrequested DNS responses are discarded if/when they reach the target machine, but by the time they have done so they have consumed network resources and a small portion of CPU time on the target machine.

To mitigate this, depending on your situation:

No open recursive name service

The authoritative name servers must not provide recursive name service. This requirement is tested by sending a query outside the jurisdiction of the authority with the “RD”-bit set.

If this is a recursive name server, limit the access only to your own networks that should be allowed to use this service. This could be done either with allow-query or allow-recursion.


Specifies which hosts are allowed to make recursive queries through this server. If allow-recursion is not set then allow-query-cache is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost;) is used.

To enable RRL to defend against this, edit named.conf and add the following rate-limit clause to the global options:

options {
          rate-limit {
              responses-per-second 10;

This is explained more thoroughly in the official documentation under options Statement Definition and Usage: Response Rate Limiting. There you can find

- why and how to use `slip` to truncate responses (done by default with value `2`)
- use `qps-scale` to tighten defenses during attacks.
  • I've asked ISC whether they could correct the error in the presentation. After all, it's currently the the first result for Google search bind query log, so it would be a responsible action to stop spreading misinformation. May 17, 2020 at 8:48
  • 1
    Great explanation. Two things that I think are worth noting: If recursion is allowed for this unknown client (we see in the log that it was requested), that should probably be the top priority to address. And on the subject of RRL, if this is an authoritative server, one might want to be more conservative to avoid for DoS scenarios where the authoritative server stops answering based on the rate-limit, resulting in resolvers giving up on it. (Possibly slip 1 to only truncate instead of dropping responses, in addition to whatever responses-per-second and qps-scale are deemed appropriate.) May 17, 2020 at 10:10
  • Thanks, Håkan! I've updated my answer to address these, too. It was a bit hard to keep it short and simple, but hopefully it's both detailed enough and helping to find the correct parts in the documentation. Unfortunately, the HTML version of BIND 9 ARM is lacking the clear structure it could have if it wasn't converted directly from the PDF book. May 17, 2020 at 11:39
  • Thank you all! Excellent answers. I am seeing, perhaps, a bit under a million of these per hour, and the IP's being queried are the IPs of the main server. My next step would, I think, be to try to delay the attacking machines if at all possible -- but I can't really see how given it's UDP. Reporting them to the ISPs seems futile... May 17, 2020 at 13:19
  • As this is not an attack against your server, but someone is using your server for the attack, you should apply the mitigations described in the answer (and in the documentation linked). Once your server is not useful for this kind of attacks, they will eventually stop or decrease in volume. May 17, 2020 at 13:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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