LYCEE FRANCO-MEXICAIN HOMERO 1521 COLONIA POLANCO 11560 MEXICO ; D.F.

LYCEE FRANCO-MEXICAIN HOMERO 1521 COLONIA POLANCO 11560 MEXICO D.F.

INTRODUCTION... 3 PRÉSENTATION... 3 STRUCTURE DES NOMS DE DOMAINES... 3 Structure hiérarchique... 3 Structure distribuée... 4 UNE BASE DE DONNÉES DISTRIBUÉE ET DISPONIBLE... 4 LA GESTION ET SA DÉLÉGATION... 4 EXEMPLE.... 5 PRIMAIRE ET SECONDAIRES... 6 RÉSOLUTION INVERSE... 6 CACHE... 7 ORDRE DE RÉSOLUTION... 7 MODES RÉCURSIF ET ITÉRATIFS... 7 Définition... 7 Usage... 7 GESTION D UN DOMAINE CONTENANT DES SOUS-DOMAINES... 8 Présentation... 8 Conclusion... 8 MISE EN PLACE D UN SERVEUR DNS... 9 ENREGISTREMENTS D'UN SERVEUR DE NOM... 9 LES SERVEURS DNS DISPONIBLES.... 10 BIND 4... 11 Fonctionnement... 11 Configuration... 11 Dépannage... 12 ETUDE DE CAS : LE SERVEUR DNS DU LYCÉE DIDEROT... 13 PRÉSENTATION... 13 NAMED.BOOT... 13 DB.ZONEINFO... 13 DB.INADDR... 14 INT.LOCALZONE... 14 INT.INADDR... 14 DB.127.0.0... 15 DB.CACHE... 15 Page 2/15

Introduction Présentation Le rôle du DNS : Domain Name Server ou Serveur de Noms de Domaine est de maintenir une table de correspondance entre les adresses IP et les noms de domaine. En effet, il est plus facile de retenir un nom de domaine qu'une adresse IP. Par exemple, lorsque quelqu un accède à www.vije.net, cela veut dire qu il accède à l ordinateur electroniques d alias www, appartenant au domaine vije.net. Le serveur de nom de domaine (DNS ou Domain Name Server) a alors pour rôle de d informer que : www est un alias de electroniques sur le domaine vije.net, pdc.diderot.org réside à l adresse 200.53.114.42. Structure des noms de domaines La gestion des noms de domaine est réalisée par une immense base de données distribuée à travers le monde. La syntaxe des noms de domaine adopte une structure hiérarchique distribuée. Structure hiérarchique La racine est désignée par le ".". En dessous se trouvent les TLD : Top Level Domains : TLD décrivant des types : com : entreprises commerciales, org : organisations non commerciales, net : organisations touchant au réseau, edu : monde éducatif, gov : structures gouvernementales américaine, TLD décrivant des états (2 lettres) : fr : organismes francais, uk : organismes anglais,, Recherche inverse : arpa : domaine réservé à la résolution de nom inversée (reverse lookup : IP nom complet). Certains pays gèrent des sous-domaines (.com.fr, co.uk, ). La racine et les TLD les plus répandus sont gérés par un organisme mondial l'internic (.,.com,.org,.net,.edu,.gov, ), puis viennent les organismes délégués : NIC France (.fr), NIC Angleterre (.uk), Page 3/15

