TABLE DES MATIÈRES 1. 1 Introduction Présentation de la problématique Présentation des services anycastés... 4

Transcription

1 DNS anycasté

2 TABLE DES MATIÈRES 1 Table des matières 1 Introduction Présentation de la problématique Présentation des services anycastés État de l art Historique DNS Anycast Etat du marché et qui le met en service Exemple d utilisations(isc, AFNIC) ISC BIND AFNIC Cahier des charges Présentation du projet Objet du projet Objectifs Délai Composition de l équipe Environnement Réalisations Suivi de projet Tâches réalisées Installation physique Service DNS Bird Planning prévisionnel 13 6 Présentation DNS Anycast Les logs Le service DNS avec Bind 14 8 Les log avec Rsyslog 14 9 La gestion du cluster 15

3 TABLE DES MATIÈRES 2 10 Annexe Bird Kanboard

4 1 INTRODUCTION 3 1 Introduction 1.1 Présentation de la problématique Le sujet de notre projet tuteuré est la mise en place un service DNS récursif anycasté au moyen d un cluster de serveurs. Cette solution repose sur la mise en place d un service de DNS, de la technique d adressage et de routage Anycast, d un système de croisement des logs, d un système de gestion de la configuration des différents serveurs et d un outil de contrôle des serveurs DNS du cluster. L objectif de ce genre d infrastructure est de délivrer un service DNS haute disponibilité tout en ayant un temps de réponse optimal grâce à la techique Anycast. Les principales raisons d utiliser une telle infrastructure sont d une part la fourniture d un service décentralisé et d autre part sa fiabilité. En effet la décentralisation répond au besoin de la haute disponibilité : au cas où un noeud du cluster ne serait plus accessible, un autre noeud prend le relais. L information est alors toujours disponible et accessible. Cette fiabilité est d autant plus forte que lorsqu une route menant à un serveur est défaillante pour quelque raison que ce soit, l annonce de celle-ci est coupée par les routeurs en attendant que le problème soit résolu : les utilisateurs ne s en retrouvent pas du tout affecté. Dans un monde où tout doit aller plus vite, où l indisponibilité des services coûtent chaque seconde plus d argent à l entreprise, il faut se prémunir au maximum, le DNS récursif couplé à l Anycast est un bon moyen d un parvenir. Ce type d infrastructure est aujourd hui utilisé aussi bien par les entreprises que par les structures publique, par exemple Google, OVH et même le réseau Lothaire se sont mis à le déployer. En plus ces avantages pré-cités, cette solution a aussi un intérêt marketing certain. Pour le cas d OVH, la rapidité du temps de réponse est un argument marketing, Google, quant à lui propose depuis le 9 décembre 2009 Google Public DNS qui consiste à offrir des serveurs DNS récursifs aux internautes, ces mêmes serveurs étant utilisés avec le service Anycast. La confiance générée est un atout quand à une expension des infrastructures utilisant cette technologie, on pourrait voir dans le future des améliorations qui se porteraient sur la sécurité et la fiabilité de celle-ci. Le réseau lothaire de l université de Lorraine est lui en phase de déployer cette solution pour fournir un service résilient et répartir la charge des serveurs DNS récursifs de l université.

5 1 INTRODUCTION Présentation des services anycastés L Internet tel qu on le connaît a grandi, et comme les systèmes et les services réseaux dans les entreprises sont devenus plus importants, beaucoup de services haute disponibilité sont apparus. Cette exigence a augmenté les demandes sur la fiabilité des infrastructures sur laquelle ces services comptent. Des techniques diverses ont été employées pour augmenter la disponibilité de services déployés sur internet, ici nous parlerons de l Anycast. Qu est-ce que l Anycast et pourquoi lui plutôt qu un autre? Selon la RFC , l Anycast est le nom donné à la pratique de faire un service d adressage disponible pour un système de routage à des nœuds Anycast de deux ou plusieurs discret location. Le service fournit par chaque nœud est généralement cohérent indépendamment du nœud choisi par le système de routage de manière à manipuler une requête particulière. Ce terme se veut proche phonétiquement des termes unicast, broadcast et multicast. En unicast, il n existe qu une association entre une adresse réseau et le point d arrivée final : chaque adresse de destination identifie de manière unique un seul receveur final. FIGURE 1 Unicast En broadcast et multicast, il y a une association "de une à plusieurs" entre les adresses réseau et les points d arrivées finaux : chaque adresse de destination identifie un ensemble de récepteurs finaux, sur lesquels toute l information est répliquée. 1.

