La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 DNS (Domain Name System). 2 DNS Sommaire –introduction –arborescence –architecture –base de données –une implémentation du DNS : BIND –Outils / ZoneCheck.

Présentations similaires


Présentation au sujet: "1 DNS (Domain Name System). 2 DNS Sommaire –introduction –arborescence –architecture –base de données –une implémentation du DNS : BIND –Outils / ZoneCheck."— Transcription de la présentation:

1 1 DNS (Domain Name System)

2 2 DNS Sommaire –introduction –arborescence –architecture –base de données –une implémentation du DNS : BIND –Outils / ZoneCheck

3 3 Introduction (1) Besoin –nommer une machine sur le réseau en effectuant une correspondance entre le nom choisi et le numéro IP (résolution de nom) –trouver le nom d une machine à partir de son numéro IP (résolution inverse) –identifier un groupe de machines ayant des ressources réseau communes (relais de messagerie, …)

4 4 Introduction (2) Quelques exemples simples : –nom de domaine : afnic.asso.fr –nom de machine : ftp.afnic.asso.fr adresse ip –nom de machine : relay1.afnic.asso.fr adresse ip –nom de machine : adresse ip –nom de machine : adresse ip –adresse IP : Une information dans le DNS indique vers quelle machine diriger le courrier électronique : relay1.afnic.asso.fr adresse ip

5 5 Introduction (3) Jusquen 1984 : fichier hosts.txt => /etc/hosts –inadapté à grande échelle temps de diffusion des infos (par ftp !) système centralisé quelques centaines de machines dans les années 70 plusieurs millions aujourdhui –correspondance statique –ne contient que des infos réduites –noms enregistrés sous le domaine arpa => collision rapide de noms

6 6 Introduction (4) Après 1984 : Domain Name System Paul Mockapetris - RFC puis –système hiérarchisé et distribué modèle en arborescence (similaire à larborescence dun système de fichiers avec ses répertoires) gestion décentralisée des bases de données => chaque site est maître de ses données –informations complémentaires : relais de messagerie, … –correspondance dynamique –limite les risques de collisions de noms

7 7 Introduction (5) RFCs –1032, 1033, 1034, 1035, 1101, 1122, 1123, 1183, 1713, 1794, 1912, 1995, 1996, 2010, 2136, 2137, 2181, 2308, Documentation –http://www.dns.net/dnsrd/ (RFC, drafts, FAQ, …) –http://www.nic.fr/Guides/DNS.html –http://www.nic.fr/Formation/ Livres –DNS and BIND (Paul Albitz & Cricket Liu)

8 8 Arborescence (1) Organisation générale –le système est organisé sous la forme dune arborescence, composée par la racine ( root ), sommet de larbre, qui est notée par un point. des nœuds, identifiés par un label ( fr, com, …), dont les informations sont stockées dans une base de données propre à chacun des nœuds –base de données du système une base de données par nœud lensemble de ces bases de données constitue le système dinformation hiérarchique et distribué du DNS

9 9 Arborescence (2).. fr net arpa ripe whois in-addr com apnic nic www whois in-addr.arpa. 192 nom adresse IPadresse IP nom whois.ripe.net whois.ripe.net

10 10 Arborescence (3) Parcours de larbre et nom de domaine –la descente dans larbre est représentée de la droite vers la gauche –chaque niveau de larborescence est séparé par un point racine 1er niveau 2éme niveau nic.fr.séparateur

11 11 Arborescence (4).. fr net arpa ripe whois = whois.ripe.net in-addr = in-addr.arpa nic com tn ffti apnic

12 12 Arborescence (5) Délégation dun nœud père vers un nœud fils –un nœud peut être père de plusieurs nœuds fils –le lien est effectué en précisant au niveau du nœud père où trouver la base de donnée des nœuds fils –but distribuer la gestion de chaque nœud à des entités différentes => une base de données pour chaque nœud, lensemble de ces bases étant géré de façon décentralisé pour définir des domaines de responsabilités différentes

13 13 Arborescence (6) Dénomination des domaines –caractères autorisés A - Z a - z pas de différences entre majuscule et minuscule –nom total limité à 255 caractères –label est unique au niveau dun nœud –label au niveau d un nœud limité à 63 caractères

14 14 Arborescence (7) Notion de domaine et de zone –le domaine est lensemble dune sous arborescence exemple : le domaine fr. rassemble toute la sous arborescence à partir du nœud fr –la zone est la partie descriptive pour un niveau donné : elle est restreinte à un nœud => une zone est constituée de la base de données décrivant un nœud