Structure distribuée Ensuite, les nœuds ou noms de domaines sont gérés par les organismes concernés, propriétaires et responsables administratifs (société louant le nom, ou société de services responsable technique). Enfin, les nœuds et/ou noms de plus bas niveau sont des noms de sous-domaines et de machines : www, mail, ftp, perso, w3 Ce système de distribution permet de répartir la charge sur de multiples serveurs. Par exemple, dans messagerie.scola.ac-paris.fr : fr est le TLD, Internic renvoie la gestion à NIC-France, ac-paris.fr est le domaine Internet de l académie de Paris, enregistré chez NIC-France (il s agit d un nom complet de domaine : Fully Qualified Domain Name), scola est le sous-domaine pédagogique de ac-paris.fr messagerie est le serveur de courrier (nom réel ou alias?) du sous-domaine : scola.ac-paris.fr. Une base de données distribuée et disponible La gestion et sa délégation Ce système fonctionne par délégation de la gestion et donc des responsabilités administratives de zones. Chaque domaine ou sous-domaine est respectivement responsable de ses sous-domaines ou "sous-sous-domaines". Exemple : NIC France est responsable des domaines en.fr. Le Rectorat de Paris achète alors le domaine ac-paris.fr et en est responsable. Ensuite il affecte par exemple au département de la scolarité le nom scola.ac-paris.fr, et peut aussi lui déléguer la gestion et la responsbilité de ses sous-domaines et serveurs. Le département de la scolarité peut créer des sous-domaines (ex : admin.scola.ac-paris.fr) puis placer des serveurs (ex : priv.admin.scola.ac-paris.fr ou encore w3.scola.ac-paris.fr), et gérer lui-même son serveur de noms. L'ensemble des nœuds composant les noms de (sous-)domaines et de serveurs existants forment un gigantesque arbre d'au maximum 127 niveaux, heureusement seuls quelques niveaux sont généralement utilisés. Il ne peut exister deux adresses identiques au niveau mondial, car la gestion est centralisée pour chaque domaine (com, fr, ). Un nœud ne peut excéder 63 caractères, et ne différencie pas minuscules et majuscules. Le caractère "_" ne peut être utilisé. Le terme de zone désigne un nœud et tous les nœuds en aval gérés par le même serveur de nom NS : Name Server. Exemple : la zone vije.net contient tout ce qui se termine par vije.net (nom de domaine de qui vous savez). Mais une zone ne contient que les informations non déléguées. En contrepartie, un serveur de nom NS peut gérer plusieurs zones. Page 4/15

Exemple. Lorsque un utilisateur d un client HTTP tape le nom w3.scola.ac-paris.fr, il s'agit du serveur se nommant w3 (nom réel ou alias), géré par le département de la scolarité de l'académie de Paris, enregistré auprès de NIC France. Or, le navigateur client ne peut charger des pages WEB html qu'à partir de l'instant où il connaît l'adresse IP du serveur w3 concerné, visible sur l'internet (adresse IP enregistrée et unique, tout comme les noms de domaine), même s il les récupère parfois finalement du serveur proxy d un FAI ou ISP. Les étapes parcourues par la recherche de nom (name lookup) sont les suivantes : Le client va par exemple s'adresser au DNS (devenant le "resolver") de son fournisseur d'accès Internet (FAI ou ISP : Internet Service Provider), afin d'obtenir l'adresse IP souhaitée. En supposant que le DNS du FAI ne connaît pas les adresses IP requises, c'est à dire qu'elles ne sont pas ou plus stockée dans son cache mémorisant les adresses les plus demandées, ce dernier va demander aux serveurs racine de l'internic, gérant la racine ".", l'adresse du serveur gérant les.fr Ensuite il va demander au DNS gérant le domaine racine.fr (NIC France) l'adresse IP du serveur gérant le nom de domaine ac-paris.fr Puis il va demander au DNS gérant ac-paris.fr (serveur de l'académie de PARIS) l'adresse IP du serveur gérant les noms scola.ac-paris.fr Si le même serveur de l'académie gère directement tous les sous-domaines de ac-paris.fr, il renverra directement l'adresse IP du serveur www, sinon, il se peut qu'il faille interroger une DNS gérée par la scolarité (scola.ac-paris.fr) pour obtenir l'adresse IP du serveur w3. Enfin le FAI stockera entre autres l'adresse IP de www.scola.ac-paris.fr dans son cache DNS puis l'enverra au client. Le client peut alors consulter la serveur de pages html w3.scola.ac-paris.fr Une variante est la possibilité pour le client d opérer lui-même cette recherche, à condition d installer sur sa machine le logiciel adéquat. En fait, les DNS de l'internet possèdent des tampons ou caches mémorisant les adresses IP des nom les plus fréquemment utilisées (associées à une durée de vie), ce qui allège le nombre d'opérations à effectuer et le trafic mondial. De plus, si un serveur de nom doit faire une résolution d'adresse dans le domaine auquel il appartient, il n'aura pas à remonter jusqu'à la racine ".", il contactera un ou plusieurs serveurs de noms du même domaine jusqu'à obtention de la résolution de nom. Page 5/15

