Quand je vois tous ceux qui foncent dans le sql en backend connecté je plains les clients en cas d'attaque ou d'isolation réseau.
Voilà ma petite expérience : - les dns ne devant pas tous se trouver sur le même AS, il faut logiquement en mettre un peu partout sur la toile pour la résilience de votre infra dns - il faut aussi les nommer avec des tld différents si vous mettez tout sur un seul tld ou plusieurs gérés par les mêmes entités administrative en cas de plantage de leurs côté tout tombe - en cas d'attaque dns, pouvoir isoler un serveur dns c'est utile - les backends mysql / psql sur bind on oublie, sur pdns c'est mieux mais la dépendance d'une architecture sql pleinement fonctionnelle est trop forte surtout en cas de réplication géographique - des pdns / sql j'en ai vu tomber plus d'un en cas de forte charge, vu des soucis de synchro sql vautrer des enregistrements avec des ttl d'une semaine, là on est content quand ça arrive Avec tous ces points, on est parti sur du Bind avec fichiers à plat, c'est clairement ce qui tient le mieux la charge y compris en cas de ddos, ça claque bien plus haut que pdns / sql. Par contre on voulait pouvoir gérer avec une interface web principalement pour éviter les erreurs de syntaxe à 4h du mat un dimanche en astreinte, même avec plus de 10 ans d'xp on fait encore ces conneries de temps en temps. L'interface montre à la façon PdnsAdmin une vue synthétique de la zone mais où les modifications ne sont pas instantanées, pdnsadmin propage directement en base et si vous avez fait une boulette c'est immédiat. Là l'interface vérifie la zone, la prépare en fichier à plat dans un coin, la teste avec un bind local si le reload se fait correctement, si oui pousse les fichiers sur les différents serveurs dns, vérifie les numéros de série des zones plus le hash des fichiers. Si tous les serveurs sont bons reload des zones modifiées. Ce qui nous permet d'avoir une solution entièrement décentralisée, de mettre des serveurs dns où l'on veut sur Internet, en cas de compromission d'un serveur dns les données maitre ne sont pas touchées puisque pas d'accès à la base, pas de dépendance de flux le bind est autonome et forcément maitre sur toutes ses zones (pas de réplication master / slave dns). Juste pour ceux qui doutent encore de l'intérêt de mettre leurs dns en dehors de leur AS et infra, quand votre infra est inaccessible, les clients qui ont leurs zones chez vous ne peuvent plus bosser (pas de mail, pas de connexion aux services autres que chez vous, ...) et en 10 ans j'en ai vu des infras isolées par coupure réseau (plusieurs transitaire d'un coup, migration réseau qui déconne, pb bgp, ...), ddos rendant injoignable la plate-forme, piratage de serveur dns maitre en réplication ou du backend de gestion dns ou du serveur bdd, ...
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