15 15 Arborescence (8)

16 16 Arborescence (9) Résolution nom => numéro IP –le nom de machine est formé en ajoutant le label choisi suffixé avec. avec le domaine auquel cette machine appartient racine 1er niveau 2éme niveau ns1.nic.fr.séparateur label

17 17 Arborescence (10) Analogie un nœud contient à la fois des noms de machines et des sous domaines, comme, pour un système de fichiers, un répertoire contient des fichiers et des sous répertoires

18 18 Arborescence (11) Résolution inverse –retrouver à partir dun numéro IP le nom dune machine associée –larborescence se trouve sous le domaine in-addr.arpa (sous ip6.int pour ipv6) –larborescence est subdivisée à partir de la notation classique sur 4 octets des numéros IPv4

19 19 Arborescence (12) Parcours de larbre et résolution inverse –le nom de domaine est inversé par apport au numéro IP domaine : in-addr.arpa. pour le numéro IP : –la descente dans larbre est représentée de la droite vers la gauche –chaque niveau de larborescence est séparé par un point

20 20 Arborescence (13).. fr net arpa ripe whois = whois.ripe.net in-addr = in-addr.arpa nic com tn ffti

21 21 Arborescence (14) Le même mécanisme sapplique pour la sous arborescence in-addr.arpa comme pour les domaines « classiques » (nic.fr) : par exemple le domaine in-addr.arpa est un sous domaine du 193.in- addr.arpa, le nœud in-addr.arpa étant défini par sa base de données Tout numéro officiellement attribué à une machine doit être déclaré dans cette arborescence

22 22 Arborescence (15) Racine : environ 15 bases de données (serveurs de nom) répartis dans le monde connaissant tous les serveurs des domaines de 1er niveau (.fr.arpa.com … ) serveur origine géré par l IANA / ICANN A.ROOT-SERVERS.NET serveurs miroirs de B.ROOT-SERVERS.NET à M.ROOT-SERVERS.NET

23 23 Arborescence (16) Top-level domain (TLD) : Domaine de 1er niveau - RFC 1591 –à 2 lettres : code ISO-3166 de chaque pays –à 3 lettres :. com,. net,. org,. edu,. gov,. mil,.int –à 4 lettres :.arpa

24 24 Arborescence (17) Enregistrer un nom de domaine Network Solutions :. com,.net,.org –http://www.networksolutions.com APNIC : Asie Pacifique NIC –http://www.apnic.net IANA :.us (rfc 1480),.edu,.gouv (Etats-Unis), –http://www.isi.edu/in-notes/usdnr/ Une liste des autres NIC européens et mondiaux : –http://www.nic.fr/Guides/AutresNics/

25 25 Architecture (1) Système clients/serveurs –client resolver : interface cliente permettant dinterroger un serveur les machines clientes pointent généralement vers un serveur par défaut (/etc/resolv.conf sur Unix) –serveur chaque serveur gère sa propre base de données optimisation par des systèmes de cache et de réplication

26 26 Architecture (2) Au dessus d IP –service sexécutant sur le port 53 => droits de super utilisateur –UDP et TCP (TCP nest pas réservé quau transfert de zone et est utilisé si la taille de la réponse est supérieure à la limite d un paquet UDP de 512 octets) RFC 1035

27 27 Architecture (3) Fonctionnement du client : le resolver –permet de communiquer avec les serveurs DNS –2 modes dinterrogation récursif : le client envoie une requête à un serveur, ce dernier devant interroger tous les autres serveurs nécessaires pour renvoyer la réponse complète au client (mode utilisé par les machines clientes en général) itératif : le client envoie une requête à un serveur, ce dernier renvoyant la réponse si il la connaît, ou le nom dun autre serveur quil suppose plus renseigné pour résoudre cette question (mode utilisé par le resolver des serveurs en général)

28 28.serveur ? Architecture (4)resolver Machine A serveurresolver int. récursive ? frde. voir serveur fr : ns1.nic.fr frserveur ? nic.frinria.fr voir serveur inria.fr : dns.inria.fr int. itérative inria.frserveur ?

29 29 Architecture (5) Serveurs –types de serveurs serveur cache serveur –« faisant suivre » (forwarder) –« esclave » (slave - forwarder-only) serveur ayant autorité sur une (plusieurs) zone(s) –primaire (source des données) –secondaire (miroir des données)

