BIND recursive - DNS Nonsense Name Attacks part 2

Neil neil20 at iprimus.com.au
Thu Jul 2 02:33:41 UTC 2015


Hi again fellow Bind users,

We have been running 9.10.2 to circumvent DNS Random QNAME attacks.
It seems that 9.10.2 had some issues for us with response performance.

At times the clients query's would be accepted but no response was generated
back to clients.
This happened on random basis where our monitoring app would fail with a
lookup test.
I did some simple debugging and could see on the tcpdump requests coming to
the dns server
But the query never made it to bind, Nothing in query.log or nameddebug.log,
and had the trace
turned up to 3. This was 9.10.2 running on RHEL6_32bit, We had no RRL of any
kind turned on.

The box its self was not under any load, ~20 recursive-clients and plenty of
free ram & cpu.
The network response times from client to server were <=15ms and connections
stable
and IPtables running with no resource exhaustion.

The only environment factor was that the box was experiencing Random QNAME
attacks.
Not sure if there is an issue with 9.10.2 but we have move some servers to
9.9.7 which is
performing much better.

The only gripe is that qname-wait-recurse is not supported in 9.9.7 and some
RPZ overrides are not working
correctly like the random qname attack [irmtal.www.desheng28.net ] below
that is in RPZ but not rewriting
due to the server performing recursion first. 

Any way to force the RPZ lookup first for a match in 9.9.7?
Are there any plans for 9.9.8 to support that qname-wait-recurse?


#RPZ zone file contents for 9.9.7 for that nonsense-attack domain
#
desheng28.net   84600   IN      CNAME   www.google.com.au.
*.desheng28.net 84600   IN      CNAME   www.google.com.au.

#Some named debug logs from 9.9.7 with trace set to 3
#
02-Jul-2015 11:14:53.097 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): timeout
02-Jul-2015 11:14:53.097 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): done
02-Jul-2015 11:14:53.097 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): stopeverything
02-Jul-2015 11:14:53.097 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): cancelqueries
02-Jul-2015 11:14:53.097 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): cancelquery
02-Jul-2015 11:14:53.098 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): sendevents
02-Jul-2015 11:14:53.100 query-errors: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: rpz QNAME rewrite
irmtal.www.desheng28.net via irmtal.www.desheng28.net stop on qresult in
rpz_rewrite() failed: timed out
02-Jul-2015 11:14:53.100 query-errors: debug 1: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: query failed
(SERVFAIL) for irmtal.www.desheng28.net/IN/A at query.c:7063
02-Jul-2015 11:14:53.100 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: error
02-Jul-2015 11:14:53.100 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: send
02-Jul-2015 11:14:53.100 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: sendto
02-Jul-2015 11:14:53.100 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: senddone
02-Jul-2015 11:14:53.100 security: debug 3: client 203.212.155.106#63367:
view host_resolver_trusted: request is not signed
02-Jul-2015 11:14:53.100 security: debug 3: client 203.212.155.106#63367:
view host_resolver_trusted: recursion available
02-Jul-2015 11:14:53.100 client: debug 3: client 203.212.155.106#63367: view
host_resolver_trusted: query
02-Jul-2015 11:14:53.100 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: error
02-Jul-2015 11:14:53.100 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: send
02-Jul-2015 11:14:53.100 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: sendto
02-Jul-2015 11:14:53.100 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: senddone
02-Jul-2015 11:14:53.101 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: next
02-Jul-2015 11:14:53.101 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: endrequest
02-Jul-2015 11:14:53.101 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: next
02-Jul-2015 11:14:53.101 client: debug 3: client 211.26.11.28#60327
(irmtal.www.desheng28.net): view host_resolver_trusted: endrequest
02-Jul-2015 11:14:53.101 query-errors: debug 2: fetch completed at
resolver.c:3281 for irmtal.www.desheng28.net/A in 10.003582: timed
out/success
[domain:desheng28.net,referral:0,restart:2,qrysent:3,timeout:2,lame:0,neterr
:0,badresp:0,adberr:0,findfail:0,valfail:0]
02-Jul-2015 11:14:53.101 resolver: debug 3: fetch 0xb45afff8 (fctx
0xb42af5a0(irmtal.www.desheng28.net/A)): destroyfetch
02-Jul-2015 11:14:53.101 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): shutdown
02-Jul-2015 11:14:53.104 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): doshutdown
02-Jul-2015 11:14:53.104 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): stopeverything
02-Jul-2015 11:14:53.104 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): cancelqueries
02-Jul-2015 11:14:53.104 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): unlink
02-Jul-2015 11:14:53.104 resolver: debug 3: fctx
0xb42af5a0(irmtal.www.desheng28.net/A): destroy

Thanks
Neil.B


-----Original Message-----
From: Neil [mailto:neil20 at iprimus.com.au] 
Sent: Friday, 29 May 2015 9:08 AM
To: 'bind-users at lists.isc.org'
Subject: BIND recursive - DNS Nonsense Name Attacks

Hi Bind users,

Just wondering if anyone else has seen the DNS nonsense name attacks on
their recursives?
Any way to mitigate such attacks?

Currently running version 9.10, I already ACL's and have RPZ deployed but
this is a "reactive" solution.  I read that fetches-per-server and
fetches-per-zone have been deployed to subscription releases, any time line
for code to be released in the public  version? Anything else I can do?

Some tcpdump  logs
17:35:26.520596 IP 211.27.99.62.1028 > 210.50.44.4.53: 17436+ A?
nbpdrsthvwxlm.wwwww.jiajiaxhhq.com. (52)
17:35:26.572225 IP 211.27.99.62.1028 > 210.50.44.4.53: 17437+ A?
gcjycliyggj.wwwww.jiajiaxhhq.com. (50)
17:35:26.604453 IP 211.27.99.62.1028 > 210.50.44.4.53: 17438+ A?
zvltevrzkmfhtcq.wwwww.jiajiaxhhq.com. (54)
17:35:26.605662 IP 211.27.99.62.1028 > 210.50.44.4.53: 17439+ A?
xcfpgnlbbwvwoyk.wwwww.jiajiaxhhq.com. (54)
17:35:26.637777 IP 211.27.99.62.1028 > 210.50.44.4.53: 17440+ A?
ttqikqwpcvk.wwwww.jiajiaxhhq.com. (50)
17:35:26.704413 IP 211.27.99.62.1028 > 210.50.44.4.53: 17441+ A?
abcqrsghijxlz.wwwww.jiajiaxhhq.com. (52)
17:35:26.704950 IP 211.27.99.62.1028 > 210.50.44.4.53: 17442+ A?
aopdefthijklm.wwwww.jiajiaxhhq.com. (52)
17:35:26.715783 IP 211.27.98.70.1029 > 210.50.44.4.53: 63183+ A?
eqw.wwwww.jiajiaxhhq.com. (42)
17:35:26.760114 IP 210.50.8.23.41508 > 210.50.44.4.53: 56630+ A?
yjmtmpqxwbuh.wwwww.jiajiaxhhq.com. (51)
17:35:26.762262 IP 210.50.8.23.41508 > 210.50.44.4.53: 54127+ A?
abelutejkzcl.wwwww.jiajiaxhhq.com. (51)
17:35:26.835637 IP 211.27.99.62.1028 > 210.50.44.4.53: 17443+ A?
nbcqrsthvwxym.wwwww.jiajiaxhhq.com. (52)

Thanks
Neil




More information about the bind-users mailing list