Primaire et secondaires Une zone est gérée généralement par plusieurs serveurs de noms : un serveur de noms primaire et plusieurs serveurs de noms secondaires. Le serveur primaire d'une zone est le seul au monde à avoir autorité sur cette zone. Mais la liste des serveurs primaire et secondaires est normalement déclarée chez Internic. Ainsi, la défaillance d'un des serveurs n'empêche pas la résolution du nom en adresse IP. Les serveurs de noms secondaires synchronisent régulièrement leurs enregistrements sur le serveur primaire. Primaire et secondaires donnent des réponses autoritaires sur la zone (authoritative answers). Un serveur peut être à la fois primaire pour certaines zones et secondaire pour d'autres. Un société possédant plusieurs serveurs de noms a tout intérêt à repartir les zones gérées entre les différents serveurs chaque serveur est le primaire d'un ensemble de zone et un secondaire pour l'ensemble des autres zone (ex : chez les FAI). Cela allège la charge des serveurs et optimise les échanges d'enregistrements. Résolution inverse Une résolution inverse est nécessaire pour la résolution d'adresse nom. Cela est réalisé par le domaine in-addr.arpa qui contient de manière récursive jusqu à 3 fois 256 sous-domaines (sur 1 à 3 niveaux, selon la classe IP est l autorité gérant l IP résolue) : ((z).y).x.in-addr.arpa, et le niveau suivant (le dernier) contient les résolutions adresses IP nom. La recherche va se faire de droite à gauche, et l'enregistrement DNS inversé doit contenir l'adresse inversé. La recherche inverse permet d identifier un site, et généralement de le localiser (domaines relatifs à des pays :.fr,.uk, ). Cela permet par exemple d offrir des services en excluant certains pays. Exemple : le chargement de logiciels intégrant un système de cryptage 128 bits (IE, Comunicator, )peut être interdit vers certains pays, idem pour le fameux logiciel de cryptage PGP, Exemple : résolution de l adresse 193.148.37.212 La zone inverse est 212.37.148.193.in-addr.arpa. La résolution va traverser les étapes suivantes : In-addr.arpa 193.in-addr.arpa 148.193.in-addr.arpa 37.148.193.in-addr.arpa serveur de noms racine a.root-server.net, serveur de noms NS.RIPE.NET (consortium gérant des administration nationales), serveur de noms NS.RIPE.NET, serveur de noms first.tvt.fr qui gère les noms du réseau de classe C 193.148.37, Remarque : la résolution inverse s arrête lorsque le serveur responsable du réseau logique concerné est atteint, c'est donc sur lui que doit être configuré la résolution inverse, à moins que cela soit délégué à une DNS gérant un sous réseau logique ou une adresse unique! Rien ne sert de configurer la résolution inverse sur votre serveur DNS, s'il n'est pas le responsable administratif de votre(vos) adresse(s) IP, dans ce cas il faut s'adresser au responsable administratif et lui demander gentiment s'il est disposé à le faire pour votre(vos) couple(s) : adresse IP fixe - nom de domaine/machine. Page 6/15