30 30 Architecture (6) Serveur cache –éviter la surcharge inutile du réseau –supprimer les délais du réseau –amoindrir la charge des autres serveurs => tout serveur possède en général au minimum un cache

31 31 Architecture (7) Serveur cache –configuration minimale base de données nécessaire –adresses des serveurs de la racine –reverse du loopback in-addr.arpa les données du cache possèdent une durée de vie limitée Time To Live - ttl) afin de permettre son rafraîchissement et la prise en compte des modifications il senrichit au fur et à mesure par les données récoltées pour résoudre les requêtes des clients => une requête déjà demandée est résolue à partir du cache du serveur

32 32 Architecture (8)serveurresolver frde nic.frinria.fr..serveur frserveur nic.frserveur int. récursive int. itérative resolver host A ? cache

33 33 Architecture (9)resolver Machine A serveurresolver cache int. itérative inria.frserveur chronos.inria.fr ? inria.frserveur int. récursive chronos.inria.fr ?

34 34 Architecture (10) Serveur « faisant suivre » / esclave –ces types de serveurs possèdent une liste de serveurs à interroger (le serveur fait suivre la requête reçue vers dautres serveurs par une requête elle-même récursive) –« faisant suivre » –vérifie si la réponse n est pas dans son cache –sinon fait suivre à un des serveurs la requête –en cas déchec tente de résoudre lui même la demande => enrichissement rapide dun cache partagé (au sein d un organisme pour ne pas surcharger la liaison vers l extérieur)

35 35 Architecture (11) Serveur « faisant suivre » / esclave esclave –vérifie si la réponse n est pas dans son cache –sinon fait suivre à un des serveurs la requête –en cas d échec avec tous les serveurs, il renvoie un code derreur => enrichissement rapide d un cache partagé pour un serveur nayant pas daccès direct à tout lInternet

36 36 Architecture (12) Serveur ayant autorité sur une (plusieurs) zone(s) –serveur primaire le serveur primaire dune zone est la source des informations relatives à cette zone (il possède la base de donnée maître) il contient les informations à partir dun fichier de données où lon effectue les mises à jour. il a lorigine de lautorité (Start Of Authority - SOA) sur cette zone

37 37 Architecture (13) Serveur ayant autorité sur une (plusieurs) zone(s) –serveur secondaire c est un miroir sauvegardé sur disque de la base de données maître –fonction de sauvegarde –de répartition de charge et d accessibilité le serveur secondaire dune zone obtient les informations relatives à celle-ci automatiquement depuis un serveur primaire ou un autre secondaire il a également autorité sur cette zone

38 38 cacheserveurresolver Architecture (14)frde nic.frinria.fr..serveur frserveur nic.frserveur int. récursive int. itérative resolver host A ? => fr : ns1.nic.fr ? => inria.fr : dns.inria.fr ? disque auth

39 39 Architecture (15) Rafraîchissement des données entres serveurs ayant autorités sur une zone –DNS Change Notification (RFC 1996) après la prise en compte de modifications de la part du serveur primaire, ce dernier notifie les serveurs secondaires quune nouvelle version de la zone a été générée ce système de mise à jour ne peut se faire quentre un primaire et un secondaire accélère le rafraîchissement des données par rapport au système classique

40 40 Architecture (16) Rafraîchissement des données entres serveurs autoritaires –système classique un serveur secondaire dune zone interroge à intervalles réguliers le serveur primaire de cette zone pour voir si une modification a eu lieu. La fréquence est indiquée par le refresh défini dans le SOA ce type de mise à jour peut se faire entre un primaire et un secondaire ou entres secondaires

41 41 Architecture (17) Rafraîchissement des données entres serveurs autoritaires –la version d une zone est identifiée par son numéro de série ( serial ) ; à chaque modification celui-ci doit être augmenté –transfère de zone le serveur secondaire transfère dabord le SOA de la zone et vérifie si le numéro de série a augmenté si cest le cas toute la zone est transférée (transfère total - AXFR) ou seul les nouvelles modifications entre les 2 versions sont transférées (transfert incrémental - IXFR - RFC 1995)

42 42 Architecture (18) Rafraîchissement des données entres serveurs autoritaires –reprise en cas d échec en cas d échec de cette interrogation, le secondaire recommence toutes les retry secondes jusquà atteindre le temps dexpiration ( expire ), ces valeurs étant fixés également dans le SOA

