Re: Résilience infrastructure DNS

Alarig Le Lay <[email protected]> Wed, 19 Apr 2017 12:49:39 +0200
Newsgroups	gmane.network.dns.french
Message-ID	<[email protected]>
On mer. 19 avr. 11:52:20 2017, [email protected] wrote:
> Bonjour,
> 
> Je me soumets à votre expertise, et souhaite partager avec vous
> quelques axes de réflexions concernant l’amélioration de la résilience
> des DNS d’une entreprise en cas d’attaques et partager avec vous nos
> expériences.
> 
> Je travaille à améliorer la résilience de nos infrastructures DNS
> publics.
> Le but, en cas d’attaques, dégradant la disponibilité de
> l’infrastructure réseau ciblée, continuer de répondre aux requêtes
> DNS.
> Une des améliorations, mise en place, déployer des serveurs sur des
> infrastructures réseaux indépendantes les unes des autres.
> Pour diminuer l’impact d’une attaque, je m’appuie sur :
> •	une liste de NS cohérente (serveurs NS réparties sur des
> infrastructures indépendantes), 
> •	sur des valeurs de TTL suffisamment longues, 
> •	sur les caches des résolveurs.
> Une des limites de cette usage, des problèmes de « timeout » peuvent
> perturber les clients, en cas de serveurs NS indisponibles.
> 
> Une seconde amélioration, envisagée, utiliser de l’IP Anycast.
> Solution lourde à mettre en place.
> En Anycast, Les paquets sont routés (annonce BGP) vers le point le
> plus proche ou le plus efficace (je cîble plutôt ce dernier point).
> Anycast est plus adapté au protocol UDP que TCP. En pensant à DNSSEC,
> est-ce que l’Anycast peut poser problème ?
> 
> Nous utilisons le GSLB directement implémenté sur nos serveurs DNS. Le
> GSLB impose un TTL de quelques secondes pour les zones concernées.
> Je pense, que le GSLB diminue la qualité de notre résilience. Je ne
> voie pas d’axe d’améliorations sur ce sujet. Qu’en pensez-vous ?
> 
> Ma contrainte, ne pas pouvoir utiliser les solutions DNS proposées par
> des AWS, DynDNS ou autres, ceci nécéssiterait que j’implémente des
> développements intégrés à nos solutions d’administrations
> centralisées, à nos solutions d’automatisation et nécéssite pour
> certains de leur déléguer les zones, notre service sécurité ne
> l’autorise pas. De plus les solutions dans le cloud ne proposent pas
> le même niveau de service GSLB.
> 
> N’hésitez pas à me faire part de votre propre expérience sur le sujet.
> 
> Merci
> Cordialement
> Eric DUVAL

Bonjour,

Pour ma part j’ai toujours eu du mal avec les loadbalancers, surtout sur
du DNS. Le DNS a déjà tout ce qu’il faut pour répartir la charge et être
résilient aux pannes.
Quand on annonce plusieurs NS sur un domaine, le client va en choisir un
au hasard, donc la charge va automatiquement se répartir entre les
serveurs. Pour ce qui est de la résilience, le client va essayer un
autre serveur s’il voit qu’un serveur ne répond pas, et après il mettra
la réponse en cache, donc la panne ne se verra plus du tout.

Bien sûr, pour que cela fonctionne, il faut des serveurs dans des AS
différents, si possible avec une diversité de transitaires.

Au niveau de la résilience directement sur IP, je ne vois pas pourquoi
l’anycast ne serait pas adapté à TCP. TCP supporte très bien le routage
asymétrique, donc anycast n’a pas de raison de le déranger. Après, j’ai
rarement joué avec, donc il est possible que ça casse des choses
auxquelles je n’ai jamais pensé.
De plus, tous les serveurs racines et un bon paquet de TLDs (qui bien
souvent sont DNSSEC-ready) ont des serveurs anycastés, c’est que ça doit
être efficace pour le DNS :)

Pour ce qui est de DNSSEC, comme très peu de clients ne le vérifient, la
charge supplémentaire induite est très faible. En tout cas, je n’ai pas
vu la différence sur mes serveurs.

-- 
alarig
signature.asc (application/pgp-signature, 488 B)