On 11 Jun 2019, at 19:40, Jonas Frey <jf@probe-networks.de> wrote:
I do see 3 major benefits to combine/unify these: - "saving" IP addresses (depending of how many you run of course[1]) - less effort managing (not having multiple places for configuration thus unifiying [automated] setup) - saving ressources (servers, virtual machines, whatever they run on)
First off, apologies for a meaningful and relevant Subject: header. :-) These assumptions may well hold for you and your network. I doubt they apply anywhere else. I think you also need to consider the setup and recurrent costs of doing things in this way compared to the alternatives. It *might* be cheaper to setup DNS your way (though I doubt it). But it will surely cost you a lot more in the long run: management, support, debugging, risk/threat analysis, etc. More so if you one day need to use some feature for authoritative service which is bad for your recursive service (or vice versa). Keeping these things functionally and physically separate is both basic common sense and good administrative practice. It just doesn’t make any sort of sense to roll up all of your DNS operations into an easily avoided single point of failure. *By design.* You shouldn’t need a document to tell you that. You seem to be using criteria from the mid-/late-1980s - an era of acoustic couplers, wardrobe-sized 1-MIP minicomputers, TCP/IP stacks that had UDP checksumming disabled by default and 64Kb/s leased lines for a university campus. Things have moved on since then. In those early days, BIND was the only game in town for DNS. So pretty much everyone used the same DNS daemon for authoritative and recursive service. There was essentially no alternative. That practice died out as hardware and networks got cheaper and faster, other DNS software emerged, cache poisoning and reflector attacks started happening, etc, etc.