43 43 Architecture (19) Remarques –un serveur peut être à la fois serveur cache et autoritaire pour des zones : le cache possède alors des informations locales et non locales –un serveur peut être à la fois primaire pour des zones et secondaire pour dautres zones

44 44 Architecture (20) Remarques –mode de fonctionnement dun serveur récursif –le serveur résout les requêtes récursives des clients et garde les informations obtenues dans son cache => le cache stocke des informations pour lesquelles le serveur n a pas autorité –serveurs cache de campus par exemple

45 45 Architecture (21) Remarques –mode de fonctionnement dun serveur itératif –il répond toujours en fonction des données quil possède localement => ne construit pas de cache pour des données non locales (serveurs de la racine) => une machine cliente (dutilisateur final) ne doit jamais pointer sur un serveur de ce type comme serveur par défaut –mode permettant de limiter la charge dun serveur (il ne résout pas toute la requête) => serveurs de la racine, serveurs ayant autorités pour un grand nombre de zones

46 46 Architecture (22) A –NSI USA B ISI USC USA C PSI USA D UNIV. MARYLAND E NASA USA F ISC USA G DOD NIC USA H Army Resarch Lab USA I NORDUSUEDE J NSIUSA K RIPE NCCLINX UK L ISI USA M Wide Project JAPON

47 47 FME D J K I L B A CGH

48 48

49 49 Base de données (1) Fichier de configuration du serveur Fichier des serveurs de la racine Un fichier par zone décrivant son contenu –au moins le fichier du reverse loopback in-addr.arpa

50 50 Base de données (2) Fichier de configuration –localisation des données fichier serveurs de la racine fichiers de zone –déclaration de lautorité sur des zones primaire / secondaire –mode de fonctionnement général récursif/itératif « faisant suivre », esclave,....

51 51 Base de données (3) Fichier des serveurs de la racine –permet de démarrer la résolution d une requête si le serveur na aucune information –contient la liste des serveurs de nom et leur numéro IP –primaire : A.ROOT-SERVERS.NET. –une quinzaine de serveurs secondaires à travers le monde –peut être générer de la façon suivante : ns > root.cache

52 52 Base de données (4) Fichier de zone –contient les données propre à chaque zone –consiste en une liste de Ressource Records (RR) –le premier RR doit être le SOA (Start of Authorithy) qui décrit lautorité technique de la zone –directives spéciales

53 53 Base de données (5) Directives spéciales –$ORIGIN spécifie le nom de domaine à jouter à des enregistrements non pleinement qualifies (non suffixé par un point) syntaxe : $ORIGIN [ ]

54 54 Base de données (6) Directives spéciales –$ORIGIN - exemple $ORIGIN exemple. $ORIGIN mon-domaine www IN CNAME serveur => équivalent à : www. mon-domaine.exemple. IN CNAME serveur. mon-domaine.exemple. Par défaut $ORIGIN est positionné au nom du domaine que le fichier de zone décrit

55 55 Base de données (7) Directives spéciales –$INCLUDE permet dinclure un fichier dans le fichier de zone syntaxe : $INCLUDE [ ] [ ] Si nest pas spécifié la valeur courante est utilisée

56 56 Base de données (8) Directives spéciales –$TTL (RFC bind 8.2) spécifie le Time To Live par défaut à appliquer aux enregistrements qui nont pas ce paramètre de spécifié dans leur déclaration syntaxe : $TTL [ ] valeur [ ]

57 57 Base de données (9) Directives spéciales –$TTL en règle générale lors de modification d une ressource importante il faut abaisser cette valeur (à quelques minutes) ttl+refresh (spécifié dans le SOA) AVANT la modification pour que celle-ci se propage rapidement

58 58 Base de données (10) t1 : date de labaissement du ttl de la ressouce t2 : date de la modification de la ressource elle- même temps t1t2 ttl + refresh

59 59 Base de données (11) Structure d un RR - RFC 1034 [ ] [ ] [ ] : nom de l enregistrement auquel vont sappliquer les : utilise la veleur courante de $ORIGIN comme nom : durée de vie, en secondes, de lenregistrement dans les caches : groupe dappartenance - IN pour Internet : type de lenregistrement : données associées au type

60 60 Base de données (12) Principaux RR - SOA (Start Of Autority) caractéristiques techniques de la zone : zoneINSOAprimaire. .( serial refresh retry expire ttl)