6 1 INTRODUCTION 5 FIGURE 2 Broadcast FIGURE 3 Multicast En Anycast, il y a aussi une association "de une à plusieurs" entre les adresses réseau et les points d arrivées finaux : chaque adresse de destination identifie un ensemble de récepteurs finaux, mais un seul d entre eux est choisi pour recevoir l information à un moment donné pour un émetteur donné. FIGURE 4 Unicast Sur Internet, Anycast est habituellement implémenté en utilisant BGP qui annonce simultanément la même tranche d adresses IP depuis plusieurs endroits du réseau. De cette façon, les paquets sont routés vers le point "le plus proche" du réseau annonçant la route de destination. On fait la transition entre les deux types de connections BGP -> soit UDP soit TCP.

7 2 ÉTAT DE L ART 6 2 État de l art 2.1 Historique DNS Avant le DNS, la résolution d un nom sur Internet devait se faire grâce à un fichier texte appelé HOSTS.TXT (RFC ) maintenu par le NIC du Stanford Research Institute (SRI) 3 et recopié sur chaque ordinateur par transfert de fichier. En 1982, ce système centralisé montre ses limites et plusieurs propositions de remplacement voient le jour, parmi lesquelles le système distribué Grapevine de Xerox et IEN Le premier est jugé trop compliqué tandis que le second est insuffisant. La tâche de développer un autre système revient à Paul Mockapetris qui publie le design du système dans les RFC et en La norme correspondante est publiée dans les RFC et en En 1987, le fichier HOSTS.TXT contenait entrées, tandis que hôtes étaient définis dans le DNS. FIGURE 5 Hiérarchie du DNS

8 2 ÉTAT DE L ART Anycast La première spécification était la RFC 1546 en À l époque, c était purement théorique mais la RFC 1546 liste bien toutes les questions. La première utilisation documentée était l année suivante, pour de la distribution de vidéo, et est notée dans l IMR Il s agissait de trouver le serveur de vidéos «le plus proche». La rumeur de l Internet dit que des FAI ont utilisé l anycast pour leurs résolveurs DNS à partir de cette époque mais il n y a pas de traces écrites. En 1997, l IAB 10 (Internet Architecture Board) s en mêle pour la première fois, avec quelques phrases dans la RFC L anycast a également été mentionné lors de l atelier sur le routage organisé par l IAB l année suivante et documenté dans la RFC Cette technique est encore présentée comme «à étudier» («We need to describe the advantages and disadvantages of anycast»). En 1999, à la 46ème réunion de l IETF, une BoF 13 sur l anycast a eu lieu. Les deux principales conclusions étaient que l usage de l anycast pour TCP n était pas forcément une bonne idée, mais que par contre l application qui serait la plus susceptible d utiliser l anycast avec profit était le DNS. La RFC d Avril 2002 décrit l utilisation de Anycast pour le service DNS comme mit en oeuvre pour les serveur root C, F, I, J, K et M FIGURE 6 Anycast Birds of a feather, réunion informelle sans agenda tenue généralement lors de conférences. Voir %28computing%

