Boiler BIGIP DNS V13.1 VF

En réunissant une structure de
commutation haute performance, un

matériel et un logiciel spécifiques, F5 offre
la flexibilité nécessaire pour prendre les
bonnes décisions concernant le trafic
applicatif sans créer de goulot
d’étranglement. Les performances élevées
qu’apportent les plates-formes BIG-IP vous
permettent de consolider l’infrastructure –
et de réduire les coûts en termes
d’administration, d’énergie, d’espace et de
refroidissement – et d’en faciliter la
croissance future.
BIGIP DNS
Version 13.1
F5 Networks
Table des Matières
1. Présentation de la solution BIG-IP DNS ................................................................................................ 3
1.1. Principaux avantages .................................................................................................................... 3
1.1.1. Disponibilité des applications sur de nombreux datacenters............................................... 3
1.1.2. Contrôle de l’ensemble du trafic applicatif........................................................................... 3
1.1.3. Amélioration des performances applicatives ....................................................................... 3
1.1.4. Simplicité et efficacité de la gestion du réseau distribué ..................................................... 3
1.1.5. Sécurisation du service DNS .................................................................................................. 3
2. Description technique de la solution .................................................................................................... 4
2.1. Objectifs de la solution de GSLB ................................................................................................... 4
2.2. Architecture de GSLB .................................................................................................................... 4
2.2.1. Positionnement dans le réseau DNS ..................................................................................... 4
2.2.2. Mode transparent ................................................................................................................. 7
2.2.3. Mode « délégation de zone » ............................................................................................... 9
2.3. Les Eléments de l’infrastructure BIG-IP DNS............................................................................... 11
2.3.1. Objets Physiques ................................................................................................................. 11
2.3.2. Objets Logiques ................................................................................................................... 13
2.3.3. Interaction avec d’autres équipements F5 ......................................................................... 15
2.3.4. Collecte de métriques ......................................................................................................... 16
2.4. Répartition de charge Globale (GSLB)......................................................................................... 19
2.4.1. Deux niveaux de répartition................................................................................................ 19
2.4.2. Différents Algorithmes de répartition de charge ................................................................ 20
2.5. Groupe de synchronisation DNS ................................................................................................. 22
2.6. Fonction Avancées ...................................................................................................................... 23
2.6.1. Bind et Zone Runner ........................................................................................................... 23
2.6.2. DNSSEC ................................................................................................................................ 24
2.6.3. DNS Express......................................................................................................................... 27
2.6.4. Cache DNS ........................................................................................................................... 28
2.6.5. DNS 6->4.............................................................................................................................. 30
2.6.6. High-Speed Logging DNS ..................................................................................................... 31
2.6.7. Log des décisions de répartition de charge ........................................................................ 32
2.6.8. Statistiques Détaillés DNS - AVR ......................................................................................... 32
1 Solution BIGIP DNS V13.1 | F5 NETWORKS
2.6.9. Response Policy Zones (RPZ) ............................................................................................... 34
2.6.10. Anycast ................................................................................................................................ 35
2.6.11. iRules ................................................................................................................................... 36
2.6.12. Sélection des Probes et Critères de Disponibilité d’une Ressource.................................... 38
2.6.13. Architecture DNS Interne du DNS ....................................................................................... 39
2.7. Management de la solution ........................................................................................................ 40
2.7.1. Interface d’administration .................................................................................................. 40
2.7.2. Sauvegarde de configuration .............................................................................................. 41
2.7.3. Logging et Reporting ........................................................................................................... 41
3. Points forts de la solution F5 .............................................................................................................. 42
4. Fonctions DNS par Releases ................................................................................................................ 43
4.1. Version 11.0.0 ............................................................................................................................. 43
4.2. Version 11.1.0 ............................................................................................................................. 44
4.3. Version 11.2.0 ............................................................................................................................. 44
4.4. Version 11.3.0 ............................................................................................................................. 44
4.5. Version 11.4.0 ............................................................................................................................. 45
4.6. Version 11.5.0 ............................................................................................................................. 45
4.7. Version 11.6.0 ............................................................................................................................. 46
4.8. Version 12.0.0 ............................................................................................................................. 47
4.9. Version 12.1.0 ............................................................................................................................. 47
4.10. Version 13.0.0 ......................................................................................................................... 47
4.11. Version 13.1.0 ......................................................................................................................... 48

1. Présentation de la solution BIG-IP DNS
La mise en place de plusieurs Data Centers est capitale pour protéger l’entreprise contre les pannes de
site et améliorer les performances des applications. Pour atteindre pleinement ces objectifs, il est
nécessaire de mettre en place une méthode efficace de surveillance de l’infrastructure et des
applications et de contrôle de l’infrastructure distribuée.
BIG-IP® DNS permet de répondre aux requêtes DNS de façon plus efficace que le simple équilibrage de
charge entre plusieurs Data Centers. BIG-IP DNS répartit les demandes liées à l’environnement applicatif
en fonction de règles métier, des performances des applications et de l’état du Data Center et du
réseau, pour un contrôle complet de l’ensemble du trafic, une plus grande disponibilité et de meilleures
performances.
BIGIP DNS permet aussi de sécuriser le service DNS contre toutes les menaces du type DDoS DNS, DNS
Reflection, DNS Poisonning, Paquets Malformés, NXDOMAIN floods, etc.
1.1. Principaux avantages
1.1.1. Disponibilité des applications sur de nombreux datacenters

En s’assurant que chaque utilisateur est toujours connecté au meilleur site, BIG-IP DNS permet de
mettre en place un plan de reprise après sinistre (PRA) et de continuité de l’activité (PCA) solide.
1.1.2. Contrôle de l’ensemble du trafic applicatif

En dirigeant les utilisateurs en fonction des besoins liés à l’activité de l’entreprise, comme aux
applications et au réseau, BIG-IP DNS permet de bénéficier d’un niveau de contrôle et de souplesse
optimal du trafic applicatif.
1.1.3. Amélioration des performances applicatives

Chaque utilisateur est orienté vers le site assurant les meilleures performances, en fonction de l’état du
réseau et des applications.
1.1.4. Simplicité et efficacité de la gestion du réseau distribué

Quel que soit son niveau de complexité Les outils d’administration et la puissance de l’interface
graphique et de commande offrent une visibilité complète sur l’ensemble des ressources, depuis un
point de contrôle centralisé.
1.1.5. Sécurisation du service DNS

Le BIGIP DNS protège le service DNS contre les attaques. Ainsi, le service DNS est garanti d’être
disponible et performant. Les utilisateurs sont assurés d’avoir un accès fiable et rapide à leurs
applications et ressources.

2. Description technique de la solution
2.1. Objectifs de la solution de GSLB
La solution BIG-IP DNS ajoute un niveau d’intelligence à l’architecture de résolution de noms (DNS). Les
limitations traditionnelles d’une infrastructure DNS sont les suivantes :
• Répartition de charge limitée : principalement du Round Robin permettant de servir

alternativement des IPs.
• Pas de visibilité sur la disponibilité : les architectures DNS servent des IPs sans notion de
disponibilité de la ressource utilisant l’adresse IP.
• Aucune visibilité sur le contexte applicatif : certaines applications nécessites de faire persister
l’utilisateur lors de ses différentes visites, ou encore certaines applications sont inter
dépendantes les unes des autres. Les serveurs DNS ne savent pas prendre en compte ces deux
notions.
• Pas de notion de proximité de l’utilisateur : les entreprises internationales investissent

massivement dans la construction de Data Center à travers le monde. Les services DNS
traditionnels ne savent pas privilégier un site en fonction de la proximité de l’utilisateur.
2.2. Architecture de GSLB
2.2.1. Positionnement dans le réseau DNS

Les solutions BIG-IP DNS se positionnent traditionnellement en complément d’une infrastructure DNS
existante. Que l’environnement soit public, gestion des noms déclarés sur Internet, ou interne, gestion
des noms de l’intranet de l’entreprise par exemple, l’objectif de l’infrastructure de GSLB est d’apporter
un complément d’agilité sur tout ou partie de la zone DNS.
Le service Bind étant également disponible sur le BIG-IP DNS, ce dernier peut remplacer les serveurs
DNS d’une entreprise.
Le schéma ci-dessous décrit le mode de fonctionne de l’architecture DNS traditionnelle dans le cas de
l’accès à une ressource sur Internet :
• Un utilisateur ouvre son navigateur et entre l’adresse du site www.domain.com
• Le navigateur déclenche une requête de résolution de nom à destination du serveur DNS

configuré sur le poste de travail (LDNS : Local DNS)