61 61 Base de données (13) Principaux RR - SOA contact technique de la zone remplacer par le premier point non protégé (\) l doit être suivi d un point francis\.dupont.inria.fr. pour

62 62 Base de données (14) Principaux RR - SOA numéro de série : spécifie la version des données de la zone incrémenter ce numéro à chaque modification (entier sur 32 bits) format conseillé : YYYYMMDDxx

63 63 Base de données (15) Principaux RR - SOA refresh : intervalle, en secondes, entre 2 vérifications du numéro de série par les secondaires (24H ; à ajuster si la zone est souvent modifiée) retry : intervalle en seconde entre 2 vérifications du numéro de série par les secondaires si la 1ére vérification a échouée (6H ; à ajuster en fonction de sa connectivité) expire : durée d expiration de la zone sur un secondaire (41 jours ) retry<

64 64 Base de données (16) Principaux RR - SOA ttl (time to live) - RFC Negative caching spécifie le TTL pour le « negative caching », soit le temps que doit rester dans les caches une réponse négative suite à une question sur ce domaine (valeur recommandé de 1 à 3 heure). Il existe 2 types de réponses négatives : NXDOMAIN : aucun enregistrements ayant le nom demandé dans la classe (IN) nexiste dans cette zone NODATA : aucune donnée pour le triplet (nom, type, classe) demandé existe ; il existe dautre enregistrements possédant ce nom, mais de type différent

65 65 Base de données (17) Principaux RR - NS (Name Server) indique un serveur de nom pour le nom spécifié (ce nom devient une zone dont la délégation est donnée au serveur en partie droite) zoneINNSserveur-nom1.domaine. INNSserveur-nom2.domaine. Il faut spécifier les serveurs de noms de la zone que l on décrit (associée au SOA)

66 66 Base de données (18) $ORIGIN nic.fr. hostmaster.nic.fr. ( ;serial 86400;refresh 21600;retry ;expire 3600; negative caching ttl ) INNSns1.nic.fr. INNSns2.nic.fr. wwwIN CNAMEns2.nic.fr ftp 21600INA

67 67 Base de données (19) Principaux RR - A (Adresse IPv4) indique l adresse IP associée à un nom machine.domaine.INA A6 :Adresse IPv6

68 68 Base de données (20) Principaux RR - PTR (Pointeur) indique le nom associé à un numéro IP dans l arborescence in-addr.arpa (ip6.int) in-addr.arpa.INPTRmachine.domaine.

69 69 Base de données (21) Principaux RR - CNAME (Canonical Name) indique que le nom est un alias vers un autre nom (le nom canonique) aliasINCNAMEnom.canonique. Nota –un nom en partie droite dun enregistrement ( ) ne doit pas pointer vers un alias –quand un nom a déjà un CNAME il est interdit de faire figurer dautres enregistrements pour ce nom

70 70 Base de données (22) Principaux RR - CNAME (Canonical Name) - faux zone.INMX10alias.zone. alias.zone.INCNAMErelais.zone. zone.INNSalias.zone. alias.zone.INCNAMEserveur.zone. zone.INSOA…….(…..) zone.INCNAMEwww.zone.

71 71 Base de données (23) Principaux RR - CNAME (Canonical Name) - correct zone.INMX10relais.zone. relais.zone.INA alias2.zone.INCNAMEalias1.zone. alias1.zone.INCNAMEcanonical.zone. zone.INSOA…….(…..) zone.INA Et l enregistrement PTR correspondant dans les reverses

72 72 Base de données (24) Fichier de zone pour nic.fr $ORIGIN nic.fr. ( ;serial 86400;refresh 21600;retry ;expire 3600;negative ttl ) INNSns1.nic.fr. INNSns2.nic.fr. ; Suite ns1INA ns2INA machineINA wwwINCNAMEmachine localhostINA

73 73 Base de données (25) Fichier du reverse in-addr.arpa –personne na la responsabilité de ce reverse pour le numéro dans la hiérarchie in-addr.arpa. –le système lutilise pour la résolution de requête vers lui-même => si on ne le configure pas sur le serveur cette requête peut échouer : root serveur contacté mal configuré => code erreur renvoie autre chose que localhost

74 74 Base de données (26) Fichier de zone pour in-addr.arpa in-addr.arpaINSOAns1.nic.fr.hostmaster.nic.fr. ( ;serial 86400;refresh 21600;retry ;expire 3600;negative ttl ) INNSns1.nic.fr in-addr.arpa.INPTRlocalhost.nic.fr.