Cache Un cache dynamique est maintenu par les serveurs DNS, conservant les résolutions de nom de domaine ->IP effectuées, avec une durée de vie fournie par les serveurs DNS concernés. Cela permet de diminuer la charge due aux résolution de noms sur le réseau mondial (World Wide Web : WWW), et d accélérer la résolution de nom (diminution du temps de réponse à une requête, non authoritative answers). Ordre de résolution L ordre de résolution des noms pour un client diverge d un système à l autre. Sous Unix, l ordre de résolution est spécifié dans le fichier /etc/hosts.conf. Le fichier local statique hosts peut être consulté avant ou après la requète DNS. Le client NIS (pages jaunes YP) peut aussi intervenir d ans l ordre de recherche (map hosts.byname centralisée). Sous Windows, le fichier %SYSTEMROOT%\SYSTEM32\DRIVER\ETC\HOSTS est consulté avant la DNS. Cela est aussi configurable dans la base de registre. Modes récursif et itératifs Définition En mode récursif, le serveur DNS interrogé prend en charge la suite de la résolution (il effectue lui même le travail de résolution, et peut à son tour le faire de manière récursive ou itérative) Il renverra au client DNS (qui peut être un serveur DNS) la résolution complète du nom sujet de la requête. En mode itératif, le client DNS (qui peut être un serveur DNS) prend en charge les appels successifs aux serveurs DNS se succédant dans la résolution d un nom. Certains serveurs de noms refusent les requêtes récursives. Il s agit principalement des serveurs root ou de premier niveau (cf fichier db.cache) très sollicités, et qui s effondreraient s il devaient eux-même effectuer intégralement toutes les résolutions. Ces derniers se contentent de renvoyer les clients vers les serveurs responsables des TLD. Usage Les clients finaux, c est à dire les postent utilisateurs, sont généralement de simples clients DNS (ils n intègrent pas de serveur DNS). Lorsqu ils veulent résoudre un nom, ils le soumettent au(x) serveur(s) DNS dont la liste leur a été fournie (soit lors de leur configuration statique, soit par un serveur DHCP). Ce serveur s occupe d effectuer lui-même la résolution (en mode récursif ou itératif). Les serveurs DNS (interrogés par leurs clients, dont eux-mêmes) fonctionnent en mode récursif ou itératif. Ils fonctionnent généralement en mode itératif pour les gros serveurs (ceux des fournisseurs d accès Internet, des sociétés possédant un réseau logique complet, ). Les serveurs DNS plus petits fonctionnent au choix dans l un ou autre des deux modes. Le mode récursif (forward) peut généralement être utilisé si le serveur DNS est client d un plus gros serveur DNS, appartenant à un FAI, ou serveur de domaine dédié dans un grosse société. Un serveur DNS derrière un pare-feu nécessite aussi généralement le mode récursif. Page 7/15

Gestion d un domaine contenant des sous-domaines Présentation Un domaine peut contenir à la fois des hôtes et des sous-domaines. Ces sous-domaines peuvent contenir à leur tour des hôtes et des sous domaines Méthodes : il existe trois méthodes pour mettre en place cette structure dans une entreprise. Serveur DNS global La première consiste à placer sur un serveur les fichiers pour les résolution de l ensemble des domaines et sous-domaines. Méthode : tout définir localement (un jeu de fichier par domaine, sous-domaine, ) Serveur DNS primaire du domaine et secondaire des sous-domaines. La seconde utilise un serveur DNS maître(primaire) pour le domaine et esclave(secondaire) pour les sous-domaines, qui sont alors chacun gérés par un serveur DNS propre. Le serveur principal du domaine se déclare secondaire pour les sous-domaines, et leur associe éventuellement (recommandé) chacun un fichier local pour stocker leurs définitions mises à jour régulièrement (refresh time). Méthode : déclarer le serveur primaire comme serveur secondaire de tous les sous-domaines (fichier named.boot) Les serveurs de sous-domaines fonctionneront en mode itératif ou récursif Serveur DNS primaire renvoyant sur les serveurs primaires des sous-domaines La troisième solution consiste à définir dans la zone du domaine les serveurs primaires pour chaque sous-domaine, ainsi que leurs adresses IP. Méthode : intégrer à la zone du domaine une définition de serveur de nom par sous-domaine, puis une définition d hôte pour chaque serveur de nom de sous-domaine (tout cela se fait dans le fichier de définition de zone avec IN NS puis IN A (ou IN CNAME)) Les serveurs de sous-domaines fonctionneront généralement en mode itératif Conclusion Ces trois méthodes peuvent être mixées en fonction de la taille des sous-domaine et de l architecture de l ensemble (présence de pare-feu, routeurs, ). En effet, le serveur DNS du domaine peut gérer localement des sous-domaines, être secondaire d autres sous-domaines, et enfin renvoyer sur un troisième ensemble de sous-domaine les requêtes les concernant! Ce raisonnement vaut ainsi pour le domaine, ses sous-domaines, soussous-domaines (peu conseillé), Les indications précédentes sur le mode de résolution (itératif ou récursif) ne comportent aucun caractère obligatoire. Il semble néanmoins logique que dans le dernier cas, le serveur de sous-domaine s assumant intégralement (puisqu il reçoit et traite lui-même les requêtes, externes au domaine, le concernant), il puisse s occuper seul de la résolution de nom pour ses hôtes (mode itératif). Dans le second cas, selon la taille des serveurs DNS des sous-domaines, ainsi que selon leur mode d accès à Internet (direct ou non, ), ces derniers préféreront le mode itératif ou bien le mode récursif. Cependant, s ils fonctionnent tous en mode récursif, le serveur DNS du domaine se verra affecter le travail de résolution pour l ensemble des hôtes directs du domaine mais aussi des sousdomaines, ce qui le chargera bien davantage! Page 8/15