• Le LDNS interroge les serveurs racines de l’infrastructure DNS publique pour l’enregistrement
www.domain.com. Un serveur racine lui répond avec l’adresse du serveur DNS autoritaire pour
la zone .com.
• Le LDNS suit la réponse et contact un serveur autoritaire pour la zone .com. Le serveur de la
zone .com lui indique l’adresse du serveur autoritaire pour la zone domain.com.
• Le LDNS envoie finalement sa requête au serveur autoritaire pour la zone domain.com. Ce

dernier répond à partir des éléments de sa configuration DNS avec l’adresse IP publique du site
www.domain.com.
• Le LDNS répond au poste de travail avec l’IP du site www.domain.com.
• Le client se connecte au serveur www.domain.com.
Figure 1 : résolution de nom traditionnelle
Dans ce type d’architecture le serveur DNS de la zone domain.com ne prend absolument pas en
considération le fait que physiquement l’utilisateur se trouve géographiquement très éloigné du serveur

final hébergeant l’application www.domain.com. De plus la ressource renvoyée est potentiellement
indisponible, mais les serveurs DNS traditionnels n’ont aucun moyen de réagir à ces cas de pannes et
une intervention manuelle est donc nécessaire pour modifier la configuration de l’enregistrement DNS
pour pointer sur une ressource d’un autre Data Center.
Le schéma suivant décrit une architecture utilisant la solution BIG-IP DNS. Le processus de résolution
DNS est le même que pour le schéma précédent, mais la dernière requête DNS aboutie non pas sur un
serveur DNS traditionnel mais sur un BIG-IP DNS.
• L'application Web www.domain.com est disponible sur deux Data Center, un aux US et le
second en Europe.
• Le BIG-IP DNS est configuré pour surveiller les applications sur chaque Data center. Il émet donc
périodiquement des requêtes http pour tester la disponibilité du service http.
• Lors de la réception de la requête DNS pour www.domain.com le BIG-IP DNS utilise sa base de
géolocalisation pour déterminer la provenance de l’utilisateur. Ce dernier résidant en Europe, il
doit donc être dirigé vers le Data Center Européen.
• Mais lors des derniers tests de vie sur le Data Center Européen il se trouve que l’application
www.domain.com n’est pas disponible et ne répond pas. Le BIG-IP DNS renvoie donc l’adresse
de l’application disponible sur le Data Center US.
• L’utilisateur envoie sa requête Web sur le serveur basé aux US, et évite ainsi une page blanche
d’indisponibilité du serveur Européen.

Figure 2 : Résolution DNS intelligente avec la solution BIG-IP DNS
Deux types d’architectures sont traditionnellement recommandés pour intégrer le BIG-IP DNS dans une
infrastructure DNS existante. L’objectif étant un déploiement rapide avec un minimum de changement
sur l’architecture en place.
2.2.2. Mode transparent

Le mode Transparent perme de ne rien modifier sur l’infrastructure DNS. Les boitiers BIG-IP DNS sont
positionnés en coupure des flux DNS et interceptent de façon transparente les requêtes pour les noms
DNS qui doivent être « load balancés » de façon globale. Ce mode coupure peut être soit physique soit
logique.
Le mode coupure physique (bridge) nécessite une refonte du réseau local d’interconnexion des serveurs
DNS, le boitier BGI-IP DNS vient s’intercaler physiquement entre les serveurs DNS et le monde extérieur.
Ce mode permet de ne rien changer au niveau de la configuration des serveurs DNS existants (plan

d’adressage IP, route par défaut …). Le BIG-IP DNS se comporte comme un pont de niveau 2 pour
l’intégralité des flux, sauf la partie DNS sur laquelle il applique ses fonctions de répartition intelligente.
Figure 3 : Mode Transparent Physique
Le mode coupure logique implique uniquement une reconfiguration du routage des flux DNS (Adresses
des serveurs) vers le BIG-IP DNS. Le schéma ci-dessous décrit un exemple de topologie. En fonction de
l’architecture réseau, il est possible soit de déclarer l’adresse IP de service DNS des clients sur le BIG-IP
et donc les flux sont nativement routés vers le boitier, soit de rediriger par routage (Policy Based Routing
par exemple) les IP des serveurs DNS sur le BIG-IP DNS.

Figure 4 : Mode Transparent Logique
Le mode transparent présente un certain nombre d’avantages. Etant en coupure de tous les flux DNS, le
BIG-IP DNS a ainsi la possibilité d’apporter des services additionnels à la pure fonction de GSLB. Ces
fonctions sont présentées plus en détail dans la suite de ce document :
• DNS-SEC : Possibilité de signer tous les échanges DNS sans avoir de modification à faire sur
l’infrastructure existante. Même pour les enregistrements qui ne doivent pas être « load
balancés » au niveau global.
• DNS-Express : DNS autoritaire en RAM pour toute la zone DNS hébergé derrière le BIG - IP DNS
permettant de servir très rapidement un grand volume de requêtes DNS.
• Load Balancing DNS : permet de répartir la charge sur les serveurs DNS existants pour les flux
non « load balancés » au niveau global.
2.2.3. Mode « délégation de zone »

Le mode délégation de zone comme son nom l’indique consiste à déléguer une sous zone de
l’arborescence DNS de l’entreprise aux boitiers BGI-DNS. Ces derniers auront la responsabilité de
répondre pour une partie des noms DNS à répartir de façon globale.
Ce type de déploiement est indiqué lorsque seulement une partie des enregistrements DNS doit être
traitée ou que l’infrastructure DNS ne se prête pas au mode transparent, par exemple dans le cas où un
très grand nombre de serveurs DNS sont utilisés et répartis dans des lieux géographiques distincts.

Reprenons notre exemple pour le service www.domain.com, ce dernier est aujourd’hui résolu par les
serveurs DNS de la zone domain.com via un enregistrement de type A (Alias) pointant sur l’adresse IP du
serveur Web.
Dans le mode délégation de zone nous allons apporter les modifications suivantes :
• Création d’une sous zone gslb.domain.com dans la configuration DNS des serveurs actuels
• Modification des enregistrements de type A par des CNAME pointant sur une nouvelle
ressource : www.glsb.domain.com
• Déclaration des IP des boitiers BIG-IP DNS par des enregistrements de type NS (serveurs de
noms autoritaires) pour la sous zone gslb.
Le nouveau schéma de flux est présenté dans le graphique ci-dessous :
• Après plusieurs itérations le serveur LDNS interroge le serveur DNS de domain.com pour
l’entrée www.
• Ce dernier répond avec l’entrée CNAME www.gslb.domain.com ainsi qu’avec les

enregistrements NS des serveurs de noms autoritaires pour cette sous zone : ici l’IP du boitier
BIG-IP DNS
• Le serveur LDNS interroge le boitier BIG-IP DNS pour l’entrée www.gslb.domain.com
• Ce dernier applique son algorithme de répartition de charge et renvoie l’adresse IP de la

meilleure ressource.

Figure 5 : Résolution DNS Intelligente en mode Délégation de Zone
2.3. Les Eléments de l’infrastructure BIG-IP DNS

Les Boitiers DNS ont une vision globale de l’infrastructure applicative répartie sur différents Data
Centers. Pour permettre une action granulaire, plusieurs éléments sont déclarés dans sa configuration.
2.3.1. Objets Physiques

2.3.1.1 DNS
Il est assez rare qu’un seul boitier BIG-IP DNS soit déployé dans une infrastructure. Typiquement au
moins deux BIG-IP DNS sont intégrés, idéalement un boitier par Data Center. Les différents DNS vont
communiquer entre eux pour :
• Synchroniser leur configuration
• Echanger les informations de disponibilité applicative

• Echanger les informations de persistance et de proximité des LDNS
Ces échanges se font à travers un protocole propriétaire et sécurisé : iQuery.
2.3.1.2 Serveurs
Les éléments serveurs sont les équipements physiques qui portent les services (serveurs virtuels) à
« load balancer » de façon globale. Ils peuvent être de différentes natures :
• Load Balancer : ces équipements ont pour rôle de répartir la charge localement au sein de Data
Center. Un équipement physique va en règle générale héberger plusieurs services qu’il gère.
• Système BIG-IP : répartiteur de charge applicatif (LTM) ou de liens WAN (Link Controller), ces
derniers ont la particularité de pouvoir communiquer avec les équipements BGI-IP DNS via le
protocole IQuery pour échanger les informations de statistiques ou encore découvrir
automatiquement les serveurs virtuels disponibles.
• Serveur générique : ce sont des serveurs non redondés qui portent un ou plusieurs services
applicatifs.
2.3.1.3 Liens
Les liens définissent les connexions physiques du Data Center vers Internet ou le réseau WAN de
l’entreprise. Les boitiers BIG-IP-DNS surveillent l’état des liens qui peut déterminer la disponibilité des
ressources hébergées au sein du Data Center.
2.3.1.4 DataCenter
L’objet Data Center représente le regroupement physique des serveurs, serveurs virtuels, liens et objets
DNS. Les boitiers BIG-IP DNS consolident les informations de chemins et métriques collectées aux près
ses serveurs et serveurs virtuels, liens, du Data Center, et utilisent ces informations pour appliquer ses
algorithmes de répartition de charge. L’objet Data Center un élément clef dans la définition des règles
de répartition globale.
L’objet Data Center permet notamment d’appliquer des politiques et actions sur toute les ressources du
Data Center, que ce soit pour forcer une population d’utilisateurs à privilégier les services d’un Data
Center ou encore désactiver toutes les applications pour réaliser des actions de maintenance.