75 75 DNS et SMTP (1) Principaux RR - MX (Mail eXchanger) à On cherche dans le DNS un MX indiquant la machine sur laquelle il faut envoyer le courrier pour nom. Un paramètre précise le poids relatif de l enregistrement MX : si plusieurs MX existent, le courrier est envoyé en 1er à la machine ayant le poids le plus bas, puis dans l ordre croissant des poids en cas d'échec nomINMX10nom.relais1. INMX20nom.relais2. INMX30nom.relais3.

76 76 DNS et SMTP (2) Principaux RR - MX (Mail eXchanger) Envoi d un message à nom - RFC (1) trie les MX par ordre croissant et contact les machines dans cet ordre ; si une connexion est établie => transfert ; sinon mail mis en file dattente - (2) transfert sur nom.relais1 : le mail est traité localement - (3) transfert sur lune des autres machines: on trie de nouveau les MX en supprimant les entrées de préférence supérieure on égale à celle associée à cette machine ; si la liste est vide => erreur de configuration ; sinon on tente de contacter les machines de la même manière quen (1)

77 77 DNS et SMTP (3) Principaux RR - MX (Mail eXchanger) –wilcard MX nic.fr.INMX10 relais.nic.fr. *.nic.fr.INMX10 relais.nic.fr. => associe le MX à tout nom inconnu dans le domaine, il nest utilisé quen labsence de tout autre RR associé à un nom. Exemple : nom.nic.fr.INAIP => pas de MX hérité des wilcards pour nom => associer systématiquement un MX à chaque fois que l on définit un A RR et éviter les wilcards

78 78 DNS et SMTP (4) Principaux RR - MX (Mail eXchanger) Si il n y a pas de MX associé à nom : SMTP utilise l adresse IP associé à ce nom (A RR) nomINAIP si il n y a pas de RR, SMTP utilise les enregistrement wildcard MX si il n y a pas de wildcard MX => erreur

79 79 Délégation et sous domaine (1) faire figurer la délégation dans la zone parente => il sagit denregistrement NS zone parente $TTL86400 nic.fr.INSOAns1.nic.fr.hostmaster.nic.fr. ( ;serial 86400;refresh 21600;retry ;expire 3600;negative ttl) INNSns1.nic.fr. INNSns2.nic.fr. ns1.nic.fr.INA ns2.nic.fr.INA fille.nic.fr.INNSns1.inria.fr. INNSns.urec.fr.

80 80 Délégation et sous domaine (2) zone déléguée $ORIGINfille.nic.fr. ( ;serial 86400;refresh 21600;retry ;expire 3600;negative ttl) INNSns1.inria.fr. INNSns.urec.fr.

81 81 Délégation et sous domaine (3) Utilisation de la glue –permet détablir des liens nom => IP avec les sous zones pour la cohérence de l arbre DNS –elle nest nécessaire dans le cas ou les serveurs de la zone fille sont dans la même arborescence que le domaine fille.domaine. –en cas de changement d adresse IP il faut modifier la zone fille et la zone parente

82 82 Délégation et sous domaine (4) dans le fichier de zone nic.fr fille.nic.fr.INNSns1.fille.nic.fr. INNSns.urec.fr. ns1.fille.nic.fr.INA dans le fichier de zone fille.nic.fr fille.nic.fr.INSOAns1.inria.fr.hostmaster.inria.fr. ( ;serial 86400;refresh 21600;retry ;expire 3600;negative ttl) INNSns1.fille.nic.fr. INNSns.urec.fr. ns1.fille.nic.fr.INA

83 83 BIND (1) Historique –JEEVES : première implémentation du DNS par Paul Mockapetris (1984) –BIND (The Berkeley Internet Name Domain) implémentation suivante sur système 4.3BSD UNIX par Kevin Dunlap Aujourdhui –BIND maintenu par Paul Vixie avec l Internet Software Consortium

84 84 BIND (2) Deux parties –la partie serveur de noms : implémentée par la commande named (ou in.named) et named-xfer (ou in.named-xfer) pour les transfert de zone –la partie client : bibliothèque C (libresolv.a ou libresolv.so.x) avec laquelle sont liées toutes les applications utilisant le DNS. Cette bibliothèque contient notamment une version de gethostbyname (3) et gethostbyaddr (3) qui utilisent le DNS.