Mise en place d un serveur DNS Enregistrements d'un serveur de nom Un fichier de démarrage spécifie au serveur de nom les zones où il est primaire (primary) et celles où il est secondaire (secondary), ainsi que la zone de cache (cache, contenant les serveurs racines), et les IPs des DNS du FAI (forwarders). Dans les trois premiers cas, un fichier est indiqué, qui contient les enregistrements nécessaires. Donc, un fichier contenant différents enregistrements est affecté à chaque zone. Les enregistrements d'un serveur de nom sont les suivants : Enregistrement SOA NS A PTR CNAME MX p HINFO TXT WINS Signification autorité administrative liste des serveurs de nom pour ce domaine correspondance nom adresse correspondance adresse nom alias serveurs de courrier et leur priorité p (une valeur inférieure est prioritaire) pour utiliser un nom de domaine pour les emails (email@domaine.tld au lieu de email@serveur.domaine.tld) description machine (entre guillemets) texte (entre guillemets) lien avec un serveur de nom Internet Windows WINS : DNS->WINS L enregistrement SOA nécessite quelques paramètres : Le nom de domaine sur lequel le serveur a autorité, ainsi que l email de l administrateur, Le numéro de série au format AAMMJJXX, Le taux de rafraîchissement des DNS esclaves (secondaires, en secondes), Le nombre de tentatives de rafraîchissement en cas d échec, Le temps d expiration des données des secondaires, La durée de vie de l information dans le cache des clients (Time To Live TTL). Exemple : @ IN SOA pdc.diderot.org. hostmaster.diderot.org. ( 990408 serial number 21600 refresh every 6 hours 3600 retry after 1 hours 604800 expire after 1 weeks 86400) default ttl is 1 days Page 9/15

Enfin, la syntaxe est telle que : @ signifie l adresse du serveur une ligne débutant par un blanc signifie la même adresse que précédement, un nom terminé par un point est absolu, un nom sans point est relatif à la zone. Des fichiers exemples à étudier terminent ce document Les logiciels de serveurs DNS disponibles. Le serveur DNS le plus répandu est celui de l Université de Berkeley : BIND. Ce serveur est la seul référence en matière de compatibilité et de performance. De plus, son implémentation est relativement simple, et n utilise pas d interface graphique. Microsoft Windows NT contient son serveur DNS, mais il pose des problèmes de mise à jour et de délais de réponse. L installation de BIND produit des fichiers de base contenant tous les commentaires explicatifs et exemples nécessaire à la compréhension de leur écriture et à la constitution d un ensemble cohérent. Il existe deux versions de BIND : la 4.x.y qui est statique (pour Unix et NT), et la 8.x.y qui est dynamique (pour Unix). Nous allons donc étudier la 4. Page 10/15

