How can I tell in the log if a query was successful or refused due to recursion?

[Mark Andrews]

> 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 AN
> Y 
> >>>ANY +E
> >>>14-Dec-2005 18:37:25.599 client 216.18.224.133#51561: query: e.tn.co.za AN
> Y 
> >>>ANY +E
> >>>14-Dec-2005 18:37:26.067 client 216.18.224.133#46417: query: e.tn.co.za AN
> Y 
> >>>ANY +E
> >>>14-Dec-2005 18:37:27.630 client 216.18.224.133#43677: query: e.tn.co.za AN
> Y 
> >>>ANY +E
> >>>14-Dec-2005 18:37:28.114 client 216.18.224.133#58498: query: e.tn.co.za AN
> Y 
> >>>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?

	You havn't seen the 3K TXT record :-)
 
                                                                          
>                                     - Kevin
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org