9 3 CAHIER DES CHARGES Etat du marché et qui le met en service. 2.3 Exemple d utilisations(isc, AFNIC) ISC BIND Depuis 1994 l ISC (Internet Systems Consortium) 15 a en charge la gestion du serveur root F, qui répond au requêtes IPv4 sur et en IPv6 sur 2001 :500 :2f : :f, utilise une technique anycast hiérarchisée 16 et le logiciel BIND AFNIC Depuis 2008 l AFNIC 18 a mis en place un nouvel ensemble de serveurs basé sur la technologie anycast afin d accroître la robustesse et la qualité du DNS des zones administrées, dont notamment celle du.fr. Dans le même temps elle améliore, au fur et à mesure de l extension de la couverture géographique, la qualité du service DNS non seulement en termes de temps de réponse mais aussi de robustesse puisqu elle offre une meilleure résistance aux attaques par saturation (DoS). Pour conduire cette évolution, l AFNIC a engagé une coopération avec Autonomica. Cette entreprise suédoise, qui est en charge de l un des serveurs de noms de la racine de l internet, appartient à Netnod, gestionnaire du "point d échange internet indépendant suédois". 3 Cahier des charges 3.1 Présentation du projet Objet du projet Ce projet consiste en la mise en place d un service de DNS récursif anycasté. La mise en place d un mécanisme émulé de GEODNS Objectifs L objectif principal est de fournir un service de DNS anycasté mais aussi de mettre en place une infrastructure respectant le cahier des charges suivant : distribution des logs des serveurs DNS vers tous les autres serveurs DNS du service 15. https :// 16. http ://ftp.isc.org/isc/pubs/tn/isc-tn txt

10 3 CAHIER DES CHARGES 9 scripts d interrogation de l état du serveur (DNS, état de l annonce anycast...) et de manipulation des services (status, reload, start, stop) mise en place d une gestion centralisée de la configuration (type Puppet, Salt...) afin d automatiser au maximum l extension du parc de serveurs DNS anycastés Délai Rapport Intermédiaire 12 Février 2016 Pré-Rapport Final 24 Mars 2016 Rapport Final 28 Mars Composition de l équipe Nom : Pierre ARNOUD Status : Etudiant Nom : Loic LABRADOR Status : Etudiant Nom : Nicolas TRUBERT DU Status : Etudiant Nom : Luc DIDRY Status : Tuteur 3.2 Environnement L infrastructure DNS sera gérée avec BIND9, la distribution des logs sera faite a l aide d un service syslog sur chaque machine qui accueillera un service BIND9. La configuration d une nouvelle machine sera gérée par Puppet 19 et les scripts de gestion seront s appuyeront sur des outils existant comme rndc. 19. https ://puppetlabs.com/

11 4 TÂCHES RÉALISÉES Réalisations Le groupe doit réaliser les taches suivantes : - Mise en place de plusieurs serveurs DNS - Réponse des services DNS sur l IP d anycast - Échanges croisés des logs sur toutes les machines DNS - Gestion de la configuration des serveurs - Création d un outil de contrôle des serveurs DNS (status, start, stop et reload) - Émulation d un mécanisme de GEODNS 3.4 Suivi de projet Le groupe devra fournir chaque semaine au tuteur de projet (M. Luc DIDRY), un rapport collectif comprenant : les tâches réalisées, ainsi que les succès/échecs les prévisions pour la semaine suivante les questions et les points bloquants Un compte rendu rapide est également effectué a chaque séance sur l outil mis a disposition sur Arche par M. Lucas NUSSBAUM. Un kanboard a été créé pour le suivi interne du projet et il a été mis à la disposition du tuteur. Kanboard est un gestionnaire de tâches visuel qui permet de gérer facilement des petits projets de manière collaborative. Concrètement, les tâches sont affichées dans un tableau à plusieurs colonnes. Chaque colonne correspond à une étape d un projet. Par la suite on peut déplacer avec la souris une tâche d une colonne à une autre. On a donc une représentation visuelle et claire de l état du projet. On sait ce qui est en cours ou terminé, mais également qui fait quoi. C est simple et compréhensible par tout le monde. 4 Tâches réalisées 4.1 Installation physique Installation de 3 serveurs physique tournant sous Debian Jessie 8.3 conjointement par Loïc et Pierre.