Figure 6 : exemple d'architecture décrivant l'utilisation de plusieurs Data Centers
2.3.2. Objets Logiques

2.3.2.1 Serveurs Virtuels
Les serveurs virtuels sont les applications que l’on souhaite « load balancer » de façon globale. Ils sont
définis par une adresse IP et un port applicatif. Dans le cas de serveurs virtuels hébergés par un Load
Balancer, ces serveurs virtuels sont des proxys applicatifs permettant de répartir la charge localement
entre différents serveurs rendant le même service. Dans le cas d’un serveur virtuel hébergé sur un
serveur générique il y a de forte probabilité que le serveur virtuel définisse la ressource à atteindre.

Figure 7 : exemple de serveurs virtuels auto-découverts sur un BIG-IP LTM
2.3.2.2 Pools
Les pools représentent un ensemble de serveurs virtuels répondant au même service. Il est possible de
créer des pools intra Data Center ou Inter Data Center. Les pools sont des éléments clefs de la
configuration du BIG-IP DNS car ils sont configurés avec un algorithme de répartition de charge
permettant de choisir une ressource parmi le pool qui sera renvoyé comme réponse DNS au LDNS.
2.3.2.3 Wide IPs

Une Wide IP est un nom DNS complétement qualifié (FQDN) qui sont associés à un ou plusieurs pools.
Quand une requête DNS est reçue sur le BIG-IP DNS, le nom DNS demandé est comparé à la liste des
Wide IP configurée sur le boitier. Si le nom correspond à une entrée de la configuration, alors le BIG-IP
DNS sait qu’il doit appliquer ses algorithmes de répartition de charge sur cette demande. Si la demande
ne correspond à aucune entrée, en fonction de la configuration, le BIG-IP DNS peut : ne pas répondre,
passer la main au serveur Bind embarqué, transmettre la requête à des serveurs DNS locaux.

Figure 8 : Exemple de configuration de plusieurs Wide IPs sur un BIG-IP DNS
2.3.3. Interaction avec d’autres équipements F5

Les boitiers BIG-IP DNS doivent communiquer avec différents éléments dans l’infrastructure. Leur rôle
principal est d’avoir une vision globale de la disponibilité des applications. Deux types de communication
sont observés :
• La communication avec d’autres boitiers BIG-IP DNS : pour la synchronisation des

configurations, des métriques, des tables de persistance.
• La communication avec des serveurs : load balancer ou encore serveurs génériques, pour
récupérer les informations de disponibilité applicative des serveurs virtuels hébergés.
Lorsque le BIG-IP DNS doit communiquer avec des équipements qui appartiennent également à la
famille BIG-IP, ils utilisent le protocole propriétaire F5 iQuery. Le protocole iQuery communique sur le
port 4353, il est chiffré en SSL pour assurer la confidentialité des échanges si ces derniers sont effectués
à travers Internet.
Les avantages d’utiliser le protocole IQuery sont les suivants :
• Il est sécurisé, et un échange de certificat permet de s’assurer de l’identité de chacun des

intervenants.

• Il permet à un boitier BIG-IP DNS de découvrir automatique tous les services configurés sur un
boitier BGI-IP LTM et éviter d’avoir à les déclarer à la main.
• Il permet de laisser la tache de supervision applicative au BIG-LTM qui l’effectue déjà tout en
récupérant de façon agrégée ces informations de disponibilité et d’état.
2.3.4. Collecte de métriques

Les BIG-IP DNS utilisent deux types de méthode de communication pour déterminer quel est le meilleur
serveur virtuel à renvoyer lors d’une résolution de nom. Le premier, les moniteurs, est utilisé pour
vérifier quels sont les serveurs virtuels fonctionnant correctement ou encore quelle est leur charge de
trafic actuelle. Le second type, les sondes, est utilisé pour tester le réseau entre les Data Centers et
l’utilisateur (ici le LDNS). Aucun type n’est utilisé par défaut, mais le BIG-IP DNS utilisera n’importe
quelle information disponible pour déterminer le meilleur virtual serveur ou chemin à un moment
donné. La configuration du BIG-IP DNS détermine quel paramètre, ou combinaison de paramètres est
utilisé pour résoudre les requêtes effectuées sur les wide ips.
2.3.4.1 Moniteurs
Les BIG-IP sont pré configurés avec un ensemble de moniteurs applicatifs utilisés pour tester la
disponibilité des serveurs, serveurs virtuels ou des pools. La plupart des moniteurs peuvent être utilisés
tels quels, mais il est possible de les personnaliser pour s’adapter au comportement des applications à
load balancer. Les moniteurs disponibles sont les suivants :
• BIG IP : permet de de récupérer les informations de métrique d’autres systèmes BIG-IP tels que
les LTM, DNS ou Link Controller.
• SNMP : utilisé pour tester les performances d’un serveur pouvant répondre en SNMP. Ce
moniteur permet notamment de récupérer des informations de performance du serveur (CPU,
nombre de connexions …).
• FTP : ouvre une connexion sur un serveur FTP et demande le téléchargement d’un fichier. Si le
fichier est reçu le test est positif.
• Gateway ICMP : envoie une requête ICMP echo et attend un message ICMP reply en retour.
• http : ouvre une connexion TCP et envoie une commande http.
• HTTPS : ouvre une connexion TCP, négocie une session SSL puis envoie une commande http.
• IMAP : détermine le statut d’un service IMAP (Internet Message Access Protocol) en se
connectant au serveur et ouvrant un répertoire spécifique.
• LDAP : Vérifie qu’il est possible d’obtenir une réponse à une requête basée sur des champs base
LDAP et filtre.

• MSSQL : effectue une vérification sur un servie Microsoft SQL.
• NTTP : récupère l’identification d’un newsgroup sur un serveur.
• POP3 : se connecte avec un nom d’utilisateur sur un serveur de type POP (Post Office Protocol)
• RADIUS : test une authentification sur un serveur RADIUS
• Real Server : test la performance d’un serveur de stream REAL utilisant l’agent Real System Data
Collection.
• Scripted : permet de créer un script shell avec le langage Expect.
• SIP : teste le statut d’in service SIP Call-ID
• SMTP : envoie des commandes SMTP à un serveur
• SOAP : test un service Web en SOAP
• TCP : essaie d’ouvrir une connexion TCP et la referme.
• TCP_Half_Open : envoie un TCP SYN et attend en retour un SYN ACK, puis renvoie un RESET
• UDP : envoie un paquet UDP sur une IP et un port
• WAP : envoie une chaine de caractère et l’attend en retour
• WMI : test un serveur embarquant Windows Management Infrastructure (WMI) via l’agent de
collecte.

Figure 9 : Exemple de configuration d'un moniteur HTTP
2.3.4.2 Sondes
Les sondes sont utilisées pour tester le chemin entre les clients DNS (ici les LDNS) et les Data Center
hébergeant les services. Ses sondes sont uniquement mises en œuvre si les algorithmes de répartition
de charge des BIG-IP DNS le nécessitent (utilisant un critère tel que le « path metric »). Cinq types de
sondes sont utilisés :
• Requête de type DNS inverse : requête DNS non récursive demandant le nom du serveur LDNS
envoyée à son adresse IP
• Requête de type Root DNS : requête DNS non récursive envoyée au LDNS pour récupérer la liste
des serveurs Root DNS.
• TCP : paquet TCP syn envoyé sur le port 53 du serveur LDNS
• UDP : paquet UDp envoyé sur le port echo du serveur.
• ICMP : ping envoyé au serveur LDNS.

Figure 10 : configuration des paramètres des sondes
L’objectif de ces sondes est de récupérer une information de temps de réponse (Round Trip Time) ou de
nombre de saut (hop) de routage entre le Data Center et le LDNS. Donnant ainsi une indication de
proximité réseau.
2.4. Répartition de charge Globale (GSLB)
2.4.1. Deux niveaux de répartition

