search

cbuijs / unbound-dns-firewall

DNS-Firewall Python script for UNBOUND
GNU General Public License v3.0
25 stars 8 forks source link

Known Issue: Sometimes UNBOUND goes unresponsive and 100% CPU #1

Closed cbuijs closed 6 years ago

cbuijs commented 6 years ago

Some queries will spike UNBOUND to grab 100% CPU and becomes unresponsive and stops answering queries until restart.

Can replicate by browsing the web to web-site www.cnet.com and everything grinds to a hold after this query:

c-7npsfqifvt34x24x78x78x78x2ehpphmfubhtfswjdftx2edpn.g00.cnet.com. A IN

Needs investigation. It is python-module related as when disabled everything works fine. Seems that lots of spawning happens. Doesn't seem to be memory related.

cbuijs commented 6 years ago

To confirm, doing a dig against c-7npsfqifvt34x24x78x78x78x2ehpphmfubhtfswjdftx2edpn.g00.cnet.com indeed make things go south.

The answer never comes out.

For comparison, dig output using google public DNS:

; <<>> DiG 9.10.3-P4-Debian <<>> c-7npsfqifvt34x24x78x78x78x2ehpphmfubhtfswjdftx2edpn.g00.cnet.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17485
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;c-7npsfqifvt34x24x78x78x78x2ehpphmfubhtfswjdftx2edpn.g00.cnet.com. IN A

;; ANSWER SECTION:
c-7npsfqifvt34x24x78x78x78x2ehpphmfubhtfswjdftx2edpn.g00.cnet.com. 299 IN CNAME cnet-wildcard.inscname.net.
cnet-wildcard.inscname.net. 599 IN  CNAME   ins-062.inscname.net.
ins-062.inscname.net.   3599    IN  CNAME   a-sg01sl03.insnw.net.
a-sg01sl03.insnw.net.   3599    IN  A   192.33.31.70

;; Query time: 55 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 02 09:10:11 EST 2017
;; MSG SIZE  rcvd: 203

Boom: 1813 root 20 0 105168 73808 5452 R 100.0 3.7 0:11.34 unbound

Nothing weird, just cname-chain (compared to the worst-one I know: www.paypal.com, this shouldn't be the issue). DNSSEC on or off doesn't make it better. Or tweaking memory and such neither.

So it seems that the spawning multitude of processes related to python is the culprit. Not sure how to influence/fix this. Any ideas, tweaks, tips or remarks?

cbuijs commented 6 years ago

Found it!

The regex ^([^\.]+){64,}$ caused havoc. Removed it with some others. Regex matching quicker as result as well.

Not sure why it was going havoc, I lack the in-dept debugging knowledge to pin-point. If anyone feels to debug, be my guest. Closing it for now.