12 4 TÂCHES RÉALISÉES Service DNS Installation du serveur DNS Bind en version sur chacun des serveurs physique. sudo aptitude install bind9 La configuration a été faite rapidement car nous avions déjà étudié le serveur DNS Bind9 avec Stéphane CASSET. Création d une zone DNS et de son reverse pour chaque serveur dns-servx, où X correspond à un numéro. Pour exemple : dns-serv zone " dns s e r v 1. l o c a l " { 2 t y p e m a s t e r ; 3 f i l e " / e t c / bind / db. dns s e r v 1 " ; 4 allow t r a n s f e r { ; ; } ; 5 f o r w a r d e r s { ; } ; 6 } ; 7 La déclaration du serveur esclave 1 zone " dns s e r v 2. l o c a l " { 2 t y p e s l a v e ; 3 f i l e " / v a r / l i b / bind / db. dns s e r v 2 " ; 4 m a s t e r s { ; fe80 : : f24d : a 2 f f : fe24 : dc6b ; } ; 5 f o r w a r d e r s { } ; 6 allow n o t i f y { fe80 : : f24d : a 2 f f : fe24 : dc6b ; } ; 7 } ; 8 Chaque serveur est l esclave d un autre et la passerelle de la salle ASRALL est le forwarder de tous. 4.3 Bird Pour commencer Bird est un projet qui vise à développer un démon IP entièrement fonctionnel de routage dynamique principalement ciblé sur (mais sans s y limiter) Linux, FressBSD et d autres systèmes de type Unix et distribué sous la GNU General Public License.

13 4 TÂCHES RÉALISÉES 12 Nous avons tout d abord regardé la documentation officielle de Bird se trouvant à l adresse qui nous a indiqué qu il été possible de télécharger Bird directement depuis les dépôts avec la commande sudo apt-get install bird. De là nous l avons installé sur deux machines sous debian ne possédant pas de DNS, ces deux machines représentent les routeurs de notre infrastructure. Pour tester que la pleine utilisation de Bird est possible il faut lancer la commande birdc show status, seulement la commande renvoyait un rapport d erreur indiquant que cette commande était inutilisable du fait qu il ne trouvait pas les fichiers adéquats nécessaire à son bon fonctionnement. De là nous avons du créer des liens symbolique dans le dossier que Bird recherchait pour les faire pointer vers un autre dossier contenant les dit-fichier. Une fois que birdc fonctionnait correctement et que le service Bird tournait bien sur les machines nous avons pu nous pencher sur la manière dont Bird traitait l utilisation de BGP. Le fichier /etc/bird/bird.conf contient une liste de tous les protocoles que Bird sait gérer, et plus particulièrement BGP. Après beaucoup de recherches et de tests pour comprendre les notions d Autonomous System et les neighbors nous avons configuré bird de manière à ce qu il établisse une connexion TCP sur le voisin direct que nous lui avons précisé, voisin qui une fois configuré de la même manière a permis la connexion. Ce qui est intéressant c est de constater que les deux machines ont synchronisé leurs tables de routage respectives, chose importante pour palier à la potentielle chute de l un d entre eux. Etablir une connexion entre les deux machines et faire en sorte qu elles communiquent entre elles était le premier objectif, le prochain sera d écrire dans la table de routage du système directement au lieu d éditer celles de Bird. Nicolas est passé par une phase d étude qui continue encore à ce jour et a installé sur toutes les machines de notre infrastructure Bird, il a configuré ce service de manière à synchroniser les tables de routage pour avoir plusieurs noeuds pour l anycast. Cela dans le but de pouvoir gérer l incapacité d un noeuds à pouvoir remplir sa fonction. Les annexes montrererons la configuration et le résultat obtenu. Aujourd hui nous sommes en train de regarder s il est possible d écrire directement dans la table de routage de l ordinateur les routes que Bird gère. Cela va permettre de n avoir à gérer qu une seule et même table de routage et donc de gagner en précision et de limiter les erreurs.

