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

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 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
>     
>     
> 
> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://mailman.ripe.net/
> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/r
> ipe%40probe-networks.de