Bind 4 Fonctionnement Le serveur named.exe est piloté par ndc.exe, dont les commandes les plus utilisée sont : Status : état du service, Reload : rechargement des tables, Stop : arrêt du service, Restart : redémarrage du service, Autres commandes : dumpdb, stats, trace, notrace, quierylog. La commande peut être suivie du nom de serveur (\\nom_de_serveur sous windows). Configuration Un fichier named.conf contient des informations concernant le fonctionnement du serveur DNS. La description qui suit concerne Bind 4. Bind 8 possède une syntaxe légèrement différente pour named.conf, mais cependant très proche et compréhensible (cf www.berkeley.org). Le fichier contient les entrées suivantes : directory : répertoire contenant les fichiers de zones check-names : cela permet de configurer le comportement du serveur DNS face aux noms non valides (par exemple contenant un «_»). primary, secondary, et response décrivent respectivement les serveurs primaire, secondaire et les réponses à des requêtes auprès de serveurs DNS distants fail signifie qu aucun nom invalide ne peut être chargé de ou par le serveur warn les noms invalides sont traités mais aussi consignés dans un fichier journal ignore les noms invalides sont traités de manière transparente primary : zone ou le serveur fait office de serveur DNS primaire, suivit du nom du fichier décrivant la zone secondary : zone ou le serveur fait office de serveur DNS secondaire, suivit de l adresse IP du serveur primaire, puis (éventuellement) du nom du fichier stockant localement une image de la zone forwarders : serveurs DNS auxquels transmettre les requêtes de résolution de nom (mode récursif) (utile si le serveur DNS local se trouve derrière un pare-feu, et ne peut librement accéder aux serveurs de noms peuplant et décrivant le réseau mondial) options : suit la ligne forwarders pour décrire le mode de résolution (non nécessaire, dans ce cas, seules les requêtes concernant la zone locale sont résolues localement) forward-only : mode forward seulement cache : directive de cache de zone, suivit de la zone puis du fichier donnant la liste des serveurs fournissants les information. La zone root «.» doit toujours être cachée (cache. db.cache), la liste des serveurs root doit être mise à jour régulièrement sur Internet à l adresse : ftp.rs.internet.net, avec le fichier /domain/named.root (automatique avec la directive hint sous Bind 8). XFRNETS : filtre d adresses IP autorisées à lire les informations des zones gérées par le serveur DNS (par adresses réseaux) Page 11/15

Dépannage Ce serveur est livré avec les commandes de dépannage suivantes : nslookup.exe, dig.exe et ipaddr.exe. Commandes de nslookup : Cet utilitaire permet principalement d interroger un serveur DNS précis, concernant des enregistrements, pour un domaine donné. NAME - print info about the host/domain NAME using default server NAME1 NAME2 - as above, but use NAME2 as server help or? - print info on common commands see nslookup(1) for details set OPTION - set an option all - print options, current server and host [no]debug - print debugging information [no]d2 - print exhaustive debugging information [no]defname - append domain name to each query [no]recurse - ask for recursive answer to query [no]vc -- always use a virtual circuit domain=name - set default domain name to NAME srchlist=n1[/n2/.../n6] - set domain to N1 and search list to N1,N2, etc. root=name - set root server to NAME retry=x - set number of retries to X timeout=x - set initial time-out interval to X seconds querytype=x - set query type, e.g., A,ANY,CNAME,HINFO,MX,PX,NS,PTR,SOA,TXT,WKS,SRV,NAPTR port=x - set port number to send query on type=x - synonym for querytype class=x - set query class to one of IN (Internet), CHAOS, HESIOD or ANY server NAME - set default server to NAME, using current default server lserver NAME - set default server to NAME, using initial server finger [USER] - finger the optional USER at the current default host root - set current default server to the root ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to FILE) -a - list canonical names and aliases -h - list HINFO (CPU type and operating system) -s - list well-known services -d - list all records -t TYPE - list records of the given type (e.g., A,CNAME,MX, etc.) view FILE - sort an 'ls' output file and view it with more exit - exit the program, ^D also exits Page 12/15