14 5 PLANNING PRÉVISIONNEL 13 5 Planning prévisionnel Pour ce qui est de notre planning prévisionnel nous avons géré le DNS ainsi que la mise en place de Bird, c est à dire communication et partage de route. Nous n avons cependant pas pu tenir les délais quand la distribution des logs et la partie scipting qui était elle optionnelle pour notre V1. En annexe se trouve notre diagramme de Gantt pour la V1. 6 Présentation 6.1 DNS DNS, Domain Name System ou, en français, Système de noms de domaines, est un service permettant de traduire un nom de domaine en information de plusieurs types qui y sont associés, notamment en adresses IP de la machine portant ce nom. Il existe treize serveurs racine dans le monde sous l autorité de l ICANN, qui répondent aux requêtes concernant les noms de domaines de premier niveau. Les principaux enregistrements DNS sont les suivants : - A record, fait correspondre un nom d hôte à une IPv4 - AAAA record, pareille mais pour les adresses IPv6 - MX record, définit le(s) serveur(s) de courriel pour ce domaine - NS record, définit le(s) serveur(s) DNS de ce domaine. La résolution inverse ou reverse DNS, permet de trouver le nom de domaine associé à une adresse IP. Exemple pour "git.framasoft.org"le principe est le suivant : la résolution parcourt le nom de domaine de droite à gauche..org : C est le TLD (Top Level Domain) C est la partie sur laquelle un des server root est interrogé. Ce dernier va repondre avec l adresse d un autre serveur DNS responsable de la zone.org framasoft : C est le Second Level Domain. Avec le TLD il forme le nom de domaine. c est le DNS responsable de la zone.org qui repondra avec l adresse du DNS responsable de framasoft.org git. : C est un sous-domaine de framasoft.org 6.2 Anycast Anycast est une technique d adressage et de routage permettant de rediriger les données vers le serveur informatique le "plus proche" ou le "plus efficace" selon

15 7 LES LOG AVEC RSYSLOG 14 la politique de routage. Sur Internet, anycast est habituellement implémenté en utilisant BGP qui annonce simultanément la même tranche d adresses IP depuis plusieurs endroits du réseau. De cette façon, les paquets sont routés vers le point le "plus proche" du réseau annonçant la route de destination. Pour les protocoles en mode connecté qui nécessitent que la conversation entière utilise le même serveur, des systèmes comme GeoDNS sont plus appropriés. Pour cette raison, anycast est habituellement utilisé pour fournir de la haute disponibilité et de la répartition de charge pour des services en mode non connecté. 6.3 Les logs En informatique, on parle de log (diminutif de logging) pour désigner un fichier, ou tout autre dispositif, permettant de stocker un historique des évènements attachés à un processus. Ces évènements sont horodatés et ordonnés en fonction du temps. En clair, le log est un peu le "journal de bord" d un système. On parle parfois en français de fichier journal pour désigner les logs. Il sera consulté en cas de besoin, par exemple pour essayer d identifier l origine d une panne ou l auteur d une intrusion (réussie ou manquée) ou analysé pour fournir des statistiques d utilisationd d un service. Les informations stockées dans ces logs sont typiquement : - l adresse IP depuis laquelle est effectuée la requête - l utilisateur si celui-ci est authentifié - la date et l heure de la requête - la requête elle-même - la réponse a la requête - les erreurs possibles Les logs sont souvent séparés en deux : les logs d accès et les logs d erreurs, ce qui permet aux administrateurs et/ou aux développeurs de voir les erreurs sur un système, ce qui facilite le débogage par exemple. 7 Les log avec Rsyslog Nous allons utiliser "Rsyslog" pour la distribution des logs entre les serveurs DNS, car c est un logiciel open source qui permet le transfert de log sur un réseau IP. Il peut être utilisé en TCP ou en UDP. Les fonctionnalités disponibles sont : Ecriture des événements dans une base de données Rotation automatique des fichiers

16 8 LA GESTION DU CLUSTER 15 Forwarder les fichiers Gestion complète de la date ( jusqu au millième de seconde ) Il est disponible sur les distributions suivantes : Fedora, OpenSUSE, Debian GNU/Linux, Ubuntu, Red Hat, solaris... 8 La gestion du cluster 9 Annexe 9.1 Bird FIGURE 7 Bird 9.2 Kanboard

17 9 ANNEXE 16 FIGURE 8 Diagramme de Gant Kanboard FIGURE 9