Lorsque le BGI-IP DNS reçoit une requête pour une résolution de nom, son objectif est de répondre à
avec la ressource la plus disponible ou la plus proche de l’utilisateur. Les algorithmes de répartition de
charge sont utilisés pour répondre à cet objectif et s’assurer qu’un serveur ne soit jamais saturé par trop
de connexion alors que le même service situé dans un autre Data Center est sous utilisé.
La configuration des BIG-IP DNS prend en compte deux niveaux de répartition de charge pour répondre
à tous les modèles d’architecture et besoins possibles :

• Load balancing au niveau de la Wide IP : plusieurs pools peuvent être associés à une Wide IP,
l’objectif est d’en choisir un. Ce niveau de répartition peut par exemple être utilisé pour répartir
la charge entre deux Data Center, un pool étant associé à chaque site.
• Load balancing au niveau du pool : comme sur un répartiteur de charge traditionnel, ici on
cherche à répartir la charge entre plusieurs serveurs virtuels configurés au sein d’un même pool
et rendant le même service. La configuration du load balancing au niveau d’un pool est découpé
en trois méthodes permettant de sélectionner un comportement en cas d’impossibilité
d’appliquer l’algorithme préférablement choisit :
➢ Preferred : methode préférée, incluant les méthodes de répartition statiques et

dynamiques
➢ Alternate : utilisé quand la méthode préférée ne peut être appliquée.
➢ Fall back : appliqué lorsqu’au algorithme n’est applicable. Si cette méthode n’arrive pas
à déterminer un serveur virtuel, le BIG-IP DNS se replie sur la méthode « Return to
DNS » en utilisant la configuration BIND embarquée et un comportement de serveur
DNS classique.
2.4.2. Différents Algorithmes de répartition de charge

2.4.2.1 Algorithmes statiques
• Round Robin : repartit la charge de façon séquentielle entre les pools ou les membres d’un
pool.
• Ratio : répartition séquentielle avec pondération.
• Global Availability : utilise toujours le premier membre disponible.
• Static Persist : utilise toujours le même membre pour un LDNS donné.
• Return to DNS : utilise la configuration du serveur BIND embarqué.
• Topologie : L’algorithme de topologie permet de cartographier son infrastructure et de se

servir de la base de géolocalisation embarquée pour déterminer la localisation de
l’utilisateur et le diriger vers le Data Center le plus proche. La base de localisation fournit
une association IP publique/continent/pays/ville, mais il est également possible de créer ses
propres enregistrements pour une utilisation dans un réseau ou les clients sont dans des
plans d’adresse privés.

Figure 11 : Exemple de configuration d'une topologie
2.4.2.2 Algorithmes dynamiques

• Round Trip Time (RTT) : utilise le serveur virtuel avec le temps de réponse le plus court jusqu’au
LDNS.
• Completion Raté : choisit le serveur virtuel qui possède le moins de connexion avec des paquets
perdus ou « timed out » durant les précédentes transactions.
• Hops : compte le nombre de sauts entre le LDNS et les Data Center et sélectionne un serveur
dans le Data Center le plus proche au niveau nombre de nœuds de routage.
• Least Connections : utilise le serveur virtuel avec le moins de connexion en cours.
• Virtual Server Capacity : sélectionne un serveur virtuel, embarqué sur un BIG-IP LTM, qui a les
plus de membre disponible.
• Kilobytes per Second (KBS) : utilise le débit réseau récupéré en SNMP ou la sonde BIG-IP pour
choisir le serveur virtuel.
• Packet Rate : utilise le débit réseau récupéré en SNMP ou la sonde BIG-IP pour choisir le serveur
virtuel.
• Quality of service : permet à l’administrateur de créer son propre algorithme de répartition de

charge en combinant les métriques de temps de réponse, taux de complétion, débit par paquet,
topologie, saut, capacité de lien, KB/S, et en assignat aux métriques choisies un poids.

Figure 12 : Configuration de l'algorithme de QOS
2.5. Groupe de synchronisation DNS

Comme indiqué précédemment un déploiement de BIG-IP DNS nécessite, le plus souvent, au moins deux
boitiers et idéalement un par Data Center. Néanmoins, que l’on déploie la solution en mode transparent
ou en délégation de zone, il n’y aucune certitude qu’en à savoir quel boitier BIG-DNS va recevoir les
requêtes DNS des clients. Il est donc impératif que ces derniers soient capables de répondre
identiquement à la même requête pour conserver une cohérence globale de la visibilité et la répartition
des utilisateurs sur l’architecture.
Lors du déploiement de plusieurs boitiers BIG-IP DNS, les étapes de configuration nécessitent la mise en
place d’un groupe de synchronisation. Le groupe de synchronisation va permettre à plusieurs BIG-IP DNS
d’échanger des informations à via le protocole IQuery (TCP port 4353).
La synchronisation prend en compte :
• Le partage des éléments de configuration : une modification effectuée sur un BIG-IP DNS est
propagée à l’ensemble des autres boitiers.

• Echange des métriques : chaque BIG-IP DNS à la vue de l’état de disponibilité de l’intégralité des
Data Center, liens et serveurs virtuels. Ainsi que la proximité déterminée par les sondes vers les
différents clients LDNS.
• Echange des informations de persistance: si la persistance est nécessaire pour certaines

applications, les BIG-IP DNS échangent leurs informations pour s’assurer qu’un même serveur
LDNS reçoit la même réponse DNS pour la résolution d’une wide ip.
Les communications IQuery au sein d’un groupe de synchronisation sont chiffrées en SSL. Lors de la
configuration du groupe de synchronisation il est également nécessaire d’échanger des certificats ssl
entre chaque boitier pour s’assurer de l’identité de son partenaire lors de l’établissement d’une session
IQuery.
2.6. Fonction Avancées
2.6.1. Bind et Zone Runner

Les boitiers BIG-IP DNS implémente un service BIND 9.5. Ce service n’est pas utilisé pour les résolutions
de noms des wide ips par défaut, mais peut être configuré pour être employé dans les cas suivants :
• Si l’entreprise souhaite remplacer son architecture DNS complétement par la solution BIG-IP
DNS.
• Si les algorithmes de répartition de charge du boitier BIG-IP DNS sont incapables de déterminer
un serveur virtuel adéquat.
Le service BIND utilise le processus named traditionel en se basant sur le fichier de configuration
named.conf et les bases de données associées embarquées sur l’appliance BIG-IP DNS.
La configuration du service BIND est automatiquement mise à jour lorsqu’un élément de configuration
est ajouté au niveau du BIG-IP DNS, tel qu’un nouvelle wide ip, impliquant la création d’une zone des
Alias associés.
Pour faciliter l’utilisation du service BIND, l’outil ZoneRunner est intégré à la console d’administration
graphique du BIG-IP DNS. ZoneRunner permet l’administration complète de BIND de façon graphique
limitant ainsi les erreurs de configuration. ZoneRunner permet également d’importer et d’exporter
facilement des informations de zone lors de l’intégration du BIG-IP DNS dans une architecture DNS
existante.

Figure 13 : Exemple de l'interface ZoneRunner
2.6.2. DNSSEC
DNSSEC est l’acronyme pour Domain Name Security Extensions. C’est un ensemble d’extension au
protocole DNS permettant de sécuriser les réponses DNS. Il fournit au client DNS (le LDNS)
l’authentification des données, l’authentification de l’absence de réponse et l’intégrité des données. Il
est à noter que DNSSEC ne fournit pas la confidentialité des informations échangées.
L’objectif principal de DNSSEC est de protéger les clients de données DNS forgées comme celles créées
via des attaques de type « DNS cache poisoning ». Il permet de signer de façon numérique les réponses
DNS. Si le client DNS fait confiance au certificat DNS associé au serveur DNSSEC, il peut être sûr que les
réponses sont authentiques et non altérées.

Figure 14 : Configuration d'une zone DNSSEC
DNSSEC introduit 3 nouveaux types d’enregistrements DNS :
• RRSIG (Ressource Record Signature) : inclus dans toutes les réponses signées d’un serveur
DNSSEC. Cela correspond à la signature de la réponse. Une réponse classique d’un serveur
DNSSEC contient donc un enregistrement de type A et RRSIG.
• DNSKEY : cet enregistrement est analogue à un certificat SSL. Il contient la clef publique du
serveur DNSSEC. Le client l’utilise pour déchiffrer l’enregistrement RRSIG et donc valider la
signature de toute la réponse. Comme pour les certificats SSL une chaîne de confiance est
établit pour déterminer l’autorité d’un serveur DNSSEC sur une zone.
• DS : cet enregistrement est utilisé pour valider un enregistrement de type DNSKEY. Si un serveur
DNSSEC réfère à un client un autre serveur DNSSEC, il fournit l’enregistrement DS que le client
pourra utiliser pour vérifier l’identité du nouveau serveur.