85 85 BIND (3) Développé par lInternet Software Consortium –http://www.isc.org/ –http://www.isc.org/bind.html Sources disponibles –ftp://ftp.isc.org/isc/src/cur (version courante) –ftp://ftp.isc.org/isc/src/testing (version en développement) –ftp://ftp.nic.fr/pub/programmes/DNS/ News –comp.protocols.dns.bind –comp.protocols.dns.ops –comp.protocols.dns.std

86 86 BIND (4) Versions –4.9.7 dernière version de la série 4.x fichier de configuration named.boot – P5 implémentation des derniers RFCs –Dynamic Updates - RFC 2136 –Change Notification par défaut - RFC 1996 –IXFR - RFC 1995 (expérimental) –Secure DNS - RFC dnskeygen –$TTL - RFC 2308 nouveau format du fichier de configuration named.conf transfert de zone plus performant (format many-answers) pas de libresolv partagée ; la librairie statique sappelle libbind.a

87 87 BIND - serveur cache (5) Version 4 - fichier de config named.boot ; répertoire des données directory/usr/local/bind/data cache.root.cache ; primairezonefichier primary in-addr.arpadb.localrev

88 88 BIND - serveur cache (6) Version 8 - fichier de config named.conf // répertoire des données options { directory «/usr/local/bind/data»; }; // cache des serveurs de la racine zone «.» in { type hint; file «root.cache»; }; // zone primaire du reverse loopback zone « in-addr.arpa» { type master; file «db.localrev»; };

89 89 BIND - serveur cache esclave (7) Version 4 - fichier de config named.boot ; serveur cache esclave ; répertoire des données directory/usr/local/bind/data cache.root.cache ; primairezonefichier primary in-addr.arpadb.localrev ; on fait tout suivre forwarders ; ou slave pour version < options forward-only

