[members-discuss] New (silent) reverse dns checks

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 at 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