Figure 15 : Déclaration d'une clef DNSSEC
Un quatrième enregistrement appelé NSEC peut être utilisé pour nier de façon autoritaire l’existence
d’un nom.
Une infrastructure DNSSEC utilise deux types de clefs privées. La première, ZSK pour Zone Signing Key,
est utilisée pour signer une zone et générer les enregistrements RRSIG et NSEC. L’enregistrement
DNSKEY contient la clef publique associée avec la ZSK.
La seconde clef, KSK pour Key Signing Key, est utilisée pour signer les enregistrements DNSKEY et tous
les enregistrements de type DS pour les sous domaines délégués.
La configuration DNSSEC sur un BIG-IP DNS peut être employée pour :
• Apporter ces fonctions de sécurité pour les wide ips configurées
• Apporter ces fonctions de sécurité pour toute la zone DNS de l’entreprise sans modification des
serveurs DNS actuels, lorsque les BIG-IP DNS sont positionnés en mode coupure.

L’utilisation des enregistrements DNSSEC est conditionnée à la présence du bit « DO » dans la requête
DNS du client. Si malgré la présence de ce bit le boitier BIG-IP DNS n’est pas configuré pour implémenter
DNSSEC, boitier renverra une réponse non signée. Si BIG-IP DNS n’est pas capable de répondre et doit
passer la main au serveur local BIND ou aux serveurs DNS de l’entreprise il signera dynamiquement les
réponses.
2.6.3. DNS Express

Les serveurs DNS sont vulnérables à différents types d’attaques. Le DDOS, pour Distributed Denial Of
Service, en est une. Dans ce type d’attaque, l’attaquant essaie de saturer le serveur de destination par
de nombreuses requêtes, le rendant inopérant. La fonction DNS Express est utilisée pour remédier à ce
risque. Comme indiqué par le schéma ci-dessous, le cabinet Forrester à déterminer que sur l’année
2010, plus de la moitié des sondés avaient subis une telle attaque lors des deux dernières années.
Figure 16 : Etude Forrester sur les attaques DDOS des services DNS
La fonction DNS Express utilise les mécanismes de transfert de zones DNS pour dupliquer la
configuration DNS existante dans la mémoire du BIG IP DNS et devenir un serveur DNS esclave
autoritaire ultra rapide.

Figure 17 : Fonctionnement de DNS Express
La fonction peut être utilisée à la fois pour le service BIND embarqué sur le BIG-IP DNS ou pour les
serveurs DNS de l’infrastructure existante.
Les zones peuvent être transférées d’un serveur DNS vers DNSX. Les zones transférées dans DNSX
peuvent notifier d’autres serveurs DNS secondaires en utilisant un message de type AXFR NOTIFY. Enfin,
DNSX supporte les clés TSIG pour les zones.
2.6.4. Cache DNS

Un cache DNS transparent peut être configuré sur le BIG-IP DNS. Dans ce cadre, le système utilise des
resolvers DNS externes pour résoudre les requêtes, et cacher les réponses retournées par les resolvers.
La prochaine fois que le BIG-IP DNS reçoit une requête pour une réponse qui existe dans son cache, le
système renvoi immédiatement la réponse à partir du cache. Le cache transparent contient les
messages et enregistrements de ressources.
Grâce au cache transparent, le BIG-IP DNS consolide le contenu qui devrait, dans le cas contraire, être
caché sur plusieurs resolvers externes. Le fait d’avoir un cache consolidé devant des resolvers externes
(chacun ayant son propre cache), permet d’avoir un meilleur pourcentage de cache hit et donc des
meilleures performances.

1.1.1. Resolver et Cache DNS
Il est possible de configurer un resolver cache sur le BIG-IP pour résoudre les requêtes DNS et cacher les
réponses. La prochaine fois que le système reçoit une requête pour une réponse qui existe dans le
cache, le système retourne la réponse à partir du cache. Le cache DNS contient les messages,
enregistrement de ressources et les nameservers que le système utilise pour résoudre les requêtes DNS.

Figure 18 : Fonctionnement du Resolver Cache DNS
En utilisant ce type de fonctions et d’architecture, le nombre de requêtes DNS et les temps de latence
sont réduits. Le BIG-IP DNS répond immédiatement aux nombreuses requêtes clientes pour un même
site et fournie son propre service de résolution DNS pour ne plus avoir à utiliser et maintenir des
serveurs DNS resolvers annexes dans l’infrastructure. Les résultats sont :
• Une navigation plus rapide grâce à une réduction pouvant aller jusqu’à 80% des temps de
latence DNS
• Jusqu’à 80% de réduction des requêtes DNS sortantes
• Réduction des coûts liés à l’infrastructure DNS
2.6.5. DNS 6->4

Le nombre d’adresses disponibles IPV4 arrivant petit à petit à son terme, les entreprises vont migrer
progressivement vers IPV6. Un fournisseur de service n’ayant plus d’adresse IPV4 disponible devra
déployer ses nouveaux utilisateurs directement en IPV6. Mais que se passe-t-il si un client IPV6 essaie de
se connecter à une ressource IPV4 ?
La fonction DNS64 fournit un proxy applicatif intelligent DNS pour coordonner le service DNS avec la
nécessité de translater l’adresse IPV6 de l’utilisateur en une adresse IPV4 pour joindre sa ressource. Le
système BIG-IP fournit ainsi le DNS64 et le NAT64 pour permettre la communication entre un client IPV6
et un serveur IPV4, sans avoir aucun changement à faire coté client ni coté serveur.
La fonction DNS64 permet le comportement suivant :
• Un client IPV6 envoie une requête DNS au BIG-IP DNS
• Le BIG-IP DNS envoie une requête DNS A et AAAA aux serveurs DNS configurés
• En fonction de sa configuration, dans son profil DNS, le BIG-IP DNS se comporte de la façon
suivante :
➢ Si le serveur DNS renvoie un enregistrement de type A, il accole un préfixe de 96 bits et

retourne une réponse AAAA au client
➢ Si le serveur DNS renvoie un enregistrement de type AAAA, le BIG-IP DNS envoie la

réponse AAAA au client.
Le préfixe de 96 bits utilisé dans le premier cas (serveur DNS envoie une réponse A) permet de capter le
flux de l’utilisateur sur une plateforme de NAT qui écoute les flux IPV6 sur ce préfixe, et translate le flux
IPV6 en IPV4 en enlevant ce préfixe. Les boitiers BIG-IP LTM peuvent remplir ce rôle de passerelle de
NAT IPV6 vers IPV4.

Figure 19 : schéma d'architecture pour translation IPV6 vers IPV4
2.6.6. High-Speed Logging DNS

Il est possible de configurer le BIG-IP pour logguer les informations en rapport avec le trafic DNS, et
envoyer les messages de log à des serveurs de log distant via le mécanisme de High-Speed logging.
Vous pouvez choisir de logguer soit les requêtes DNS, soit les réponses, ou les deux.
De plus, vous pouvez décider de configurer le système pour faire des logs DNS de manière différente en
fonction des ressources.

Figure 20 : Configuration du High-Speed Logging
2.6.7. Log des décisions de répartition de charge

Quand une requête arrive au GTM pour une résolution de nom DNS, dans le but d’envoyer une réponse,
le système prend une décision de load-balancing. Il est désormais possible de logguer, via le mécanisme
de High-Speed Logging, les raisons pour lesquelles le GTM a pris telle décision de load-balancing.
2.6.8. Statistiques Détaillés DNS - AVR

Le Module AVR (Application Visibity Reporting) vous permet de visualiser graphiquement des
statistiques DNS afin de vous aider à manager et avoir des rapports sur le trafic DNS. Les statistiques
DNS dans AVR incluent :
Les requêtes DNS par :
• Application ;
• virtual server ;
• query name ;
• query type ;
• adresse IP client.

Par ailleurs, vous pouvez aussi accéder aux statistiques DNS Globale qui incluent :
• Total de requêtes et réponses DNS ;
• Détails sur les requêtes et les réponses DNS ;
• Nombre de requêtes wide IP ;
• Nombre de requête et Notify DNS Express ;
• Nombre de requêtes cache DNS ;
• Nombre de requêtes DNS IPv6 vers IPv4,
• Nombre d’échecs ;
• Nombre d’actions de type «unhandled ».
Figure 21 : Nombre de Requêtes DNS par Query Name

Figure 22 : Nombre de Requêtes DNS par Adresse IP Client
2.6.9. Response Policy Zones (RPZ)