Etude de cas : le serveur DNS du Lycée Diderot. Présentation Le serveur DNS du Lycée Diderot pilote deux domaines : diderot.org (externe) et intranet (interne). Il n y a pas de DNS secondaire, cependant, les serveurs DNS d une société externe se synchronisent en permanence sur cette DNS unique du Lycée Diderot concernant le domaine diderot.org. Ce sont ces DNS externes qui sont enregistrées comme primaire et secondaires auprès d internic. named.boot Voir description précédente du fichier named.boot Notre serveur résout tout lui-même, et joue le rôle de maitre (primaire) pour le domaine Internet diderot.org et le domaine intranet intranet. directory C:\\Progra~1\\bind primary 0.0.127.IN-ADDR.ARPA db.127.0.0 primary diderot.org db.zoneinfo primary intranet int.zoneinfo primary 9.113.198.212.in-addr.arpa db.inaddr primary 10.in-addr.arpa int.inaddr cache. db.cache db.zoneinfo Description du domaine Internet diderot.org. @ IN SOA pdc.diderot.org. hostmaster.diderot.org. ( 990408 serial number 21600 refresh every 6 hours 3600 retry after 1 hours 604800 expire after 1 weeks 86400) default ttl is 1 days IN NS pdc.diderot.org. localhost IN A 127.0.0.1 diderot.org. IN A 212.198.113.9 pdc IN A 212.198.113.9 IN MX 0 mail.diderot.org. mail IN CNAME pdc.diderot.org. www IN CNAME pdc.diderot.org. ftp IN CNAME pdc.diderot.org. Page 13/15

db.inaddr Résolution inverse pour 212.198.113.9 -> pdc.diderot.org. En fait la résolution inverse ne sera jamais traitée localement, car si la Lyonnaise Câble nous a attribué une IP fixe, c est elle qui est enregistrée chez Internic comme responsabl e de notre IP fixe. Il faut donc lui demander d enregistrer cette résolution inverse dans sa DNS. @ IN SOA pdc.diderot.org. hostmaster.diderot.org. ( 951213 serial number 43200 refresh every 12 hours 7200 retry after 2 hours 1209600 expire after 2 weeks 172800) default ttl is 2 days IN NS pdc.diderot.org. IN PTR pdc.diderot.org. int.zoneinfo Description du domaine intranet intranet. @ IN SOA pdc.intranet. hostmaster.intranet. ( 990408 serial number 21600 refresh every 6 hours 3600 retry after 1 hours 604800 expire after 1 weeks 86400) default ttl is 1 days IN NS pdc.intranet. localhost IN A 127.0.0.1 intranet. IN A 10.10.10.10 pdc IN A 10.10.10.10 web IN CNAME pdc int.inaddr Résolution inverse pour 10.10.10.10 -> pdc.intranet. @ IN SOA pdc.intranet. hostmaster.intranet. ( 951213 serial number 43200 refresh every 12 hours 7200 retry after 2 hours 1209600 expire after 2 weeks 172800) default ttl is 2 days IN NS pdc.intranet. IN PTR pdc.intranet. Page 14/15

db.127.0.0 Résolution pour le nom localhost -> 127.0.0.1, c est à dire le client lui-même. @ IN SOA pdc.diderot.org. hostmaster.diderot.org. ( 951213 serial number 43200 refresh every 12 hours 7200 retry after 2 hours 1209600 expire after 2 weeks 172800) default ttl is 2 days IN NS pdc.diderot.org. 1 IN PTR localhost.diderot.org. db.cache Fichier pour le cache root (obligatoire pour les DNS résolvant sur Internet). Ce fichier est à mettre à jour régulièrement sur Internet à l adresse : ftp.rs.internet.net, avec le fichier /domain/named.root. formerly NS.INTERNIC.NET. 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 formerly NS1.ISI.EDU. 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 formerly C.PSI.NET. 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 formerly TERP.UMD.EDU. 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 formerly NS.NASA.GOV. 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 formerly NS.ISC.ORG. 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 formerly NS.NIC.DDN.MIL. 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 formerly AOS.ARL.ARMY.MIL. 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 formerly NIC.NORDU.NET. 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 Page 15/15