DNS - ordinatous.com

Transcription

Ludovic MARCHAL
Formation:TSGERI
Session:2015/2016
Technicien Supérieur Gestionnaire
Exploitant de Ressources Informatiques
et Réseaux
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative
Commons Attribution - Pas d’Utilisation Commerciale 4.0 International.
[email protected]
Table des matières
Principe......................................................................................................................................................1
Gouvernance..............................................................................................................................................3
IANA...............................................................................................................................................4
Evolution..........................................................................................................................................4
Litige................................................................................................................................................5
Fonctionnement...............................................................................................................................6
Liste des RIR.............................................................................................................................................7
Réalité..............................................................................................................................................8
Position de l'ICANN.............................................................................................................................8
Registry Information........................................................................................................................8
Basic Information............................................................................................................................9
What We Do.....................................................................................................................................9
Figure historique.................................................................................................................................10
Biographie................................................................................................................................10
Principe de robustesse........................................................................................................................10
Hommages.....................................................................................................................................10
Hierarchie................................................................................................................................................11
Root DNS............................................................................................................................................11
Protocole BGP.........................................................................................................................................13
Fonctionnement..................................................................................................................................13
Liste ROOT DNS....................................................................................................................................15
Sécurité des serveurs racine................................................................................................................16
............................................................................................................................................................16
Les sous-domaines..............................................................................................................................17
Aspect Technique....................................................................................................................................18
Fonctionnalités....................................................................................................................................18
cache.............................................................................................................................................18
Recursif :.......................................................................................................................................19
Primary master..............................................................................................................................20
Secondary master..........................................................................................................................20
BIND............................................................................................................................................................21
Fonctionnement de bind..........................................................................................................................21
Fichier de configuration......................................................................................................................21
Nota Bene...........................................................................................................................................21
General................................................................................................................................................21
named.conf.........................................................................................................................................22
named.conf.options.............................................................................................................................22
Named.conf.default-zones..................................................................................................................22
named.conf.local.................................................................................................................................23
Fichiers de logs...................................................................................................................................24
/etc/bind/named.conf.logging........................................................................................................24
Creer les fichiers de log.................................................................................................................24
Je vérifie leur présence :................................................................................................................24
Puis je change le propriétaire et le groupe :...................................................................................24
Editer ce fichier..............................................................................................................................24
Fichier de zones..................................................................................................................................25
Changer le propriétaire de rndc.key...................................................................................................25
IMPORTANT..........................................................................................................................................26
Redemarrage du service......................................................................................................................26
Vérifier les zones de noms..................................................................................................................26
Test du service BIND.........................................................................................................................26
Script...................................................................................................................................................27
Bonus:Unbound.......................................................................................................................................28
Serveur Récursif en local....................................................................................................................28
Préambule......................................................................................................................................28
About Unbound..................................................................................................................................28
Download............................................................................................................................................28
Récupération de Unbound..................................................................................................................28
Ajouter le groupe unbound........................................................................................................29
Ajouter l'utilisateur unbound au group unbound.......................................................................29
Check configuration...........................................................................................................................32
Test/Resultat...................................................................................................................................32
DNS bouygues..........................................................................................................................32
Bonus..................................................................................................................................................33
References..........................................................................................................................................34
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Domain Name Server
Principe
Le réseau étant basé sur le protocole TCP/IP, chaque machine est
identifiée par une adresse IP.
Si nous pouvons naviguer sur le oueb et accéder à nos webmail, sites
favoris etc ; de manière intuitive. en écrivant un nom pour voir un site,
par exemple debian.org ( http://www.debian.org), et non une adresse IP :
;; ANSWER SECTION:
debian.org.
debian.org.
debian.org.
debian.org.
debian.org.
3600
3600
3600
3600
3600
IN
IN
IN
IN
IN
A
A
A
A
A
130.89.148.14
140.211.15.34
149.20.20.22
5.153.231.4
128.31.0.62
C'est grâce au « mécanisme » du DNS : Domain Name Server, serveur de
nom de domaine.
Si la page est disponible elle devrait s’afficher.
Derrière cette requête se déroule toute un processus vieux d’une
trentaine d'années, car à l'époque il fallait maintenir à jour un fichier
« hosts » au sein de son propre ordinateur, bien qu'on puissions le
récupérer auprès d’institution fiable, il était également possible de le
modifier et de se le repartager.
La tâche de développer un autre système revient à Paul Mockapetris qui
publie le design du système dans les RFC 882 et RFC 883 en 1983.
La norme correspondante est publiée dans les RFC 1034 et RFC 1035 en
1987.
En 1987, le fichier HOSTS.TXT contenait 5 500 entrées, tandis que 20 000
hôtes étaient définis dans le DNS.
Il est fait mention du fichier hosts dans la section 2.1 de la RFC 1034
Le domaine name server DNS gère la correspondance entre les noms
d’hôte et les adresses IP.
Voilà pour la notion de « Résolution de noms de domaine » ce qui s'avère
pratique.
[email protected]
1/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Un nom de domaine à cette forme :
•
debian.org
•
ordinatous.com
•
poleemploi.fr
Ces noms correspondent à des enregistrements auprés des registrars,
mais penchons-nous sur la fin du nom de domaine ce que l'on nomme le
Top Level Domain.
Les TLD (Top Level Domain) font l'objet d'un « découpage », certains sont
réservés vous ne pourrait pas les obtenir .
On les classe de manière hiérarchique en les différenciant par leur type
de suffixe :
.com ou .biz pour les entreprises (mais pas forcément, byz attire l'oeil)
.net pour les structures liées au réseau
.org ou .asso.fr pour les structures associatives
.edu pour les structures éducatives
.gov pour les structures gouvernementales
.int pour les structures internationales
.mobi pour les sites consultables depuis un mobile
.mil pour l'armée Américaine
On trouve aussi des suffixes par territoire.
Par exemple :
.fr ou .tm.fr pour la France, .re pour la Réunion, .yt pour Mayotte, .mq
pour la Martinique, .gp pour la guadeloupe, .gf pour la Guyane, .tf pour
les terres australes, .nc pour la Nouvelle Calédonie, .pf pour la Polynésie,
.wf pour Wallis et Futuna, .pm pour Saint Pierre et Miquelon (voir afnic.fr).
.be pour la Belgique (voir dnsbelgium.be).
.eu pour l’Europe (voir eurid.eu).
.paris pour la ville de Paris (voir bienvenue.paris).
Ce que l'on nomme les CountryCode, vous le devinez se sont des codes
pays.
[email protected]
2/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Gouvernance
Schéma synthétique des différents acteurs de la gouvernance de
l'INTERNET.
Disponible en ligne, en beaucoup plus grand, prévoir de dézoomer.
En pratique l’ensemble des textes et des normes qui sont discutées
entre ces instances, restent quasi inexploitable pour l’ensemble des
utilisateurs, sans un minimum de compétences et connaissances
techniques.
[email protected]
3/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
IANA
Evolution
Illustration 1: Sources:Wikipédia
Le 20 juin 2011, le conseil d’administration de l’ICANN votait, pendant la
conférence de Singapour, le lancement des nouvelles extensions
génériques de noms de domaine (new gTLD’s).
Cette ouverture du système de nommage de l’Internet est une véritable
révolution, elle donne la possibilité aux villes, régions et marques de
créer leurs extensions de premier niveau.
Nombreux sont ceux qui ont répondu à l’appel et qui ont fait connaître
leur intérêt auprès de l'autorité suprême de régulation des noms de
domaine.
Le succès a été tel qu’il a fallu procéder à un tirage au sort pour
décider de l’ordre de traitement des 2000 des dossiers de candidature.
A ce jour, l’ICANN a délivré le droit de création de près de 600 nouvelles
extensions : dans un souci de lisibilité,elles sont classées ici en
différentes catégories, telles que :
TECHNOLOGIE (.app, .web),
BUSINESS (.store, .market),
VILLE /REGION (.paris, .bzh),
LOISIR (.art, .photo),
ALIMENTATION (.bio, .restaurant) etc…
Après quatre ans de préparation les noms de domaine créés à partir
des nouvelles extensions apparaissent
dès la fin 2013 à l’issue d’un calendrier dont les grands jalons sont :
Juillet - août 2013 : signature des premiers contrats et premiers
tests de pré-délégation
Août - septembre 2013 : premières insertions de nouveaux TLD
dans la "racine" du DNS
Septembre - octobre 2013 : début des premières "sunrise periods"
Octobre - novembre 2013 : premières "ouvertures" globales
[email protected]
4/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Litige
Le gouvernement Français à envoyé des signes de mécontentement ,
celui-ci souhaiterait d'une part que que le .fr passe du status de
CountryCode à TopLeveldomain.
Ce n'est pas aussi simple , aussi Axelle Lemaire plaide pour une
« ouverture » de » la gouvernance.
« Les Etats-Unis reprennent d’une main ce qu’ils donnent de l’autre
»
Peu connue du grand public, cette organisation a fait parler d’elle
en 2014 lorsque la secrétaire d’Etat française chargée du
numérique, Axelle Lemaire, avait menacé à grands cris de la quitter
après que celle-ci avait mis en vente les extensions «.vin » et
«.wine ». A l’époque, déjà, la question de l’indépendance de
l’Icann agitait les gouvernements. Car l’organisation, implantée à
Los Angeles et qui relève du droit californien, est sous la
supervision du département du commerce américain. « Cela signifie
concrètement que pour les paramétrages du “.fr”, il faut l’accord
du gouvernement américain », souligne-t-on au Quai d’Orsay.
Source : Le Monde 24 Mars 2015
Axelle Lemaire, la secrétaire d'État chargée du Numérique, demande
au régulateur mondial de l'Internet de prendre en compte les
intérêts nationaux dans sa gestion des extensions Internet .VIN
et .WINE (vin en Anglais).
"La France fait de la suspension des noms de domaine .VIN et .WINE
une condition de sa participation au processus de réforme de
l'ICANN." Axelle Lemaire est venue à la réunion ICANN de Londres
pour y délivrer un message très clair.
Lundi 23 juin, devant 175 représentants gouvernements de 77 pays (dont
le ministre britannique du numérique Ed Vaisey et la vice présidente
de la Commission européenne Neelie Kroes), et un nombre record de
participants pour une réunion ICANN (plus de 3300!), Axelle Lemaire a
milité pour une meilleure prise en compte des intérêts nationaux.
"Je me suis entretenue avec le Président Hollande juste avant de venir
à Londres. Le message que je viens porter à l'ICANN, je le fais au nom
du gouvernement français."
La ministre s'était déjà montrée très déterminée sur le dossier
VIN/WINE la veille, lors d'un dîner donné par l'AFNIC, le gestionnaire
du .FR, dans les locaux londoniens du cabinet d'avocats Hogan Lovells,
chez qui Axelle Lemaire avait travaillé lorsqu'elle était juriste.
Source:Huffington post
Ce n'est pas aussi simple non plus, Axelle prend cependant position, et le
« problème » à bras le corps ,je vous laisse le soin de vous faire un avis,
car il faut saisir les tenants et les aboutissants.
L'aspect technique n'étant pas le seul ceci n'est qu'une partie de la
réponse à un problème en soulevant bien d'autres.
[email protected]
5/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
vous constaterez de la complexité de l'attribution des TLD (ou gTLD).
(Proposition de trasition)
La création de nom de domaine est géré par un organisme de
régulation nommé :
ICANN : L'Icann (Internet Corporation for Assigned Names and Numbers),
société à but non lucratif basée en Californie, est l'autorité de régulation
en charge de l'attribution des noms de domaines sur Internet.
Elle gère certaines des ressources de l'Internet, notamment les
adresses IP et les noms de domaine dits "de premier niveau",
généralement appelés TLD (Top-Level Domains).
Sous l'ICANN se trouvent d'autres acteurs plus proche des des zones de
répartitions et de gestion des noms de domaines pour nous il s'agir de l'
RIPE-NCC (Réseaux IP Européens, créé en 1992) pour l'Europe et le
Moyen-Orient .(Listing et spécification d'attibution)
Fonctionnement
Des blocs d'adresses IP sont distribués aux registres internet régionaux
(RIR) par l'IANA, une composante de l'ICANN.
À leur tour, les RIR distribuent des blocs d'adresses à des « registres
Internet locaux » (en anglais Local Internet Registries ou LIR ) qui les
distribuent aux utilisateurs finaux dans leur zone d'opération.
Les registres Internet locaux sont habituellement des opérateurs de
réseau ou des fournisseurs d'accès Internet.
Les RIR n'offrent des services qu'à leurs membres, les LIR, et non aux
utilisateurs finaux. La politique d'allocation des blocs d'adresses IP, ainsi
que l'éventuelle tarification, dépend du RIR.
Les RIR gèrent aussi la numérotation des réseaux en systèmes
autonomes (ASN) permettant le routage des adresses affectées aux
utilisateurs finaux, et les bases de données DNS et whois permettant
l'identification inverse du nom de domaine auquel est assigné chaque
adresse IP.
Les RIR ne gèrent pas le système DNS permettant la résolution des noms
de domaine en adresses IP (ou autres identifiants).
Un RIR peut aussi allouer des blocs d'adresses à un registre Internet
national unique pour un pays, qui les réalloue ensuite aux LIR du pays.
C'est le cas pour les pays de l'APNIC (notamment la Chine et le Japon) et
pour certains pays du LACNIC comme le Brésil. Dans ces cas, les
utilisateurs finaux du pays doivent demander des blocs d'adresses IP à
leur NIR.
Des allocations transfrontalières sont possibles en Europe et en Asie
pour les plus grands réseaux des utilisateurs finaux. Ces allocations
sont faites par le RIR (RIPE NCC ou APNIC).
[email protected]
6/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Il est possible d'interroger les bases de données des RIR pour savoir à
qui est allouée une adresse IP. Si le serveur interrogé ne contient pas la
réponse, il donnera l'adresse du RIR à interroger. Ces requêtes se font
grâce à la commande whois ou via les sites Web des LIR.
Liste des RIR
Il existe aujourd'hui cinq RIR. Par ordre de création, ce sont :
• RIPE-NCC (Réseaux IP Européens, créé en 1992) pour l'Europe et le
Moyen-Orient ;
• APNIC (Asia Pacific Network Information Center, créé en 1993) pour
l'Asie et le Pacifique ;
• ARIN (American Registry for Internet Numbers, créé en 1997) pour
l'Amérique du Nord (entre 1993 et 1997, ce rôle était attribué à
InterNIC) ;
• LACNIC (Latin America and Caribbean Network Information
Center, créé en 1999) pour l'Amérique latine et les îles des
Caraïbes ;
• AfriNIC (African Network Information Center, créé en 2005) pour
l'Afrique.
Un registre Internet régional (RIR, de l'anglais Regional Internet Registry)
est un organisme qui alloue les blocs d'adresses IP (adressage IPv4, IPv6)
et des numéros d'Autonomous System dans sa zone géographique.
[email protected]
7/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Réalité
Ce qu'est l'ICANN afin que vous compreniez les points de discordes :
Créée en 1998 au terme de longues négociations menées par le
vice-président américain Al Gore avec toutes les parties prenantes :
chercheurs, industrie des télécommunications, fabricants
d'équipements, fournisseurs de contenus, administrations diverses, et
le fameux professeur Jon Postel, l'ICANN est une organisation de droit
californien sans but lucratif dont le rôle premier est d'allouer
l'espace des adresses de protocole Internet, d'attribuer les
identificateurs de protocole (IP), de gérer le système de noms de
domaine de premier niveau (génériques et nationaux), et d'assurer les
fonctions de gestion du système de serveurs racines du DNS2. Ces
services étaient initialement assurés dans le cadre d'un contrat avec
le gouvernement fédéral américain par l'Internet Assigned Numbers
Authority (IANA) et d'autres organismes. L'ICANN assume à présent les
fonctions de l'IANA.
Sa compétence est mondiale et ses décisions s'imposent de fait
aux États, alors même qu'elle est de droit californien, se trouve
soumise de ce fait au procureur général de Californie et relève en
dernière instance du département du Commerce des États-Unis.
L'ICANN est dirigé par un conseil d'administration composé
actuellement de seize administrateurs sélectionnés par les différentes
agences de l'ICANN qui votent les décisions majeures de
l'organisation4. Le président de l'ICANN, Fadi Chehade, fait partie de
ces seize votants.
Cependant l'ICANN c'est aussi des actions comme cell-ci :
Le 30 octobre 2009, l'ICANN vote la fin de l'exclusivité de l'alphabet latin pour
la rédaction des noms de domaine Internet. Depuis le 16 novembre 2009, peuvent être
enregistrées des adresses web rédigées avec des caractères arabes, chinois, coréens,
japonais ou cyrilliques 3.
Ce qui est une bonne chose, notre alphabet latin n'a pas vocation à
dominer le monde.
Revenons à un aspect plus technique et éloignons-nous du contexte
géopolitique.
Car devant tant de chamaillerie, je demande à Axelle Lemaire et son
gouvernement de prendre clairement position face au traité de libre
échange tarns-atlatique : TAFTA et/ou TTIP..
Position de l'ICANN
(Texte non traduit, sans quoi cela ne refléterait plus le texte original)
Registry Information
Registry area encompasses information about both sponsored and
unsponsored generic top-level domains. The relationships between and
the registries are governed by the individual Registry or Sponsorship
Agreements, which set out the obligations of both parties.
[email protected]
8/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Basic Information
The right-most label in a domain name is referred to as its "top-level
domain" (). TLDs with two letters have been established for over 250
countries and external territories and are referred to as "country-code"
TLDs or "ccTLDs". TLDs with three or more characters are referred to
as "generic" TLDs, or "gTLDs".
The responsibility for operating each (including maintaining a registry of
the domain names within the ) is delegated to a particular organization.
These organizations are referred to as "registry operators" or
"sponsors". Currently, domain names under the following gTLDs are
available, and the corresponding registries are under contract with :
.aero, .asia, .biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net,
.org, .pro, .tel and .travel.
Generally speaking, an unsponsored Registry operates under policies
established by the global Internet community directly through the
process. .biz, .com, .info, .name, .net, .org, and .pro are unsponsored TLDs.
A sponsored is a specialized that has a sponsor representing a specific
community that is served by the . The sponsor thus carries out
delegated policy-formulation responsibilities over many matters
concerning the . .aero, .asia, .cat, .coop, .jobs, .mobi, .museum, .tel and
.travel are sponsored TLDs.
What We Do
As the business environment changes, and technology continues to
develop, staff works closely with the registries to review and adapt the
provisions of the Registry and Sponsorship Agreements
[email protected]
9/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Figure historique
John Postel :
Jonathan Bruce Postel, Jon Postel
(né le 6 août 1943 à Altadena en
Californie et mort le 16 octobre 1998 à
Santa Monica en Californie), était un
informaticien américain et l'un des
principaux contributeurs à la création
de l'Internet.
Illustration 2: Sources: wikipédia
Biographie
Jon Postel a obtenu son doctorat d'informatique en 1974. Il était l'éditeur
des Requests for Comments, série de documents visant à établir les
standards de l'Internet de l'IETF. À ce poste, il a apporté une très
importante contribution à la création du protocole de communication
TCP/IP, utilisé notamment sur l'Internet et dans la plupart des réseaux
locaux d'aujourd'hui.
Il fut le premier membre de l'Internet Society et était le responsable de
l'IANA, l'organisation gérant l'allocation des adresses IP sur l'Internet.
Il est mort à la suite de complications d'une opération du cœur en 1998.
Principe de robustesse
Il est notamment célèbre pour la phrase : « Be liberal in what you accept,
and conservative in what you send » : « Soyez tolérant dans ce que vous
acceptez, et pointilleux dans ce que vous envoyez », qui définit le
principe de robustesse (parfois appelé le principe de Postel).
Écrit dans la RFC 791, ce principe met en avant l'interopérabilité sur le
respect des standards et a été une des plus importantes différences
entre la suite des protocoles Internet et son concurrent qui a depuis
disparu, le modèle OSI 1.
Hommages
Le prix Jon Postel est attribué depuis 1999 en son honneur par l'Internet
Society. Il en a été le premier récipiendaire, à titre posthume.
La RFC 2468 I remember IANA de Vint Cerf (17 octobre 1998) lui rend
hommage.
En 2012, il est admis à titre posthume au temple de la renommée
d'Internet, dans la catégorie des pionniers.
[email protected]
10/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Hierarchie
Au sommet de cette mécanique de résolution de noms se trouve la
Racine , symbolisé ici par un point : en réalité les noms de domaines se
terminent par un point , l'utilisateur ne le voit pas et ne l'indique pas pour
des raisons de simplicité.
Réminiscence du système Unix, ici BSD, et ce sont par ailleur des
systèmes openBSD qui font tourner les ROOT DNS.
Illustration 3: Source wikipédia
Les TLD, gTLD, et CountryCode ccTLD, sont donc gérés par des
machines de « plus niveaux » comme nous pourrions nous le
représenter, ou du moins l'imaginer comme sur ce schéma.
Ce qui de plus s'avère vrai. Voici les Root DNS
Root DNS
Les Root DNS sont réparti sur le globe, ils gèrent chacun des noms qui
correspondent généralement à de grandes zones géopolitique.
La RFC 1035 prévoit que les requêtes et les réponses DNS sur UDP ne
dépassent pas 512 octets.
Si la réponse est plus volumineuse, TCP doit alors être utilisé.
[email protected]
11/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Ceci consomme plus de ressources et présente le risque d'être bloqué
par un pare-feu.
Ce cas de réponse volumineuse est rare en pratique, mais la liste des
serveurs de noms de la zone racine avec les adresses IP
correspondantes atteint cette limite, 671 octets étant nécessaires pour
une réponse complète en juillet 2010.
Les serveurs A, C, F, G, I, J, K, L et M sont maintenant distribués
géographiquement grâce à anycast.
En général, le serveur le plus proche du client au sens du réseau sera
alors utilisé. C'est ainsi que la plupart des serveurs DNS physiques sont
à présent situés hors des États-Unis.
Les serveurs racines du DNS peuvent également être déclinés
localement, sur les réseaux des FAI par exemple. Ils doivent être
synchronisés avec le fichier de la zone racine14 du Département du
Commerce des États-Unis ainsi que le préconise l'ICANN. De tels
serveurs ne sont pas des serveurs DNS alternatifs mais une déclinaison
locale des serveurs racines du DNS A à M.
Illustration 4: Sources
[email protected]
12/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Protocole BGP
Le DNS étant un pilier de l'infrastructure de l'internet mondial, le vrai en
grand dans sa globalité, vient contre dire une notion.
Les ROOT DNS sont répartis en 12 zones mondiale. De A à M, ce qui
implique que des machines physiques portent la même adresse IP.
Car il ne peut exister seulement 12 machines, c'est impossible pour
plusieurs raisons notament la taille de la requête.
Border Gateway Protocol (BGP) est un protocole d'échange de route
utilisé notamment sur le réseau Internet. Son objectif est d'échanger des
informations de routage et d'accessibilité de réseaux (appelés préfixes)
entre Autonomous Systems (AS).
Contrairement aux protocoles de routage interne, BGP n'utilise pas de
métrique classique mais fonde les décisions de routage sur les chemins
parcourus, les attributs des préfixes et un ensemble de règles de
sélection définies par l'administrateur de l'AS. On le qualifie de protocole
à vecteur de chemins (path vector protocol).
BGP prend en charge le routage sans classe et utilise l'agrégation de
routes afin de limiter la taille de la table de routage. Depuis 1994, la
version 4 du protocole est utilisée sur Internet, les précédentes étant
considérées comme obsolètes. Ses spécifications sont décrites dans la
RFC 4271 A Border Gateway Protocol 4 (BGP-4).
BGP a remplacé Exterior Gateway Protocol (EGP) qui était utilisé dans la
dorsale ARPANET et a permis la décentralisation du routage sur Internet.
Certaines extensions de BGP permettent l'échange de routes IPv6 (RFC
2545) et l'extension multi-protocole (MP-BGP, RFC 2858) qui permet
d'utiliser BGP pour convoyer des informations de routage pour d'autres
protocoles que IPv4, par exemple IPv6 ou IPX.
Fonctionnement
Les connexions entre deux voisins BGP (neighbors ou peers) sont
configurées explicitement entre deux routeurs. Ils communiquent alors
entre eux via une session TCP sur le port 179 initiée par l'un des deux
routeurs. BGP est le seul protocole de routage à utiliser TCP comme
protocole de transport.
Il existe deux versions de BGP : Interior BGP (iBGP) et Exterior BGP (eBGP).
iBGP est utilisé à l'intérieur d'un Autonomous System alors que eBGP est
utilisé entre deux AS.
En général, les connexions eBGP sont établies sur des connexions pointà-point ou sur des réseaux locaux (un Internet Exchange Point par
exemple), le TTL des paquets de la session BGP est alors fixé à 1. Si la
liaison physique est rompue, la session eBGP l'est également, et tous les
[email protected]
13/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
préfixes appris par celle-ci sont annoncés comme supprimés et retirés
de la table de routage.
À l'inverse, les connexions iBGP sont généralement établies entre des
adresses logiques, non associées à une interface physique particulière.
Ceci permet, en cas de rupture d'un lien physique, de conserver la
session iBGP active si un lien alternatif existe et si un protocole de
routage interne dynamique (IGP) est employé (par exemple OSPF).
Une fois la connexion entre deux routeurs établie, ceux-ci s'échangent
des informations sur les réseaux qu'ils connaissent et pour lesquels ils
proposent du transit, ainsi qu'un certain nombre d'attributs associés à
ces réseaux qui vont permettre d'éviter des boucles (comme AS Path) et
de choisir avec finesse la meilleure route
Border Gateway Protocol dans sa version 4, utilisé sur Internet (RFC 1654
A Border Gateway Protocol 4, 1994), OSPF, EIGRP ou RIPv2.
Les registres Internet régionaux (RIR) adaptent leur politique
d'attribution des adresses en conséquence de ce changement.
L'utilisation de masque de longueur variable (Variable-Length Subnet
Mask, VLSM) permet le découpage de l'espace d'adressage en blocs de
taille variable, permettant une utilisation plus efficace de l'espace
d'adressage.
Le calcul du nombre d'adresses d'un sous-réseau est le suivant, 2taille de
l'adresse - masque.
Un fournisseur d'accès internet peut ainsi se voir allouer un bloc /19 (soit
232-19 = 213 = 8192 adresses) et créer des sous-réseaux de taille variable
en fonction des besoins à l'intérieur de celui-ci : de /30 pour des liens
points-à-point à /24 pour un réseau local de 200 ordinateurs. Seul le bloc
/19 sera visible pour les réseaux extérieurs, ce qui réalise l'agrégation et
l'efficacité dans l'utilisation des adresses.
[email protected]
14/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Liste IPv4 réservés
L'IANA, qui est depuis 2005 une division de l'ICANN, définit l'usage des
différentes plages d'adresses IP en segmentant l'espace en 256 blocs de
taille /8, numérotés de 0/8 à 255/8.
Préfixes IPv4 réservés
0.0.0.0/8
127.0.0.0/8
169.254.0.0/16
198.18.0.0/15
192.0.0.0/24
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
192.0.2.0/24 198.51.100.0/24 203.0.113.0/24
100.64.0.0/10
224.0.0.0/4
240.0.0.0/4
réservé pour les adresses sources du réseau courant
réservé pour la boucle locale
réservé pour le lien local
réservé pour les tests de performance d’équipements réseau
réservé pour l’IANA pour des allocations futures dédiées à des protocoles de l’IETF
réservés pour l’usage privé
"préfixes respectifs des TEST-NET-1 TEST-NET-2 et TEST-NET-3 réservés pour la documentation
"réservé pour les connexions entre fournisseurs et clients faisant usage du Carrier-Grade NAT
réservé pour le multicast
réservé pour un « usage futur »
255.255.255.255/32
« limited broadcast ». Les paquets à destination de cette adresse ne sont pas transférés par les routeurs
Les adresses IP unicast sont distribuées par l'IANA aux registres Internet
régionaux (RIR). Les RIR gèrent les ressources d'adressage IPv4 et IPv6
dans leur région. L'espace d'adressage unicast IPv4 est composé des
blocs d'adresse /8 de 1/8 à 223/8. Chacun de ces blocs est soit réservé,
assigné à un réseau final ou à un registre Internet régional (RIR) ou
libre6,7. En février 2011, il ne reste plus aucun bloc /8 libre.
En IPv6, le bloc 2000::/3 est réservé pour les adresses unicast globales8.
Des blocs /23 sont assignés aux RIR depuis 1999.
Liste IPv6 réservés
::ffff:0:0/96
100::/64
2001::/23
2001::/32
2001:2::/48
2001:10::/28
2001:db8::/32
2002::/16 (uniquement les préfixes plus
spécifiques)
fc00::/7
fe80::/10
ff00::/8
réservé
réservé
réservé
réservé
réservé
réservé
réservé
pour la correspondance IPv4
pour le black-holing 6
par l’IANA pour des protocoles (TEREDO parexemple)
pour le service TEREDO
pour les tests de performance des équipementsréseau
pour ORCHID
pour la documentation
réservé pour le 6to4
réservé pour les adresses Unique-Local
réservé pour les adresses Link-Scoped Unicast
réservé pour le multicast
Il est possible d'interroger les bases de données des RIR pour savoir à
qui est assignée une adresse IP grâce à la commande whois ou via les
sites web des RIR.
Les RIR se sont regroupés pour former la Number Resource
Organization (NRO) afin de coordonner leurs activités ou projets
communs et mieux défendre leurs intérêts auprès de l'ICANN (l'IANA),
mais aussi auprès des organismes de normalisation (notamment l'IETF
[email protected]
15/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
ou l'ISOC)
[email protected]
16/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
La Sécurité des sessions
Les spécifications de la version actuelle de BGP (version 4) ne
définissent pas de mécanisme permettant de protéger les sessions. Le
protocole BGP s’appuyant sur TCP, il est possible de mettre fin aux
sessions en envoyant des paquets TCP RST, ce qui peut permettre à un
attaquant de réaliser un déni de service.
Bien que la mise en œuvre d’une telle attaque implique certains
prérequis, TCP MD5 est un mécanisme complémentaire aux autres
mesures de sécurité, et dont l’utilisation s’inscrit dans une démarche de
défense en profondeur.
LʼAuthentification des messages
La RFC 4271 , publiée en janvier 2006, spécifie que les implémentations
de BGP doivent permettre d’utiliser le mécanisme d’authentification
fourni par l’option de TCP couramment appelé TCP MD5, et décrit dans la
RFC 2385 .
Ce mécanisme est disponible dans la plupart des implémentations de
BGP, et permet d’assurer l’intégrité et l’authenticité des messages TCP
en incluant un MAC 1 calculé à l’aide de la fonction de hachage MD5.
La mise en place de ce mécanisme repose sur un secret partagé entre
les deux routeurs.
L’algorithme s’applique aux éléments suivants :
• un pseudo en-tête IP comprenant l’adresse IP source, l’adresse IP
destination, le numéro de protocole et la longueur du segment ;
• l’en-tête TCP, hormis les options, avec une valeur nulle pour la
somme de contrôle ;
• les données du segment TCP.
Le destinataire d’un segment calcule le MAC de la même façon et vérifie
si le résultat est le même que la valeur contenue dans l’option TCP MD5.
En cas d’échec, le segment est rejeté silencieusement. En cas de
changement de secret au cours d’une session, les paquets émis par le
pair ayant conservé l’ancien secret sont rejetés, et la session expire une
fois que le hold time est dépassé.
TCP MD5 n’est pas un mécanisme cryptographique robuste.Cependant,
les implémentations existantes à la date d’écriture de ce document ne
proposent pas l’Authentication Option de TCP, définie dans la RFC 5925
qui doit permettre l’utilisation d’autres algorithmes. Malgré son
obsolescence, TCP MD5 constitue un élément de sécurité
supplémentaire aux autres bonnes pratiques de configuration.
[email protected]
17/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
En l’absence de mécanisme plus robuste, TCP MD5 devrait être
systématiquement utilisé lorsque l’interconnexion est effectuée en multihop, ou au moyen d’un équipement partagé (par exemple, un
commutateur) au sein d’un point d’échange.
Lorsque l’interconnexion est effectuée entre deux routeurs proposant
un mécanisme cryptographique plus robuste, ce mécanisme doit être
utilisé en lieu et place de TCP MD5.
Un secret différent doit être configuré pour chaque interconnexion. Le
secret utilisé doit être fort, sans quoi le mécanisme fourni par TCP MD5
ne présente plus d’intérêt. La force d’un secret dépend de sa longueur
et des classes de caractères qui le composent.
Commande permettant de configurer lʼauthentification MD5
TCP MD5 - Routeurs Alcatel-Lucent
neighbor <ip-address > authentication-key <secret >
Authentification TCP MD5 pour un pair (à l’adresse IP ip-address) sur un
routeur Alcatel-Lucent à l’aide de la commande authentication-key. La
clé demandée (secret) est la chaîne de caractères constituant le secret
sur lequel les pairs se sont préalablement accordés.
neighbor 192.0.2.3 authentication-key ght8CD %E7am
TCP MD5 - Routeurs Cisco
Cisco( config-router )# neighbor <ip-address > password <string >
Authentification MD5 est configurable . pour un pair à l’aide de son
adresse IP (ip-address). Le secret entré est une chaîne de caractères
(string).
Cisco( config )# router bgp 64506
Cisco( config-router )# neighbor 192.0.2.3 password ght8CD %E7am
[email protected]
18/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
TCP MD5 - Routeurs Juniper
[edit protocols bgp group session-to-AS64506 neighbor 192.0.2.6 ]
root@Juniper # set authentication-key ght8CD %E7am
Authentification TCP MD5 sur un routeur Juniper à l’aide de la
commande . set authentication-key. La clé demandée est la chaîne de
caractères constituant le secret sur lequel les pairs se sont
préalablement accordés.
TCP MD5 - Routeurs OpenBGPD
tcp md5sig { password | key} <secret >
Le secret entré peut être une chaîne . de caractères ASCII (utilisation de
password secret) ou fourni sous forme . hexadécimale (utilisation de key
secret).
tcp md5sig password " ght8CD %E7am"
Filtrage sur les préfixes réservés
Les martians sont des préfixes réservés à des fins spécifiques. Il peut
s’agir, par exemple, des blocs d’adresses privées définis dans la RFC 1918
et dans la RFC 6890 .
Les martians ne devraient pas être annoncés dans l’Internet, et
constituent donc une première catégorie de préfixes devant être filtrés.
Les filtres sur ces préfixes doivent être appliqués aussi bien sur les flux
entrants que sur les flux sortants.
[email protected]
19/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Routeurs Alcatel-Lucent
configuration de filtres statiques pour des martians IPv4
>config >router > policy-options #
prefix-list " v4-martians "
prefix 0.0.0.0/8 longer
prefix 255.255.255.255/32 exact
exit
policy-statement " reject-martians "
entry 10
from
exit
action reject
exit
exit
default-action accept
exit
Application du filtre
>config >router >bgp#
group "EBGP"
import " reject-martians "
export " reject-martians "
neighbor 192.0.2.3
exit
exit
[email protected]
20/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Configuration de filtres statiques pour des martians
IPv6
>config >router > policy-options #
prefix ::1/128 exact
prefix ::/128 exact
prefix :: ffff :0.0.0.0/96 longer
prefix 100::/64 longer
prefix 2001::/23 longer
prefix 2001: db8 ::/32 longer
prefix 2002::/16 prefix-length-range 17 -128
prefix fc00 ::/7 longer
prefix fe80 ::/10 longer
prefix ff00 ::/8 longer
prefix 3ffe ::/16 longer
prefix 5f00 ::/8 longer
exit
prefix-list " v6-authorized "
prefix 2000::/3 prefix-length-range 3-48
exit
policy-statement " reject-v6-martians "
entry 10
from
exit
action reject
exit
exit
entry 20
from
prefix-list " v6-authorized "
exit
action accept
exit
exit
default-action reject
exit
Configuration de filtres statiques. Ces filtres sont appliqués à un ou
pour les préfixes réservés (IPv4 et IPv6) plusieurs pairs.
[email protected]
21/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Filtrage sur des préfixes réservés - Routeurs Cisco
Commande permettant de créer une prefix-list
Cisco ( config )#ip prefix-list <list-name > | <list-number > [seq
number ] {deny <network >/< length > | permit <network >/<
length >} [ge ge-length ] [le le-length ]
Paramètres et options disponibles pour cette commande :
• list-name et list-number permettent d’identifier la prefix-list par
un nom ou un nombre .
• seq number fixe un numéro de séquence, compris entre 1 et 2n-2
soit 2 puissance 32 -2
indiquant l’ordre dans lequel sont traitées les entrées. Si aucun numéro
de séquence n’est donné, un numéro par défaut est fixé. S’il s’agit d’une
première entrée dans une prefix-list, la valeur 5 est fixée. Pour des
entrée ultérieures, le numéro est incrémenté de 5 ;
• deny et permit permettent respectivement d’interdire ou
d’autoriser un préfixe donné
• les paramètres optionnels ge ge-length et le le-length
permettent d’indiquer une longueur de masque pour laquelle le test
sera vrai. Le mot-clé ge permet d’effectuer un test de type « supérieur
ou égal », le permet d’effectuer un test de type « inférieur ou égal ».
Configuration de filtres statiques pour des préfixes réservés
(IPv4)
Cisco( config )#ip prefix-list ipv4-martians seq 5 deny
0.0.0.0/8 le 32
127.0.0.0/8 le 32
169.254.0.0/16 le 32
198.18.0.0/15 le 32
192.0.0.0/24 le 32
10.0.0.0/8 le 32
172.16.0.0/12 le 32
192.168.0.0/16 le 32
255.255.255.255/32
Cisco( config )#ip prefix-list ipv4-martians seq 500 permit
0.0.0.0/0 le 24
[email protected]
22/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Application de la prefix-list à un pair en entrée et en sortie
Cisco( config-router-af )# neighbor 192.0.2.3 prefix-list
ipv4-martians in
Cisco( config-router-af )# neighbor 192.0.2.3 prefix-list
ipv4-martians out
Configuration de filtres statiques pour des préfixes réservés
(IPv6)
Cisco ( config )#ipv6 prefix-list ipv6-filter deny ::1/128
Cisco ( config )#ipv6 prefix-list ipv6-filter deny ::/128
Cisco ( config )#ipv6 prefix-list ipv6-filter permit 2002::/16
Cisco ( config )#ipv6 prefix-list ipv6-filter deny 2002::/16 le
128
Cisco ( config )#ipv6 prefix-list ipv6-filter deny 3FFE ::/16 le
128
Cisco ( config )#ipv6 prefix-list ipv6-filter deny 5F00 ::/8 le
128
Cisco ( config )#ipv6 prefix-list ipv6-filter permit 2000::/3 le
48
Cisco ( config )#ipv6 prefix-list ipv6-filter seq 500 deny ::/0
le 128
Pour des préfixes IPv6, le filtrage s’effectue de manière analogue à celle
présentée, à l’aide de la commande ipv6 prefix-list.
Filtrage sur des martians - Routeurs Juniper
Construction dʼun filtre (policy-statement) pour les martians IPv4
[edit policy-options policy-statement ipv4-martians ]
root@Juniper # set from route-filter 0.0.0.0/8 orlonger
Définition de lʼaction à effectuer pour le filtre ipv4-martians
[edit policy-options policy-statement ipv4-martians ]
root@Juniper # set then reject
Filtre des martians IPv4
[edit policy-options ]
root@Juniper # show policy-statement ipv4-martians
from {
route-filter 0.0.0.0/8 orlonger ;
route-filter 255.255.255.255/32 exact ;
}
then reject ;
[email protected]
23/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Application du filtre ipv4-martians
[edit protocols bgp]
root@Juniper # set group session-to-AS64502-v4
import
ipv4-martians
root@Juniper # show group session-to-AS64502-v4
type external ;
import ipv4-martians ;
peer-as 64502;
neighbor 192.0.2.2;
Filtre des martians IPv6
[edit policy-options ]
root@Juniper # show policy-statement ipv6-martians
from {
family inet6 ;
route-filter ::1/128 exact;
route-filter ::/128 exact ;
route-filter 2001:0000::/23 orlonger ;
route-filter 2001: db8 ::/32 orlonger ;
route-filter 2002::/16 exact next policy ;
route-filter 2002::/16 longer ;
}
then reject ;
Filtrage sur les martians - Routeurs OpenBGPD
Configuration de filtres statiques pour les martians IPv4 et IPv6
# Martians IPv4
deny from any prefix 0.0.0.0/8 prefixlen >= 8
# Martians IPv6
deny from any prefix ::1/128
deny from any prefix ::/128
deny from any prefix :: ffff :0:0/96 prefixlen >= 96
deny from any prefix 64: ff9b ::/96 prefixlen >= 96
[email protected]
24/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Liste ROOT DNS
Voici la liste : egalement disponible ici
Hostname
a.root-servers.net
b.root-servers.net
c.root-servers.net
d.root-servers.net
e.root-servers.net
f.root-servers.net
g.root-servers.net
h.root-servers.net
i.root-servers.net
j.root-servers.net
k.root-servers.net
l.root-servers.net
m.root-servers.net
IP Addresses
198.41.0.4,
2001:503:ba3e::2:30
192.228.79.201,
2001:500:84::b
192.33.4.12, 2001:500:2::c
199.7.91.13, 2001:500:2d::d
192.203.230.10
192.5.5.241, 2001:500:2f::f
192.112.36.4
198.97.190.53, 2001:500:1::53
192.36.148.17, 2001:7fe::53
192.58.128.30,
2001:503:c27::2:30
193.0.14.129, 2001:7fd::1
199.7.83.42, 2001:500:9f::42
202.12.27.33, 2001:dc3::35
Manager
VeriSign, Inc.
University of Southern California
(ISI)
Cogent Communications
University of Maryland
NASA (Ames Research Center)
Internet Systems Consortium, Inc.
US Department of Defense (NIC)
US Army (Research Lab)
Netnod
VeriSign, Inc.
RIPE NCC
ICANN
WIDE Project
Sécurité des serveurs racine
Les serveurs racine jouent un rôle important dans le système DNS.
Si l'un ou quelques-uns d'entre eux ne répondent plus, la charge est
répartie entre les serveurs qui subsistent.
Si aucun d'entre eux ne pouvait répondre aux requêtes, les noms de
domaines deviendraient progressivement inaccessibles, au fur et à
mesure que les informations dans les caches parviendraient à
expiration, c'est-à-dire environ 2 % par heure d'indisponibilité totale15
Nous avons passé en revu un certain nombre d'acteurs, je suis resté
axé sur une vision très franco Française.
Vous iriez plus naturellement vers un
.fr
.com
.net
pour des raisons de clareté, de facilité mnémotechnique.
Vous pourriez bien prendre un .co.uk ; .jp ; .ch ; .cn … au final c'est pareil
[email protected]
25/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
oui ce n'est plus une simple question de localisation, si ce n'est que vous
vous soumettez à d'autres lois et divers « procédés » de … rétention de
contenu non conforme aux dits droits.
Mais ceci est encore un autre problème, qui demande encore une autre
réflexion.
Dont la complexité demande la prise en compte de beaucoup de
variable. Il faut une approche raisonnée .
(Je reviendrais probablement sur ce point, pour le moins délicat. Comme
exprimé le Dns joue un rôle majeur dans l'internet mondial, et a ses
fragilités.
Je signalerais l'existence du réseau TOR :
The Onion Router
GNS : Gnu Name Server
[email protected]
26/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Les sous-domaines
Domain Name Space
NS RR ("resource record")
names the nameserver
authoritative for
delegated subzone
"delegated subzone"
When a system administrator
wants to let another administrator
manage a part of a zone, the first
administrator's nameserver
delegates
part of the zone to another
nameserver.
=
resource records
associated with name
=
zone of authority,
managed by a name server
see also: RFC 1034 4.2:
How the database is divided into zones.
On peut découper un domaine en plusieurs sous-domaines avec un « . »
pour séparateur.
Cela peut permettre de séparer différentes fonctions de votre site.
Par exemple : forum.domaine.suffixe ou blog.domaine.suffixe
A noter : www.domaine.suffixe est un sous domaine de domaine.suffixe
alors que les deux pointent généralement sur le même site.
On ne doit pas confondre zones et sous domaine, une zone (ou
délégation de zones) correspondra à un segment, le sous.domaine.TLPD
[email protected]
27/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Aspect Technique
Fonctionnalités
4 types de serveur DNS différent (RFC 1035) :
cache
Simplement un serveur cache, il ne fait pas autorité pour faire la
résolution pour des clients. Il garde une mémoire tampon, pour éviter
charger le réseau
local
cache
Mail Client
Web Browser
DNS Resolver
DNS Resolver
cache timeout: mini
1-30 min cache
Client Programs
local
cache
Operating System
Your ISP
recursive
DNS
search
Your Computer
C'est une chose à prévoir en entreprise, si une address est déjà connu
inutile d'aller la chercher sur le WAN.
[email protected]
28/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Recursif :
Le serveur va interroger de manière récursive la chaine de DNS afin de
résoudre le nom ; compléter la requête.
Illustration 6: Résolution itérative d'un nom dans le DNS
par un serveur DNS (étapes 2 à 7) et réponse (étape 8)
suite à l'interrogation récursive (étape 1) effectuée par un
client (resolver) DNS. (remarque: Le serveur DNS
récursif est dit récursif car il accepte ce type de requêtes
mais il effectue des requêtes itératives)
Illustration 5: Sources wikipedia
Quand un serveur DNS récursif doit trouver l'adresse IP de
fr.wikipedia.org, un processus itératif démarre pour consulter la
hiérarchie DNS.
Ce serveur demande aux serveurs DNS appelés serveurs racine quels
serveurs peuvent lui répondre pour la zone org.
Parmi ceux-ci, le serveur va en choisir un pour savoir quels serveurs
sont capables de lui répondre pour la zone wikipedia.org.
C'est un de ces derniers qui pourra lui donner l'adresse IP de
fr.wikipedia.org.
S'il se trouve qu'un serveur ne répond pas, un autre serveur de la liste
sera consulté.
Pour optimiser les requêtes ultérieures, les serveurs DNS récursifs font
aussi office de DNS cache : ils gardent en mémoire (cache) la réponse
d'une résolution de nom afin de ne pas effectuer ce processus à
[email protected]
29/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
nouveau ultérieurement. Cette information est conservée pendant une
période nommée Time to live et associée à chaque nom de domaine.
Ceci permet également plus de discrétion, puisque la requête ne sort
pas tel quel sur le WAN. Je fais tourner Unbound en local pour la
récursion et n’utilise pas les serveurs DNS de mon opérateur.
Primary master
Secondary master
local
cache
Mail Client
Primaire
local
cache
DNS Resolver
Web Browser
cache timeout: mini
1-30 min cache
Client Programs
Secondaire
DNS Resolver
DNS Resolver
Operating System
Your ISP (FAI)
recursive
DNS
search
Your Computer
Un nom de domaine peut utiliser plusieurs serveurs DNS.
Généralement, les noms de domaines en utilisent au moins deux :
un primaire et un secondaire.
Il peut y avoir plusieurs serveurs secondaires.
L'ensemble des serveurs primaires et secondaires font autorité pour un
domaine, c'est-à-dire que la réponse ne fait pas appel à un autre
serveur ou à un cache.
Les serveurs récursifs fournissent des réponses qui ne sont pas
nécessairement à jour, à cause du cache mis en place. On parle alors
de réponse ne faisant pas autorité (non-authoritative answer).
Cette architecture garantit au réseau Internet une certaine continuité
dans la résolution des noms.
Quand un serveur DNS tombe en panne, le bon fonctionnement de la
résolution de nom n'est pas remis en cause dans la mesure où des
serveurs secondaires sont disponibles.
Nora Bene : Ici encore nous constatons la présence de serveur faisant
office de cache.
Il est du devoir des intervenants technique et décideurs de protéger le
réseau, ne contrôlant pas les éléments du WAN, nous ne pouvons nous
permettre de consommer de la ressource, sans nous soucier de sa
[email protected]
30/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
capacité à absorber les charges.
[email protected]
31/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
BIND
Fonctionnement de bind
Fichier de configuration
Vue schématique
Nota Bene
Ne pas copier/coller les configurations présenter ici, car le formatage
du texte ne correspondra sans doute pas.
De plus une configuration est propre à un réseau, il convient donc de
l'adapter en fonction de ses propres besoins.
General
Les fichiers de configurations sont contenus dans :/etc/bind/
•
named.conf: fichier de configuration principal du server , il
utilise des include pour inclure d'autres fichiers
•
named.conf.options : dédié aux options du serveur qui
décrivent les caractéristiques commune à l'ensemble des
zones
•
named.conf.local
[email protected]
32/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
named.conf
Le fichier /etc/bind/named.conf redirige vers 3 autres
fichiers de configuration, attention ceci sont indiqué entre
des guillements..
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
named.conf.options
Nous indiquons ici le port et sur quelle adresse écouter ; nous pouvons
indiquer un forwarder (un proxy) par la même occasion.
Dans le cas présent le DNS écoute sur 2 cartes.
options {
directory "/var/cache/bind";
listen-on-port 53 {127.0.0.1; 192.168.1.2; 172.25.10.1;}
dnssec-validation auto;
forwarders { 192.168.131.21; };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Named.conf.default-zones
Fichier indiquant les root-server, la boucle locale et locale-inverse
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
type master;
};
type master;
};
[email protected]
33/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
named.conf.local
Les ACL pour acces control list, définissent les segment réseau qu'il doit
servir.
Dans l'exemple : 172.25.10.0/24 correspond à un LAN pour booter en PXE,
192.168.1.0 correspond à un portail d'acces.
Le 172.25.3.0/24 à mon LAN
J'indique également les fichiers d' include
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
acl internals { 127.0.0.0/8; 172.25.10.0/24; 168.168.1.0/24; 172.25.3.0/24};
include "/etc/bind/named.conf.logging";
//include "/etc/bind/named.conf.local.afpanet";
incluse "/etc/bind/named.conf.local.grp3";
};
Créer /etc/bind/named.conf.local.afpanet
J'indique mes zones, zones inverse pour la résolution invers de type
master.
zone "grp3.info-msj.net" {
type master;
file "/etc/bind/db.grp3.info-msj.net";
allow-update {key rndc-key;};
};
zone "3.25.172.in-addr.arpa"{
type master;
file "/etc/bind/db.grp3.info-msj.net.inv";
};
zone "afpanet.info-msj.net" {
type master;
file "/etc/bind/db.afpanet.info-msj.net";
};
type master;
file "/etc/bind/db.afpanet.info-msj.net.inv";
};
zone "afpanet.local" {
type master;
file "/etc/bind/db.afpanet.local";
};
type master;
file "/etc/bind/db.afpanet.local.inv";
};
Repéter l'opération autant de fois que vous avez de zones.
[email protected]
34/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Fichiers de logs
/etc/bind/named.conf.logging
Nous allons crée des fichiers de log suivant :
D'abord le dossiers les contenant :
$ sudo mkdir /var/log/named
Creer les fichiers de log
$ sudo touch
$ sudo touch
$ sudo touch
$ sudo touch
/var/log/named/update_debug.log
/var/log/named/security_info.log
/var/log/named/bind.log
/var/log/named/named.log
Je vérifie leur présence :
$ ls /var/log/named/
bind.log named.log security_info.log update_debug.log
Puis je change le propriétaire et le groupe :
$ sudo chown
$ sudo chown
$ sudo chown
$ sudo chown
$ sudo chown
bind:bind /var/log/named/named.log
bind:bind /var/log/named/update_debug.log
bind:bind /var/log/named/security_info.log
bind:bind /var/log/named/bind.log
bind:bind /var/log/named/update_debug.log
Editer ce fichier
sudo vi /etc/bind/named.conf.logging
logging {
channel update_debug {
file "/var/log/named/update_debug.log" version 3 size 100k;
severity debug;
print-severity yes;
print-time
yes;
};
channel security_info {
file "/var/named/security_info.log" version 1 size 100k;
severity info;
print-severity yes;
print-time
yes;
};
channel bind_log {
file "/var/log/named/bind.log" version 3 size 1m;
channel bind_log {
severity info;
print-category yes;
print-severity yes;
print-time
yes;
};
};
category
category
category
category
category
default { bind_log; };
lame-servers { null; };
update { update_debug; };
update-security { update_debug; };
security { security_info; };
[email protected]
35/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Fichier de zones
Ce sont les db, ils y a un format précis à respecter.
Chaque ligne correspond à un aspect de la zone pour laquelle le DNS
fait autorité ou non
touch /etc/bind/db.grp3.info-msj.net
$ORIGIN grp3.info-msj.net.
$TTL 1600
@ IN SOA ns1.grp3.info-msj.net. @root.grp3.info-msj.net. (
2013112801
; serial
604800
; Refresh
86400
; Retry
2419200
; Expire
604800 ); Negative Cache TTL
@
IN
A
mail
www
www2
www3
webmail
IN
NS
ns1.grp3.info-msj.info-msj.net.
172.25.3.1
IN
A
172.25.3.4
IN
A
172.25.3.107
IN
A
172.25.3.113
IN
A
172.25.3.123
IN
CNAME mail
$ORIGIN afpanet.local.
$TTL 1600
@
IN
SOA ns.afpanet.local.
2016011001
;Serial
60400
;Refresh
86400
;Retry
2419200
;Expire
Correspond à la zone
Time To Live le temps
State Of Autority : fait autorité sur la zone
série d’incrémentation à chaque nouveau enregistrement
@
IN
MX
10
mail.grp3.info-msj.net.
ns1
Enregistrement boite mail (MX)
Enregistrement site web (A)
@root.afpanet.local. (
@
IN
NS
ns.afpanet.local.
@
IN
MX
10
mail.afpanet.local.
ns
IN
A
192.168.1.2
afpanet IN
A
192.168.1.10
mail IN
A
192.168.1.15
info IN
A
192.168.1.11
rtfm IN
A
192.168.1.12
info2 IN
A
192.168.1.100
webmail IN
CNAME mail
www IN
CNAME afpanet
$ORIGIN 1.168.192.addr.arpa.
$TTL 1600
@
IN
SOA ns.afpanet.local. @root.afpanet.local. (
2016011001
;Serial
60400
;Refresh
86400
;Retry
2419200
;Expire
@
#@
10
15
12
14
100
IN
IN
IN
IN
IN
IN
IN
NS
MX
PTR
PTR
PTR
PTR
PTR
ns.afpanet.local.
10
mail.afpanet.local.
www.afpanet.local.
mail.afpanet.loacal.
info.afpanet.local
rtfm.afpanet.local.
info2.afpanet.local.
Enregistrement inverse boite mail
Enregistrement inverse de nom
Changer le propriétaire de rndc.key
Sudo chown root.bind /etc/bind/rndc.key
[email protected]
36/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
IMPORTANT
Ne jamais mettre les paramétres locaux dans le fichier
/etc/bind/name.conf, en cas de mise à jour du système les paramètres
seront écrasés.
Redemarrage du service
La commande suivante va vérifier les fichiers de config précédemment
$ sudo named-checkconf -z
zone grp3.info-msj.net/IN: loaded serial 2013112801
zone 3.25.172.in-addr.arpa/IN: loaded serial 2013112801
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
Vérifier les zones de noms
sudo named -g
sudo service bind9 restart
$ sudo service bind9 restart
Test du service BIND
Dig -x 127.0.0.1
[email protected]
37/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Script
Le script suivant permet de vérifier les correspondances des fichiers de
zones ainsi que la résolution inverse.
####~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~###
###------------------------dns_verify.sh--------------------------------------###
###____________________________________________________###
###-----Modifier les adresses en fonction de son propre réseau--------###
###-----Ajouter plusieurs réseaux séparés par une virgule ,-------------###
###-----juste à la première ligne: 172.25.3 correspond à mon lan------###
###---------------------ordinatous.com---------------------------------------###
NETS="172.25.3"
IPS=$(seq 1 254) ## for Linux
#
# IPS=$(jot 254 1) ## for OpenBSD or FreeBSD
# IPS=$(seq 1 254) ## for Linux
#
echo
echo -e "\tip
-> hostname -> ip"
echo '--------------------------------------------------------'
for NET in $NETS; do
for n in $(seq 1 254); do
A=${NET}.${n}
HOST=$(dig -x $A +short)
if test -n "$HOST"; then
ADDR=$(dig $HOST +short)
if test "$A" = "$ADDR"; then
echo -e "ok\t$A -> $HOST -> $ADDR"
elif test -n "$ADDR"; then
echo -e "fail\t$A -> $HOST -> $ADDR"
else
echo -e "fail\t$A -> $HOST -> [unassigned]"
fi
fi
done
done
echo ""
echo "DONE."
[email protected]
38/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Bonus:Unbound
Serveur Récursif en local.
Préambule
Il semble que le manque de foi, les orientations sexuelles, et/ou politique
soient des sujets qui pré occupe énormément ces régimes
démocratiques légitimement élus.
C'est donc en tout légitimité que les dites démocratie peuvent mettre en
place divers procédé afin d'améliorer le contenu accessible en
connaissant mieux les habitudes de navigation des utilisateurs.
About Unbound
Unbound is a validating, recursive, and caching DNS resolver.
The C implementation of Unbound is developed and maintained by NLnet
Labs. It is based on ideas and algorithms taken from a java prototype
developed by Verisign labs, Nominet, Kirei and ep.net.
Unbound is designed as a set of modular components, so that also
DNSSEC (secure DNS) validation and stub-resolvers (that do not run as a
server, but are linked into an application) are easily possible.
The source code is under a BSD License.
Download
The latest source code tarball is available for download.
Récupération de Unbound
Se déplacer dans le répertoire /tmp, et récupérer l'archive.
cd /tmp
wget http://www.unbound.net/downloads/unbound-latest.tar.gz
tar -xzvf unbound-latest.tar.gz
--2016-02-06 14:16:48-- http://www.unbound.net/downloads/unbound-latest.tar.gz
Résolution de www.unbound.net (www.unbound.net)… 185.49.140.10, 2a04:b900::1:0:0:10
Connexion à www.unbound.net (www.unbound.net)|185.49.140.10|:80… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 4859573 (4,6M) [application/x-tar]
Sauvegarde en : « unbound-latest.tar.gz »
unbound-latest.tar.gz
ds ,7s
100%[========================================>]
4,63M
832KB/s
2016-02-06 14:16:55 (711 KB/s) — « unbound-latest.tar.gz » sauvegardé [4859573/4859573]
On se déplace dans le répertoire
cd unbound-x.x.x/
./configure && make && make install
[email protected]
39/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Details lib
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n
/usr/local/lib
---------------------------------------------------------------------Libraries have been installed in:
/usr/local/lib
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
---------------------------------------------------------------------./libtool --mode=finish /usr/local/lib
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n
/usr/local/lib
---------------------------------------------------------------------Libraries have been installed in:
/usr/local/lib
Ajouter le groupe unbound
# groupadd unbound
Ajouter l'utilisateur unbound au group unbound
# useradd -d /var/unbound -m -g unbound -s /bin/false unbound
On se déplace dans /var/unbound/
Et on récupère les DNS racine
wget ftp://ftp.internic.net/domain/named.cache
--2016-02-06 14:33:38-- ftp://ftp.internic.net/domain/named.cache
=> « named.cache »
Résolution de ftp.internic.net (ftp.internic.net)… 192.0.32.9, 2620:0:2d0:200::9
Connexion à ftp.internic.net (ftp.internic.net)|192.0.32.9|:21… connecté.
Ouverture de session en tant que anonymous… Session établie.
==> SYST ... terminé.
==> PWD ... terminé.
==> TYPE I ... terminé. ==> CWD (1) /domain ... terminé.
==> SIZE named.cache ... 3171
==> PASV ... terminé.
==> RETR named.cache ... terminé.
Taille : 3171 (3,1K) (non certifiée)
named.cache
100%[===============================>]
3,10K
--.-KB/s
2016-02-06 14:33:40 (679 KB/s) - « named.cache » sauvegardé [3171]
On créer le répertoire qui va contenir le PID
mkdir -p /var/unbound/var/run
Et on donne les droits:
chown -R unbound:unbound /var/unbound
On crée le lien symbolique
ln -s /var/unbound/var/run/unbound.pid /var/run/unbound.pid
Il faut un script de démarrage ; vous le trouverez page suivante, par
contre ce script est parfaitement utilisable en l'état sur Débian
[email protected]
40/49
ds 0,005s
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
vi /etc/init.d/unbound
#!/bin/sh
#
# unbound
This shell script takes care of starting and stopping
#
unbound (DNS server).
exec="/usr/local/sbin/unbound"
prog="unbound"
config="/var/unbound/unbound.conf"
pidfile="/var/run/unbound.pid"
rootdir="/var/unbound"
case "$1" in
start)
[ -x $exec ] || exit 5
[ -f $config ] || exit 6
echo -n $"Starting $prog: "
# setup root jail
if [ -s /etc/localtime ]; then
[ -d ${rootdir}/etc ] || mkdir -p ${rootdir}/etc ;
if [ ! -e ${rootdir}/etc/localtime ] || /usr/bin/cmp -s /etc/localtime ${rootdir}/etc/localtime; then
cp -fp /etc/localtime ${rootdir}/etc/localtime
fi;
fi;
if [ -s /etc/resolv.conf ]; then
[ -d ${rootdir}/etc ] || mkdir -p ${rootdir}/etc ;
if [ ! -e ${rootdir}/etc/resolv.conf ] || /usr/bin/cmp -s /etc/resolv.conf ${rootdir}/etc/resolv.conf; then
cp -fp /etc/resolv.conf ${rootdir}/etc/resolv.conf
fi;
fi;
if ! egrep -q '^/[^[:space:]]+:space:+'${rootdir}'/dev/log' /proc/mounts; then
[ -d ${rootdir}/dev ] || mkdir -p ${rootdir}/dev ;
[ -e ${rootdir}/dev/log ] || touch ${rootdir}/dev/log
mount --bind -n /dev/log ${rootdir}/dev/log >/dev/null 2>&1;
fi;
if ! egrep -q '^/[^[:space:]]+:space:+'${rootdir}'/dev/random' /proc/mounts; then
[ -d ${rootdir}/dev ] || mkdir -p ${rootdir}/dev ;
[ -e ${rootdir}/dev/random ] || touch ${rootdir}/dev/random
mount --bind -n /dev/random ${rootdir}/dev/random >/dev/null 2>&1;
fi;
# if not running, start it up here
start-stop-daemon --start --quiet --pidfile $pidfile --exec $exec -- -c $config
echo
;;
stop)
echo -n $"Stopping $prog: "
start-stop-daemon --stop --quiet --oknodo --pidfile $pidfile
echo
if egrep -q '^/[^[:space:]]+:space:+'${rootdir}'/dev/log' /proc/mounts; then
umount ${rootdir}/dev/log >/dev/null 2>&1
fi;
if egrep -q '^/[^[:space:]]+:space:+'${rootdir}'/dev/random' /proc/mounts; then
umount ${rootdir}/dev/random >/dev/null 2>&1
fi;
;;
restart)
start-stop-daemon --stop --quiet --oknodo --pidfile $pidfile
start-stop-daemon --start --quiet --pidfile $pidfile --exec $exec -- -c $config
;;
reload)
start-stop-daemon --stop --signal 1 --quiet --oknodo --pidfile $pidfile --exec $exec
;;
force_reload)
start-stop-daemon --stop --signal 1 --quiet --oknodo --pidfile $pidfile --exec $exec
;;
*)
echo $"Usage: $0 {start|stop|restart|reload|force-reload}"
exit 2
;;
esac
exit 0
[email protected]
41/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Le rendre executable et le désigner par default
chmod 755 /etc/init.d/unbound
update-rc.d unbound defaults
Configuration.
Éditons le fichier de configuration :
vi /etc/var/unbound/unbound.conf
vi /etc/var/unbound/unbound.conf
server:
verbosity: 1
interface: 0.0.0.0
port: 53
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
# Ci dessous j'autorise unbound à servir les machines du resau local 192.168.8.0/24
access-control: 192.168.8.0/24 allow
# Ci dessous je n'autorise pas la connexion à toute les machines
#access-control: 0.0.0.0/0 refuse
# Ci dessous une configuration pour servir la machine uniquement
« Le serveur est chrooté, c'est comme si il était à la racine, mais il est isolé.
chroot: "/var/unbound"
username: "unbound"
directory: "/var/unbound"
use-syslog: yes
pidfile: "/var/run/unbound.pid"
# ci dessous les ROOT DNS
root-hints: "/var/unbound/named.cache"
[email protected]
42/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Voici un fichier minimaliste , typiquement ce que l'on trouve sur internet,
pour le coup , ne copiez pas ça.
Regardez les plages d'adresses, elles sont excessivement grandes pour
un usage en local.
De plus vous allez droit chez google. Il ne faut pas copier/coller tout ce
que l'on trouve sans regarder et comprendre un temps soit peu.
server:
interface: 0.0.0.0
verbosity: 1
forward-zone:
name: "."
forward-addr: 8.8.8.8
# Google Public DNS
forward-addr: 74.82.42.42 # Hurricane Electric
Check configuration
unbound-checkconf /var/unbound/unbound.conf
unbound-checkconf /var/unbound/unbound.conf
unbound-checkconf: no errors in /var/unbound/unbound.conf
Test/Resultat
DNS bouygues
dig ordinatous.com
; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> ordinatous.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25785
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ordinatous.com.
IN
A
;; ANSWER SECTION:
ordinatous.com.
;;
;;
;;
;;
3600
IN
A
213.186.33.82
Query time: 238 msec
SERVER: 192.168.8.1#53(192.168.8.1)
WHEN: Sat Feb 06 15:01:25 CET 2016
MSG SIZE rcvd: 59
[email protected]
43/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
DNS FDN
Bien plus complet
;; Got answer:
;ordinatous.com.
IN
A
;; ANSWER SECTION:
ordinatous.com.
3600
IN
A
;; AUTHORITY SECTION:
ordinatous.com.
172800 IN
ordinatous.com.
172800 IN
;; ADDITIONAL SECTION:
ns108.ovh.net.
15716
ns108.ovh.net.
15716
dns108.ovh.net.
15716
dns108.ovh.net.
15716
;;
;;
;;
;;
IN
IN
IN
IN
NS
NS
213.186.33.82
dns108.ovh.net.
ns108.ovh.net.
A
213.251.128.152
AAAA 01:41d0:1:1998::1
A
213.251.188.152
AAAA 2001:41d0:1:4a98::1
SERVER: 80.67.169.40#53(80.67.169.40)
WHEN: Sat Feb 06 15:03:05 CET 2016
MSG SIZE rcvd: 195
Avec unbound
;; Got answer:
;ordinatous.com.
IN
A
;; ANSWER SECTION:
ordinatous.com.
;;
;;
;;
;;
3600
IN
A
213.186.33.82
SERVER: 127.0.0.1#53(127.0.0.1)
WHEN: Sat Feb 06 15:04:26 CET 2016
MSG SIZE rcvd: 59
Le prochain coup il mettra 0 seconde...
Bonus
DNS de la French Data Network, ajoutez ceci à votre configuration
réseau, avec votre gestionnaire de connexion.
ns0.fdn.fr = 80.67.169.12 ou 2001:910:800 ::12
ns1.fdn.fr = 80.67.169.40 ou 2001:910:800 ::40
[email protected]
44/49
Ludovic MARCHAL
Formation : TSGERI
Session 2015/2016
Ou ceci dans le fichier de configuration de unbound :
forward-zone:
name: "."
References
ICANN
IETF
IANA
ISC
Unbound
calomel
[email protected]
45/49

DNS - ordinatous.com

Transcription

Documents pareils

Dominique Marchal: un destin d`exception - Rotary Verbier St

communiqué de presse

Compte rendu DNS

LIVRE DE RECETTE « LE FOIE GRAS DU PERIGORD SUBLIME

Guide DNS - Strass Syndicat du travail sexuel

Tapez votre courrier ici

DJ Spooky @ InfoLab

Imprimer - LICHNER Immobilier

Exercice DNS