La fonction de RPZ est un mécanisme de firewall utilisé par les résolveurs DNS récursifs, qui permet de
filtrer via des listes de catégories la résolution des noms de domaines. En effet, un RPZ est une zone qui
contient une liste de domaine Internet malicieux. La liste inclue un ensemble de RR (RRset) pour chaque
domaine malicieux. Chaque RRset inclue les noms du domaine malicieux et tous les sous-domaines
relatifs.
Quand le BIG-IP reçoit une requête DNS pour un domaine qui est dans la liste du RPZ, le système peut
répondre d’une manière ou d’une autre en fonction de la configuration.
Le BIGIP peut répondre un NXDOMAIN à une requête pour un domaine malicieux :
Alternativement, vous pouvez configurer le système pour retourner une réponse qui redirige l’utilisateur
vers un « walled garden » :

Il existe beaucoup de fournisseurs de RPZs. Le BIG-IP supporte l’utilisation de ces fournisseurs.
Actuellement, F5 Networks a testé le BIG-IP avec les fournisseurs Spamhaus
(http://www.spamhaus.org/organization/dnsblusage/) et SURBL (http://www.surbl.org/df).
Si vous ne souhaitez pas souscrire un abonnement à un de ces fournisseurs, vous pouvez utiliser
ZoneRunner sur le BIGIP pour créer votre propre RPZ.
2.6.10. Anycast
Les fonctions IP Anycast font partie d’un ensemble fourni par une licence additionnel « advanced
routing » permettant de gérer les protocoles de routage dynamique et notamment l’injection de routes
dynamique. L’objectif de cette fonction conjointement à l’utilisation du module BIG-IP LTM est de
pouvoir annoncer dynamiquement l’adresse virtuelle de service du BIG-IP DNS quand les services DNS
du site sont disponibles. Les bénéfices d’utiliser IP anycast pour les services DNS sont :
• Améliorer l’évolutivité de l’infrastructure
• Mitiger les attaques de DDOS
• Aider à la distribution géographique de flux
• Réduire les latences DNS.
Le schéma ci-dessous décrit le fonctionnement de l’architecture avec la fonction IP Anycast. Deux BIG-IP
DNS annoncent leur adresse de service DNS (identique). Les routeurs prennent en compte cette
information dans leurs échanges de routage dynamique. En fonction de la localisation du client, il sera
donc routé vers le boitier le plus proche au sens du nombre de nœuds de routage (en fonction du
protocole) réseau.

Figure 23 : Figure 23 : exemple de fonctionnement de la fonction IP Anycast
2.6.11. iRules
Les Irules sont un ensemble de directives utilisés pour scripter le comportement des boitiers BIG-IP dans
leur tâche de gestion des flux. L’avantage des Irules est de pouvoir plier le comportement des solutions
F5 en fonction des besoins particuliers des applications de l’entreprise même si ce comportement n’a
pas été prévu initialement lors du développement de la solution.
Dans une configuration traditionnelle sans Irules, le BIG-IP DNS résout les requêtes DNS en se basant sur
sa configuration de wide ips, ses méthodes de load balancing. Mais il se pourrait que dans des
conditions particulières, on souhaite résoudre de façons différentes certaines requêtes. Le mode
traitement est le suivant :
• La requête est reçue sur le BIG-IP DNS pour une wide ip configurée.
• Un évènement Irule apparait et l’Irule est appliquée
• Si l’évènement n’apparait pas, ou si l’Irule n’influe pas sur le processus de résolution (juste pour
des besoins de logging par exemple) la résolution normale de la wide ip s’applique.
Les Irules sont appliquées au niveau des wide ip et vous permette par exemple de spécifier un pool
pour certaines requêtes, ou une machine, ou encore d’ignorer la requête.
Voici un exemple d’IRule qui spécifie l’utilisation d’un pool lorsque l’adresse IP du client LDNS est
10.10.10.10 :

When DNS_REQUEST {
If { [IP ::client_addr] equals 10.10.10.10 {
Pool my_pool
}
}
Le site web communautaire DevCentral contient de nombreux exemples et la syntaxe du langage Irule :
http://devcentral.f5.com
La liste des commandes iRules disponibles est ci-dessous. En fonction des besoins, il est donc possible
d’intercepter une requêtes ou réponse DNS afin de l’inspecter, l’interdire, la loguer, etc…
Un deuxième exemple d’iRule pourrait être l’utilisation de la base de donnée de Réputation afin
d’interdire ou autoriser une requête DNS. On peut y voir un intérêt dans deux types de besoins :
• Protection DNS Entrant :

Si la requête vient d’une machine de « mauvaise réputation » changer la réponse DNS ou mettre en
place une limite de requêtes par seconde.
• Protection DNS Sortant :
Si la réponse à la requête a « mauvaise » réputation changer la valeur (possible redirection sur une page
LTM).
2.6.12. Sélection des Probes et Critères de Disponibilité d’une Ressource

Il est possible de spécifier, pour chaque serveur, une préférence pour le choix des BIG-IP qui vont
prendre en charge les probes (exécution des monitors et des sondes) : local, distant, ou un pool
spécifique. Ceci permet de mettre en œuvre des règles customisées au lieu d’utiliser le mécanisme par
défaut qui est basé sur une élection automatique.
Le choix se fait en utilisant les options « Prober Preference » et « Prober Fallback ». Ces options
s’ajoutent à l’option « Prober Pool » traditionnelle (cf captures d’écran plus bas pour les choix
possibles).
De plus, afin d’améliorer les critères de disponibilité, une option appelée « Require » est sélectionnable.
Cette option permet la mise en œuvre d’une règle de monitoring de type « M à partir de N ». Celle-ci a
comme action qu’une ressource soit monitorée simultanément à partir de N BIGIPs. La ressource est
considérée comme disponible si au moins M monitors sont vus up par les différents BIGIPs.
Les options « Prober Preference » et « Prober Fallback » sont complètement indépendantes des règles
de monitoring « M à partir de N » (configurables à travers l’option « Require »).
Figure 24 : Option Prober Preference

Figure 25 : Option Prober Fallback
Figure 26 : Option Require
2.6.13. Architecture DNS Interne du DNS

Le schéma ci-dessous décrit les différents modules que le trafic DNS traverse dans le BIG-IP DNS.
La requête DNS, puis la réponse DNS, suivent un cheminement interne qui permet de mettre en œuvre
toutes les actions nécessaires avec un maximum de performance.

Par exemple, l’évènement iRule DNS_RESPONSE est la dernière vérification d’une réponse DNS avant
qu’une signature DNSSEC soit ajoutée. Cela veut dire que n’importe quelle réponse DNS, même celles
venant de DNS Express, de DNS ou réécrite par DNS, aussi bien que celles venant d’un serveur DNS
externe ou du BIND, peuvent être inspectées et modifiées.
Il est possible pour une réponse DNS de venir d’un serveur DNS externe, d’être modifiée par la fonction
DNS64, puis réécrite par DNS, et finalement inspectée par une iRule DNS. Suite à cela, l’iRule peut
rejeter la réponse et créer sa propre réponse, ou même réémettre une nouvelle requête, et par
conséquent recommencer tout le process une fois de plus.
2.7. Management de la solution
2.7.1. Interface d’administration

Les boitiers BIG-IP DNS sont administrables via une interface graphique web et une ligne de commande
(TMSH).

Dans le cas où le BIG-IP DNS est utilisé en tant que module avec d’autres produits BIG - IP F5, l’interface
d’administration est commune pour l’intégralité des services. Simplifiant ainsi les taches
d’administration.
Figure 27 : capture d'écran de l'interface d'administration du BIG-IP DNS
2.7.2. Sauvegarde de configuration

Il est possible de sauvegarder la configuration intégrale de BIG-IP DNS dans une archive pouvant être ré
injecté sur un nouveau boitier. Il est également possible d’utiliser la fonction de groupe de
synchronisation pour mettre à jour un nouveau boitier avec la configuration en place sur d’autres BGI-IP
DNS du même groupe.
2.7.3. Logging et Reporting

Plusieurs sources d’information sont disponibles pour notifier l’administrateur d’un évènement survenu
sur le BIG-IP DNS :
• Fichiers de logs locaux : l’outil Syslog-ng est disponible nativement sur les boitiers BIG-IP DNS
pour gérer les évènements survenant sur les boitiers BIG-IP. Les filtres de type Facilité ou niveau
de log permettent de gérer au mieux la criticité des différents évènements.

• Système de log centralisé : en plus de pouvoir générer local des logs, les BIG-IP ont la possibilité
de les exporter en temps réel vers des serveurs d’analyse ou de stockage
• Ecran LCD : un écran LCD en face avant est disponible sur la plupart des boitiers et permet de
remonter des informations d’alerte survenant sur le châssis.
• Support de SNMP : Les boitiers BIG-IP permettent l’envoie d’alertes sous forme de trap SNMP
mais également d’être interrogé par des serveurs SNMP pour fournir des statistiques. Une mib
propriétaire est disponible pour le module DNS : F5-BIGIP-GLOBAL-MIB.
• Envoie d’EMAIL : un client PostFix est disponible pour envoyer des alertes sous forme de mails
aux administrateurs.
3. Points forts de la solution F5

▪ Performances de la solution / Architecture Interne Unique. La conception matérielle et logicielle
des plateformes F5 est optimisée et dédiée aux fonctions ADC leur permettant des
performances de premiers rangs :
▪ ASICs de commutation et de traitement niveau 4 (sur les plateformes supportées)
▪ Carte accélératrice SSL
▪ Carte de Compression (sur les plateformes supportées)
▪ OS TMOS performant, temps réel et modulaire
▪ Fonctionnement Full Proxy (2 connexions par client : 1 entre le client et le load balancer,
1 entre le load balancer et le serveur)
▪ CPU puissants de dernière génération (utile pour les traitements applicatifs intelligents)
▪ Mémoire importante (table de connexions et de persistance)
▪ Clustered Multiprocessing: fonction de l’OS TMOS qui grâce à un matériel (FPGA)

permet d’utiliser l’ensemble de la puissance CPU de la machine pour traiter le trafic.
▪ Evolutivité de la solution
▪ Gamme complète de 5 Gbps à plus de 80 Gbps de capacité
▪ Plateformes On Demand : VIPRION
▪ Modules complémentaires de disponibilité, de sécurité, de gestion des accès et

d’optimisation des applications sur la même plateforme (LTM, AFM, ASM, APM, etc.)

▪ Management
▪ Interface graphique ergonomique
▪ Interface en Commande en ligne complète
▪ Outils de Troubleshooting utiles dont Tcpdump, ssldump, telnet, ssh, etc.
▪ Interface d’administration dédiée permettant de garder le contrôle à distance sur

l’équipement même en cas de reboot
▪ Gestion de plusieurs environnements de configuration (partitions)
▪ Outil d’administration Centralisée (BIG-IQ)
▪ API iControl permettant d’automatiser ou d’intégrer le pilotage de tâches

d’administration depuis une application tierce.
▪ Véritable Load Balancer Applicatif
▪ Connaissance Native du protocole DNS
▪ Gestion de trafic applicatif intelligente (iRules, persistance)
▪ Nombreux tests de vie applicatifs intégrés et possibilité d’intégration de nouveaux tests

de vie
▪ API REST permettant d’intégrer les équipements F5 dans l’écosystème applicatif
▪ Pérennité de la société
▪ F5 est une société focalisée dans les domaines de l’ADC et de la sécurité. F5 est un
leader de ces marchés (vu comme leader par les différents analystes de ce marché, part
de marché et croissance annuelle importante).
▪ F5 dispose d’une forte stabilité financière (cash important, pas de dettes)
▪ De nombreux éditeurs importants ont tissé des partenariats forts avec la société F5
(Oracle, Microsoft, IBM, BEA, VMWare,etc.).
4. Fonctions DNS par Releases

4.1. Version 11.0.0
▪ DNS Express
▪ GTM sur Viprion
▪ GTM sur Virtual Edition (VE)
▪ IP Anycast pour les services DNS
▪ Device-specific Probing : possibilité, pour des serveurs spécifiques, de choisir un groupe de
BIGIP-IP en charge de faire les monitors et retrouver les statistiques de performance.
▪ Support des Route Domaines pour les Monitors : il est possible de déployer des BIG-IP GTM
avec des BIG-IP LTM qui sont configurés avec des Route Domaines.
4.2. Version 11.1.0

▪ iRules DNS : Les nouvelles commandes iRules DNS s’appliquent au listener DNS et sont
exécutées dans les évènements DNS_REQUEST et DNS_RESPONSE. Elles nécessitent un
profile DNS et sont disponibles dans le module GTM ou le nouvelle Add-On DNS pour LTM.
Les commandes iRules DNS permettent d’inspecter les paquets DNS et de les modifier. Les
capacités incluent : manipulation des requêtes DNS (lecture/modification), des
enregistrements DNS (RR), et des réponses DNS. D’autres commandes donnent la capacité
de contrôler le trafic DNS en activant et désactivant des fonctions DNS. Grâce aux iRules
DNS, il est simple d’implémenter du filtrage DNS, du log de requêtes, ou tout autre cas
d’utilisation tel que le DNS Firewall.
4.3. Version 11.2.0

▪ DNS cache : le BIGIP-IP peut cacher les réponses DNS. Ainsi, la prochaine fois que le système
recoit une requête pour une réponse qui existe dans le cache, le BIG-IP répond avec
l’enregistrement de son cache.
4.4. Version 11.3.0

▪ Intervalle de sauvegarde de la configuration : par défaut, les changements de configuration
du GTM sont sauvés dans le fichier bigip_gtm.conf toutes les 15 secondes. Désormais, il est
possible de configurer cet intervalle de temps.
▪ DNS Remote High-Speed Logging : les informations sur le traffic DNS peuvent être logguées
et envoyées à des serveurs de logs via le moteur de high-speed logging. On peut choisir de
logguer les requêtes DNS et/ou les réponses DNS. De plus, des serveurs de logs différents
peuvent être configurés pour des ressources spécifiques.
▪ Statistiques Détaillées DNS dans AVR et dans les statistiques globales : le module AVR
permet d’intégrer et visualiser des statistiques détaillées DNS. Les statistiques DNS AVR
incluent les requêtes DNS par : virtual server, query name, query type, client IP address. Les
statistiques globales incluent : total des requêtes et réponses DNS, détails sur les requêtes
et réponses DNS, nombre de requêtes WIP, nombre de requêtes et notify DNS Express,

nombre de requêtes Cache DNS, nombre de requêtes IPv6 to IPv4 DNS, réécritures, échecs,
et nombre de requêtes non prises en comptes.
4.5. Version 11.4.0

▪ Synchronisation incrémentale pour les groupes de GTM : le système synchronise les
changements de synchronisation de manière incrémentale entre les BIGIP appartenant à un
groupe de synchronisation GTM. En synchronisant uniquement les données qui ont été
modifiées, les performances sont améliorées. La synchronisation incrémentale est le
mécanisme par défaut. Cependant, dans le cas où une synchronisation incrémentale
échoue, le système met en œuvre, automatiquement, une synchronisation complète.
▪ Sauvegarde manuelle des changements de configuration : par défaut, les changements de
configuration du GTM, qu’ils soient faits en tmsh ou via la gui, sont sauvés toutes les 15
secondes. Depuis la version 11.3, il est possible de configurer cet intervalle de temps. En
addition, il est maintenant aussi possible de désactiver la sauvegarde automatique, et de
lancer une commande tmsh pour sauver les changements.
▪ Rate-Limited Licences et Statistiques : avec cette release, des licences rate-limited sont
disponibles pour BIG-IP GTM et DNS. Si une telle licence est utilisée, alors le système donne
des statistiques sur le rate limit.
▪ DNSKey records available in the Configuration utility : L’enregistrement DS publique pour
une zone DNS peut être copiée à partir de la GUI afin de faciliter l’envoie de
l’enregistrement à la parent authority.
▪ Log de la décision de répartition de charge : quand une requête arrive au GTM pour une
résolution de nom DNS, dans le but d’envoyer une réponse, le système prend une décision
de load-balancing. Il est désormais possible de logguer, via le mécanisme de High-Speed
Logging, les raisons pour lesquelles le GTM a pris telle décision de load-balancing.
4.6. Version 11.5.0

▪ Menu Global Traffic renommé en menu GSLB et placé sous le menu DNS.
▪ DNS Express Zone renommé en DNS Zone avec la possibilité d’avoir une configuration plus
fine. Par exemple, créer une zone DNS et la configurer pour utiliser DNS Express en
sélectionnant un serveur DNS autoritaire à partir duquel les transferts de zones vont se
faire. Il est aussi possible d’indiquer les serveurs DNS qui sont autorisés en tant que clients
pour des transferts de zone.
▪ DNS Cache et DNS64 : Il est désormais possible de créer une profile DNS où le champs DNS
Cache est activé, où un resolver cache est associé, et le champs DNS IPv6 to IPv4 est
positionné à Secondary ou Immediate. Avec cette configuration, si une requête AAAA ne

renvoie aucune réponse, alors le système fait une requête pour un enregistrement A et
réécrit la réponse en une réponse AAAA avant d’envoyer la réponse au client.
▪ DNS Cache and Local Zones : une zone locale peut être ajoutée à un resolver transparent ou
un cache resolver. Cela est utile quand on souhaite que le BIG-IP resolve les requêtes, pour
une petite zone locale, avec des réponses autoritaires.
▪ DNS Cache and Forward Zones : Il est possible d’attacher une Forward Zone à un resolver ou
resolver cache. Ainsi, le BIG-IP envoie les requêtes DNS qui correspondent aux Forward
Zones vers des nameservers spécifiques qui peuvent résoudre la requête.
▪ GPRS Tunneling Protocol (GTP) Monitor : ce monitor utilise le protocole UDP et supporte le
protocole GTP dans les versions 1 et 2. Il envoie un GTP Echo Request et attend un GTP Echo
Reply.
▪ DNS Express and NAPTR Queries : le moteur DNS Express peut répondre avec des
enregistrements A, AAAA et SRV dans la section additionnelle d’une réponse DNS à une
requête NAPTR.
▪ Nouvelle commande iRule DNS::scrape : Utilisable dans les évènements DNS_REQUEST et

DNS_RESPONSE pour un virtual server avec un profile DNS. Cf
https://devcentral.f5.com/wiki/iRules.DNS__scrape.ashx.
▪ DNS Express et Zone Transfers : Les zones qui sont transferrées dans DNS Express peuvent
notifer des serveurs DNS secondaires en utilisant un AXFR NOTIFY. DNS Express supporte
aussi les clés TSIG pour les zones.
4.7. Version 11.6.0

▪ DNS Rapid-Response : possibilité d’améliorer les performances pour que le BIG-IP réponde
plus rapidement aux requêtes DNS pour les zones dont il est autoritaire.
▪ Response Polizy Zones (RPZ) : RPZ est un mécanisme de firewall utilisé par les résolvers DNS
qui permet de filtrer la résolution des noms de domaines. Une RPZ est récupérable via une
souscription à un fournisseur externe, ou via ZonneRunner en créant une RPZ custom. Avec
une RPZ, le BIG-IP peut filtrer les requêtes DNS pour des domaines connues comme étant
malicieux, et retourner une réponse customisée afin d’empêcher les connexions vers le
domaine malicieux.

4.8. Version 12.0.0
▪ Changement de nom du module GTM en DNS : F5 a décidé cette modification afin d’aligner
le nom du produit avec ces capacités fonctionnelles. BIG-IP DNS permet de renforce le
message de F5 qui est de résoudre toutes les problématiques de disponibilité et de sécurité
aux applications qui se basent sur une connectivité DNS. F5 sécurise le service DNS et assure
une disponibilité globale des applications déployées dans plusieurs data centers et des
environnements de clouds hybrides.
▪ DNS DDoS Hardware : Le cache DNS et la validation protocolaire se font au niveau matériel.
Ainsi, les réponses venant du cache DNS sont plus rapides. De même, la validation
protocolaire bloque plus rapidement les requêtes malformées et libère la CPU pour d’autres
fonctions et process. Ces capacités matérielles sont disponibles uniquement dans les blades
B2250 sur les Viprion 2x00, et ne sont pas supportées avec vCMP.
▪ "Return Code on Failure" pour les échecs de Load Balancing GSLB : il est possible de spécifier
un code (RCODE) à retourner dans une réponse au client quand la décision de load balancing
GSLB échoue.
▪ Support d’enregistrements additionnels : le GSLB supporte des nouveaux types
d’enregistrement pour les WIPs : MX, SRV et NAPTR. En ajoutant ces nouveaux types
d’enregistrement, BIG-IP DNS peut load balancer des requêtes dont les réponses
contiennent autre chose qu’une adresse IP. Ainsi, le GSLB peut prendre en charge des
réponses pour des noms DNS qui sont des objets différents dans la hiérarchie DNS. Ces
nouveaux enregistrements complètent ceux déjà supportés : A, AAAA et CNAME.
4.9. Version 12.1.0

▪ Rotation RRset dans le cache DNS : possibilité de configurer la méthode que le cache DNS
utilise quand il doit décider dans quel ordre retourner les enregistrements dans les réponses
cachées.
4.10. Version 13.0.0

▪ Configuration de plusieurs probes pour les pool members : il est possible de spécifier une
préférence pour le choix des BIG-IP qui vont prendre en charge des probes : local, distant,
ou un pool. Il y a aussi une nouvelle option de fallback qui contrôle ce que le système doit
faire quand il n’y a pas assez de probers disponibles du type choisis.
▪ Permettre d’avantage d’enregistrements retournés dans une réponse GSLB : La limite du
nombre maximum d’enregistrements retournés (Maximum Answers Returned) dans une
réponse GSLB passe de 16 à 500.

4.11. Version 13.1.0
▪ Aucune nouvelle fonction DNS.

Langue

Boiler BIGIP DNS V13.1 VF

Transféré par

Informations du document

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Boiler BIGIP DNS V13.1 VF

Transféré par

Droits d'auteur :

En réunissant une structure de

commutation haute performance, un

2 Solution BIGIP DNS V13.1 | F5 NETWORKS

1.1. Principaux avantages

1.1.1. Disponibilité des applications sur de nombreux datacenters

1.1.2. Contrôle de l’ensemble du trafic applicatif

1.1.3. Amélioration des performances applicatives

1.1.4. Simplicité et efficacité de la gestion du réseau distribué

1.1.5. Sécurisation du service DNS

3 Solution BIGIP DNS V13.1 | F5 NETWORKS

• Répartition de charge limitée : principalement du Round Robin permettant de servir

• Pas de notion de proximité de l’utilisateur : les entreprises internationales investissent

2.2. Architecture de GSLB

2.2.1. Positionnement dans le réseau DNS

• Un utilisateur ouvre son navigateur et entre l’adresse du site www.domain.com

• Le navigateur déclenche une requête de résolution de nom à destination du serveur DNS

4 Solution BIGIP DNS V13.1 | F5 NETWORKS

• Le LDNS envoie finalement sa requête au serveur autoritaire pour la zone domain.com. Ce

• Le LDNS répond au poste de travail avec l’IP du site www.domain.com.

• Le client se connecte au serveur www.domain.com.

Figure 1 : résolution de nom traditionnelle

5 Solution BIGIP DNS V13.1 | F5 NETWORKS

6 Solution BIGIP DNS V13.1 | F5 NETWORKS

2.2.2. Mode transparent

7 Solution BIGIP DNS V13.1 | F5 NETWORKS

Figure 3 : Mode Transparent Physique

8 Solution BIGIP DNS V13.1 | F5 NETWORKS

2.2.3. Mode « délégation de zone »

9 Solution BIGIP DNS V13.1 | F5 NETWORKS

Le nouveau schéma de flux est présenté dans le graphique ci-dessous :

• Ce dernier répond avec l’entrée CNAME www.gslb.domain.com ainsi qu’avec les

• Le serveur LDNS interroge le boitier BIG-IP DNS pour l’entrée www.gslb.domain.com

• Ce dernier applique son algorithme de répartition de charge et renvoie l’adresse IP de la

10 Solution BIGIP DNS V13.1 | F5 NETWORKS

2.3. Les Eléments de l’infrastructure BIG-IP DNS

2.3.1. Objets Physiques

• Synchroniser leur configuration

• Echanger les informations de disponibilité applicative

11 Solution BIGIP DNS V13.1 | F5 NETWORKS

Ces échanges se font à travers un protocole propriétaire et sécurisé : iQuery.

12 Solution BIGIP DNS V13.1 | F5 NETWORKS

2.3.2. Objets Logiques

13 Solution BIGIP DNS V13.1 | F5 NETWORKS

2.3.2.3 Wide IPs

14 Solution BIGIP DNS V13.1 | F5 NETWORKS

2.3.3. Interaction avec d’autres équipements F5

• La communication avec d’autres boitiers BIG-IP DNS : pour la synchronisation des

Les avantages d’utiliser le protocole IQuery sont les suivants :

• Il est sécurisé, et un échange de certificat permet de s’assurer de l’identité de chacun des

15 Solution BIGIP DNS V13.1 | F5 NETWORKS

2.3.4. Collecte de métriques

• http : ouvre une connexion TCP et envoie une commande http.

16 Solution BIGIP DNS V13.1 | F5 NETWORKS

• NTTP : récupère l’identification d’un newsgroup sur un serveur.

• RADIUS : test une authentification sur un serveur RADIUS

• Scripted : permet de créer un script shell avec le langage Expect.

• SIP : teste le statut d’in service SIP Call-ID

• SMTP : envoie des commandes SMTP à un serveur

• SOAP : test un service Web en SOAP

• TCP : essaie d’ouvrir une connexion TCP et la referme.

• UDP : envoie un paquet UDP sur une IP et un port

• WAP : envoie une chaine de caractère et l’attend en retour

17 Solution BIGIP DNS V13.1 | F5 NETWORKS

• TCP : paquet TCP syn envoyé sur le port 53 du serveur LDNS

• UDP : paquet UDp envoyé sur le port echo du serveur.

• ICMP : ping envoyé au serveur LDNS.