90 90 BIND - serveur cache esclave(8) Version 8 - fichier de config named.conf options { directory «/usr/local/bind/data»; // répertoire des données // on fait tout suivre forwarders { ; }; options forward-only ; }; zone «.» {// cache des serveurs de la racine type hint ; file «root.cache»; }; zone « in-addr.arpa» { type master; file «db.localrev »; };

91 91 BIND - serveur autoritaire et cache (9) Version 4 - fichier de config named.boot ; serveur ayant autorité et cache directory/usr/local/bind/data cache.root.cache ; primairezonefichier primary in-addr.arpadb.localrev primarynic.frdb.nic.fr primary in-addr.arpadb.nic-rev ; secondairezoneip serv authfichier secondaryinria.fr db.inria.fr

92 92 BIND - serveur autoritaire et cache (10) Version 8 - fichier de config named.conf options { directory «/usr/local/bind/data»; // répertoire des données }; zone «.» {// cache des serveurs de la racine type hint; file «root.cache»; }; zone « in-addr.arpa» {// zone primaire type master; file «db.localrev»; };

93 93 BIND - serveur autoritaire et cache (11) Version 8 - fichier de config named.conf - suite zone «nic.fr» {// zone primaire type master; file «db.nic.fr»; }; zone « in-addr.arpa» {// zone primaire type master; file «db.nic-rev»; }; zone «inria.fr» { // zone secondaire type slave; file «db.inria.fr»; masters { ; }; };

94 94 BIND - serveur autoritaire (12) Version 4 - fichier de config named.boot ; serveur ayant autorité et iteratif directory/usr/local/bind/data cache.root.cache ; primairezonefichier primary in-addr.arpadb.localrev primarynic.frdb.nic.fr primary in-addr.arpadb.nic-rev ; non recursif options no-recursion

95 95 BIND - serveur autoritaire (13) Version 8 - fichier de config named.conf options { directory «/usr/local/bind/data»; recursion no;// non récursif }; zone «.» { type hint; file «root.cache»; }; zone « in-addr.arpa» { type master; file «db.localrev»; };

96 96 BIND - serveur autoritaire (14) Version 8 - fichier de config named.conf - suite zone «nic.fr» { type master; file «db.nic.fr»; }; zone « in-addr.arpa» { type master; file « db.nic-rev»; };

97 97 BIND (15) - Version 8 générer named.conf à partir de named.boot – outil de conversion bin/named/named-bootconf.pl –exemple de fichier named.conf bin/named/named.conf

98 98 BIND (16) Relancer le serveur –kill -HUP pid Debugger –Dump du contenu du cache => kill -INT pid le résultat est dans un fichier named_dump.db –Passage en mode debug avec trace dans le fichier named.run => kill -USR1 pid chaque nouvelle utilisation de cette commande augmente le niveau de début arrêt de ce mode => kill -USR2 pid

99 99 Outils Dans le package BIND –nslookup –dig (domain information groper) –host –h2n (convertit un fichier /etc/hosts en fichiers de zone) –checksoa Ripe –ftp://ftp.ripe.net/tools/dns/host.tar.Z A. Romão : Tools for DNS debugging –ftp://ftp.ripe.net/rfc/rfc1713.txt NIC France –http://www.nic.fr/ZoneCheck/

100 100 Pièges à éviter (1) –La durée refresh est dau moins une heure, –La durée retry est dau moins une heure, –la durée expire est dau moins une semaine et est très supérieur à la durée refresh, –la durée TTL est dau moins une heure pour les enregistrements SOA et NS pour une zone stable –la durée du negative TTL doit être inférieure à 7 jours –Le numéro de série de la zone est cohérent sur chacun des Name Server.

101 101 Pièges à éviter (2) –Problème avec les Name Server NS not reachable, NS not set up –Domaine pas complètement nommé (oublie du point final) $ORIGIN in-addr.arpa. 1 PTR ns1.nic.fr est résolue comme : 1 PTR ns1.nic.fr in-addr.arpa –La zone nest pas installée sur les Name Server annoncés dans la zone parente.

102 102 Zone Check (1) Disponible à lURL suivant : –http://www.nic.fr/ZoneCheck Les sources sont disponibles à lURL suivant : –http://www.nic.fr/ZoneCheck/sources.html

103 103 Zone Check (2) Utilisation de cet outil qui vérifie la validité de linstallation dun nom de domaine. –renseigner le nom de la zone ou directement le n° du ticket attribué au nom de domaine. –renseigner la méthode pour obtenir les infos concernants ce nom de domaine. Formulaire libre : remplir à la main les différents noms des serveurs de noms et les adresse IP si nécessaire. DNS pour zone existante (dns) : récupère automatiquement les noms des serveurs de noms pour la zone.

104 104 Zone Check (3) Le lancement de la vérification, plusieurs choix : –Inclure les messages daide, Affiche des messages supplémentaires lors derreurs. –Vérifier la base RIPE, Test lexistence des enregistrement inetnum et route dans la base RIPE. –Vérifier lenvoi de courrier électronique au zone-contact, Vérifie lexistence des adresses électroniques des responsables de la zone. –Vérifier le contenu de la zone, Vérifie la validité de la zone sur les Name Server. –avec des icônes, –le nom du serveur whois. Permet de changer le nom du serveur whois, par défaut est whois- ripe.nic.fr

105 105 Zone Check (4) Vérification de la connexion TCP : –ping sur le port 53 du serveur de nom. Vérification de la zone sur le serveur : Vérification de la liste de NS présente sur ce serveur Vérification de la liste des serveurs de noms de la racine connus de ce serveur : Vérification de lenregistrement SOA de in-addr.arpa : Vérification de lenregistrement SOA de fr

106 106 Zone Check (5) Vérification des mappings inverses du n° IP de chaque Name Server : Vérification des mappings inverses de de chaque Name Server : Test des checksums UDP : –Validité des paquets UDP –Recompiler le noyau pour SUN/OS après avoir modifié le fichier : /usr/kvm/sys/netinet/in_proto.c, et changer la ligne : int udp_cksum = 0; /* turn off to check & generate udp checksums */ en int udp_cksum = 1; /* turn on to check & generate udp checksums */

107 107 Zone Check (6) Vérification de lenregistrement inetnum dans la base RIPE : Vérification de lenregistrement route dans la base RIPE : Vérification de ladresse IP des autres serveurs de la zone :

108 108 Zone Check (7) Vérification de lenregistrement SOA. –vérification des RR : SERIAL PRIMARY CONTACT REFRESH RETRY EXPIRE TTL

109 109 Zone Check (8) Vérification des MX Record pour le nom de domaine. Vérification des adresses de courrier électronique –Tout relais de messagerie SMTP doit implémenter la commande VRFY conformément aux RFCs aujourdhui en vigueur; voir entre autre le RFC 1123 paragraphe (VRFY and EXPN commands) et les rappels dans les RFCs 1425, 1651, 1869.


Télécharger ppt "1 DNS (Domain Name System). 2 DNS Sommaire –introduction –arborescence –architecture –base de données –une implémentation du DNS : BIND –Outils / ZoneCheck."

Présentations similaires


Annonces Google