Thousands of 'Bad' DNS requests per second after update

After updating to the latest version (0.97.2) my network intrusion prevention system went nuts catching over six thousand ‘Bad’ DNS requests per second (yes, per second) from Hassio.

Each request comes from a different source port on UDP protocol 17 destined for either 1.1.1.1 (CloudFair) or 9.9.9.9 (Quad9) destination port 53 (DNS)

2019-08-20 15:53:00.045	1	2027758	1	3	192.168.10.217	48028	1.1.1.1	53	17	dns	bad-unknown	ET DNS Query for .cc TLD	true
2019-08-20 15:53:00.042	1	2027758	1	3	192.168.10.217	55377	1.1.1.1	53	17	dns	bad-unknown	ET DNS Query for .cc TLD	true
2019-08-20 15:53:00.038	1	2027758	1	3	192.168.10.217	59863	9.9.9.9	53	17	dns	bad-unknown	ET DNS Query for .cc TLD	true
2019-08-20 15:53:00.035	1	2027758	1	3	192.168.10.217	50639	9.9.9.9	53	17	dns	bad-unknown	ET DNS Query for .cc TLD	true

This does not fill me with confidence with regards to the safety/security of using Hassio, anyone know whats going on with this ?

Thanks.
Phil.

The devs have changed the way DNS works in Hassio, it’s using coredns now. This may be why you’re getting these issues. As on how to fix them, I’m not really sure - I’m not a networking engineer.

I’ve whitelisted this signature on my IDS system and now the request ‘storm’ has stopped. Hard coded DNS is not good…, what were they thinking ?

I have an internal port forward rule that makes sure all internal DNS request are serviced by my local router, this way I know where all DNS requests are resolved on my network, even if devices try and use their own hard coded DNS (clearly like HassIO now…).

No idea, I had a look on the github issues and apparently 1.1.1.1 (CloudFair) or 9.9.9.9 (Quad9) are fallback DNS, I’d rather fallback wasn’t used at all and if it can’t find local DNS then give some sort of error.

You can set your own using hassio dns options --servers dns://x.x.x.x using the ssh addon console. The fallbacks do remain.

Yes, but this resets after a reboot (as far as I understand it), and its also does not stop the requests to 1.1.1.1 & 9.9.9.9. This change also breaks local DNS name resolution, again, not good…

That’s old info and was fixed. It now prefers the users’ choice correctly and does not reset.

Well, I still see the requests go out to 1.1.1.1 and 9.9.9.9 on the wire…

Other available commands are hassio dns info and hassio dns restart. Try a restart?

core-ssh:~# hassio dns info
Error: unknown command "dns" for "hassio"
Run 'hassio --help' for usage.
FATA[0000] Error while executing rootCmd: unknown command "dns" for "hassio" 

Make sure whatever ssh addon you are using is up to date. I use the community repo addon which is always a “moment” behind the core-ssh, depending on how bogged down @frenck is. But at this point both include the dns commands in the most recent versions.

Wait, now I’m confused. If you weren’t up to date, how did you add your own server entry in the first place? You said you “still still see the requests go out to 1.1.1.1 and 9.9.9.9”. But I assumed that was after having set your own preferred server when I provided the above command.

Actually I work on both :wink:
In case of the Hass.io CLI & SSH, both the community version and the core version are released in sync, since I maintain the CLI.

Ha! Well, I was spamming the addon store refresh button and did in fact have to wait exactly 1 Moment. I can’t get more precise than that. :stuck_out_tongue_winking_eye:

1 Like