How can I tell in the log if a query was successful or refused due to recursion?
Kevin Darcy
kcd at daimlerchrysler.com
Thu Dec 15 03:40:12 UTC 2005
Mark Andrews wrote:
>>Tony Toews wrote:
>>
>>
>>
>>>Folks
>>>
>>>I'm told that my DNS server is participating in "recursive dns dos
>>>attack".
>>>
>>>So I've locked things down I think. More on that to follow as a
>>>separate posting. So I'm looking at my log entries and I'm seeing the
>>>same kind of traffic now as before I removed the recursion option.
>>>
>>>How can I tell in the log if a query was successful or refused due to
>>>recursion? An example of my current log follows:
>>>
>>>14-Dec-2005 18:37:24.145 client 216.18.224.133#41538: query: e.tn.co.za ANY
>>>ANY +E
>>>14-Dec-2005 18:37:25.599 client 216.18.224.133#51561: query: e.tn.co.za ANY
>>>ANY +E
>>>14-Dec-2005 18:37:26.067 client 216.18.224.133#46417: query: e.tn.co.za ANY
>>>ANY +E
>>>14-Dec-2005 18:37:27.630 client 216.18.224.133#43677: query: e.tn.co.za ANY
>>>ANY +E
>>>14-Dec-2005 18:37:28.114 client 216.18.224.133#58498: query: e.tn.co.za ANY
>>>ANY +E
>>>
>>>Bind 9.3.1 on a Win 2003 Server. Serving as DNS for 23 very low traffic
>>>domains hosted on that same system.
>>>
>>>
>>>
>>>
>>There's no way I know of to tell via normal BIND 9 logging whether a
>>query was "successful" or not. For that matter, it depends on what you
>>mean by "success". Is a NODATA response (NOERROR with "no relevant
>>answers" in the Answer Section) "success"? How about a referral?
>>
>>You could, I suppose, configure some addresses locally on virtual
>>interfaces (or whatever the Win 2003 equivalent would be), and send some
>>queries from those source addresses, using dig's -b option, or something
>>similar, just to see how the responses come back.
>>
>>By the way, if those queries above are supposed to be some sort of
>>"recursive DNS DoS attack", then it's a pretty lame one: since BIND
>>treats ANY queries as non-recursive whenever anything owned by the name
>>exists in cache, the attack could be easily fooled, without touching any
>>"production" data, by putting some bogus RRset out there (e.g. TXT, RP)
>>with a really long TTL. As it is, since e.tn.co.za doesn't exist and the
>>relevant negative-caching TTL is 1 day, I can't imagine the negative
>>impact being very high (but I'm open to the possibility that the owner
>>of the zone may have deleted that name subsequent to the beginning of
>>the attack...)
>>
>>- Kevin
>>
>>
>
> It's a recursive DNS DDoS amplification attack. The client's
> address is forged. It is depending on named to amplify the
> traffic. The actual target is 216.18.224.133.
>
>
OK, I get the whole "forge the address of the victim" mechanic now, but
I'm still missing something here. A typical response to an arbitrary
*non*-recursive query, is an "upwards referral" to the root zone, about
440-450 bytes. A typical response to e.tn.co.za/ANY with recursion being
honored is less than 90 bytes. So why would the perpetrator choose to
make their queries recursive?
- Kevin
More information about the bind-users
mailing list