Jim Reid <jim at rfc1035.com> wrote:
>>>>>> "joe" == cschen <cschen at cc.nctu.edu.tw> writes:
> joe> BTW, we also found another kind of DNS queries (or attacks ?)
> joe> being issued continuously. - Some user program keeps sending
> joe> DNS queries to some remote IP addr.
> joe> It seemt that BIND 8.x has implemented the Negative Cache
> joe> feature. I wonder why the NCache feature could NOT take care
> joe> of this. Is there something special ?
> No. Negative caching is normally only done by up to date name
> servers. Resolvers don't. This is because resolvers don't have any
> cache and maintain almost no state information. As a general rule, an
> application invokes the resolver to make one DNS lookup. With negative
> caching, a name server is told "this name does not exist and remember
> that for N seconds". So if the name server then gets asked for that
> non-existent name, it can give that negatively-cached answer without
> going and looking up the name again. And getting the same answer as
> before.
> Now it's possible - but highly unlikely - that an application would
> understand the semantics of negative caching. Especially one that
> appears to be stuck in a tight loop asking for the same name over and
> over again. What you have to do is find the owner of the computer
> that's mking these idiot requests and get them to fix it. Oh and if a
> name server doesn't implement negative caching - and there are many
> thousands of them in use! - it will behave in the same idiotic manner
> by making the same queries over and over.
We'd checked. Both the query forwarding server and ours run BIND 8.x.
- I suppose that the servers have Negative Caching built-in.
After we contact the dept.'s administrators, they found that some
lab exercise concerning some SAMBA applications were doing the
errorenous query....
So, it is very simple for a lab exercise to overwhelm some DNS
servers on the campus. This is absolutely NOT a good news.
Anyway, here is some excerpt from the snapshot I still kept.
Symptom:
The PTR of 210.68.133.85 is being asked by the same host continuously.
It seems that our server was forced to forwarding the same query to
the registered authoritative DNS server continously... :-( !
Only after we stop the query site by BIND/acl could the CPU loading
drop to some bwtween 30% to 50%.
- Before that, the CPU loading of the named process almost goes up to
95% to 100%.
FYI,
On normal situation, "named" usually goes below 5% on our server.
PS. See the entries marked by "^^^^^^^^^" below.
======================================================================
datagram from [140.113.209.1].1523, fd 22, len 44
^^^^^^^^^^^^^^
req: nlookup(85.133.68.210.in-addr.arpa) id 30963 type=12 class=1
^^^^^^^^^^^^^^^^^^^^^^^^^^
req: found '85.133.68.210.in-addr.arpa' as '85.133.68.210.in-addr.arpa' (cname=0)
req: found '85.133.68.210.in-addr.arpa' as '85.133.68.210.in-addr.arpa' (cname=0)
forw: forw -> [210.68.133.6].53 ds=5 nsid=7885 id=30963 22ms retry 4sec
^^^^^^^^^^^^^^^^^
datagram from [140.113.209.1].1523, fd 22, len 44
req: nlookup(130.59.66.203.in-addr.arpa) id 30962 type=12 class=1
req: found '130.59.66.203.in-addr.arpa' as '59.66.203.in-addr.arpa' (cname=0)
req: found '130.59.66.203.in-addr.arpa' as '59.66.203.in-addr.arpa' (cname=0)
forw: forw -> [203.66.59.1].53 ds=5 nsid=46733 id=30962 7ms retry 4sec
datagram from [140.113.209.1].1523, fd 22, len 44
req: nlookup(2.188.132.202.in-addr.arpa) id 30961 type=12 class=1
req: found '2.188.132.202.in-addr.arpa' as '188.132.202.in-addr.arpa' (cname=0)
req: found '2.188.132.202.in-addr.arpa' as '188.132.202.in-addr.arpa' (cname=0)
forw: forw -> [203.69.38.2].53 ds=5 nsid=13252 id=30961 22ms retry 4sec
datagram from [140.113.209.1].1523, fd 22, len 44
^^^^^^^^^^^^^^^^^^^
req: nlookup(85.133.68.210.in-addr.arpa) id 30960 type=12 class=1
^^^^^^^^^^^^^^^^^^^^^^^^^^
req: found '85.133.68.210.in-addr.arpa' as '85.133.68.210.in-addr.arpa' (cname=0)
req: found '85.133.68.210.in-addr.arpa' as '85.133.68.210.in-addr.arpa' (cname=0)
forw: forw -> [210.68.133.6].53 ds=5 nsid=5617 id=30960 22ms retry 4sec
^^^^^^^^^^^^^^^
datagram from [140.113.209.1].1523, fd 22, len 44
req: nlookup(130.59.66.203.in-addr.arpa) id 30959 type=12 class=1
req: found '130.59.66.203.in-addr.arpa' as '59.66.203.in-addr.arpa' (cname=0)
req: found '130.59.66.203.in-addr.arpa' as '59.66.203.in-addr.arpa' (cname=0)
forw: forw -> [203.66.59.1].53 ds=5 nsid=30206 id=30959 7ms retry 4sec
datagram from [140.113.209.1].1523, fd 22, len 44
^^^^^^^^^^^^^^^^^^^
req: nlookup(85.133.68.210.in-addr.arpa) id 30958 type=12 class=1
^^^^^^^^^^^^^^^^^^^^^^^^^^^
req: found '85.133.68.210.in-addr.arpa' as '85.133.68.210.in-addr.arpa' (cname=0)
req: found '85.133.68.210.in-addr.arpa' as '85.133.68.210.in-addr.arpa' (cname=0)
forw: forw -> [210.68.133.6].53 ds=5 nsid=52889 id=30958 22ms retry 4sec
[deleted]
--
* Joe. C.S.Chen, cschen at ns.nctu.edu.tw