DNS DDOS Attack - would like to understand log

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,
      • logging Statement Definition and Usage,
        • The category Phrase,
          • queries

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).

5. After this the destination address the query was sent to is reported.
6. 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 203.0.113.88#3074 (example.com): query: example.com IN RRSIG + (192.0.2.1)

• 203.0.113.88#3074 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
• 192.0.2.1 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 203.0.113.88#3074. 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:

• If this is an authoritative server, do not allow open recursion. This comes directly from the IANA's Technical requirements for authoritative name servers:

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.

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.

• You can use Response Rate Limiting:

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.