Un DNS stable (service continu à travers une VIP DNS imaginons) avec un contenu cohérent ainsi qu’un mécanisme logique de réplication/résolution, que demander de plus à part un bon niveau de sécurité ?
La redondance et la continuité des services DNS caractérisent selon moi un environnement informatique sécurisé et bien pensé.
L’absence ou la défaillance de ce service engendre de nombreux impacts, assez négatifs.
Tout est DNS, ne l’oublions pas … peu importe la technologie (Linux BIND, Microsoft DNSADI, Infoblox, QIP, EfficientIP et cætera).
Constat
Mes différentes interventions dans différents cadres me laissent croire que ce service est fondamental. Il est nécessaire au bon fonctionnement de l’informatique moderne, mais malheureusement souvent mal géré.
Peu importe la taille des entreprises, les secteurs ou les technologies, c’est juste hallucinant (ça me fume).
Le service DNS étant un protocole normalisé et un service fondamental pour n’importe quelle infrastructure, il convient donc de s’y attarder. Il faut faire de la robustesse de son infrastructure DNS une réalité, facilement atteignable via une VIP DNS.
C’est une redite, mais ma VIP DNS, j’y tiens énormément !
Accroitre son niveau de sécurité commence par garantir une résilience sans faille de ses services d’infrastructure. C’est un passage obligé pour prétendre une continuité de son métier. C’est vraiment la base avant de penser sécurité, cybersécurité, PRA (Plan de Reprise d’Activité) et ainsi de suite.
Vouloir sécuriser nécessite des efforts, cela va de soi.
Rappel
Pour rappel, le protocole DNS a été conçu dès le départ pour fonctionner avec les deux modes : déconnecté et connecté, donc techniquement avec les protocoles tcp et udp.
Il est tout simplement que les requêtes DNS utilisent principalement le port 35/udp, mais certains échanges DNS s’appuient aussi sur le port 53/tcp.
Le protocole 53/udp n’est que la valeur par défaut. Il bascule vers 53/tcp naturellement quand la communication avec le protocole par défaut ne peut plus se faire. C’est le cas lorsque la taille du paquet devient trop importante pour être transmise dans un seul paquet udp.
Concrètement, si une zone est signée, donc sécurisée via le protocole DNSSEC, elle répondra avec des réponses volumineuses. Cela s’explique par la présence de la clé cryptographique (e.g. signature pour les enregistrements de type RRSIG). L’échange ne peut se faire alors que via le protocole 53/tcp, mode connecté.
Autre cas classique, le transfert d’une zone (conséquente et sécurisée) se fera également via le port en 53/tcp. Il reste concevable que le DNS n’utilise pas obligatoirement le port 53/tcp pour les transferts de zone (petite et non sécurisée).
Pour simplifier, la majorité des transactions DNS s’effectuent via le port 53/udp. Toutefois, le port 53/tcp peut également être utilisé lorsqu’un client l’utilise ou si la réponse est volumineuse.
Techniquement, la taille maximale d’un message DNS via 53/udp est de 512 octets.
Il faut ainsi s’affranchir des idées reçue disant que le DNS fonctionne exclusivement sur le port 53/udp.
Cela peut être une source d’erreur lors des phases d’analyse et des premières approches avec certaines appliances également.
Concept
Il est simple et consiste à garantir de façon continue un service DNS et ne pas agir sur les configurations des clients DNS.
Ce n’est pas évident mais c’est l’objectif, cela sachant que la configuration VIP peut prêter souvent à confusion vis-à-vis de de certains Load Balancers.
Le port proposé à la création de la VIP est uniquement le port 53 (sous-entendu à tort 53/tcp uniquement).
Si vous parvenez à créer deux VIPs DNS dans votre environnement, l’une représentant le DNS primaire tandis que l’autre le secondaire, alors tout le reste devient un jeu d’enfant.
D’emblée, la disponibilité de votre DNS est accrue à travers la VIP.
Si cette première VIP dysfonctionne malgré tout, vous avez toujours la seconde VIP qui assurera le bon fonctionnement du mécanisme DNS au sein de votre infrastructure. Elle joue le rôle de DNS secondaire.
En couvrant le comportement de deux grandes familles de clients DNS, Linux et Windows, je pense que n’importe quelle entité peut obtenir une bonne couverture de son infrastructure.
Prise en charge des clients DNS via une VIP DNS
Imaginons que la première VIP soit indisponible, c’est le scenario.
Pour l’environnement Linux, voici le paramétrage pour rendre la bascule quasi transparente du DNS primaire vers un DNS secondaire (fichier /etc/resolv.conf à modifier) :
options attempts:1 timeout:1
Pour l’environnement Windows, le principe consiste à rajouter une clé de registre pour permettre une bascule rapide vers le DNS secondaire.
La clé est la suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DNSQueryTimeouts
DNSQueryTimeouts (REG_MULTI_SZ)
1 2 2 4 8 0
(Personnellement, j’ai tendance à amender cette valeur par défaut « 1 2 2 4 8 0 » en la valorisant à « 1 1 1 1 1 0 » pour limiter le temps d’attente … à voir ce que cela donne dans la vraie vie de votre côté 😊).
Synthèse
D’une façon générale, il ne faut pas négliger la puissance d’une VIP.
La robustesse de l’infrastructure DNS se trouve augmentée avec cette approche VIP DNS, reste dans un cadre standard et normalisé.
Cette approche apporte également la possibilité d’uniformiser l’ensemble des clients DNS. Quel que soit le client DNS, le paramétrage est constant avec les mêmes DNS primaire et secondaire.
Pour le reste, selon le type de client, il faut simplement s’assurer que le timeout se gère avec transparence. Si toutefois la VIP primaire cesse d’émettre les services qui lui sont confiés, la secondaire doit prendre le relais.
Pour le service DNS, je recommande une VIP DNS avec direct return. Je m’adresse à la VIP, puis un serveur du Pool DNS de la VIP me répond directement. Simple et efficace !
Voilà une approche qui est au top architecturalement parlant !
Si le composant essentiel de l’infrastructure de base est instable, il sera difficile d’aborder les thématiques sécurités / cybersécurités !