Semi-flooded with semi-bogus semi-requests

Wiley Sanders bind at
Wed Apr 5 22:18:18 UTC 2006

Some of my customer access DNS servers are being flooded with these
semi-bogus requests: -> DNS C Internet Addr ? -> DNS C Internet Addr ?
[repeated 50 or so  times from the same IP address...]

and then again a few seconds later in the next successive IP in the subnet: -> DNS C Internet Addr ? -> DNS C Internet Addr ?
[repeated 50 or so times from the same IP address...]

Request detail from snoop:
DNS:  Query ID = 24378
DNS:  Opcode: Query
DNS:  1 question(s)
DNS:      Domain Name:
DNS:      Class: 1 (Internet)
DNS:      Type:  1 (Address)

           0: 0003 ba27 1d51 00e0 2b85 9500 0800 4500    ...'.Q..+.....E.
          16: 003e 4024 4000 dd11 2abc c206 c8a8 d178    .>@$@...*......x
          32: d6a6 6336 0035 002a 9766 5f3a 0000 0001    ..c6.5.*.f_:....
          48: 0000 0000 0000 0c67 6f6c 642d 6d6f 6e69
          64: 746f 7203 636f 6d00 0001 0001    

My servers are configured as garden-variety caching-only severs for
use by customer resolvers. The owner of the 194.6.200 subnet has
emailed us to complain, and of course my NOC sent this to me since its
obviously a DNS problem. (/sarcasm) is a stragely configured zone, with 39 NS RRs and 28
A RRs assigned to the name. Doesn't matter, the request does not have
the RD bit set, so my server just sends the root zone back 50 times.

Besides the usual precautions to block spoofed addresses, does anyone
have any comments? This doesn't really look like a DoS, more like a
misconfiguration somewhere.

I stopped the problem by just blockholing the 196.4.200 net with a
blackhole static route on the server. I get the bogus requests but I
don't care, BIND can handle it just fine.

Arcane question: Why are the RCODE bits set to 1 for a request? Those
are the last 4 bits in bytes 62 and 63 above. The RCODE is set to 1 in
normal requests as well. (See RFC1035 - it is meaningless in requests)
Just curious, this is the first time I've looked into a DNS packet bit
by bit.

- W Sanders

More information about the bind-users mailing list