A bit longer answer than one of my collegue.
It is so complicated, because it is a router and it needs to do attention-less upgrades. If you have a server and do apt-get upgrade, it can ask questions. We can’t. The updater needs to solve the problems it has with the rules and flags it has. Furthermore, we wanted to be on the safe side, so we forced the „critical“ flag onto everything that is the very base TurrisOS system.
The stub resolver in libc is not enough, for several reasons. For one, it is a router. It is supposed to provide real resolution to such stub resolvers on the devices on your LAN. Omnia uses knot, you can alternatively switch to unbound. We don’t really support anything else, because, you know, there’s only limited amount of manpower and we can’t just test everything.
As the router uses its own resolver as well, removing it would break the internet access both to other devices on your LAN and the router itself, further preventing it from downloading any packages in manual attempt to fix that.
Depending on your OS on computer, if you try to remove some important parts, like libc or kernel, you’ll be prevented from doing that or you’ll be at least given a very loud warning. We can’t opt for the warning, because the updater needs to work on its own if the repository changes. So it can’t really decide to get rid of some of these things because it collides with some other request.
Yes, I agree that, in some cases, we marked more than absolutely necessary as critical. We try to err on the safe side. As I said, I’ll have a look at making it more flexible and allowing some more freedom. But I still think it is quite reasonable to mandate that DNS resolution must work both on the router and on LAN.