Mans, 1) Ok, but as you say this is a corner case and has to be decided on a rare per-case basis.2) Ok, but this would require the resolvers to be actually down/broken which can be mitigated by monitoring (as you say). The stability is dependent on the software one is using, so this is again a per-case basis. Basically this is (almost) what ISC is saying in the link i provided. 3) Basically same as 2) which (if proper monitoring is in place) can be mitigated easily. 4) Not seen this yet (with proper limiting via RRL et al in place). All of this is very situation dependent and (in my eyes) doesnt apply to every setup. Now as for the pro's of a combined setup i can see: - less resources (i.e. no additional IP addresses "wasted", no requirement for a 3rd/4th server/VM) - less operational effort (i.e. managing 2 servers vs. 4) But i think this is now going way off-topic and should probably be discussed on the dns-wg of RIPE as per Anand's recommendation. The bottom line is that if a feature is changed or dropped i'd like to be noticed (best in advance) of that and that this is actually compiled into a rule set or BCP for people using that service. (and that this is readable somewhere, which isnt the case right now) - Jonas Am Freitag, den 07.06.2019, 20:22 +0000 schrieb Måns Nilsson:
Ok,
Mentioning djb and DNS operations is a bait, but I'm stupid and I'll bite.
1. Cache poisoning. Yeah, the risk is lessened since BIND 9 has way better memory management and data structures than older software, but there are corner cases still.
2. Operational integrity. I do not like having stupid stub resolvers as clients hardwired to my backend system. The stub resolver <-> full service resolver relation is a lot less resilient than the self- healing and adaptive relation between full-service resolver and name server. If I suddenly have clients that are unable to select another server (except by timeout, and then won't learn from it) a lot more outages become service affecting. If one of say 4 name servers for a zone stops answering, no one except monitoring systems will notice. If one of four resolvers stops, 25% of the clients will claim that the Internet is b0rkened. (nothing today feels like working when the timeout to server #2 in /etc/resolv.conf is between 5 to 10 seconds...)
3. Bedwetting is nice until it gets cold. Having an authoritative name server as resolver will mask out real delegation problems further up in the delegation chain, giving issues like "It looks OK here" which is business-affecting ignorance.
4. Resource exhaustion is real. I have recent experience from a corporate system where there was a mixup of name service and resolver service. That was not a nice way to start a Friday morning.
I encourage my competitors to run BIND 8 as resolver and name server. Myself, I stopped doing that in 2001.
-- Måns Nilsson SVT +46 8 7848628
Den 2019-06-07 22:03 skrev "Jonas Frey" <ripe@probe-networks.de> följande:
Mans, can you explain why? ISC (as for bind) itself only states that separting them has one purpose: protecting from downtimes should one fail [1] DJ Bernstein stated it also has protective reasons due to ressource exhaustion [2] (but that info is from 2003). With current hardware in 2019 i hardly see this possible. Even more unlikely if combined with RRL (on bind), which is neccessary for anything open nowadays. With uRPF on the network side this handles quite well. Given all this, what are the real reasons in 2019 to not combine recursor and auth.? - Jonas [1] https://kb.isc.org/docs/bind-best-practices-authoritative [2] https://cr.yp.to/djbdns/separation.html > And, open resolvers have no place on authoritative servers. Full > stop. > > -- > Måns Nilsson SVT > +46 8 7848628
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/r ipe%40probe-networks.de