[BIND-8.2.2] query attack or named bug ?

C.S.Chen cschen at ns1.NCTU.edu.tw
Wed Nov 10 16:15:45 UTC 1999


Hi,

We'd run BIND 8.2.2-REL on our Ultra1 DNS server for a while.
- running SunOS 2.5.1. (I'd tried BIND 8.2.1, and got similiar results.)

At first, everything seems to work fine.
However, we'd often encountered some weird things on our DNS server recently.
The CPU loading of the named process will go high suddenly after receiving
tons of continuous bogus DNS queries (e.g. the same one)

- The event was rippled to the DNS forwarder host. The CPU loading of
  the "named" process goes high, too. 
  * The DNS forwarder host runs FreeBSD 3.3-Stable, and BIND 8.2.2-P3.

I wonder if anyone had seen such an event before.

The same query loops almost never end. I'd enabled the debug mode and 
dumped some trace logs.  Here is some sample excerpt.
-----------------------------------------------------------------
datagram from [140.113.216.204].1056, fd 22, len 45
req: nlookup(148.13.102.202.in-addr.arpa) id 46625 type=12 class=1
req: found '148.13.102.202.in-addr.arpa' as '13.102.202.in-addr.arpa' (cname=0) 
forw: forw -> [140.113.54.11].53 ds=5 nsid=36768 id=46625 -1ms retry 4sec
datagram from [140.113.216.204].1056, fd 22, len 45
req: nlookup(148.13.102.202.in-addr.arpa) id 46626 type=12 class=1
req: found '148.13.102.202.in-addr.arpa' as '13.102.202.in-addr.arpa' (cname=0) 
forw: forw -> [140.113.54.11].53 ds=5 nsid=57166 id=46626 -1ms retry 4sec
datagram from [140.113.216.204].1056, fd 22, len 44
req: nlookup(66.218.68.210.in-addr.arpa) id 46627 type=12 class=1
req: found '66.218.68.210.in-addr.arpa' as '66.218.68.210.in-addr.arpa' (cname=0
)
... [deleted]
-----------------------------------------------------------------
Is there anything we could do in the configuration file "named.conf"
to avoid this ?

Worse, I wonder if it is a BIND 8.x bug, or it is a serius DNS attack ?

PS.
  I'd blocked the client sending the bogus queries temporarily. And the 
  CPU loading was lowered.  However, I believe that is not the normal 
  way to go since we cannot expect when/where another bogus queries like
  this one will come in.

  I'd seen lots of another similiar ill-configured examples, which did
  not resolve well as they were supposed to be. ( listed in the end)

  If some one/program(s) calls these ill-configured queries repeatedly,
  our DNS server will suffer badly again.

FYI:
====
 The example query entry "148.13.102.202.in-addr.arpa" listed above is 
 found to be ill-configured.

% dig 148.13.102.202.in-addr.arpa

; <<>> DiG 8.2 <<>> 148.13.102.202.in-addr.arpa
;; res options: init recurs defnam dnsrch
;; res_nsend[signed] to server default -- 127.0.0.1: Connection timed out


% dig 13.102.202.in-addr.arpa ns

; <<>> DiG 8.2 <<>> 13.102.202.in-addr.arpa ns
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5
;; QUERY SECTION:
;;      13.102.202.in-addr.arpa, type = NS, class = IN

;; ANSWER SECTION:
13.102.202.in-addr.arpa.  3d18h46m27s IN NS  ns.bta.net.cn.
13.102.202.in-addr.arpa.  3d18h46m27s IN NS  ns.cn.net.
13.102.202.in-addr.arpa.  3d18h46m27s IN NS  ns.jsnjptt.net.cn.
13.102.202.in-addr.arpa.  3d18h46m27s IN NS  ns.sdjnptt.net.cn.
13.102.202.in-addr.arpa.  3d18h46m27s IN NS  ns.spt.net.cn.

;; ADDITIONAL SECTION:
ns.bta.net.cn.          19h16m7s IN A   202.96.0.133
ns.cn.net.              1d19h5m56s IN A  202.97.16.195
ns.jsnjptt.net.cn.      22h30m48s IN A  202.102.0.68
ns.sdjnptt.net.cn.      21h21m43s IN A  202.102.128.68
ns.spt.net.cn.          21h21m43s IN A  202.96.199.133

;; Total query time: 7 msec
;; FROM: ns1 to SERVER: default -- 127.0.0.1
;; WHEN: Wed Nov 10 23:39:48 1999
;; MSG SIZE  sent: 41  rcvd: 242


)




Here are another more examples:
=====================================================
datagram from [140.113.216.204].1056, fd 22, len 44
req: nlookup(153.3.102.202.in-addr.arpa) id 46624 type=12 class=1
req: found '153.3.102.202.in-addr.arpa' as '3.102.202.in-addr.arpa' (cname=0)
forw: forw -> [140.113.54.11].53 ds=5 nsid=1699 id=46624 -1ms retry 4sec
datagram from [140.113.216.204].1056, fd 22, len 45
req: nlookup(148.13.102.202.in-addr.arpa) id 46625 type=12 class=1
req: found '148.13.102.202.in-addr.arpa' as '13.102.202.in-addr.arpa' (cname=0) 
forw: forw -> [140.113.54.11].53 ds=5 nsid=36768 id=46625 -1ms retry 4sec
datagram from [140.113.216.204].1056, fd 22, len 45
req: nlookup(148.13.102.202.in-addr.arpa) id 46626 type=12 class=1
req: found '148.13.102.202.in-addr.arpa' as '13.102.202.in-addr.arpa' (cname=0) 
forw: forw -> [140.113.54.11].53 ds=5 nsid=57166 id=46626 -1ms retry 4sec
datagram from [140.113.216.204].1056, fd 22, len 44
req: nlookup(66.218.68.210.in-addr.arpa) id 46627 type=12 class=1
req: found '66.218.68.210.in-addr.arpa' as '66.218.68.210.in-addr.arpa' (cname=0

-- 
Joe. C.S.Chen, cschen at nctu.edu.tw
* Computer Center of National Chiao Tung University, Hsinchu, Taiwan.



More information about the bind-users mailing list