Vous êtes sur la page 1sur 620

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et BIND

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Cricket LIU et Paul ALBITZ

DNS et BIND
5e dition

Traduction de Giles Carr

ditions OREILLY 18 rue Sguier 75006 Paris FRANCE france@oreilly.com http://www.oreilly.fr

Cambridge Cologne Farnham Paris Pkin Sebastopol Taipei Tokyo

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Ldition originale de ce livre a t publie aux tats-Unis par OReilly Media, Inc., sous le titre DNS and BIND, 5th Edition, ISBN 0-596-10057-4. 2006 OReilly Media, Inc.

Couverture conue par Edie FREEDMAN et Marcia FRIEDMAN

dition : Dominique Buraud Relecture : Franois Cerbelle

Retrouvez galement la version papier sur notre site :

http://www.oreilly.fr/catalogue/9782841774098

Les programmes gurant dans ce livre ont pour but dillustrer les sujets traits. Il nest donn aucune garantie quant leur fonctionnement une fois compils, assembls ou interprts dans le cadre dune utilisation professionnelle ou commerciale.

DITIONS OREILLY, Paris, 2006

ISBN 2-35402-122-4

Toute reprsentation ou reproduction, intgrale ou partielle, faite sans le consentement de lauteur, de ses ayants droit, ou ayants cause, est illicite (loi du 11 mars 1957, alina 1er de larticle 40). Cette reprsentation ou reproduction, par quelque procd que ce soit, constituerait une contrefaon sanctionne par les articles 425 et suivants du Code pnal. La loi du 11 mars 1957 autorise uniquement, aux termes des alinas 2 et 3 de larticle 41, les copies ou reproductions strictement rserves lusage priv du copiste et non destines une utilisation collective dune part et, dautre part, les analyses et les courtes citations dans un but dexemple et dillustration.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Table des matires

Prface ...................................................................................................xi 1. Contexte .......................................................................................... 1


Petit historique de lInternet ..............................................................................1 Internet et internet..............................................................................................2 Systme de noms de domaine ............................................................................4 Historique de BIND ............................................................................................9 Alternative au DNS ? ..........................................................................................9

2.

Principes du DNS ......................................................................... 11


Espace de noms ..................................................................................................11 Espace de noms du domaine Internet .............................................................17 Dlgation dautorit.........................................................................................20 Serveurs de noms et zones ................................................................................21 Resolvers .............................................................................................................25 Rsolution de noms...........................................................................................26 Mmoire cache...................................................................................................32

3.

Premiers pas dans la mise en uvre........................................... 35


Tlcharger BIND ..............................................................................................35 Choisir le nom de domaine ..............................................................................39

4.

Mise en uvre de BIND ............................................................... 49


Notre zone ctive ..............................................................................................49 Initialiser les donnes de zone..........................................................................51 Initialiser le chier de conguration de BIND ...............................................62

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

vi

Table des matires Abrviations .......................................................................................................64 Tester les noms dhtes ......................................................................................68 Outils ..................................................................................................................70 Dmarrer un serveur primaire .........................................................................71 Dmarrer un serveur-esclave ............................................................................77 Grer plusieurs zones ........................................................................................83 Et maintenant ? .................................................................................................84

5.

DNS et courrier lectronique....................................................... 85


Enregistrements MX ..........................................................................................86 La messagerie lUniversit du Cinma..........................................................88 changeurs de messages ....................................................................................88 Algorithme des MX............................................................................................90 DNS et authentication du courrier................................................................92

6.

Prparation des clients................................................................. 95


Le resolver ..........................................................................................................95 Congurer le resolver........................................................................................96 Exemples de conguration de resolver ..........................................................105 Minimiser les contraintes................................................................................107 Fichiers complmentaires de conguration ..................................................111 Le resolver de Windows XP.............................................................................112

7.

Exploitation de BIND................................................................. 119


Piloter le serveur de noms ..............................................................................119 Mettre jour les chiers de zone ...................................................................128 Organiser les chiers .......................................................................................134 Emplacement des chiers ...............................................................................138 Messages gnrs par BIND............................................................................138 Le secret de la russite .....................................................................................148

8.

Expansion de domaine ............................................................... 167


Choisir le nombre de serveurs........................................................................167 Ajouter des serveurs ........................................................................................174 Enregistrer des serveurs...................................................................................178 Ajuster les valeurs de TTL ...............................................................................180 Anticiper les pannes ........................................................................................183 Traiter les pannes .............................................................................................186

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Table des matires

vii

9.

Gestion de sous-domaines .......................................................... 189


Crer des sous-domaines .................................................................................190 Nombre de sous-domaines..............................................................................190 Nom des sous-domaines..................................................................................191 Devenir parent .................................................................................................192 Sous-domaines de in-addr.arpa .......................................................................201 Lien correct de parent....................................................................................206 Grer la transition vers des sous-domaines ...................................................209 Cycle de vie dun parent .................................................................................211

10. Fonctionnalits avances ........................................................... 213


Liste dadresses et ACL ....................................................................................213 Mise jour dynamique ...................................................................................214 DNS NOTIFY (annonce de modication).....................................................221 Transfert incrmental de zone (IXFR)............................................................225 Redirection (forwarding) 229 Vues...................................................................................................................232 Rpartition de charge par tourniquet ............................................................235 Classement dadresses par un serveur ............................................................238 Serveurs de noms prfrentiels sur certains rseaux.....................................239 Serveur de noms itratif ..................................................................................240 liminer les serveurs dfectueux....................................................................241 Paramtrer le systme......................................................................................242 Compatibilit ...................................................................................................250 Les bases de ladressage IPv6 ...........................................................................251 Adresses et ports...............................................................................................252

11. Scurit........................................................................................ 265


TSIG ..................................................................................................................266 Scuriser un serveur ........................................................................................270 DNS et pare-feu................................................................................................282 Extensions de scurit du DNS.......................................................................302

12. nslookup et dig............................................................................ 329


Prsentation de nslookup ...............................................................................329 Interactivit ......................................................................................................331 Jeu doptions ....................................................................................................331 Dsactiver la liste de recherche.......................................................................334

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

viii

Table des matires Manipulations de base ....................................................................................334 Utilisation avance...........................................................................................337 Problmes avec nslookup................................................................................344 La cerise sur le gteau......................................................................................348 Utiliser dig ........................................................................................................348

13. Interprtation des informations de dbogage de BIND ........... 353


Niveaux de dbogage ......................................................................................353 Lancer le dbogage ..........................................................................................356 Lire les messages de dbogage ........................................................................357 Algorithme de recherche dun resolver et mmoire cache ngative (BIND 8)................................................................................................368 Algorithme de recherche dun resolver et mmoire cache ngative (BIND 9)................................................................................................369 Outil de conversion dadresses........................................................................370

14. Dpannage du DNS et de BIND ................................................ 371


Problme de DNS ou de NIS ? .......................................................................371 Techniques et outils de dpannage.................................................................372 tudes de cas.....................................................................................................383 Problmes de transition ..................................................................................400 Problmes dinteroprabilit et de version ...................................................401 Erreurs TSIG.....................................................................................................404 Guide de dpannage........................................................................................405

15. Programmation avec les bibliothques du service de noms..... 411


Programmation en shell avec nslookup ........................................................411 Programmation en C avec les fonctions de la bibliothque du resolver.............................................................................................417 Programmation en Perl avec Net::DNS.........................................................442

16. Architecture ................................................................................ 447


Infrastructure DNS externe faisant autorit..................................................448 Infrastructure de redirection ..........................................................................451 Infrastructure DNS interne ............................................................................453 Tches ................................................................................................................454 Surveiller les volutions du DNS et de BIND ...............................................455

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Table des matires

ix

17. Divers .......................................................................................... 457


Utiliser les enregistrements CNAME.............................................................457 Mta-caractres.................................................................................................461 Limites des enregistrements MX ....................................................................462 Connexions commutes..................................................................................463 Nom et adresse de rseau................................................................................467 Enregistrements de ressource complmentaires ...........................................468 ENUM...............................................................................................................473 Internationalisation des noms de domaine...................................................476 DNS et WINS...................................................................................................478 DNS, Windows et Active Directory................................................................480

A. Format des messages et des enregistrements de ressource du DNS........................................................................................ 487 B. C. Compatibilit des versions de BIND ......................................... 507 Compilation et installation de BIND dans Linux..................... 509

D. Domaines de niveau suprieur.................................................. 513 E. Conguration dun serveur de noms et dun resolver BIND ... 523

Index................................................................................................... 563

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Prface

Mme en tant nophyte au sujet du systme de noms de domaine (Domain Name System, DNS), ds que lon utilise lInternet, on y a recours ; on en dpend chaque fois que lon envoie un courrier lectronique ou que lon surfe sur le World Wide Web. Alors que les tres humains prfrent retenir des noms dordinateurs, les ordinateurs prfrent se dsigner entre eux par un nombre. Dans un rseau internet, ce nombre a une longueur de 32 bits soit environ une valeur comprise entre 0 et 4 milliards1. Les ordinateurs peuvent facilement stocker ces adresses numriques en mmoire, ce qui nest pas le cas pour un humain. Prenez dix numros de tlphone au hasard dans lannuaire et essayez de les mmoriser. Pas facile ! Maintenant, associez au hasard chaque numro de tlphone un indicatif gographique. Mmorisez nouveau le tout. Cela donne une ide de la difcult de mmoriser dix adresses internet quelconques. Cest en partie pour cette raison que le systme de noms de domaine est indispensable. Le DNS gre les correspondances entre les noms dhte, pratiques pour les humains, et les adresses internet que manipulent les ordinateurs. En fait, le DNS est le mcanisme standard de lInternet pour la diffusion et laccs toutes sortes dinformations concernant les adresses et les htes eux-mmes. Le DNS est utilis par quasiment tous les logiciels rseau, dont le courrier lectronique, les programmes de terminal distant comme ssh, les programmes de transfert de chiers comme ftp et les navigateurs web comme Microsoft Internet Explorer. Une autre caractristique importante du DNS est quil rend disponibles des informations sur les htes partout sur lInternet. Le stockage dinformations concernant les htes dans un chier structur localis sur une machine spcique nest utile quaux utilisateurs de cette machine. Le DNS fournit un moyen daccder ces informations distance, o que lon soit dans le rseau.

1.

Avec IPv6, il aura une longueur de 128 bits, soit une valeur comprise entre 0 et un nombre dcimal 39 chiffres.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

xii

Prface

De plus, le DNS permet de distribuer la gestion des informations concernant les htes vers plusieurs sites et organisations. Il nest pas ncessaire de fournir de donnes un site central, ni de rcuprer rgulirement des copies de la base de donnes matre . On sassure simplement que sa propre partie, appele zone, est jour sur ses propres serveurs de noms. Ces derniers rendent les donnes de la zone disponibles tous les autres serveurs de noms du rseau. Puisque la base de donnes est distribue, le systme doit galement pouvoir puiser les donnes recherches dans divers endroits. Le systme de noms de domaine fournit aux serveurs de noms lintelligence ncessaire pour naviguer travers la base de donnes et retrouver les donnes de toute zone. Bien sr, le DNS a aussi ses problmes. Par exemple, le systme permet plusieurs serveurs de stocker les donnes dune mme zone, par souci de redondance, mais des incohrences peuvent survenir entre les diffrentes copies des donnes. Mais le pire est que, malgr son utilisation universelle sur lInternet, la documentation sur la gestion et la maintenance du DNS est vraiment trs succincte. Beaucoup dadministrateurs ne travaillent quavec les informations fournies par les vendeurs et celles glanes dans les listes de diffusion de lInternet ou les forums de Usenet. Ce manque de documentation rvle que la comprhension dun service aussi fondamental pour lInternet daujourdhui ne repose que sur sa transmission dadministrateur administrateur comme un trsor de famille, ou sur un dfrichage rpt par chaque programmeur ou ingnieur. Les nouveaux administrateurs de zone se heurtent souvent aux mmes erreurs que leurs ans ! Cet ouvrage vise contribuer rsoudre cette situation. Bien sr, chacun na peut-tre pas lambition de devenir un expert du DNS, du fait des nombreuses tches accomplir, autres que la gestion dune zone ou dun serveur de noms : administration des systmes, ingnierie rseau ou dveloppement de logiciel. Seule une institution de taille importante peut se permettre daffecter une personne temps plein pour le DNS. Nous essaierons de fournir les informations utiles, que ce soit pour la gestion dune petite zone ou dune multinationale tentaculaire, un unique serveur de noms ou une centaine dentre eux. Pour lheure, il nest pas ncessaire de faire une lecture exhaustive de louvrage mais plutt une lecture cible en fonction des besoins. Le DNS est un vaste sujet, sufsamment large pour requrir deux auteurs, mais nous avons essay de le prsenter aussi nement et clairement que possible. Les deux premiers chapitres sont un prambule thorique et fournissent assez dinformations pratiques pour dmarrer. Les chapitres suivants approfondissent les diffrentes questions. Plus loin se trouve une description dtaille pour cheminer dans louvrage, au gr du travail et de lintrt de chacun. Lorsque nous parlerons des logiciels actuels de DNS, nous nous concentrerons presque exclusivement sur BIND (Berkeley Internet Name Domain), mise en uvre du DNS la plus rpandue (et celle que nous connaissons le mieux). Nous avons tent dmailler cet ouvrage de notre exprience en matire de gestion et de maintenance de zones avec BIND (lune de ces zones comptait parmi les plus vastes de lInternet lpoque). Lorsque cela est possible, nous avons inclus les programmes rels que nous utilisons pour la gestion, la plupart dentre eux tant rcrits en Perl pour la vitesse et lefcacit.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Versions

xiii

Nous esprons que ce livre sera une bonne prise de contact avec le DNS et BIND pour les dbutants, un moyen dafner la comprhension pour ceux qui en sont familiers, et un clairage et une exprience apprciables pour ceux qui les connaissent dj comme le fond de leur poche.

Versions
La cinquime dition de ce livre traite des nouvelles versions 9.3.2 et 8.4.7 de BIND mais aussi des anciennes versions 8 et 9. Les versions 9.3.2 et 8.4.7 sont les plus rcentes au moment o nous crivons, mais elles sont encore peu intgres dans les distributions commerciales dUnix, dune part parce quelles sont rcentes, dautre part parce que de nombreux diteurs sont sur leurs gardes ds quil sagit dutiliser des nouveaux logiciels. Nous ferons galement rfrence dautres versions de BIND car de nombreux diteurs continuent les utiliser au sein de leurs produits Unix. Chaque fois quune caractristique nest disponible que dans une des versions 8.4.7 ou 9.3.2, ou quil y a une diffrence de comportement entre les versions, nous essaierons de la caractriser. Nous utilisons nslookup, un utilitaire pour serveurs de noms, pice matresse dans nos exemples. La version utilise est celle fournie avec le code de BIND 9.3.2. Les versions plus anciennes disposent de la plupart des caractristiques de nslookup 9.3.2 (mais pas de toutes). Dans nos exemples, nous avons essay dutiliser des commandes communes la plupart des nslookup ; quand cela nest pas possible, nous lindiquons.

Nouveauts de la cinquime dition


Tout en exposant les nouveauts de BIND, nous avons prot de cette cinquime dition pour approfondir plusieurs sujets :

SPF (Sender Policy Framework), au Chapitre 5 ; mise jour dynamique et NOTIFY, et tude dtaille de la mise jour dynamique
signe et du nouveau mcanisme de BIND 9, update-policy, au Chapitre 10 ;

transfert incrmental de zone, galement au Chapitre 10 ; zones rediriges ( forward zones) et redirection conditionnelle, au Chapitre 10 ; redirection et rsolution inverse en IPv6 laide, respectivement, des enregistrements de ressource AAAA et de ip6.arpa, en n de Chapitre 10 ;

signature de transaction, TSIG, un nouveau procd dauthentication des transactions, au Chapitre 11 ;

scurisation des serveurs de noms, au Chapitre 11 ; fonctionnement avec pare-feu Internet, au Chapitre 11 ; rvision des extensions de scurit (DNS Security Extensions ou DNSSECbis), procd
de signature numrique sur les donnes dune zone, au Chapitre 11 ;

conception dune architecture DNS complte pour une entreprise au Chapitre 16,
un chapitre nouveau ;

ENUM, qui met en correspondance les numros de tlphone conformes la norme


E.164 avec les URI, au Chapitre 17 ;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

xiv

Prface

internationalisation des noms de domaine (Internationalized Domain Names ou IDN),


une norme pour lutilisation des caractres Unicode dans les noms de domaine; au Chapitre 17 ;

mise en relation dActive Directory et de BIND, au Chapitre 17, dans une section
entirement revue.

Organisation de louvrage
Cet ouvrage est structur, autant que possible, de manire suivre lvolution dune zone et de son administrateur. Les chapitres 2 et 3 prsentent la thorie du systme de noms de domaine. Les chapitres 4 7 guident dans les choix de conguration dune zone, puis dans sa mise en uvre. Les chapitres intermdiaires, 8 12, dcrivent comment entretenir une zone, congurer les htes pour utiliser des serveurs de noms, grer la croissance dune zone, crer des sous-domaines et scuriser les serveurs de noms. Les derniers chapitres, 13 15, traitent des outils dintervention, des problmes, ainsi que de lart de la programmation avec les procdures de la bibliothque du resolver. Le chapitre 16 lie lensemble au sein dune architecture complte. Voici une description plus dtaille, chapitre par chapitre : Chapitre 1, Contexte Aprs un rappel historique, il expose les raisons qui ont men au dveloppement du DNS, puis prsente la thorie du DNS. Chapitre 2, Principes du DNS Il approfondit les aspects thoriques du DNS en abordant lorganisation de lespace de noms du DNS, les domaines, les zones et les serveurs de noms. Nous introduisons galement des concepts importants comme la rsolution de noms et la mmoire cache. Chapitre 3, Premiers pas dans la mise en uvre Il indique comment obtenir le logiciel BIND, envisager la conguration de son domaine et choisir son nom, et comment contacter lorganisation qui peut dlguer la gestion de la zone. Chapitre 4, Mise en uvre de BIND Il dtaille la manire dinitialiser ses deux premiers serveurs de noms avec BIND, en crant la base de donnes, dmarrant les serveurs et testant leur fonctionnement. Chapitre 5, DNS et courrier lectronique Il traite des enregistrements MX du DNS, qui permettent aux administrateurs de dsigner des htes alternatifs pour grer le courrier vers une destination donne. Ce chapitre couvre les stratgies de routage du courrier pour une grande diversit de rseaux et dhtes, y compris pour des rseaux avec pare-feu de scurit et htes sans connectivit directe lInternet. Enn, il dcrit SPF (Sender Policy Framework), qui utilise le DNS pour autoriser les serveurs de messagerie expdier des courriers partir dadresses spciques.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Organisation de louvrage

xv

Chapitre 6, Prparation des clients Il explique comment congurer un resolver BIND. Nous avons ajout des indications sur les particularits des resolvers de Windows. Chapitre 7, Exploitation de BIND Il dcrit la gestion dune zone que doit effectuer un administrateur, comme le test de ltat et de lautorit des serveurs de noms. Chapitre 8, Expansion de domaine Il traite de lvolution dune zone : croissance, planication des migrations et interruptions. Chapitre 9, Gestion de sous-domaines Il prsente les joies de devenir une zone-parent. Nous y expliquons quand devenir un parent (cest--dire quand crer un sous-domaine) et comment appeler, crer et surveiller les enfants. Chapitre 10, Fonctionnalits avances Il traite des options de conguration moins courantes pouvant aider ajuster les performances dun serveur de noms et faciliter son administration. Chapitre 11, Scurit Il dcrit comment scuriser un serveur de noms et comment le faire fonctionner avec un pare-feu internet. Il dcrit aussi deux nouvelles fonctions de scurit : les extensions de scurit du DNS et la signature de transaction. Chapitre 12, nslookup et dig Il prsente les outils de dbogage du DNS les plus rpandus, ainsi que des techniques daccs aux informations situes dans les serveurs de noms distants. Chapitre 13, Interprtation des informations de dbogage de BIND Il est la Pierre de Rosette des informations de dbogage de BIND. Ce chapitre devrait vous aider donner un sens aux informations de dbogage mises par BIND et mieux comprendre un serveur de noms. Chapitre 14, Dpannage du DNS et de BIND Il aborde de nombreux problmes usuels du DNS et de BIND, ainsi que leurs solutions, puis dcrit des cas plus rares, difciles diagnostiquer. Chapitre 15, Programmation avec les bibliothques du service de noms Il montre comment utiliser les procdures du resolver de BIND pour interroger les serveurs de noms et rcuprer les informations par un programme en C ou en Perl. Nous prsentons un programme utile (nous lesprons !) pour tester ltat et lautorit dun serveur de noms. Chapitre 16, Architecture Il prsente une infrastructure DNS complte, comprenant des serveurs de noms externes, des redirecteurs et des serveurs de noms internes.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

xvi

Prface

Chapitre 17, Divers Il regroupe tous les autres petits dtails. Nous y abordons les mta-caractres, les htes et les rseaux connects lInternet de faon intermittente par rseau tlphonique commut, le codage dun nom, des types denregistrement supplmentaires, ENUM, IDN et Active Directory. Annexe A, Format des messages et des enregistrements de ressource du DNS Elle dcrit, octet par octet, les formats utiliss dans les requtes et les rponses, ainsi quune liste des types denregistrements de ressource actuellement dnis. Annexe B, Compatibilit des versions de BIND Elle rsume les principales caractristiques de BIND, version par version. Annexe C, Compilation et installation de BIND dans Linux Elle dcrit pas pas les oprations de compilation de la version 9.3.2 de BIND dans Linux. Annexe D, Domaines de niveau suprieur Elle numre les domaines de niveau suprieur actuels (top-level domains) de lespace de noms de lInternet. Annexe E, Configuration dun serveur de noms et dun resolver BIND Elle rsume la syntaxe et la smantique des paramtres utilisables pour congurer un serveur de noms et un resolver.

Notre public
Cet ouvrage est tout dabord destin aux administrateurs systme qui grent une zone et un ou plusieurs serveurs de noms, mais il comporte galement des informations pour les ingnieurs rseaux ou pour les gestionnaires de messagerie. Tous les chapitres ne sont peut-tre pas intressants au mme degr, et vous navez peut-tre pas envie de le parcourir jusquau chapitre 17 pour y trouver ce qui vous concerne. Nous esprons que la description suivante vous aidera mieux vous reprer : Administrateurs systme initialisant leur premire zone Il devraient lire les chapitres 1 et 2 pour la thorie du DNS, le chapitre 3 pour les instructions de dmarrage et le choix judicieux dun nom de domaine, puis les chapitres 4 et 5 pour apprendre congurer une premire zone. Le chapitre 6 explique comment prparer un hte pour utiliser les nouveaux serveurs de noms. Ultrieurement, ils pourraient lire le chapitre 7 qui explique comment tendre leur mise en uvre de zone par le dmarrage de serveurs de noms supplmentaires et par lajout de donnes. Enn, les chapitres 12 14 dcrivent des outils et des techniques dintervention. Administrateurs systme expriments Ils trouveront un intrt au chapitre 6 pour tudier la mise en uvre dun resolver sur des htes diffrents et au chapitre 7 pour les informations sur la maintenance de leur zone. Le chapitre 8 contient des instructions sur la planication de lextension et lvolution dune zone, ce qui est particulirement intressant pour un

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Tlchargement des exemples

xvii

administrateur de grande zone. Le chapitre 9 explique la liation (cration de sousdomaines), lire absolument pour ceux qui envisagent des migrations de service. Le chapitre 10 dcrit de nombreuses caractristiques avances des serveurs de noms BIND 9.2.3 et 8.4.7. Le chapitre 11 traite de la scurisation des serveurs de noms, ce qui peut tre utile aux administrateurs expriments. Les chapitres 12 14 dcrivent les outils et techniques dintervention, dans lesquels mme les administrateurs expriments pourront trouver une valeur ajoute. Le chapitre 16 peut les aider aborder une vue densemble. Administrateurs systme de rseaux sans connexion directe lInternet Ils peuvent lire le chapitre 5 pour tudier la conguration de la messagerie sur de tels rseaux et les chapitres 11 et 17 pour la mise en uvre dune hirarchie DNS indpendante. Programmeurs Ils peuvent lire les chapitres 1 et 2 pour la thorie du DNS, puis le chapitre 15 pour les dtails sur la programmation avec les procdures de la bibliothque du resolver de BIND. Administrateurs rseau non directement responsables dune zone Ils devraient tout de mme lire les chapitres 1 et 2 pour la thorie du DNS, le chapitre 12 pour apprendre utiliser nslookup et dig, et le chapitre 14 pour les techniques dintervention. Responsables de messagerie (postmasters) Ils liront les chapitres 1 et 2 pour la thorie du DNS, puis le chapitre 5 pour tudier la cohabitation du DNS et du courrier. Le chapitre 12, qui dcrit nslookup et dig, aidera les postmasters rechercher les informations de routage des courriels dans lespace de noms. Utilisateurs seulement curieux Ils peuvent lire les chapitres 1 et 2 pour la thorie du DNS, et bien sr tout ce que bon leur semble ! Rappelons que nous supposons que vous tes familiariss avec ladministration de base dun systme Unix, les rseaux TCP/IP et la programmation de scripts shell et en Perl. Nous ne prsumons aucune autre connaissance spcialise. Lorsque nous aborderons un nouveau terme ou concept, nous ferons de notre mieux pour le dnir ou lexpliquer. Lorsque cela est possible, nous utiliserons des analogies avec le monde Unix (et avec le monde rel) pour faciliter votre comprhension.

Tlchargement des exemples


Les programmes dexemple de cet ouvrage2 sont accessibles via FTP partir des URL suivantes :

ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z ftp://ftp.oreilly.com/published/oreilly/nutshell/dnsbind/
2. Les exemples anglais sont aussi accessibles en ligne sur http://examples.oreilly.com/dns5.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

xviii
Les exemples en franais sont accessibles partir de lURL suivante : http://www.oreilly.fr/catalogue/2841774090.html Extrayez les chiers des archives en excutant :
% zcat dns.tar.Z | tar xf -

Prface

ou, avec Unix System V :


% zcat dns.tar.Z | tar xof -

Si zcat nest pas disponible sur votre systme, utilisez sparment les commandes uncompress et tar.

Votre avis
Les questions et commentaires concernant ce livre peuvent tre adresss : ditions OReilly 18, rue Sguier 75006 Paris France OReilly dispose dune page web pour la version originale de ce livre, qui indique des erreurs et donne des informations complmentaires : http://www.oreilly.fr/catalogue/2841774090.html Pour envoyer des commentaires ou poser des questions techniques, crivez : france@oreilly.com Pour des informations concernant les livres, les confrences, les logiciels, les centres de ressources et le rseau OReilly, consultez les sites : http://www.oreilly.fr ou : http://www.oreilly.com

Conventions typographiques
Nous utilisons les polices de caractres et formats suivants pour les commandes, utilitaires et appels au systme Unix :

les extraits de scripts ou de chiers de conguration sont afchs en chappement


constant :
if test -x /usr/sbin/named -a -f /etc/named.conf then /usr/sbin/named fi

les extraits de commandes interactives, montrant la ligne de commande et le rsultat


correspondant, sont afchs en chappement constant, la ligne de commande apparaissant en gras :
% cat /var/run/named.pid 78

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Utilisation des exemples de code

xix

une commande devant tre saisie par le super-utilisateur (root) est prcde du signe
dise (#) :
# /usr/sbin/named

les valeurs remplaables dans le code sont afches en chappement constant et


italique ;

les noms de domaine, les noms de chier, les fonctions, les commandes, les rfrences
aux pages du manuel Unix, les spcicits de Windows, les URL, les extraits de programme et les termes conservs en langue anglaise sont afchs en italique lorsquils apparaissent dans un paragraphe.
Ce pictogramme signale une note importante en marge du texte principal.

Cette image indique un avertissement en marge du texte principal.

Utilisation des exemples de code


Ce livre est l pour vous aider raliser votre travail. Vous pouvez gnralement utiliser les codes quil prsente, au sein de vos propres programmes et de votre documentation. Vous navez pas besoin de nous contacter pour demander une autorisation, moins que vous nen reproduisiez une portion signicative. Ainsi, lcriture dun programme utilisant plusieurs parties de nos codes ne requiert pas de permission. Par contre, la vente ou la distribution dun CD-ROM des exemples des ouvrages dOReilly requiert une permission. La rponse une question en faisant rfrence cet ouvrage ou ses exemples ne ncessite pas non plus de permission. Par contre, linclusion dune portion signicative dun code dexemple extrait de ce livre dans la documentation de votre produit ncessite une permission. Nous apprcierions, sans toutefois lexiger, quil soit fait rfrence au titre, lauteur, lditeur et au numro ISBN, comme par exemple : DNS et BIND, Cinquime dition, de Cricket Liu et Paul Albitz. Copyright 2006 OReilly, 2-84177-409-0 . Si vous pensez que votre utilisation des exemples sort des cas libres cits ci-dessus, vous pouvez nous contacter permissions@oreilly.com.

Citations
Les citations de Lewis Carroll au dbut de chaque chapitre sont extraites des textes lectroniques du Projet Gutenberg, de Alice au pays des merveilles (Millennium Fulcrum dition 2.9) et de Alice travers le miroir (Millennium Fulcrum dition 1.7). Les citations des chapitres 1, 2, 5, 6, 8 et 14 proviennent de Alice au pays des merveilles, et celles des chapitres 3, 4, 7, 9 13 et 15 17 de Alice travers le miroir3.
3. NdT : la version franaise des citations est extraite des traductions de ces romans par Henri Parisot ou Jacques Papy.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

xx

Prface

Remerciements
Les auteurs tiennent remercier Ken Stone, Jerry McCollom, Peter Jeffe, Hal Stern, Christopher Durham, Bill Wisner, Dave Curry, Jeff Okamoto, Brad Knowles, K. Robert Elz et Paul Vixie pour leur contribution inestimable cet ouvrage. Nous aimerions aussi remercier nos relecteurs, Eric Pearce, Jack Repenning, Andrew Cherenson, Dan Trinkle, Bill LeFebvre et John Sechrest, pour leurs critiques et suggestions. Sans leur aide, ce livre ne serait pas ce quil est (il serait plus maigre !). Pour la seconde dition, les auteurs voudraient galement remercier leur quipe de relecteurs de conance : Dave Barr, Nigel Campbell, Bill LeFebvre, Mike Milligan et Dan Trinkle. Pour la troisime dition, les auteurs saluent leur quipe idale de relecteurs : Bob Halley, Barry Margolin et Paul Vixie. Pour la quatrime dition, les auteurs doivent toute leur gratitude Kevin Dunlapp, Edward Lewis et Brian Wellington, leurs relecteurs dlite. Pour la cinquime dition, les auteurs voudraient remercier leur quipe de relecteurs de choc, Joo Damas, Matt Larson et Paul Vixie, ainsi que Silvia Hagen pour son aide de dernire minute sur IPv6. Cricket voudrait remercier tout particulirement son ancien responsable, Rick Nordensten, qui est le parfait modle dun superviseur HP moderne, sous la vigilance duquel la premire version de ce livre a t crite ; ses voisins, qui ont support sa mauvaise humeur durant plusieurs mois ; et bien videmment, sa femme Paige, pour son inlassable patience et pour avoir support le bruit de son clavier pendant son sommeil. Pour la seconde dition, Cricket voudrait ajouter un remerciement pour ses superviseurs prcdents, Regina Kershner et Paul Klouda, pour leur soutien dans son travail avec lInternet. Pour la troisime dition, Cricket exprime toute sa gratitude son collgue, Matt Larson, pour leur travail commun de dveloppement de Acme Razor. Pour la quatrime dition, Cricket remercie ses loyaux amis velus, Dakota et Annie pour leurs bisous et leur compagnie, ainsi que le fabuleux Walter B. pour son attention envers papa. Pour la cinquime dition, il se doit de mentionner un nouveau venu, le fabuleux bb G. Enn, il envoie ses remerciements ses amis et collgues de Infoblox pour leur dur travail, leur aide gnreuse et leur compagnie. Paul aimerait remercier sa femme Katherine pour sa patience, pour de nombreuses sessions de relecture, et pour avoir prouv quelle pouvait coudre un patchwork pendant son temps libre plus rapidement que son poux ne peut crire une moiti de livre.

Le mot du traducteur
Le travail de traduction dun document aussi exhaustif allie plaisir et difcult, on sen doute. Langlais technique a tellement envahi notre jargon franais dinformaticien quil faut souvent peser le pour et le contre avant de pencher pour conserver le terme anglais qui est vraiment entr dans lusage, traduire dans un terme franais, ou crer un nologisme qui, bien qutranger notre dictionnaire, saura tre vecteur optimal de sens.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le mot du traducteur

xxi

Tout au long de la traduction, le souci a t double : dune part viter au maximum tous les termes anglais inutiles quand une francisation permet denraciner le sens, et dautre part traquer tous les termes entrs dans lusage et qui, au l du temps, savrent imprcis ou non fonds. Je ne citerai ici quun seul exemple, qui est le plus patent, celui de la traduction de domain name . Jusqu prsent, dans la littrature, domain name a souvent t traduit par nom de domaine alors que cette traduction correspond plutt domain name of a domain en anglais. Il aurait fallu, au dpart, crer un terme original avant que lusage non nuanc du terme nom de domaine ne prenne le dessus. Ainsi ai-je opt, aprs concertation, pour le terme nom qui, chaque fois quil est employ, signie implicitement nom de type domaine , bien que le langage oral utilise parfois des termes tels que nom domainis . Ce dernier prsente linconvnient, pour sa part, de ne pas apparatre dans la formule universellement employe de systme de noms de domaine . Et voil donc vite la fcheuse rencontre dun faux-ami.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

1
Contexte
Le lapin blanc mit ses lunettes. Plaise votre Majest, o dois-je commencer ? demanda-t-il. Commencez au commencement, dit le Roi dun ton grave, et continuez jusqu ce que vous arriviez la fin ; ensuite, arrtez-vous.

Il importe avant toute chose de se pencher sur lhistorique du rseau ARPAnet pour bien comprendre le systme de noms de domaine (Domain Name System ou DNS). Le DNS a t dvelopp an de rpondre certaines difcults du rseau ARPAnet, et lInternet, descendant dARPAnet, en est toujours le principal utilisateur. Si vous utilisez lInternet depuis des annes, vous pouvez probablement vous dispenser de lire ce chapitre. Sinon, nous esprons quil vous donnera sufsamment dlments pour comprendre ce qui a motiv le dveloppement du DNS.

Petit historique de lInternet


Vers la n des annes 1960, lARPA, connue ultrieurement sous le nom de DARPA (Department of Defenses Advanced Research Projects Agency), commence dvelopper un grand rseau informatique exprimental, appel ARPAnet, connectant les principaux organismes de recherche des tats-Unis. Le but initial dARPAnet est de permettre aux sous-traitants du gouvernement de partager des ressources de calcul rares ou chres. Ds le dbut, les utilisateurs dARPAnet emploient galement le rseau pour le travail collaboratif, allant du partage de chiers et de logiciels, ou de lexpdition de courrier lectronique (aujourdhui chose courante) jusqu la recherche et au dveloppement en groupe, grce lutilisation de calculateurs distants et partags. Dveloppe au dbut des annes 1980, la suite de protocoles Transmission Control Protocol/Internet Protocol (TCP/IP) devient rapidement le protocole standard des machines dans ARPAnet. Son incorporation dans le systme dexploitation Unix BSD de lUniversit de Californie Berkeley est un vecteur de dmocratisation de la mise en rseau. Unix BSD est pratiquement gratuit pour les universits, ce qui entrane une mise en rseau et une connexion ARPAnet soudainement disponibles un faible cot pour bien plus dorganisations que celles prcdemment connectes. La plupart des
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Chapitre 1 Contexte

ordinateurs dj relis ARPAnet se connectent aux rseaux locaux (Local Area Network ou LAN) et, par effet de bord, les autres machines des rseaux locaux communiquent galement travers ARPAnet. Le rseau passe alors de quelques machines des dizaines de milliers dhtes. LARPAnet initial devient lpine dorsale dune fdration de rseaux locaux et rgionaux bass sur TCP/IP appele lInternet. , En 1988, le DARPA dcide toutefois darrter lexprience. Il commence par dmanteler ARPAnet. Un nouveau rseau, NSFNET, fond par la National Science Foundation remplace ARPAnet dans son rle dpine dorsale de lInternet. Au printemps 1995, lInternet subit une nouvelle transition lors du remplacement de lpine dorsale gre par lorganisme public NSFNET par un ensemble dpines dorsales commerciales exploites par des oprateurs de tlcommunication, tels que SBC et Sprint, et des acteurs commerciaux expriments dans le travail en rseau tels que MFS et UUNET. Aujourdhui, lInternet relie des millions dhtes sur toute la plante. Lessentiel des ordinateurs y est connect. Certaines des nouvelles pines dorsales commerciales peuvent vhiculer plusieurs gigabits par seconde, soit des dizaines de milliers de fois la bande passante dARPAnet initial. Des dizaines de millions de personnes utilisent quotidiennement le rseau pour communiquer et collaborer.

Internet et internet
Il est maintenant utile de prciser la notion dInternet, par opposition internet en gnral. Lun scrit avec une majuscule, lautre avec une minuscule et cette nuance est signicative. LInternet, avec un I majuscule, se rapporte au rseau qui a vu le jour sous le nom dARPAnet et qui est aujourdhui, en quelque sorte, la fdration de tous les rseaux TCP/IP directement ou indirectement connects des pines dorsales commerciales. En fait, il est aujourdhui compos dun ensemble de rseaux divers : pines dorsales TCP/IP commerciales, rseaux TCP/IP dentreprise ou gouvernementaux et rseaux TCP/IP internationaux, rseaux TCP/IP de nombreux pays, tous interconnects par des routeurs et des circuits numriques haute vitesse. Un internet, avec un i minuscule, est simplement un rseau constitu de multiples petits rseaux utilisant tous les mmes protocoles. Un internet ( i minuscule) nest ni obligatoirement connect lInternet ( I majuscule), ni ne doit obligatoirement utiliser la pile TCP/ IP comme protocole dinterconnexion. Il existe des rseaux dentreprise isols, par exemple. Un intranet ( i minuscule) nest rien dautre quun internet bas sur TCP/IP et utilis , pour promouvoir lutilisation des technologies dveloppes et introduites dans lInternet, dans les rseaux internes des entreprises. loppos, un extranet est un internet bas sur TCP/IP qui relie des entreprises partenaires, ou une entreprise ses distributeurs, fournisseurs et clients.

Historique du systme de noms de domaine


Durant les annes 1970, ARPAnet demeure une petite communaut de quelques centaines dhtes, rpertoris dans un chier unique, HOSTS.TXT, contenant la corres-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Internet et internet

pondance nom-adresse pour chaque hte connect ARPAnet. La table Unix des htes, /etc/hosts, est gnre partir de HOSTS.TXT (le plus souvent par suppression des champs quUnix nutilise pas). HOSTS.TXT est gr par le Network Information Center (NIC) au SRI et distribu partir dune machine unique, SRI-NIC1. Les administrateurs ARPAnet envoient leurs modications par courriel au NIC et rcuprent priodiquement le dernier HOSTS.TXT par FTP depuis SRI-NIC. Les modications sont reportes une ou deux fois par semaine dans le chier HOSTS.TXT. Avec la croissance dARPAnet, cette procdure devient vite inutilisable. La taille de HOSTS.TXT augmente proportionnellement au nombre dhtes connects ARPAnet et le trac gnr par le processus de mise jour augmente encore plus rapidement : un nouvel hte signie non seulement une nouvelle information dans HOSTS.TXT, mais aussi, potentiellement, un nouvel hte susceptible de pouvoir tre mis jour partir de SRI-NIC. LorsquARPAnet volue vers lutilisation des protocoles TCP/IP la taille de la popula, tion connecte explose et une horde de problmes se prsentent avec HOSTS.TXT (sans jeu de mot2) : Trafic et charge Le cot sur SRI-NIC, en terme de charge du rseau et du processeur lors de la diffusion du chier, devient beaucoup trop lev. Conflit de noms Dans HOSTS.TXT, deux htes ne peuvent avoir le mme nom. Pourtant, si le NIC peut attribuer des adresses en garantissant leur unicit, il na en revanche aucune autorit sur les noms dhte. Rien nempche alors quelquun dajouter un hte avec un nom dj attribu et de dstabiliser ainsi lensemble. Lajout dun hte de mme nom quun routeur important de messagerie, par exemple, pourrait interrompre le service dans une grande partie dARPAnet. Cohrence La gestion de la cohrence du chier sur un rseau en expansion devient de plus en plus difcile : le chier HOSTS.TXT volue trop rapidement par rapport son dlai de propagation jusqu la priphrie du grand ARPAnet. Malheureusement, le mcanisme bas sur HOSTS.TXT ne peut suivre correctement lexpansion du rseau. Ironiquement, le succs de lexprience ARPAnet conduit lchec et lobsolescence de son chier HOSTS.TXT. Les autorits dARPAnet lancent alors une rexion sur le dveloppement dun remplaant HOSTS.TXT. Le but est de crer un systme rsolvant les problmes inhrents un chier central de description des htes. Le nouveau systme devrait permettre la gestion locale des donnes tout en les rendant globalement accessibles. La dcentralisation de la gestion liminerait le goulot dtranglement de lhte unique et rduirait le problme du trac. La gestion locale permettrait galement davoir des donnes jour plus facilement. Lespace de noms serait hirarchique. Ceci garantirait lunicit des noms.
1. 2. Le SRI est un institut de recherche, le Stanford Research Institute Menlo Park en Californie. Il mne des recherches dans de nombreux domaines, dont celui des rseaux. NdT : host signie galement horde .

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Chapitre 1 Contexte

Paul Mockapetris, alors en poste lInformation Sciences Institute de lUSC, se voit coner la responsabilit de la conception de larchitecture du nouveau systme. En 1984, il crit les RFC 882 et 883, qui dcrivent le systme de noms de domaine3. Ces deux RFC sont ensuite remplaces par les RFC 1034 et 1035 qui constituent la rfrence actuelle. Les RFC 1034 et 1035 sont aujourdhui compltes par plusieurs autres traitant de scurit, de mise en uvre, de gestion, de mise jour automatique de serveurs de noms, de scurisation des donnes dun domaine, etc.

Systme de noms de domaine


Le systme de noms de domaine est une base de donnes distribue. Ainsi, la base de donnes globale est-elle contrle localement, les donnes de chaque segment tant accessibles depuis lensemble du rseau par un mcanisme client-serveur. Des duplications et une mmoire cache rglent les problmes de robustesse et de performance. Des programmes, appels serveurs de noms, prennent en charge laspect serveur du mcanisme client/serveur. Les serveurs de noms contiennent les informations concernant un segment de la base de donnes et les mettent la disposition des clients, appels resolvers. Dans la plupart des cas, les resolvers sont simplement mis en uvre dans des bibliothques de procdures qui gnrent et envoient les requtes vers un serveur de noms via un rseau. La structure de la base de donnes du DNS ( gure 1-1) est similaire celles des systmes de chiers Unix. La base de donnes (ou le systme de chiers) est reprsente comme un arbre invers, avec le nud-racine en haut. Un nom identie chaque nud de larbre relativement son nud-parent. Cela est analogue au chemin relatif dun systme de chiers, comme bin. Le nom vide " " est rserv au nud-racine. Textuellement, le nud-racine est reprsent par un point unique ( . ). Dans un systme de chiers Unix, la racine est reprsente par une barre oblique (/). Chaque nud est aussi la racine dun nouveau sous-arbre de larbre global. Chaque sous-arbre reprsente une partie des donnes globales : un rpertoire dans un systme de chiers Unix, un domaine dans le systme de noms de domaine. Chaque domaine ou rpertoire peut lui-mme tre divis en partitions, appeles sous-domaines pour le DNS et sous-rpertoires pour un systme de chiers. Les sous-domaines, tout comme les sousrpertoires, sont reprsents comme des enfants de leur domaine-parent. Chaque domaine (ou rpertoire) a un nom unique. Le nom dun domaine indique la position du domaine dans la base de donnes, tout comme un chemin absolu de rpertoire indique sa position dans le systme de chiers. Dans le DNS, un nom est la runion des noms de chaque nud, en commenant par le nud-racine du domaine, en terminant par le nud-racine de larbre, avec un . sparant chaque nom ou terme. Dans un systme de chiers Unix, un chemin absolu de rpertoire est la liste des noms relatifs, de la racine la feuille (le sens de parcours est invers par rapport au DNS, comme le montre la gure 1-2), avec une barre oblique / sparant chaque nom.

3.

Les RFC (Request for Comments) sont un lment de la procdure relativement informelle dintroduction de nouveaux standards dans lInternet. Elles sont habituellement diffuses gratuitement et contiennent des descriptions techniques de rfrence, souvent destines aux programmeurs.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Systme de noms de domaine

Base de donnes du DNS

""
com edu gov mil

Systme de fichiers Unix

etc

bin bin

usr etc bin

system local etc

Figure 1-1. La base de donnes du DNS compare un systme de fichiers Unix


Base de donnes du DNS

""

Systme de fichiers Unix

com

usr

hp

local

corp

bin

winnie winnie.corp.hp.com

imake

/usr/local/bin/imake

Figure 1-2. Formation des noms dans le DNS et dans un systme de fichiers Unix
Laetitia MAISON <keshin@free.fr>

[12/01/08]

DNS et Bind

Chapitre 1 Contexte

Dans le DNS, chaque domaine peut tre subdivis en plusieurs sous-domaines et chacun deux peut tre gr par un organisme diffrent. Par exemple, EDUCAUSE gre le domaine edu (educational) mais dlgue lautorit sur le sous-domaine berkeley.edu luniversit de Berkeley ( gure 1-3). Cela ressemble au montage de systmes de chiers distants : certains rpertoires du systme de chiers peuvent tre physiquement situs sur une autre machine. Par exemple, ladministrateur de lhte winken est responsable du systme de chiers qui apparat sur la machine locale sous le nom /usr/nfs/winken ( gure 1-3).

Base de donnes du DNS

gr par lICANN

""
gr par le NSI edu com gov mil

berkeley

gr par lUniversit de Berkeley

Systme de fichiers Unix


/

systme de fichiers sur la machine locale

usr nfs local nod

bin bin

etc

system

blinken winken

systme de fichiers sur la machine distante winken

Figure 1-3. Gestion distante de sous-domaines et de systmes de fichiers

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Systme de noms de domaine

Une dlgation dautorit de berkeley.edu lUniversit de Berkeley cre une nouvelle zone, gre de manire autonome dans lespace des noms. La zone berkeley.edu devient alors indpendante de edu et contient tous les noms se terminant par berkeley.edu. Autrement dit, la zone edu contient uniquement les noms se terminant par edu et qui ne sont pas dans des zones dlgues comme berkeley.edu. berkeley.edu peut lui-mme tre scind en sous-domaines tels que cs.berkeley.edu. Certains de ces sous-domaines peuvent eux-mmes tre des zones spares, si les administrateurs de berkeley.edu en dlguent la gestion. Si cs.berkeley.edu est une zone spare, la zone berkeley.edu ne contiendra pas de nom se terminant par cs.berkeley.edu ( gure 1-4).

zone edu

edu

zone berkeley.edu

berkeley

stanford

cmu

zone cs.berkeley.edu cs co me

Figure 1-4. Les zones edu, berkeley.edu et cs.berkeley.edu


Les noms servent dindex dans la base de donnes du DNS. On peut considrer que les donnes du DNS sont attaches un nom. Dans un systme de chiers, les rpertoires contiennent des chiers et des sous-rpertoires. De la mme manire, un domaine peut contenir simultanment des htes et des sous-domaines. Un domaine contient les htes et les sous-domaines dont les noms sont dans le sous-arbre commenant au domaine, en considrant lespace de noms. Chaque hte dun rseau a un nom qui pointe vers les informations sur cet hte ( gure 1-5). Ces informations peuvent tre son adresse IP des indications sur le routage , de courriels, etc. Les htes peuvent avoir un ou plusieurs surnoms (alias) qui sont des pointeurs dun nom (le surnom) vers un autre nom (le nom ofciel ou nom canonique). Dans la gure 1-5, mailhub.nv est un surnom du nom canonique rincon.ba.ca

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Chapitre 1 Contexte

ca or

nv

ba

la

mailhub

oakland

rincon

adresse IP 192.2.18.44

Figure 1-5. Un surnom du DNS pointe vers un nom canonique


Pourquoi avoir conu une architecture aussi complexe ? Et bien, cest pour rsoudre les problmes lis HOSTS.TXT. Par exemple, la hirarchisation des noms limine le pige des conits de noms. Un domaine a un nom unique et lorganisme qui le gre est libre quant lattribution des noms dhte et de sous-domaine dans le domaine. Quel que soit le nom choisi, il nest pas en conit avec un nom dans un autre domaine, puisque ce nom se termine de manire unique par le nom de son domaine. Par exemple, lorganisme qui gre hic.com peut attribuer le nom puella un hte ( gure 1-6), puisquil sait que le nom de lhte se termine par hic.com, un nom de domaine unique.

""

com

hic haec

hoc

puella

puer

puella

puella.hic.com

puella.hoc.com

Figure 1-6. Solution au problme du conflit de noms

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Historique de BIND

Historique de BIND
La premire mise en uvre du systme de noms de domaine sappelle JEEVES et a t crite par Paul Mockapetris lui-mme. BIND (Berkeley Internet Name Domain) est une version postrieure, crite par Kevin Dunlap pour Unix BSD 4.3 de Berkeley. BIND est aujourdhui maintenu par lInternet Systems Consortium4. BIND est limplmentation que nous allons dtailler dans cet ouvrage et elle est de loin la mise en uvre du DNS la plus rpandue aujourdhui. Il a t port sur la plupart des systmes Unix et fait partie intgrante de la majorit des offres commerciales dUnix. BIND a mme t port sur Windows NT, Windows 2000 et Windows Server 2003 de Microsoft.

Alternative au DNS ?
Malgr lutilit du systme de noms de domaine, il y a des situations o il nest pas intressant de lutiliser. Il existe dautres systmes que le DNS, certains dentre eux pouvant tre livrs en standard avec un systme dexploitation. De plus, il arrive que la surcharge lie la gestion du domaine et ses serveurs de noms, en masque les bnces. En revanche, pour certaines situations, il ny a pas dautre choix que celui du DNS. Voici quelques lments pour vous guider dans une dcision : Si vous tes connect lInternet... ... DNS est un must. Considrez le DNS comme un sauf-conduit travers lInternet : peu prs tous les services en rseau de lInternet utilisent le DNS, en particulier le web, le courrier lectronique, laccs par terminal distant et le transfert de chiers. Pourtant, cela ne signie pas que vous deviez initialiser et exploiter une zone par vous-mme et pour vous-mme. Si vous navez hrit que de quelques machines, vous pouvez rejoindre une zone existante (voir le Chapitre 3) ou trouver quelquun qui grera une zone pour vous. Si vous tes client dun fournisseur daccs pour votre connexion lInternet, demandez-lui sil peut grer une zone pour vous. Mme si vous ntes pas encore client, des entreprises sont prtes vous rendre ce service, commercialement. Si vous avez un peu plus de machines, vous voudrez probablement avoir votre propre zone et, pour avoir un contrle direct sur votre domaine et vos serveurs de noms, vous aurez la grer vous-mme. Ce livre est pour vous ! Si vous avez votre propre internet bas sur TCP/IP... ... vous avez probablement besoin du DNS. Par internet, nous ne dsignons pas un rseau Ethernet unique de stations de travail utilisant TCP/IP (lisez la section suivante si vous le pensiez), mais un rseau complexe de rseaux. Peut-tre mme avez-vous plusieurs dizaines de segments Ethernet connects par des routeurs, par exemple.

4.

Pour plus dinformation sur lInternet Systems Consortium et ses travaux sur BIND, on peut consulter http://www.isc.org/sw/bind/.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

10

Chapitre 1 Contexte
Si vous avez un rseau homogne et que vos htes nont pas besoin du DNS (sils ne fonctionnent pas en TCP/IP par exemple), alors vous pouvez vous en passer. Mais si , vous avez un parc htrogne, tout particulirement des versions diffrentes dUnix, vous aurez besoin du DNS. Il simpliera la distribution des informations et vous dbarrassera de toutes les procdures de distribution de tables dhtes que vous auriez pu concocter.

Si vous avez votre propre rseau local ou rseau de site... ... et que ce rseau nest pas connect un rseau fdrateur, vous pouvez probablement vous passer du DNS. Vous pouvez toutefois envisager dutiliser le service de noms Internet de Windows (Windows Internet Name Service ou WINS) de Microsoft, des tables dhtes ou le service dinformations en rseau (Network Information Service ou NIS) de Sun. Par contre, si vous avez besoin dune gestion distribue ou que vous rencontrez des problmes de cohrence des donnes dans votre rseau, le DNS est peut-tre fait pour vous. De plus, si vous prvoyez de connecter prochainement votre rseau un autre (rseau dentreprise ou lInternet), il peut tre judicieux de dmarrer un domaine ds prsent.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

2
Principes du DNS
...et, se disait Alice, quoi peut bien servir un livre o il ny a ni images ni conversations ?

Le systme de noms de domaine (Domain Name System) est avant tout une base de donnes dinformations sur les htes. On y trouve de nombreux renseignements : des noms dhtes utiles, des serveurs de noms, un espace de noms (une notion qui sera aborde plus loin). Ne perdons pas de vue, cependant, que le service du DNS fournit surtout des informations sur les htes dun internet. Nous avons dj expos certains des aspects importants du DNS, dont larchitecture client/serveur et la structure de la base de donnes, mais nous ne sommes pas beaucoup entrs dans les dtails et navons pas encore expliqu son fonctionnement. Dans ce chapitre, nous expliquerons et illustrerons donc le fonctionnement du DNS. Nous dnirons les termes indispensables pour la suite de la lecture de louvrage (et pour une discussion intelligible entre spcialistes). Tout dabord, intressons-nous aux concepts introduits dans le chapitre prcdent. Nous essaierons dy ajouter le plus de dtails possibles an de les rendre attrayants.

Espace de noms
La base de donnes distribue du DNS est indexe par les noms. Chaque nom peut tre considr comme un simple chemin dans un grand arbre invers, ce dernier tant appel lespace de noms. La structure hirarchique de cet arbre ( gure 2-1) est similaire celle dun systme de chiers Unix. Larbre a une seule racine, situe en haut1. Dans un systme de chiers Unix, ce sommet est appel rpertoire-racine et est reprsent par une barre oblique / . Il est appel simplement racine (root) dans le cas du DNS. Comme pour un systme de chiers Unix, larbre du DNS peut rattacher des chemins, quel que soit leur nombre, chaque point dintersection, appel nud (node). La

1.

Cest lvidence un arbre dinformaticien, pas de botaniste.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

12

Chapitre 2 Principes du DNS

profondeur de larbre est limite 127 niveaux (limite quil nest pas souhaitable datteindre !).
""

arpa

com

edu

gov

mil

org

Figure 2-1. La structure de lespace de noms du DNS

Noms absolus
Chaque nud de larbre a un nom individuel (sans point . ) dune longueur maximale de 63 caractres. Le nom de longueur nulle est rserv la racine. Le nom complet de chaque nud de larbre est la succession des noms individuels sur le chemin qui va du nud la racine. Les noms complets sont toujours lus du nud vers la racine (lecture ascendante), avec ajout dun point sparateur entre chaque nom individuel. Si le nom du nud-racine apparat dans un nom de nud, le nom du nud semble se terminer par un point, comme dans www.oreilly.com. ; il se termine en fait par un point (le sparateur), suivi du nom de longueur nulle. Lorsque le nom du nud-racine apparat isolment, il est reprsent par un point unique . . Par consquent, certains logiciels considrent quun point terminal dans un nom indique un nom absolu. Un nom absolu est dcrit relativement la racine et indique sans ambigut la position dun nud dans la hirarchie. Un nom absolu est aussi appel nom totalement quali (Fully Qualied Domain Name ou FQDN). Les noms sans point terminal sont parfois interprts relativement un domaine, autre que la racine, tout comme les noms de rpertoire sans barre oblique initiale sont interprts relativement au rpertoire courant. Le DNS impose que les nuds-enfants dun mme parent aient des noms diffrents. Cette rgle garantit quun nom dsigne un nud unique de larbre. Ce nest donc pas une limitation, car les noms ne doivent tre uniques quimmdiatement en dessous dun mme nud et non pas par rapport tous les nuds de larbre. La mme rgle sapplique au systme de chiers Unix : vous ne pouvez pas nommer deux objets dun mme sous-rpertoire de la mme manire. Tout comme vous ne pouvez pas avoir deux nuds hobbes.pa.ca.us dans le mme espace de noms, vous ne pouvez pas non plus avoir

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Espace de noms

13

deux rpertoires /usr/bin dans le mme systme de chiers ( gure 2-2). Par contre, vous pouvez avoir un nud hobbes.pa.ca.us et un nud hobbes.lg.ca.us, de la mme manire quun rpertoire /bin et un rpertoire /usr/bin.

Base de donnes du DNS

""

us

ca

il

pa

mpk

lg hobbes.lg.ca.us

hobbes

hobbes

hobbes hobbes.pa.ca.us hobbes.pa.ca.us

impossible au mme niveau

Systme de fichiers Unix

usr

bin

etc /bin

system

bin

bin

/usr/bin impossible au mme niveau /usr/bin

Figure 2-2. Garantie dunicit de noms dans le DNS et de chemins dans Unix

Domaines
Un domaine est tout simplement un sous-arbre de lespace de noms. Le nom dun domaine est celui du nud au sommet du domaine. Ainsi, par exemple, le sommet du domaine purdue.edu est un nud nomm purdue.edu ( gure 2-3). De la mme manire, dans un systme de chiers, vous tes en droit dattendre un nud appel /usr au sommet du rpertoire /usr ( gure 2-4). Tout nom du sous-arbre est considr comme faisant partie du domaine. Un nom peut apparatre dans plusieurs sous-arbres ; il peut donc apparatre galement dans plusieurs domaines. Par exemple, le nom pa.ca.us est une partie du domaine ca.us mais aussi du domaine us ( gure 2-5).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

14

Chapitre 2 Principes du DNS

""

edu

com

org

nud purdue.edu
purdue

domaine purdue.edu

Figure 2-3. Le domaine purdue.edu


/

nud /usr usr

bin

etc

rpertoire /usr

Figure 2-4. Le rpertoire /usr


""

net us

mil domaine us

il ca nud pa.ca.us pa pa mpk

ny

domaine ca.us

Figure 2-5. Un nud peut appartenir plusieurs domaines


[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Espace de noms

15

Un domaine est donc simplement un sous-arbre de lespace de noms et il est constitu de noms et de domaines. Il reste maintenant y placer les htes, car les domaines sont aussi des groupes dhtes. Les htes sont quant eux reprsents par des noms. Souvenons-nous que les noms sont simplement des index dans la base de donnes du DNS. Les htes sont les noms qui dsignent des informations concernant un hte individuel et un domaine contient tous les htes dont les noms sont dans le domaine. Les htes sont rpartis de manire logique, souvent gographique ou par appartenance une entreprise, mais pas ncessairement par rseau, adresse ou type de matriel. Vous pouvez avoir dix htes diffrents, chacun deux sur un rseau diffrent et ventuellement dans des pays diffrents, mais appartenant pourtant au mme domaine. Attention, il ne faut pas confondre les domaines DNS avec les domaine NIS (Network Information Service). Un domaine NIS dsigne aussi un groupe dhtes, la structure des noms est similaire dans les deux cas mais les concepts sont diffrents. NIS utilise des noms hirarchiques mais la similitude sarrte l : les htes dun mme domaine NIS partagent des donnes concernant les htes et les utilisateurs, mais ils ne peuvent pas naviguer dans lespace de noms NIS pour rechercher des informations en provenance des autres domaines NIS. De la mme manire, les domaines NT, qui fournissent des services de gestion de comptes et de scurit, nont aucun rapport avec les domaines du DNS. Par contre, les domaines Active Directory sont intimement lis aux domaines DNS. Nous parlerons des relations entre DNS et Active Directory au Chapitre 17. Les noms aux extrmits infrieures de larbre (les feuilles) dsignent en gnral des htes individuels et peuvent donner accs des adresses de machines, des informations sur le matriel ou des prcisions sur le routage de la messagerie. Les noms lintrieur de larbre peuvent dsigner un hte et peuvent donner accs des informations concernant le domaine, indiffremment. Ces deux cas ne sont pas exclusifs lun de lautre : un nom intrieur peut reprsenter simultanment le domaine et un hte dans le rseau. Par exemple, hp.com est la fois le nom du domaine de la socit HewlettPackard et le nom dun hte qui hberge le serveur web principal de HP . Le type dinformation renvoye lors de lutilisation dun nom, dpend du contexte dans lequel vous lutilisez. Lexpdition dun courrier lectronique quelquun dans hp.com doit produire le renvoi dune information de routage de courrier, alors quune connexion ssh doit provoquer la recherche dune information sur un hte (par exemple, la gure 2-6, ladresse IP de hp.com). Un domaine peut avoir plusieurs sous-arbres, appels sous-domaines2. Un moyen simple pour dterminer si un domaine est sous-domaine dun autre domaine, consiste comparer leurs noms. Le nom dun sous-domaine se termine par le nom de son parent. Par exemple, le domaine la.tyrell.com doit tre un sous-domaine de tyrell.com car la.tyrell.com se termine par tyrell.com. Il est aussi sous-domaine de com.

2.

Les termes domaine et sous-domaine sont souvent utiliss sans distinction ou presque, dans les documentations relatives au DNS. Dans cet ouvrage, nous utilisons le terme de sous-domaine dans le sens relatif : un domaine A est un sous-domaine dun domaine B si la racine de A se trouve dans le domaine B.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

16

Chapitre 2 Principes du DNS

""

com adresse IP de hp.com hp

corp

gr

sdd

Figure 2-6. Un nud interne contenant la fois des donne sur un hte et sur un domaine
Plutt que dtre classs relativement un domaine, les sous-domaines sont souvent classs par niveau (level). Dans les listes de diffusion et les forums, les termes domaine de niveau suprieur (top-level domain, TLD) ou domaine de second niveau (second-level domain) sont parfois utiliss pour marquer une hirarchie de valeur. Ils font simplement rfrence la position du domaine dans lespace de noms :

un domaine de niveau suprieur est un enfant direct de la racine ; un domaine de premier niveau ( rst-level domain) est un enfant direct de la racine
(cest un domaine de niveau suprieur) ;

un domaine de second niveau est un enfant dun domaine de premier niveau, et


ainsi de suite.

Enregistrements de ressource
Les donnes associes aux noms sont contenues dans des enregistrements de ressource (resource records ou RR). Ces enregistrements sont diviss en classes, chacune delles se rapportant un type de rseau ou de logiciel. ce jour, il existe des classes pour les internets TCP/IP pour les rseaux bass sur les protocoles de Chaosnet (un ancien , rseau dont lhistoire est signicative) et pour les rseaux qui utilisent le logiciel Hesiod. La classe des internets TCP/IP est de loin la plus rpandue (nous ne savons pas si quelquun utilise encore la classe Chaosnet et lutilisation de la classe Hesiod est essentiellement conne au MIT). Dans cet ouvrage, nous nous consacrerons donc surtout la classe des internets. lintrieur dune classe, les enregistrements sont rpartis en types qui correspondent aux diffrentes catgories de donnes pouvant tre stockes dans lespace de noms. Chaque classe denregistrement peut avoir ses propres types, bien que certains types existent dans plusieurs classes. En effet, quasiment chaque classe a un type adresse. Chaque type denregistrement dans une classe donne a une syntaxe particulire que tous les enregistrements de ressource de cette classe et de ce type doivent respecter. Si ces informations vous paraissent incompltes, ne vous inquitez pas ; nous ne manquerons pas de dcrire en dtail les enregistrements pour la classe des internets. Les enregistrements les plus courants sont dcrits au Chapitre 4 et une liste dtaille est incluse lAnnexe A.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Espace de noms du domaine Internet

17

Espace de noms du domaine Internet


Jusquici, nous avons parl de la structure thorique de lespace de noms et du type des donnes qui y sont mmorises ; nous avons mme mis en valeur diffrents types de noms laide dexemples (parfois ctifs). Cela ne permet cependant pas de comprendre les noms que lon rencontre quotidiennement dans lInternet. Le systme de noms de domaine impose peu de rgles sur les noms individuels de nuds et nassocie aucune signication particulire aux noms dun niveau particulier. Quand vous grez une partie de lespace de noms, vous pouvez xer votre propre smantique. Vous pouvez mme nommer vos sous-domaines par les lettres de lalphabet et personne ne pourrait vous en empcher (tout au plus, fortement vous le dconseiller). Lactuel espace de noms de lInternet a toutefois une structure organise. Dans les domaines de niveau suprieur, les noms suivent des traditions (pas des rgles, car ces noms ont t et peuvent encore tre modis), ce qui permet dviter lanarchie. La comprhension de cette structure par un utilisateur est un norme avantage pour le dchiffrement de la smantique dun nom.

Domaines de niveau suprieur


lorigine, les domaines de niveau suprieur (top level domains) dcoupaient lespace de noms de lInternet en sept domaines : com pour les entreprises commerciales telles que Hewlett-Packard (hp.com), Sun Microsystems (sun.com) ou IBM (ibm.com). edu est rserv aux organismes universitaires des tats-Unis, tels que lUniversit de Californie Berkeley (berkeley.edu) ou lUniversit de Purdue (purdue.edu). gov est rserv aux organismes gouvernementaux des tats-Unis, tels que la NASA (nasa.gov) ou la National Science Foundation (nsf.gov). mil est rserv aux organismes militaires des tats-Unis, tels que lU.S. Army (army.mil) ou la Navy (navy.mil). net est rserv aux organismes fournissant une infrastructure de rseau, tels que NSFNET (nsf.net) ou UUNET (uu.net). Toutefois, depuis 1996, net a t ouvert aux entreprises commerciales, ce qui tait dj le cas pour com. org est rserv aux organismes non-commerciaux, tels que Electronic Frontier Foundation (eff.org). Comme net, toutefois, les restrictions sur org ont t leves en 1996.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

18
int

Chapitre 2 Principes du DNS

est rserv aux organismes internationaux, tels que lOTAN (nato.int). Un autre domaine de niveau suprieur, appel arpa, a t utilis pendant la priode o ARPAnet passait de lutilisation dune table dhtes lutilisation du DNS. Tous les htes du rseau ARPAnet initial avaient un nom dans le domaine arpa et restaient donc faciles trouver. Par la suite, les htes furent dplacs vers divers sous-domaines. Toutefois, le domaine arpa est toujours utilis dans un contexte prcis, dcrit plus loin. On peut noter un certain dsquilibre dans lorientation gnrale, qui correspond des organisations amricaines. Cela est comprhensible dans la mesure o lInternet est le successeur dARPAnet, projet de recherche amricain. Personne navait prvu le succs dARPAnet, ni mme quil pourrait avoir une porte internationale sous le nom dInternet. Aujourdhui, les domaines initiaux sont appels domaines gnriques de niveau suprieur (generic top-level domains ou gTLD). Le terme gnrique doit tre oppos aux domaines nationaux de niveau suprieur, particuliers chaque pays.

Domaines nationaux de niveau suprieur


Pour saccommoder de la mondialisation de lInternet, les concepteurs de son espace de noms ont d faire quelques compromis. Plutt que de rechercher tout prix des noms de domaine de niveau suprieur dcrivant des organismes, ils ont ajout une dnomination par pays. De nouveaux domaines de niveau suprieur ont t dclars (mais pas ncessairement crs) pour dsigner ces pays. Leur nom respecte une norme internationale appele ISO 31663. Cette dernire tablit des noms abrgs sur deux lettres pour tous les pays du monde. Nous avons inclus la liste des actuels domaines de niveau suprieur lAnnexe D.

Nouveaux domaines de niveau suprieur


En 2000, lorganisme qui gre le DNS, lICANN (Internet Corporation for Assigned Names and Numbers), a cr sept nouveaux domaines gnriques pour pouvoir prendre en compte lexpansion rapide dInternet et le besoin de plus despace de noms. Certains dentre eux sont de vritables domaines gnriques de niveau suprieur, de la mme manire que com, net ou org, alors que dautres se rapprochent de lide de gov ou mil : ils sont rservs une communaut spcique (et parfois de manire surprenante). LICANN y fait rfrence sous le vocable de sponsored TLD (sTLD), par opposition avec les premiers (unsponsored gTLD). Un TLD sponsoris dispose dune charte qui dnit sa fonction, et il est gr par un organisme sponsoris, qui xe sa politique et contrle son fonctionnement, avec le soutien de lICANN. Voici les nouveaux gTLD : aero Sponsoris, pour lindustrie aronautique.

3.

Sauf pour la Grande Bretagne. Daprs lISO 3166 et la tradition dans lInternet, le nom du domaine de niveau suprieur pour la Grande Bretagne devrait tre gb. Pourtant, de nombreux organismes de Grande Bretagne ou dIrlande du Nord (Royaume Uni ou United Kingdom) utilisent le nom uk.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Espace de noms du domaine Internet


biz Gnrique. coop Sponsoris, pour les cooprations. info Gnrique. museum Sponsoris, pour les muses. name Gnriques, pour les particuliers. pro Gnriques, pour les professionnels.

19

Plus rcemment, au dbut de 2005, lICANN a approuv deux nouveaux TLD sponsoriss, jobs, pour la gestion des ressources humaines, et travel, pour les professionnels du voyage. Plusieurs autres TLD sponsoriss sont en cours dvaluation, dont cat, pour la communaut linguistique et culturelle catalane, mobi, pour les mobiles, et post, pour la communaut de la poste. Jusqu prsent, seul mobi a t dlgu partir de la racine. Vous pouvez en savoir plus sur le site de lICANN http://www.icann.org.

Quelques prcisions
lintrieur de ces domaines de niveau suprieur, les traditions varient ainsi que leur porte. Certains des domaines de type ISO 3166 suivent formellement le dcoupage amricain initial. Par exemple, le domaine pour lAustralie, au, a des sous-domaines comme edu.au et com.au. Dautres domaines de niveau suprieur ISO 3166 suivent lexemple du domaine uk et ont des sous-domaines comme co.uk pour les entreprises (corporations) ou ac.uk pour la communaut acadmique. Cependant, dans la plupart des cas, les domaines gographiques de niveau suprieur ont une structure smantique organise. Cela ntait pas vrai pour le domaine us lorigine. ses dbuts, ce domaine avait cinquante sous-domaines, correspondant aux cinquante tats amricains4. Chacun deux tait nomm selon labrviation standard sur deux lettres pour les tats, celle normalise par le service postal amricain. lintrieur de chaque tat, le dcoupage tait encore essentiellement gographique, la plupart des sous-domaines correspondant des villes. lintrieur des villes, les noms correspondaient habituellement des htes individuels. Tout comme de nombreuses rgles despaces de noms, cette structure a t abandonne lors de la reprise de la gestion de us par Neustar en 2002. Dsormais, us, tout comme com et net, est ouvert tous.

4.

En ralit, il y a quelques domaines supplmentaires sous us : un pour Washington, un pour Guam, etc.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

20

Chapitre 2 Principes du DNS

Interprtation des noms


Maintenant que vous savez ce que reprsente la majorit des domaines de niveau suprieur et comment est structur leur espace de noms, vous comprendrez certainement plus facilement la plupart des noms. Prenons des exemples et analysons-les : lithium.cchem.berkeley.edu Nous vous avons dj parl de berkeley.edu propos du domaine de lUniversit de Berkeley (mme si nous ne lavions pas prcdemment cit, vous pourriez constater quil correspond une universit amricaine en raison de son appartenance au domaine edu). cchem est le sous-domaine de berkeley.edu pour le College of Chemistry. Enn, lithium est le nom dun hte prcis, et probablement un parmi une centaine, si on suppose quil y a un hte par lment chimique. winnie.corp.hp.com Cet exemple est un peu plus complexe. Le domaine hp.com appartient probablement la socit Hewlett-Packard (nous lavons dj voqu). Son sous-domaine corp est sans doute celui de son sige et winnie est sans doute un nom invent par quelquun pour baptiser une machine. fernwood.mpk.ca.us Ici, vous devrez utiliser votre connaissance du domaine us. ca.us est manifestement le domaine pour la Californie, mais mpk peut tre nimporte quoi. Ici, il nest pas vident de deviner quil sagit du domaine de Menlo Park moins de connatre fond la gographie de la baie de San Francisco (et non, ce nest pas le Menlo Park o a vcu Edison dans le New Jersey). daphne.ch.apollo.hp.com Nous citons cet exemple uniquement pour que vous ne pensiez pas que tous les noms sont uniquement composs de quatre membres. apollo.hp.com est lancien sous-domaine dApollo Computer lintrieur du domaine hp.com (quand la socit HP a achet Apollo, elle a hrit du domaine Internet dApollo, apollo.com, qui est devenu apollo.hp.com). ch.apollo.hp.com est le site dApollo de Chelmsford dans le Massachusetts. daphne est un hte Chelmsford.

Dlgation dautorit
Souvenons-nous que lun des principaux buts du systme de noms de domaine est de dcentraliser sa propre administration. Cela est possible par la dlgation. La dlgation de domaine ressemble beaucoup la dlgation de tches au travail. Un dirigeant peut scinder un grand projet en petites tches et dlguer la responsabilit de chacune delles diffrentes personnes. De la mme manire, un organisme grant un domaine peut le diviser en sousdomaines. Chacun deux peut tre dlgu un autre organisme, qui devient responsable de la gestion de toutes les informations de ce sous-domaine. Cet organisme peut modier librement les donnes et mme dcouper son sous-domaine en plusieurs sousdomaines, puis les dlguer. Le domaine-parent contient seulement des pointeurs vers les origines des donnes du sous-domaine et il peut indiquer ces pointeurs ceux qui

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Serveurs de noms et zones

21

les demandent. Par exemple, le domaine stanford.edu est dlgu aux personnes de Stanford qui exploitent le rseau de luniversit ( gure 2-7).
""

edu

org

mil

mit stanford

cmu

gr par lUniversit de Stanford

Figure 2-7. stanford.edu est dlgu lUniversit de Stanford


Tous les organismes ne dlguent pas la totalit de leur domaine, de mme que tous les dirigeants ne dlguent pas tout leur travail. Un domaine peut avoir plusieurs sousdomaines et aussi contenir des htes qui ne sont dans aucun sous-domaine. Par exemple, la socit Acme Corporation a une division Rockaway et son sige Kalamazoo. Elle pourrait avoir deux sous-domaines : rockaway.acme.com et kalamazoo.acme.com. Toutefois, les quelques htes dans les bureaux de vente disperss sur le territoire amricain entreront mieux dans le domaine acme.com que dans les sousdomaines. Nous expliquerons ultrieurement comment crer et dlguer des sous-domaines. Pour le moment, il est important de comprendre que la dlgation est le transfert de la responsabilit dun sous-domaine vers un autre organisme.

Serveurs de noms et zones


Les htes qui stockent les informations de lespace de noms sont appels des serveurs de noms. Les serveurs de noms disposent en gnral de toutes les informations concernant une partie de lespace de noms, appele zone. Ils chargent ces informations partir dun chier local ou dun autre serveur de noms. On dit alors que le serveur de noms fait autorit sur la zone. Un serveur de noms peut faire autorit sur plusieurs zones. La diffrence entre une zone et un domaine est subtile mais importante. Tous les domaines de niveau suprieur, ainsi que de nombreux domaines de second niveau ou plus (comme berkeley.edu ou hp.com), sont dcoups en units plus petites et plus faciles grer, par dlgation. Ces units sont appeles zones. Le domaine edu ( gure 2-8) est divis en de nombreuses zones, dont berkeley.edu, purdue.edu ou nwu.edu. Au sommet du domaine, il y a une zone edu. Il est normal que ceux qui exploitent edu veuillent le scinder, sinon ils auraient grer eux-mmes le sous-domaine berkeley.edu. Il est plus sens de dlguer berkeley.edu lUniversit de Berkeley. Que reste-t-il ceux qui exploitent edu ? La zone edu, qui contient essentiellement des informations de dlgation aux sous-domaines de edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

22

Chapitre 2 Principes du DNS

""

com

edu zone edu


ati on ati on d lg d lg

org

berkeley nwu

purdue

zone berkeley.edu

zone purdue.edu

domaine edu

Figure 2-8. Le domaine edu divis en zones


Le sous-domaine berkeley.edu est lui-mme divis en zones par dlgation ( gure 2-9). Il existe des sous-domaines dlgus appels cc, cs, ce, me, etc. Chacun deux est dlgu un ensemble de serveurs de noms et certains dentre eux font aussi autorit pour le domaine berkeley.edu. De toutes faons, les zones sont toujours spares et peuvent avoir des groupes de serveurs de noms faisant autorit totalement diffrents.
""

edu

zone berkeley.edu berkeley

zone edu

= dlgation

cc

ce

cs

me

zone cc.berkeley.edu

zone zone ce.berkeley.edu cs.berkeley.edu

zone me.berkeley.edu

Figure 2-9. Le domaine berkeley.edu divis en zones


[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Serveurs de noms et zones

23

Une zone contient tous les noms contenus dans le domaine de mme nom, excepts les noms qui sont dans des sous-domaines dlgus. Par exemple, le domaine de niveau suprieur ca (pour le Canada) peut avoir les sous-domaines ab.ca, on.ca et qc.ca, respectivement pour les provinces de lAlberta, de lOntario et du Qubec. Lautorit sur les sous-domaines ab.ca, on.ca et qc.ca peut tre dlgue des serveurs de noms dans chaque province. Le domaine ca contient toutes les donnes dans ca plus toutes celles de ab.ca, on.ca et qc.ca. Mais la zone ca ne contient que les donnes dans ca ( gure 2-10), qui sont a priori essentiellement des pointeurs vers les sous-domaines dlgus. De la mme manire, ab.ca, on.ca et qc.ca sont des zones distinctes de la zone ca.
"" zone ca ca zone ab.ca ab on qc fr org zone qc.ca

domaine ca zone on.ca

Figure 2-10. Le domaine ca...


Si un sous-domaine de domaine nest pas dlgu, la zone contient aussi les noms et les donnes de tous les sous-domaines non dlgus. Par exemple, les sous-domaines bc.ca et sk.ca (British Columbia et Saskatchewan) existent mais ne sont pas dlgus (peuttre que les autorits provinciales de British Columbia et du Saskatchewan ne sont pas prtes grer leurs sous-domaines, mais que lautorit qui gre le domaine de niveau suprieur ca veut prserver la cohrence de lespace de noms et met en place les sousdomaines pour toutes les provinces du Canada). Dans ce cas, la zone ca stend vers le bas pour contenir bc.ca et sk.ca, mais ne contient pas les autres sous-domaines de ca ( gure 2-11). On comprend maintenant la raison pour laquelle un serveur de noms charge les informations dune zone et non pas celles dun domaine : un domaine peut contenir plus dinformations que ncessaire pour un serveur car il peut contenir des donnes dlgues dautres serveurs de noms5. Puisquune zone est borne par la dlgation, elle ninclura jamais de donnes dlgues.

5.

Imaginez ce qui se passerait si un serveur de noms de la racine chargeait les informations du domaine plutt que celles de la zone : il chargerait la totalit de lespace de noms !

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

24

Chapitre 2 Principes du DNS

zone ca

ca

bc

ab

sk

on

qc

domaine ca zone ab.ca zone on.ca zone qc.ca

Figure 2-11. ...compar la zone ca


Si vous dbutez juste la construction dun domaine, ce dernier ne contient probablement pas de sous-domaines. Dans ce cas, puisquil ny a pas de dlgation, votre domaine et votre zone contiennent les mmes donnes

Dlgation un sous-domaine
Mme si, pour le moment, vous navez pas besoin de dlguer une partie de votre domaine, il est bon de comprendre le fonctionnement de la dlgation. En thorie, elle implique le transfert de la responsabilit dune partie de votre domaine un autre organisme. Dans les faits, il sagit de transfrer lautorit sur vos diffrents sous-domaines vers dautres serveurs de noms (notez que nous crivons serveurs et non pas juste serveur ). Les donnes de votre domaine contiendront des pointeurs vers les serveurs de noms qui font autorit sur le sous-domaine, au lieu dinclure les informations concernant le sousdomaine que vous avez dlgu. Dsormais, si lun de vos serveurs de noms reoit une question concernant les donnes du sous-domaine, il rpondra en renvoyant la liste des serveurs de noms contacter.

Types de serveurs de noms


Le standard du DNS dnit deux types de serveurs de noms : les serveurs primaires et les serveurs secondaires. Un serveur-matre primaire (primary master) dune zone acquiert les donnes de la zone partir dun chier local alors quun serveur-matre secondaire (secondary master) les rcupre partir dun autre serveur faisant autorit sur la zone. Ce dernier est appel son serveur-matre. Trs souvent, le serveur-matre est le serveur-matre primaire de la zone, mais ce nest pas une obligation : un serveur-matre secondaire peut charger les donnes de la zone partir dun autre serveur secondaire. Quand un serveur secondaire dmarre, il contacte son serveur-matre et, si ncessaire, rcupre les donnes de la zone : cest ce que lon appelle un transfert de zone. Aujourdhui, on prfre souvent le terme de serveur-esclave (slave) celui de serveur secondaire, mais de nombreuses personnes (et logiciels, parmi lesquels la console DNS de Microsoft) utilisent lancien terme.
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Resolvers

25

Les serveurs primaire et secondaire font tous deux autorit sur la zone. Bien que leur diffrence de nom puisse le suggrer, les esclaves ne sont pas des serveurs de seconde classe. Le DNS dnit ces deux types de serveurs pour faciliter la gestion. Une fois que vous avez cr les donnes de votre zone et initialis un serveur primaire, vous navez pas besoin de copier ces donnes dhte en hte pour crer de nouveaux serveurs pour la zone. Il suft dinitialiser les serveurs-esclaves qui chargent leurs donnes partir du serveur-matre primaire de la zone. Ils ne transfreront les donnes de la zone quen cas de besoin. Les serveurs-esclaves ont un rle important car il est bon dinitialiser plus dun serveur faisant autorit sur une zone, an dassurer la redondance, dabsorber les problmes de charge et doffrir un serveur physiquement proche tous les htes dune zone. Les serveurs-esclaves rendent tout ceci possible et grable. Il est insufsant de caractriser un serveur particulier par son type, serveur-matre primaire ou serveur-esclave. En effet, nous avons indiqu prcdemment quun serveur peut simultanment faire autorit sur plusieurs zones. Un serveur peut trs bien tre matre primaire pour une zone et esclave pour une autre. Toutefois, la plupart des serveurs sont, soit primaires, soit esclaves pour la plupart des zones quils chargent. Lorsque nous qualierons un serveur de serveur primaire ou desclave, nous signierons implicitement quil est serveur primaire ou esclave pour la plupart des zones sur lesquelles il fait autorit.

Fichiers de zone
Les chiers partir desquels les serveurs-matres primaires chargent leur zone sont souvent appels les chiers de donnes de la zone. Nous y ferons souvent rfrence par les expressions de chiers de donnes, chiers de zone ou base de donnes. Les serveursesclaves peuvent aussi charger leurs donnes partir de chiers. En effet, les esclaves sont en gnral rgls pour sauvegarder les donnes dune zone quils ont transfre partir dun serveur, vers un chier de donnes. Si lesclave tait ultrieurement arrt puis redmarr, il lirait tout dabord le chier de sauvegarde puis vrierait que les donnes sont toujours valables. Ces deux actions permettent, dune part dviter un transfert de zone si les donnes nont pas volu, et dautre part, de dmarrer mme si le matre est arrt. Les chiers de donnes contiennent des enregistrements de ressource qui dcrivent la zone, cest--dire tous les htes dune zone ainsi que les dlgations de sous-domaine. BIND autorise aussi des directives spciales dinclusion du contenu dun chier dans un chier de donnes, un peu comme la directive #include du langage C.

Resolvers
Les resolvers sont les clients des serveurs de noms. Les programmes qui ont besoin dune information venant de lespace de noms utilisent le resolver. Le resolver gre :

linterrogation dun serveur de noms ; linterprtation des rponses (qui sont, soit un enregistrement de ressources, soit un
message derreur) ;

le renvoi de linformation au programme demandeur.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

26

Chapitre 2 Principes du DNS

Dans BIND, le resolver est simplement un jeu de procdures lies aux programmes comme ssh ou ftp. Ce nest pas un processus spar. Le resolver compte presque entirement sur le serveur de noms interrog : il gnre une requte, lenvoie, attend une rponse, renvoie la requte sil ne reoit pas de rponse et cest tout. Lessentiel du travail (trouver une rponse la requte) se fait sur le serveur. Le document de spcication du DNS appelle ce type de resolver, un resolver lmentaire (stub resolver). Dautres mises en uvre du DNS peuvent avoir des resolvers plus sophistiqus qui peuvent, par exemple, suivre des rfrences pour localiser les serveurs de noms faisant autorit sur une zone spcique.

Rsolution de noms
Les serveurs de noms sont spcialiss dans la recherche de donnes lintrieur de lespace de noms, ce qui est ncessaire tant donnes les fonctions limites de certains resolvers. Ils peuvent non seulement renvoyer des informations concernant des zones sur lesquelles ils font autorit, mais aussi rechercher dans lespace de noms des donnes sur lesquelles ils ne font pas autorit. Ce processus sappelle la rsolution de noms ou simplement la rsolution. Puisque lespace de noms est structur comme un arbre invers, un serveur na besoin que de peu dlments pour trouver un chemin vers un point quelconque de larbre : il lui faut connatre les noms et adresses des serveurs de noms de la racine. Un serveur de noms peut demander un serveur de la racine tout nom de lespace de noms et le serveur de la racine effectuera alors sa propre recherche.

Serveurs de noms de la racine


Les serveurs de noms de la racine savent o se trouvent les serveurs de noms de chaque zone de niveau suprieur (en fait, la plupart des serveurs de la racine font autorit sur les domaines gnriques de niveau suprieur). Pour rpondre une requte concernant un nom quelconque, les serveurs de la racine peuvent au minimum renvoyer les noms et les adresses des serveurs faisant autorit pour le domaine de niveau suprieur concernant le nom recherch. Puis les serveurs de niveau suprieur peuvent renvoyer la liste des serveurs (noms et adresses) faisant autorit pour le domaine de second niveau concernant le nom recherch. Chaque serveur de noms interrog renvoie soit une indication permettant de poursuivre la recherche, soit la rponse la requte elle-mme. Les serveurs de noms de la racine ont une importance fondamentale pour la rsolution de noms. Ainsi, le DNS fournit des mcanismes pour limiter leur surcharge, tels que la mmoire cache qui sera tudie plus loin. Cependant, en labsence dindication supplmentaire, la rsolution devra commencer au niveau des serveurs de noms de la racine. Ces serveurs sont cruciaux pour le fonctionnement du DNS ; si aucun deux nest accessible sur lInternet durant une longue priode, aucune requte naboutira plus. Pour viter cela, lInternet dispose ( ce jour) de 13 serveurs de noms de la racine, rpartis en diffrents endroits du rseau6. Lun deux est sur PSINet, une pine dorsale commer6. En ralit, les 13 serveurs logiques de la racine englobent bien plus de serveurs physiques. La plupart des serveurs de la racine sont soit des ensembles partage de charge derrire une adresses IP unique ou un groupe de serveurs distribus utilisant la mme adresse IP soit une combinaison , des deux.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Rsolution de noms

27

ciale de lInternet, un autre sur le rseau scientique de la NASA, deux en Europe, un au Japon. tant donne leur position centrale et malgr leur nombre, les serveurs de la racine sont en permanence occups et le trac vers chacun deux est trs dense. Des mesures rcentes ont montr que certains serveurs recevaient plusieurs milliers de requtes par seconde. Malgr cette charge importante sur les serveurs de la racine, la rsolution de noms dans lInternet fonctionne bien. La gure 2-12 montre le processus de rsolution de ladresse dun hte rel dun domaine rel, en particulier les changes dinformations pour le parcours de lespace de noms.

recherche de ladresse de girigiri.gbrmpa.gov.au indications sur les serveurs de noms de au

serveur de ""

recherche de ladresse de girigiri.gbrmpa.gov.au

serveur de noms local

indications sur les serveurs de noms de gov.au

serveur de au

au

nz

sg

recherche de ladresse de girigiri.gbrmpa.gov.au

requte de rsolution

rponse

indications sur les serveurs de noms de gbrmpa.gov.au

serveur de gov.au

gov

edu

recherche de ladresse de girigiri.gbrmpa.gov.au adresse de girigiri.gbrmpa.gov.au

serveur de gbrmpa.gov.au

sa

ips

gbrmpa

resolver

Figure 2-12. Rsolution de girigiri.gbrmpa.gov.au dans lInternet


Le serveur de noms local demande ladresse de girigiri.gbrmpa.gov.au un serveur de la racine, qui renvoie des indications sur les serveurs de noms de au. Puis il pose la mme question lun des serveurs de au, qui renvoie des indications sur les serveurs de noms de gov.au. Les serveurs de gov.au renvoient une indication sur les serveurs de noms de gbrmpa.gov.au. Enn, le serveur de noms local demande ladresse recherche un serveur de noms de gbrmpa.gov.au et obtient la rponse.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

28

Chapitre 2 Principes du DNS

Mode rcursif
On peut remarquer une norme diffrence entre les tches des diffrents serveurs de lexemple prcdent. Quatre des serveurs se contentent de renvoyer la meilleure rponse dont ils disposent dj, le plus souvent des rfrences dautres serveurs. Ils nenvoient pas eux-mmes de requtes pour trouver la rponse complte la question. Par contre, le cinquime serveur, interrog directement par le resolver, effectue des requtes successives tant quil na pas reu la rponse complte. Pourquoi le serveur de noms local na-t-il pas simplement renvoy le resolver vers un autre serveur de noms ? Parce quun resolver lmentaire ne dispose pas de lintelligence pour suivre une rfrence. Et comment le serveur local sait-il quil ne doit pas rpondre par une rfrence ? Parce que le resolver a gnr une requte rcursive. Il existe deux sortes de requtes : rcursives ou itratives (ou non rcursives). Les requtes rcursives induisent lessentiel de la charge sur un serveur de noms prcis. Le mode rcursif, ou la rsolution rcursive, est le nom du processus de rsolution excut par un serveur de noms lorsquil reoit une requte rcursive. De la mme manire quun algorithme rcursif en programmation, le serveur de noms rpte le mme processus de base (linterrogation dun serveur distant et lutilisation des rfrences dautres serveurs de noms) jusqu ce quil obtienne une rponse. De mme, le mode itratif, ou rsolution itrative, est le nom du processus de rsolution excut par un serveur de noms lorsquil reoit une requte itrative. En mode rcursif, un resolver envoie une requte rcursive un serveur de noms pour demander des informations propos dun nom particulier. Le serveur de noms interrog est alors oblig de rpondre compltement la question pose ou de renvoyer une erreur indiquant que la donne du type requis ou le nom demand nexiste pas. Le serveur de noms ne peut pas simplement renvoyer le demandeur vers un autre serveur de noms, en raison du mode rcursif de la demande. Si le serveur interrog ne fait pas autorit sur les informations demandes, il doit poser la question un autre serveur. Il pourrait lui envoyer une requte rcursive, lobligeant son tour trouver la rponse et la lui renvoyer. Il pourrait galement lui envoyer une requte itrative et lui donner la possibilit de renvoyer des rfrences dautres serveurs hirarchiquement proches du nom recherch. Les mises en uvres actuelles sont par dfaut courtoises et utilisent la seconde mthode, celle qui consiste suivre successivement les diffrentes rfrences renvoyes jusqu ce quune rponse soit trouve7. Un serveur de noms qui reoit une requte rcursive laquelle il ne peut pas lui-mme rpondre interrogera avec la mme requte le serveur de noms quil sait tre hirarchiquement le plus proche du nom recherch. Ainsi, si le serveur de noms reoit une requte rcursive pour ladresse correspondant au nom girigiri.gbrmpa.gov.au, il regardera tout dabord sil connat les serveurs de noms faisant autorit sur girigiri.gbrmpa.gov.au. Si cest le cas, il enverra la requte lun deux. Sinon, il regardera sil connat les serveurs de noms de gbrmpa.gov.au, puis de gov.au et enn de au. Dans le pire

7.

Sauf dans le cas o un serveur de noms est rgl pour rediriger toutes les requtes non rsolues vers un serveur de noms dtermin, appel un forwarder (voir le Chapitre 10).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Rsolution de noms

29

des cas, la recherche ira jusqu la zone racine, puisque chaque serveur de noms connat les noms et les adresses des serveurs de la racine. Lutilisation du serveur hirarchiquement le plus proche garantit que le processus de rsolution est aussi court que possible. Un serveur de berkeley.edu recevant une requte rcursive pour ladresse de waxwing.ce.berkeley.edu na pas besoin de consulter un serveur de la racine ; il lui suft de suivre les informations de dlgation pour atteindre les serveurs de ce.berkeley.edu. De mme, un serveur qui viendrait juste de rechercher un nom dans ce.berkeley.edu na pas besoin de redmarrer une rsolution la racine pour rechercher un nouveau nom dans ce.berkeley.edu (ou berkeley.edu) ; nous dvelopperons ce sujet la section Mmoire cache, page 32. Un serveur de noms recevant une requte rcursive retransmet la mme requte que celle reue du resolver, par exemple celle pour ladresse de waxwing.ce.berkeley.edu. Il nenvoie jamais de requtes simplies pour requrir les adresses des serveurs de ce.berkeley.edu ou de berkeley.edu, bien que cette information existe dans lespace de noms. En effet, lenvoi de requtes simplies pourrait poser des problmes : il nexiste peut-tre pas de serveur pour ce.berkeley.edu (qui pourrait tre une partie de la zone berkeley.edu). Il se pourrait aussi quun serveur de edu ou de berkeley.edu connaisse dj ladresse de waxwing.ce.berkeley.edu. Une requte simplie concernant berkeley.edu ou ce.berkeley.edu ne prendrait alors pas en compte cette dernire information.

Mode itratif
Une rsolution itrative ne demande pas autant de travail au serveur interrog quune rsolution rcursive. En mode itratif, un serveur rpond du mieux possible au demandeur avec ce quil sait dj. Il ne gnre aucune nouvelle requte. Le serveur interrog recherche la solution dans ses donnes locales (y compris la mmoire cache, dont nous parlerons prochainement). Sil ny trouve pas la rponse, il cherche les nom et adresse des serveurs de noms les plus proches du nom recherch dans ses donnes locales, et renvoie ces informations pour aider le demandeur poursuivre sa recherche. Notons que la rponse contient la liste de tous les serveurs de noms quil connat ; ce sera au demandeur den choisir un pour lancer la requte suivante.

Choix du serveur de noms interroger


De nombreux lecteurs avertis se demandent probablement comment le serveur qui reoit la requte rcursive choisit un serveur parmi ceux qui font autorit sur une zone. Ainsi, nous avons dit que lInternet contient aujourdhui 13 serveurs de la racine. Le serveur choisit-il le premier qui apparat dans la liste ou choisit-il alatoirement ? Les serveurs de noms BIND utilisent la mtrique du temps daller-retour (RoundTrip Time ou RTT) pour choisir lun des serveurs faisant autorit sur une zone. Le RTT est la mesure du temps mis pour obtenir une rponse une requte. chaque fois quun serveur de noms BIND envoie une requte vers un serveur de noms distant, il dmarre un temporisateur interne. Il larrte la rception de la rponse et mmorise le dlai. Lorsque le serveur de noms doit choisir un serveur de zone qui poser une question, il choisit celui qui a le plus petit temps daller-retour. Tant que BIND na pas interrog un serveur spcique, il lui attribue une valeur de temps daller-retour alatoire, mais infrieure toute ralit. Cela permet de sassurer

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

30

Chapitre 2 Principes du DNS

que BIND interrogera tous les serveurs de noms faisant autorit sur une zone, dans un ordre alatoire, avant den lire un. Pour rsumer, cet algorithme simple permet BIND de se verrouiller rapidement sur le serveur de noms le mieux plac pour une zone, sans gnrer de charge supplmentaire lie un mcanisme de mesure sophistiqu.

Processus complet
En clair, le processus de rsolution complet a lallure indique en gure 2-13.
Serveurs de noms 1 Le serveur de noms A reoit une requte rcursive en provenance du resolver. 2 A envoie une requte itrative B. 3 B renseigne A au sujet dautres serveurs de noms, dont C. 4 A envoie une requte itrative C. 5 C renseigne A au sujet dautres serveurs de noms, dont D. 6 A envoie une requute itrative D. 7 D rpond. 8 A envoie la rponse au resolver.
8
rponse

B
3
renseignement

C
5
renseignement

2
requte

requte

4 6 requte 7
rponse

requte

resolver

Figure 2-13. Le processus de rsolution


Un resolver interroge un serveur de noms local qui, son tour, interroge dautres serveurs de noms en vue de rpondre au demandeur. Chaque serveur interrog donne une indication sur un serveur faisant autorit sur une zone de plus en plus profonde dans lespace de noms et de plus en plus proche hirarchiquement du domaine recherch. Finalement, le serveur de noms local interroge le serveur de noms faisant autorit et ce dernier renvoie une rponse. Le serveur de noms local utilise toutes les rponses reues, que ce soient des rfrences ou la rponse, pour mettre jour le RTT du serveur qui rpond an de choisir le serveur de noms interroger par la suite.

Rsolution dune adresse vers un nom


Un lment majeur non trait jusquici dans la prsentation du processus de rsolution est celui de la rsolution dune adresse vers un nom. Cette rsolution produit des afchages humainement comprhensibles (dans les chiers de journalisation, par exemple). Elle est galement utilise dans certains tests dautorisation. Par exemple, les htes Unix font correspondre les adresses des noms pour les comparer aux informa-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Rsolution de noms

31

tions des chiers .rhosts et hosts.equiv. Lorsquon utilise des tables locales dhtes, la correspondance est aise : une simple recherche squentielle dans un chier suft. Par contre, avec le DNS, cette correspondance nest pas aussi simple. Les donnes de lespace de noms, dont les adresses, sont indexes par des noms. tant donn un nom, la recherche dune adresse est relativement facile. Par contre, la recherche du nom correspondant une adresse spcique ncessiterait, de prime abord, un parcours exhaustif de toutes les donnes lies chaque domaine de larbre. En ralit, il existe une meilleure solution. Puisquil est facile de trouver des informations une fois quon dispose du nom qui les rfrence, pourquoi ne pas crer une section de lespace de noms qui utiliserait des adresses comme noms dindex ? Dans lespace de noms de lInternet, cette section de lespace de noms est le domaine in-addr.arpa. Les nuds du domaine in-addr.arpa sont composs des numros de la reprsentation en dcimal point des adresses IP (cette reprsentation, la plus communment utilise, montre une adresse IP sur 32 bits sous la forme de quatre nombres allant de 0 255, spars par des points). Le domaine in-addr.arpa, par exemple, pourrait avoir jusqu 256 sous-domaines, chacun deux correspondant chaque valeur possible du premier octet dune adresse IP Chacun de ces sous-domaines pourrait avoir son tour 256 sous. domaines correspondant aux valeurs possibles du second octet. Enn, au quatrime niveau, des enregistrements de ressource attachs au quatrime octet donnent le nom complet de lhte ou du rseau correspondant cette adresse IP Lensemble forme un . norme domaine : in-addr.arpa ( gure 2-14) est sufsamment spacieux pour contenir chaque adresse de lInternet.
"" adresse IP 15.16.192.152 arpa in-addr

255

15

255

16

255

192

255

152 machine winnie.corp.hp.com

Figure 2-14. Le domaine in-addr.arpa

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

32

Chapitre 2 Principes du DNS

Notons que lors de la lecture du nom, ladresse IP apparat inverse car le nom est nonc de la feuille vers la racine. Ainsi, si ladresse IP de lhte winnie.corp.hp.com est 15.16.192.152, le sous-domaine correspondant dans in-addr.arpa est 152.192.16.15.inaddr.arpa, qui renvoie au nom quali winnie.corp.hp.com. Les adresses IP auraient pu tre reprsentes en sens inverse dans lespace de noms, avec le premier octet de ladresse IP au pied du domaine in-addr.arpa. De cette manire, les adresses IP auraient t lues facilement dans les noms. Quoiquil en soit, les adresses IP sont hirarchiques, tout comme les noms : les administrateurs peuvent subdiviser leur espace dadresses en sous-rseaux et dlguer la numrotation. La diffrence entre les adresses IP et les noms est que les adresses sont de plus en plus spciques de gauche droite, alors que les noms le sont de moins en moins ( gure 2-15).

plus spcifique

moins spcifique

winnie . corp . hp . com 152 . 192 . 16 . 15


Figure 2-15. Noms et adresses hirarchiques
Le premier octet de ladresse IP apparaissant en haut de larbre, il est possible de dlguer lautorit sur le domaine in-addr.arpa tout au long du parcours de larbre. Par exemple, le domaine 15.in-addr.arpa, qui contient les correspondances adresse/nom pour tous les htes dont ladresse IP commence par 15, peut tre dlgu aux administrateurs du rseau 15/8. Cela serait impossible si les octets apparaissaient dans lautre sens : dans ce cas, 15.in-addr.arpa reprsenterait tous les htes dont ladresse IP se termine par 15, ce qui nest pas un domaine facile dlguer.

Mmoire cache
Le processus complet de rsolution pourrait paratre tortueux et obscur aux utilisateurs habitus une simple recherche dans un chier dhtes, mais il est habituellement trs efcace. Une des caractristiques qui lacclre notablement est lutilisation de la mmoire cache. Un serveur de noms effectuant une recherche rcursive peut avoir envoyer de nombreuses requtes pour trouver la rponse. Au cours de ses recherches, il apprend beaucoup sur lespace de noms. chaque fois quil se rfre une nouvelle liste de serveurs de noms, il apprend que ces serveurs font autorit sur une certaine zone et il retient leur adresse. la n du processus de rsolution, lorsquil obtient enn linformation recherche, il peut mmoriser toutes ces donnes dans une mmoire cache pour une utilisation ultrieure. Les serveurs de noms BIND mettent mme en uvre un cache ngatif : si un serveur faisant autorit rpond une requte en indiquant que le

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Mmoire cache

33

nom ou le type des donnes recherches nexiste pas, le serveur ayant pos la question mmorise temporairement cette information. Les serveurs de noms mmorisent les donnes dans une mmoire cache an de pouvoir rpondre rapidement des requtes successives. La prochaine fois quun resolver interroge le serveur de noms sur des donnes quil connat dj, la rponse est plus rapide. Le serveur de noms a peut-tre mmoris la rponse, positive ou ngative, auquel cas il renvoie simplement la rponse au resolver. Mme sil na pas la rponse complte, il sait peut-tre dj des choses sur les serveurs de noms faisant autorit sur la zone recherche et il peut alors leur poser directement des questions. Supposons que notre serveur de noms ait dj recherch ladresse de eecs.berkeley.edu. Au cours de ce processus, il a mmoris dans sa mmoire cache les noms et adresses des serveurs de noms de eecs.berkeley.edu et de berkeley.edu, ainsi que ladresse de lhte eecs.berkeley.edu. Maintenant, si un resolver demande ladresse de baobab.cs.berkeley.edu notre serveur de noms, ce dernier peut se passer dinterroger les serveurs de noms de la racine. Voyant que berkeley.edu est actuellement connu comme le parent hirarchiquement le plus proche de baobab.cs.berkeley.edu, notre serveur de noms peut commencer sa recherche en interrogeant le serveur de berkeley.edu ( gure 2-16). Dautre part, si notre serveur de noms trouvait que ladresse de eecs.berkeley.edu nexistait pas, la prochaine requte concernant ce nom, il pourrait simplement rpondre partir de sa mmoire cache.

B
requte

serveurs de noms de la racine

C D
2
renseignement

serveurs de noms de berkeley.edu

1 serveur de noms 3
requte

E F

1 recherche de ladresse de baobab.cs.berkeley.edu 2 renseignements concernant F et G 3 recherche de ladresse de baobab.cs.berkeley.edu 4 adresse de baobab.cs.berkeley.edu 4
rponse

serveurs de noms de cs.berkeley.edu

Figure 2-16. Rsolution de nom pour baobab.cs.berkeley.edu


En plus dacclrer la rsolution, lutilisation dune mmoire cache vite dinterroger nouveau les serveurs de noms de la racine, ce qui signie que la rsolution nest pas exagrment dpendante des serveurs de la racine.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

34

Chapitre 2 Principes du DNS

Dure de vie
Les serveurs de noms ne peuvent pas garder ternellement les donnes dans leur mmoire cache. Sils le faisaient, les modications sur les serveurs faisant autorit ne seraient jamais vues du reste du rseau : les serveurs de noms distants continueraient travailler avec les donnes en mmoire cache. Par consquent, ladministrateur de chaque zone dcide dune dure de vie (TTL pour Time To Live) pour les donnes de sa zone. Le TTL indique chaque serveur la dure pendant laquelle il est autoris conserver une donne en mmoire cache. Aprs coulement de ce dlai, le serveur de noms doit abandonner les donnes en mmoire et obtenir les nouvelles donnes partir des serveurs faisant autorit. Cela sapplique galement aux informations ngatives : un serveur de noms doit oublier une rponse ngative, pour le cas o des donnes auraient t ajoutes aux serveurs de noms faisant autorit. Le choix dune dure de vie pour les donnes revient essentiellement trouver un compromis entre performance et cohrence. Un petit TTL garantira une cohrence forte des donnes sur lensemble du rseau, car les serveurs de noms distants les oublieront plus rapidement et seront forcs dinterroger plus souvent un serveur de noms faisant autorit. Par contre, il augmentera la charge du serveur et le temps moyen de rsolution des informations pour le domaine. Un TTL lev diminuera le temps moyen de rsolution car les donnes pourront tre gardes plus longtemps en mmoire cache. Par contre, les informations seront incohrentes plus longtemps en cas de modication sur les serveurs de noms faisant autorit. Et maintenant, trve de thorie ! Vous devez tre impatient de passer laction. Il reste quelques travaux effectuer avant daborder la mise en uvre dune zone et de ses serveurs de noms, et cest ce que nous vous proposons au chapitre suivant.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

3
Premiers pas dans la mise en uvre
Qui tes-vous ? finit par demander le Faon. Quelle douce voix il avait ! Je voudrais bien le savoir ! pensa la pauvre Alice. Elle rpondit, non sans quelque tristesse : Pour linstant, rien du tout Rflchissez encore, dit le Faon ; ce que vous venez daffirmer nest pas admissible. Alice rflchit, mais sans rsultat. Pourrais-tu, je te prie, me dire qui tu es toi-mme ? demanda-t-elle timidement. De le savoir, je crois que cela pourrait maider un peu. Je vous le dirai si vous voulez bien que nous fassions ensemble quelques pas, rpondit le Faon. Ici, je ne saurais men souvenir.

Maintenant que vous connaissez les principes sous-jacents au systme de noms de domaine, nous pouvons aborder des dtails plus pratiques. Avant dinitialiser une zone, il est ncessaire de se procurer le logiciel BIND. Il est habituellement standard dans la plupart des systmes dexploitation Unix, toutefois vous pouvez avoir besoin de le tlcharger pour proter des dernires amliorations et des volutions lies la scurit. Vous devez ensuite choisir un nom de domaine pour votre zone, tche parfois complexe, ncessitant de slectionner un domaine-parent adquat dans lespace de noms de lInternet. Vous devez alors contacter ladministrateur de la zone retenue. Une chose la fois : commenons par le tlchargement de BIND.

Tlcharger BIND
Si vous projetez de construire et dexploiter votre propre zone, vous avez tout dabord besoin de BIND. Mme si vous envisagez de sous-traiter lexploitation de votre zone, il peut tre intressant, par exemple, dutiliser BIND pour tester en local vos chiers de donnes de zone avant de les transmettre ladministrateur distant.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

36

Chapitre 3 Premiers pas dans la mise en uvre

La plupart des systmes Unix incluent BIND en standard dans leur couche rseau TCP/ IP Cette couche tant gnralement intgre de base au systme dexploitation, vous . disposez ainsi de BIND directement. Mme si la couche rseau est facture sparment, elle aura probablement dj t acquise, puisque si vous envisagez de mettre en uvre le DNS, cest que vous utilisez dj sufsamment le rseau, nest-ce-pas ? Si vous ne disposez pas de BIND dans votre systme Unix, ou si vous en voulez la dernire version, vous pouvez tlcharger son code-source, disponible gratuitement. Les versions 8.4.7 et 9.3.2 de BIND sont les plus rcentes au moment o nous crivons, et sont accessibles sur le site web de lInternet Systems Consortium, http://www.isc.org/, ainsi que par FTP anonyme sur ftp.isc.org dans /isc/bind/src/8.4.7/bind-src.tar.gz ainsi que dans /isc/bind9/9.3.2/bind-9.3.2.tar.gz, respectivement La compilation sur la plupart des systmes Unix est assez simple1. LISC indique dans le chier src/INSTALL (BIND 8) et README (BIND 9), la liste des systmes Unix, Linux et mme Windows, sur lesquels BIND est rput se construire sans problme. Ces chiers indiquent aussi les systmes de type Unix ou non (quelquun, quelque part, travaille-t-il avec MPE ? ) ayant dj support BIND et sur lesquels il se compilera sans doute sans difcult. Dans tous les cas, nous conseillons fortement de lire toutes les sections du chier qui concernent votre systme dexploitation. Nous donnons aussi des indications pour la compilation de BIND 8.4.7 et 9.3.2 sur Linux lAnnexe C. Si BIND est dj livr avec votre systme dexploitation, vous vous demandez peut-tre ce quune version plus rcente pourrait vous apporter. Voici un aperu de ses dernires amliorations : Rsolution de failles de scurit Le meilleur argument en faveur de la version de BIND la plus rcente est celui de la protection contre les attaques subies par les serveurs de noms, certaines dentre elles tant dj bien connues. Les versions 8.4.7 et 9.3.2 de BIND rsistent toutes les attaques dj identies alors que les versions antrieures sont plus vulnrables. Historiquement, BIND 9 dispose dun meilleur suivi de scurit que BIND 8 (cependant, des vulnrabilits rsiduelles signicatives ont t dcouvertes dans BIND 9). Si vous exploitez un serveur de noms sur lInternet, nous vous recommandons dutiliser BIND 9.3.2 ou au moins BIND 8.4.7 (ou leurs successeurs). lments de scurisation BIND 8 et 9 acceptent des listes daccs pour les requtes, les transferts de zone et les mises jour dynamiques. BIND 9 intgre aussi les vues (views), qui permettent dexcuter plusieurs serveurs virtuels sur une seule machine. Certains serveurs de noms, notamment ceux fonctionnant sur des htes bastion ou des htes scurit critique, peuvent avoir besoin de ces fonctions. Nous les dcrivons au Chapitre 11.

1.

La compilation des premires versions de BIND 9 (avant 9.1.0) peut tre dlicate car celles-ci requirent pthreads dont la mise en uvre est dfectueuse sur certains systmes. Cette ncessit est contournable partir de BIND 9.1.0 en utilisant loption --disable-threads de congure.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Tlcharger BIND

37

Mise jour dynamique BIND 8 et 9 acceptent le standard de mise jour dynamique (Dynamic Update) dcrit dans la RFC 2136. Il autorise des agents mettre jour les donnes de la zone par lenvoi de messages dajout ou de suppression denregistrement de ressource. Les versions antrieures de BIND nont pas cette capacit. BIND 9 accepte des descriptions dautorisation de mise jour dynamique plus nes que celles de BIND 8. Nous dcrivons la mise jour dynamique au Chapitre 10. Transfert incrmental de zone Les versions actuelles de BIND 8 (telles que 8.4.7) et BIND 9 acceptent le transfert incrmental de zone, qui permet un serveur-esclave de ne demander son matre que les changements dans la zone. Les transferts de zone sont alors plus efcaces et plus rapides, ce qui est particulirement important pour les zones de grande taille et en constante volution. Daprs notre exprience, la mise en uvre dans BIND 9 est plus robuste que celle dans BIND 8. Si donc, la lecture de tout cela, il vous semble que vous avez besoin de BIND 8 ou 9 et que ni lun, ni lautre nest disponible en standard sur votre systme dexploitation, tlchargez son code source et compilez-le.

Listes de diffusion et forums


Les instructions de compilation de BIND pour toutes les versions possibles dUnix ncessiteraient un ouvrage entier de la mme taille que celui-ci. Nous vous renvoyons donc la liste de diffusion bind-users@isc.org ou au forum comp.protocols.dns.bind de Usenet2. Ceux qui contribuent ces listes peuvent normment vous aider lors dun portage de BIND. Avant de les contacter, il est ncessaire de vous assurer que le portage dont vous avez besoin na pas dj t ralis en consultant larchive de la liste ( ladresse http://www.isc.org/index.pl?/ops/lists). Consultez galement la page daccueil de BIND lISC (http://www.isc.org/sw/bind) pour des informations concernant votre systme dexploitation. Les participants la liste namedroppers sont impliqus dans les travaux du groupe de travail de lIETF sur les extensions des caractristiques du DNS, DNSEXT. Ainsi, une discussion sur des propositions de nouveaux types denregistrement trouvera sa place dans la liste namedroppers plutt que dans les listes de BIND. Pour des informations sur la charte de DNSEXT, consultez http://www.ietf.org/html.charters/dnsext-charter.html. Ladresse de la liste namedroppers est namedroppers@ops.ietf.org. La liste est en relation avec le groupe de discussion comp.protocols.dns.std. Pour rejoindre cette liste, il vous faut envoyer un courriel namedroppers-request@ops.ietf.org contenant subscribe namedroppers comme corps de message.
2. Pour poser une question dans une liste de diffusion, il suft dy envoyer un courriel. Si vous voulez adhrer la liste, vous devez tout dabord envoyer un courriel au gestionnaire de la liste, en lui demandant dy ajouter votre adresse (ncrivez pas directement dans la liste pour une demande dadhsion). Habituellement, on peut joindre le gestionnaire dune liste ladresse listrequest@domaine, si list@domaine est ladresse de la liste de diffusion. Pour joindre le gestionnaire de la liste du groupe de travail sur BIND, par exemple, vous devez contacter bind-usersrequest@isc.org.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

38

Chapitre 3 Premiers pas dans la mise en uvre

Recherche dadresse IP
Nous vous avons indiqu plusieurs noms dhtes accessibles par FTP et les listes de diffusion mentionnes incluent galement des noms de domaine. Cela prouve encore limportance du DNS : il donne accs de nombreux logiciels ou conseils utiles. Malheureusement, cest un serpent qui se mord la queue : il est impossible dexpdier un courriel une adresse sous la forme dun nom moins davoir dj initialis le DNS, et on ne peut poser de questions sur linitialisation dun domaine dans la liste sans utiliser son nom. Nous pourrions vous donner les adresses IP des htes mentionns, mais comme les adresses IP changent souvent (par rapport la dure de vie de cet ouvrage), nous allons vous indiquer comment utiliser temporairement le serveur de noms de quelquun dautre pour retrouver les informations utiles. Si votre hte est connect lInternet et dispose du programme nslookup, vous pouvez interroger lespace de noms de lInternet. Pour obtenir ladresse IP de ftp.isc.org, par exemple, vous pouvez utiliser :
% nslookup ftp.isc.org. 207.69.188.185

Cela ordonne nslookup dinterroger le serveur de noms ladresse IP 207.69.188.185 pour trouver ladresse IP de ftp.isc.org et devrait produire la rponse suivante :
Server: ns1.mindspring.com Address: 207.69.188.185 Name: ftp.isc.org Address: 204.152.184.110

Vous pouvez maintenant effectuer une connexion FTP vers ftp.isc.org, dont ladresse est 204.152.184.110. Nous avons su que lhte dadresse IP 207.69.188.185 est un serveur de noms grce au FAI (Fournisseur dAccs Internet), Mindspring, car ns1 est lun de ses serveurs de noms. Si votre FAI fournit des serveurs de noms ses clients (il devrait le faire), utilisez lun deux. Si ce nest pas le cas (honte lui !), vous pouvez temporairement utiliser lun des serveurs indiqus dans ce livre3. Tant que vous ne lutiliserez que pour demander quelques adresses IP ou autres informations, les administrateurs ny prteront pas attention. Il est bien sr impoli de faire pointer votre resolver de manire permanente vers le serveur de noms de quelquun dautre. Bien sr, si vous avez accs un hte connect lInternet et qui utilise le DNS, vous pouvez lutiliser pour accder ce dont vous avez besoin via ftp. Une fois que vous avez une version de BIND utilisable, vous pouvez commencer rchir au nom de votre domaine.

3.

NdT : cette possibilit risque dtre de moins en moins accessible, car la politique gnrale actuelle, pour des raisons de scurit, est de rgler les serveurs de noms dun domaine pour quil ne rponde quaux requtes rcursives provenant de ses propres clients.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Choisir le nom de domaine

39

Choisir le nom de domaine


Le choix du nom du domaine est plus complexe quil ny parat, car il implique la fois de devoir choisir un nom et de trouver un parent. En dautres termes, vous avez besoin de vous situer dans lespace de noms de lInternet ainsi que de dcider comment vous voulez nommer votre petit coin de lespace. La premire tape consiste se choisir une position dans lespace de noms. Le plus simple est dobserver lespace de noms partir de son sommet, de choisir un domaine de niveau suprieur, puis un de ses sous-domaines. Pour avoir une ide de lallure de lInternet (au-del de ce que nous vous en avons dit), il est ncessaire dy tre connect. Vous navez pas obligatoirement besoin dun hte dont le systme de noms de domaine soit initialis, mais vous devrez alors emprunter le service de noms dun autre serveur (comme dans notre exemple ftp.isc.org).

propos de lenregistrement de domaine


Avant daller plus loin, il est ncessaire de dnir les termes registry, registrar et registration. Ils ne sont pas issus des standards du DNS mais de lorganisation actuelle de lInternet. Un registry est un organisme responsable de la gestion dun domaine suprieur (ou plutt dune zone). Ses chiers de donnes contiennent une dlgation pour chaque sous-domaine du domaine suprieur. Dans la structure actuelle de lInternet, un domaine suprieur ne peut pas avoir plus dun registry. Un registrar (bureau denregistrement) ralise linterface entre les clients et le registry ; il effectue les enregistrements de domaine et fournit des services. Une fois que le client a choisi un sous-domaine, le registrar soumet au registry les informations de zone ncessaires pour dlguer le sousdomaine vers les serveurs de noms dsigns par le client. En quelque sorte, le registry agit comme un grossiste de dlgation pour une zone spcique, le registrar agissant alors comme un revendeur, gnralement pour plusieurs registry. Lenregistrement (registration) est le processus par lequel un client indique un registrar vers quels serveurs de noms dlguer la gestion dun sous-domaine ainsi que le nom des contacts techniques et administratifs. Ainsi, ce jour, Public Interest Registry gre le registry pour org, et VeriSign le registry pour les domaines suprieurs com et net. Il y a ensuite des dizaines de registrars pour com, net et org, comme par exemple GoDaddy.com, Register.com, Network Solutions ou Gandi en France. Quant lui, lorganisme EDUCAUSE est la fois le registry et le seul registrar pour edu. Mais nous nous loignons de notre sujet

Comprendre lespace de noms de lInternet


Si votre organisme est connect lInternet hors des tats-Unis, vous devez choisir un rattachement un domaine gnrique de niveau suprieur tel que com, net ou org, ou bien un des domaines national de niveau suprieur. Les domaines gnriques de niveau suprieur ne sont pas rservs aux tats-Unis. Si votre socit est une multinationale, ou simplement si vous le dsirez, vous rejoindrez un de ces domaines gnriques. Si vous optez pour cette solution, passez directement la section Domaines gnriques de niveau suprieur, page 43.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

40

Chapitre 3 Premiers pas dans la mise en uvre

Si vous choisissez un sous-domaine du domaine national correspondant votre pays, vous devez vrier que ce dernier est formellement en service, puis vous intresser sa structure. Consultez la liste des domaines de niveau suprieur actuels lAnnexe D, page 513 si vous ntes pas certain du nom de celui de votre pays. Certains domaines nationaux, comme nz (Nouvelle Zlande), au (Australie) ou uk (Royaume Uni), sont subdiviss en domaines de second niveau dont les noms, tels que co ou com pour les entits commerciales, retent la structure. Dautres, comme fr (France) ou dk (Danemark), sont subdiviss en une multitude de sous-domaines grs individuellement par des universits ou des socits, tels celui de lUniversit de Sainttienne, univ-st-etienne.fr, ou celui du Danish Unix Users Group, dkuug.dk. De nombreux domaines de niveau suprieur dcrivent leur structure sur leur site web. Si vous ntes pas sr de son URL, commencez votre recherche sur http://www.allwhois.com, qui dispose de liens vers de tels sites. Si le domaine suprieur ne propose pas de serveur web prsentant son organisation mais que vous avez une ide du sous-domaine auquel vous appartiendrez, vous pouvez utiliser un outil comme nslookup pour dcouvrir ladresse de messagerie du contact technique du sous-domaine concern (si nos exemples avec nslookup ne vous sufsent pas, survolez le Chapitre 12 pour une introduction). Pour dcouvrir qui contacter pour un sous-domaine spcique, il faut trouver lenregistrement SOA (start of authority) de la zone. Chaque enregistrement SOA contient ladresse lectronique du contact technique de la zone4 (les autres champs du SOA fournissent des informations gnrales sur la zone ; nous les dcrirons ultrieurement). Par exemple, si vous souhaitez avoir des informations sur le sous-domaine csiro.au, vous pouvez savoir qui le gre en consultant son enregistrement SOA :
% nslookup - 207.69.188.185 > set type=soa Recherche de linformation SOA > csiro.au. pour csiro.au Server: ns1.mindspring.com Address: 207.69.188.185#53 csiro.au origin = zas.csiro.au mail addr = hostmaster.csiro.au serial = 2005072001 refresh = 10800 retry = 3600 expire = 3600000 minimum ttl = 3600 > exit

4.

Le sous-domaine et la zone portent le mme nom, mais lenregistrement SOA fait partie intgrante de la zone, et pas du sous-domaine. Le contact technique indiqu dans cet enregistrement peut ne pas tre en charge de la totalit du sous-domaine (si celui-ci contient des sous-domaines dlgus), mais il est certain quil connat la nalit du sous-domaine.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Choisir le nom de domaine

41

Le champ mail addr est ladresse lectronique de ladministrateur de csiro.au. Pour utiliser cette adresse avec la plupart des outils de messagerie, vous devez remplacer le premier . par @ . Ainsi, hostmaster.csiro.au devient hostmaster@csiro.au5.

whois
Le service whois peut lui aussi vous aider dans linvestigation. Malheureusement, il existe de nombreux serveurs whois (la plupart des domaines suprieurs en possdent un) et ils ne dialoguent pas entre eux. Par consquent, la premire tape consiste trouver quel serveur whois interroger. Le mieux est de commencer avec le site http://www.allwhois.com ( gure 3-1). Nous avons dj indiqu que ce site tient jour une liste des sites web de chaque domaine suprieur national ; il propose galement un service whois uni.

Figure 3-1. Le site web www.allwhois.com


5. Cette forme dadresse de messagerie est un vestige de deux anciens enregistrements du DNS : MB (MailBox) et MG (Mail Group), qui dsignaient respectivement des botes lettres et des listes de diffusion sous la forme de sous-domaines. Cette reprsentation nest plus utilise que dans lenregistrement SOA.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

42

Chapitre 3 Premiers pas dans la mise en uvre

Supposons que nous dsirions nous informer sur un sous-domaine de jp. Nous pouvons slectionner Japan (jp) dans la liste des registries au bas de http://www.allwhois.com/ pour aboutir directement une page web permettant dinterroger le bon serveur whois ( gure 3-2).

Figure 3-2. Linterface web vers le serveur whois de jp


Cest bien sr un excellent site consulter pour les domaines hors des tats-Unis. Une fois que le bon site web est trouv, on a gnralement trouv le registrar. En dehors des tats-Unis, de nombreux domaines nont quun seul registrar. Inversement, certains dentre eux, tels que dk (Danemark), co.uk ou org.uk (Grande Bretagne) en ont plusieurs. Toutefois, la plupart des sites web de registry contiennent des liens vers leurs registrars ; vous pouvez donc utiliser le site web du registry comme point de dpart.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Choisir le nom de domaine

43

Le cas des tats-Unis


Nous avons trait le cas gnral en premier. Passons maintenant aux tats-Unis. Votre choix dpendra beaucoup de ce que fait votre entreprise et de votre souhait pour le nom de domaine. Si vous tes dans lun des cas suivants, nous vous encourageons rejoindre le domaine suprieur us :

coles lmentaires ; collges ; agences dtat ou agences du gouvernement local.


En effet, ces organismes sont historiquement enregistrs sous us, conformment larchitecture dcrite dans la RFC 1480. Dans cette organisation, une cole lmentaire dpend de k12.<tat>.us, o <tat> correspond labrviation postale sur deux caractres du nom de ltat dans lequel se trouve lcole. Une municipalit devrait apparatre sous ci.<tat>.us, et le gouvernement dun comt sous co.<tat>.us. Toutefois, il ny a aucune obligation de suivre cette structure rigide. De nombreuses coles, collges ou gouvernements locaux enregistrent des domaines dans org ou mme com. Le registry qui gre us a assoupli les rgles pour les demandeurs de us : vous pouvez dsormais vous faire enregistrer directement sous lespace local (<tat>.us) voire mme sous lespace tendu. Dans ce dernier, vous pouvez enregistrer, par exemple, acme.us au lieu de acme.co.us. De nombreux utilisateurs prfrent, toutefois, les domaines gnriques bien connus, dcrits la section suivante.

Domaines gnriques de niveau suprieur


Comme nous lavons dj dit, de nombreuses bonnes raisons peuvent vous amener demander votre propre sous-domaine dun domaine gnrique de niveau suprieur, tel que com, edu ou org : vous travaillez pour une entreprise multinationale, vous apprciez le fait que ces domaines sont bien connus ou vous trouvez que votre nom de domaine sonne mieux avec com . Prenons un exemple de choix dun domaine gnrique de niveau suprieur. Supposons que vous tes ladministrateur dun petit rseau dentreprise Hopkins, dans le Minnesota. Vous venez juste dobtenir une connexion lInternet via un FAI. Votre socit na jamais possd plus quune liaison tlphonique commute ; vous ntes donc pas encore enregistr dans lespace de noms de lInternet. Puisque vous tes aux tats-Unis, vous pouvez rejoindre soit le domaine us, soit un domaine gnrique suprieur. Comme votre entreprise a dj une renomme mondiale, vous pensez que us ne serait pas un bon choix et vous envisagez un sousdomaine dun domaine gnrique de niveau suprieur. Mais lequel ? Au moment de lcriture de louvrage, cinq possibilits soffrent vous : biz Un nouveau domaine gnrique de niveau suprieur. com Le domaine gnrique dorigine de niveau suprieur, le plus connu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

44

Chapitre 3 Premiers pas dans la mise en uvre

info Un nouveau domaine gnrique de niveau suprieur. net lorigine rserv aux organismes de gestion des rseaux, mais aujourdhui ouvert tous. org lorigine rserv aux organismes but non lucratif ou non-gouvernementaux, mais aujourdhui ouvert tous. Votre entreprise est connue sous le nom de The Gizmonics Institute et vous souhaitez utiliser le nom de domaine gizmonics.com. Vous utilisez alors votre compte personnel lUMN pour vrier que le nom gizmonics.com est libre :
% nslookup Default Server: ns.unet.umn.edu Address: 128.101.101.101 > set type=any Recherche de tous les types denregistrement > gizmonics.com. pour gizmonics.com Server: ns.unet.umn.edu Address: 128.101.101.101 gizmonics.com gizmonics.com nameserver = ns1.11l.net nameserver = ns2.11l.net

Horreur ! Il semble que le nom gizmonics.com soit dj utilis (mais qui a donc pu avoir cette ide ?). OK, essayons maintenant gizmonic-institute.com qui est plus long, mais encore assez intuitif6 :
% nslookup Default Server: ns.unet.umn.edu Address: 128.101.101.101 > set type=any > gizmonic-institute.com. Server: ns.unet.umn.edu Address: 128.101.101.101 Recherche de tous les types denregistrement pour gizmonic-institute.com

*** ns.unet.umn.edu can't find gizmonic-institute.com.: Non-existent host/domain

Visiblement, gizmonic-institute.com est libre et vous pouvez passer ltape suivante, celle de la recherche du registrar.

Choix dun registrar


Choisir un registrar ? Bienvenue dans le nouveau monde de la comptition ! Jusquau printemps 1999, une unique socit, Network Solutions Inc., tait la fois le registry et
6. Si vous avez des difcults imaginer un nom de domaine adquat, les sites Web de la plupart des registrars fournissent gratuitement des conseils. Par exemple, www.nameboy.com proposera diverses combinaisons de gizmonic et de institut , et mme avec des dclinaisons de ces mots.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Choisir le nom de domaine

45

Quen est-il des caractres non ASCII ?


Certains registrars permettent maintenant denregister des noms comportant des caractres non-ASCII, incluant les caractres accentus des langues europennes. Cette pratique est connue sous le nom de noms de domaines internationaliss (internationalized domain names ou IDN). Cette option est tentante, particulirement si vous travaillez, par exemple, chez Nestl. Mais est-ce que cela en vaut la peine ? proprement parler, non ! Bien que vous puissiez enregistrer de tels noms, il ny a aujourdhui presque pas de logiciels qui sachent les rechercher. Si un utilisateur saisit un caractre accentu dans un navigateur, il y a de fortes chances quil naboutisse pas au bon endroit. Il existe une norme pour coder ces caractres dans les noms de domaines, et nous la prsenterons au Chapitre 17. Mais le navigateur le plus rpandu, Internet Explorer, et la plupart des logiciels de messagerie ne les prennent pas en comptea. Les registrars qui permettent lenregistrement de noms de domaine internationaliss sont contents daccepter votre argent et denregistrer votre nom, mais quasiment personne ne saura lutiliser. Tant que la prise en compte des noms internationaliss ne sera pas largement disponible, la seule utilit dun tel enregistrement pourrait tre de protger un nom de marque.
a. Microsoft a annonc que IE 7.0 supportera les noms de domaine internationaliss.

lunique registrar de com, net et org, ainsi que de edu. Pour la dclaration dun sousdomaine, il sufsait de contacter Network Solutions. En juin 1999, lICANN, lorganisme qui gre lespace de noms (nous lavons mentionn au chapitre prcdent) a introduit la comptition dans la fonction denregistrement dans com, net et org. Il y a maintenant des dizaines de registrars pour com, net et org. Pour plus dinformation, vous pouvez consulter le site de lInterNIC (gr par lICANN) http://www.internic.net/regist.html. Nous ne nous permettrons pas de vous indiquer comment choisir un registrar, mais noubliez pas de vrier le cot de lenregistrement, la rputation du service ainsi que loffre complmentaire de services. Notamment, il faut vrier lexistence de paquetages complets et les possibilits de modication en ligne pour faciliter ladministration.

Vrier lenregistrement dun rseau


Avant de poursuivre, vous devez vrier que votre rseau IP est ofciellement enregistr. Certains registrars ne dlgueront pas de domaine un rseau non enregistr, de mme quil ne pourra pas y avoir de dclaration dans le sous-domaine in-addr.arpa. Un rseau IP dnit une plage dadresses IP Par exemple, le rseau 15/8 est constitu des . adresses IP de 15.0.0.0 15.255.255.255, et le rseau 199.10.25/24 des adresses IP 199.10.25.0 199.10.25.255. Dans le pass, lInterNIC, maintenant gr par lICANN, tait lunique source pour les adresses IP ; il attribuait les numros aux rseaux connects lInternet, en sassurant quil ny avait aucun recouvrement de plages. Aujourdhui, ce rle est largement pris en

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

46

Chapitre 3 Premiers pas dans la mise en uvre

propos de CIDR
Lors de la rdaction de la premire dition de cet ouvrage, lespace dadresses de lInternet sur 32 bits tait divis en trois classes principales : A, B et C. Les rseaux de la classe A sont ceux dont le premier octet (les huit premiers bits) de ladresse IP dsigne le rseau et dont les 24 bits suivants sont grs par lorganisme propritaire du rseau, pour diffrencier ses htes. La plupart des organismes bnciant dun rseau de classe A divisent leur rseau en sous-rseaux, en ajoutant un nouveau niveau hirarchique leur schma de numrotation. Les rseaux de classe B consacrent deux octets lidentication du rseau et deux octets celle de lhte, et les rseaux de classe C, trois octets pour lidentication du rseau et un seul octet pour celle de lhte. Malheureusement, ce schma de rpartition des rseaux ne convient plus. De nombreux organismes ont besoin de plusieurs rseaux de classe C (jusqu 254 htes chacun), sans pour autant ncessiter un rseau de classe B (jusqu 65534 htes). Nombre de ces organismes ayant obtenu un rseau de classe B, ces derniers sont devenus rares. Le routage inter-domaines sans classe (Classless Inter-Domain Routing ou CIDR) tente de rsoudre ce problme. CIDR ne tient plus compte de la rpartition en classe A, B ou C. Plutt que dattribuer un, deux ou trois octets lidentication de rseau, lautorit de gestion peut attribuer nimporte quel nombre de bits contigus de ladresse IP cette identication. Par exemple, si un organisme a besoin dun rseau denviron quatre fois la taille dun rseau de classe B, elle peut recevoir un identiant de rseau de 14 bits, permettant ainsi dutiliser 18 bits (lquivalent de quatre rseaux de classe B) pour la numrotation de ses htes. Lapparition de CIDR rend obsolte la terminologie des classes, bien quelle continue tre utilise dans la conversation. Dsormais, pour dsigner un rseau CIDR, il faut indiquer la valeur de loctet de poids fort attribu un organisme, ainsi que le nombre de bits ncessaires lidentication du rseau ; les deux valeurs sont spares par une barre oblique. Par exemple, 15/8 est lancien rseau de classe A dont le numro commence par les bits 00001111. Lancien rseau de classe B 128.32.0.0 se note maintenant 128.32/16. Le rseau 192.168.0.128/25 est constitu des 128 adresses IP allant de 192.168.0.128 192.168.0.255. charge par les fournisseurs daccs lInternet (FAI, ou ISP pour Internet Service Providers) qui rpartissent entre leurs clients les plages dadresses qui leur sont attribues. Si votre adresse de rseau vient dun FAI, le rseau englobant est probablement dclar au nom de votre FAI. Vous pouvez ventuellement vrier que votre FAI a bien effectu les enregistrements adquats, mais dans la ngative, vous ne pourrez probablement rien faire vous-mme, except le harceler. Si lenregistrement est correct, vous pouvez vous dispenser du reste de cette section.

Il nest pas ncessaire denregistrer les adresses dnies par la RFC 1918 (les rseaux 10/8, 172.16/12 et 192.168/16). En fait, cest mme impossible, puisque ces rseaux sont utiliss par de nombreux organismes.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Choisir le nom de domaine

47

Si votre rseau a t attribu par lInterNIC ou si vous tes un FAI, vous devez vrier son ofcialisation en contactant lorganisme qui la enregistr et uniquement celui-l. En effet, ces organismes, appels registry rgional dInternet (regional Internet registry ou RIR), grent lenregistrement pour diffrentes zones du monde. Pour le continent amricain, ARIN (American Registry of Internet Numbers, http://www.arin.net) gre lespace dadresses IP et lenregistrement de rseau. Pour lAsie et le Pacique, APNIC (Asia Pacic Network Information Center, http://www.apnic.net) remplit la mme fonction, de mme que RIPE Network Coordination Centre (http://www.ripe.net) pour lEurope. LAmrique Latine et les Carabes sont servies pas le Latin America and Caribbean Internet Addresses Registry (LACNIC, www.lacnic.net). Chaque RIR peut dlguer lautorit denregistrement un organisme rgional. Par exemple, LACNIC dlgue lenregistrement pour le Mexique et le Brsil des registries locaux. Il faut donc sassurer de contacter le bon RIR. Si vous ntes pas certain que votre rseau soit enregistr, la meilleure solution est de contacter le service whois fourni par ces organismes. Voici les URL des services whois utiliser : ARIN http://www.arin.net/whois/index.html APNIC http://www.apnic.net/search/index.html RIPE http://www.ripe.net/perl/whois/ LACNIC http://lacnic.net/cgi-bin/lacnic/whois?lg=EN Si votre rseau nest pas enregistr, il est ncessaire de le faire avant dinitialiser votre zone in-addr.arpa. Chaque organisme a ses propres procdures, qui sont gnralement payantes, malheureusement. Vous pouvez aussi dcouvrir que votre rseau est dj attribu votre FAI, auquel cas vous navez rien effectuer auprs du RIR. Une fois que tous vos htes sont dans des rseaux enregistrs, vous pouvez contacter votre domaine-parent.

Enregistrer une zone


Chaque registrar a sa propre politique et ses propres procdures denregistrement, mais la plupart proposent une procdure denregistrement en ligne partir de leur site web. tant donn que vous avez dj choisi votre registrar dans les pages prcdentes, nous supposons que vous connaissez ladresse de son site web. Le registrar a besoin de connatre les adresses et les noms de vos serveurs de noms ainsi que quelques informations administratives (pour facturer le service). Si vous ntes pas connect lInternet, fournissez ladresse des htes qui effectueront le service pour votre compte. Certains registrar exigent que vos serveurs de noms soient oprationnels au moment de votre demande dadhsion (sinon, certains demanderont la date prvue

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

48

Chapitre 3 Premiers pas dans la mise en uvre

pour la mise en service). Si cest le cas, passez au Chapitre 4 et initialisez vos serveurs de noms. Contactez ensuite votre registrar. Vous devrez aussi fournir divers renseignements, tels que le contact administratif et le contact technique de votre zone (qui peuvent tre la mme personne). Si ces derniers ne sont pas encore enregistrs dans la base de donnes whois du registrar, vous devrez fournir des informations complmentaires : nom, adresse postale, numro de tlphone, adresse lectronique, etc. Sils sont dj enregistrs dans whois, indiquez simplement leur rfrence whois (un code alphanumrique unique). Il reste parler du cot de lenregistrement dune nouvelle zone. La plupart des registrars sont des entreprises commerciales et facturent lenregistrement des noms de domaine. Network Solutions, le registrar original de com, net et org, facture 35 $ par domaine et par an pour enregistrer un sous-domaine des domaines gnriques. Si vous avez dj un sous-domaine de com, net ou org et que vous navez reu aucune facture rcemment, il serait bon de vrier les informations de contact concernant votre domaine dans le service whois. Si vous tes directement connect lInternet, vous devriez galement avoir une dlgation pour la zone in-addr.arpa correspondant votre rseau IP7. Par exemple, si vous disposez du rseau 192.201.44/24, vous devriez aussi grer la zone 44.201.192.inaddr.arpa, ce qui vous permettrait de grer la correspondance adresse-IP/nom pour votre rseau. Le Chapitre 4 explique comment initialiser votre zone in-addr.arpa. la section Vrier lenregistrement dun rseau, nous vous avons demand de rpondre plusieurs questions :

Votre rseau est-il une partie de celui dun FAI ? Votre rseau, ou celui du FAI qui englobe le vtre, est-il enregistr ? Si oui, dans quel RIR ?
Vous aurez besoin des rponses ces questions pour obtenir la dlgation de votre zone in-addr.arpa. Si votre rseau est une partie dun rseau englobant attribu un FAI, vous devez contacter ce FAI pour obtenir la dlgation de la zone in-addr.arpa approprie. Chaque FAI a ses propres mthodes pour dlguer une zone in-addr.arpa et sa page web daccueil est sans doute le lieu indiqu pour en prendre connaissance. Si vous ny trouvez pas les informations, consultez lenregistrement SOA de la zone in-addr.arpa correspondant au rseau de votre FAI. Par exemple, si votre rseau est une partie du rseau 153.35/16, vous pouvez consulter lenregistrement SOA de 35.153.in-addr.arpa pour trouver ladresse lectronique du contact technique de cette zone. Si votre rseau est enregistr directement auprs dun des RIR (Regional Internet Registry), contactez ce dernier pour dclarer galement votre zone in-addr.arpa. Chaque organisme dcrit ses procdures sur son site web. Maintenant que vous avez enregistr votre zone, vous pouvez aborder le chapitre suivant o il sera question de linitialisation de votre domaine et de vos serveurs de noms.

7.

Pour des informations sur la rsolution inverse en IPv6, consultez le Chapitre 11.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

4
Mise en uvre de BIND
Cela semble trs joli, dit-elle, quand elle en eut termin la lecture, mais cest rudement difficile assimiler ! (Elle ne voulait pas savouer quelle ny comprenait rien du tout, voyez-vous bien.) Je ne sais pourquoi, jai limpression que cela me remplit la tte de toute sorte dides Jignore malheureusement quelles sont ces ides ! Pourtant, quelquun a tu quelque chose : cest ce quil y a de clair l-dedans en tout cas

Si vous avez lu consciencieusement chacun des chapitres prcdents, vous avez certainement hte que votre serveur de noms soit oprationnel. Ce chapitre se propose de vous montrer comment dmarrer un couple de serveurs. Peut-tre certains dentre vous ontils dj lu la table des matires et sont arrivs directement ce chapitre (honte eux !). Si vous tes dans ce cas, sachez que nous utiliserons des concepts prsents dans les chapitres prcdents et que nous les supposerons acquis. Plusieurs facteurs interviennent dans les choix de conguration des serveurs de noms. Votre type daccs lInternet en est le principal : accs complet (vous pouvez utiliser FTP vers ftp.rs.internic.net), accs limit (contrl par un pare-feu de scurit) ou pas daccs du tout. Ce chapitre prsuppose que vous disposez dun accs complet. Les autres cas seront dcrits au Chapitre 11. Nous allons dmarrer les deux serveurs de noms dune zone ctive. Nous donnerons sufsamment dindications pour les rendre oprationnels et les chapitres suivants donneront plus de dtails. Si vos serveurs de noms sont dj actifs, survolez ce chapitre pour simplement xer la terminologie ou pour vrier que vous navez rien omis dimportant lors de leur cration.

Notre zone ctive


Notre zone ctive est celle de lUniversit du Cinma (Movie University) qui enseigne tous les aspects de lindustrie cinmatographique et effectue des recherches sur de nouvelles mthodes de distribution (lgales). Lun de ses projets les plus prometteurs envisage dutiliser IP comme canal de distribution. Aprs consultation du site web de son registrar, luniversit a choisi movie.edu comme nom de domaine. Elle a paralllement obtenu une connexion complte lInternet.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

50

Chapitre 4 Mise en uvre de BIND

Luniversit dispose actuellement de deux rseaux Ethernet et projette dinstaller un ou deux nouveaux rseaux. Les rseaux actuels ont les adresses 192.249.249/24 et 192.253.253/24. Voici un extrait de la table dhtes de luniversit :
127.0.0.1 localhost

# Et voici nos principaux serveur 192.249.249.2 shrek.movie.edu shrek 192.249.249.3 toystory.movie.edu toystory toys 192.249.249.4 monsters-inc.movie.edu monsters-inc mi # Ces machines sont en mauvais tat et seront remplaces prochainement 192.253.253.2 misery.movie.edu misery 192.253.253.3 shining.movie.edu shining 192.253.253.4 carrie.movie.edu carrie # # # # # Un wormhole (trou de ver) est un phnomne imaginaire qui transporte instantanment les voyageurs de lespace sur de longues distances, et qui est rput instable. La seule diffrence entre un wormhole et un routeur est que ce dernier ne transporte pas les paquets instantanment (tout particulirement les ntres !!!).

192.249.249.1 wormhole.movie.edu wormhole wh wh249 192.253.253.1 wormhole.movie.edu wormhole wh wh253

Le rseau est prsent la gure 4-1.


shrek toystory monsters-inc

rseau 192.249.249

wormhole

rseau 192.253.253

misery

shining

carrie

Figure 4-1. Le rseau de lUniversit du Cinma

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Initialiser les donnes de zone

51

Initialiser les donnes de zone


La premire tape dans linitialisation des serveurs de noms consiste convertir la table dhtes en son quivalent pour le DNS. La version de la table pour le DNS est compose de plusieurs chiers. Lun deux relie les noms dhtes leur adresse, dautres relient les adresses leur nom dhte. La correspondance nom-adresse est parfois appele correspondance directe (forward mapping) et la correspondance adresse-nom est parfois appele correspondance inverse (reverse mapping). Chaque rseau a son propre chier de correspondance inverse. Par convention, dans ce livre, un chier tablissant la correspondance nom-adresse porte le nom db.DOMAINE. Pour movie.edu, ce chier est db.movie.edu. Les chiers tablissant la correspondance adresse-nom sont appels db.ADR, o ADR (sans zro ni masque de rseau nal) est le numro de rseau. Dans notre cas, ces chiers sont db.192.249.249 et db.192.253.253 ; il y a un chier pour chaque rseau et db est labrviation pour database (base de donnes). Lensemble des chiers db.DOMAINE et db.ADR seront appels chiers de donnes de la zone ou chiers de zone. Enn, chaque serveur possde obligatoirement deux autres chiers de donnes, db.cache et db.127.0.0, qui sont globalement identiques sur chaque serveur. Pour relier entre eux tous les chiers de la zone, un serveur de noms doit avoir un chier de conguration. Avec BIND 8 et 9, il sagit habituellement de named.conf. Le format des chiers de donnes de la zone est le mme pour tous les logiciels de service de noms, BIND ou autre, et est appel format du chier-matre, mais le chier de conguration est spcique chaque logiciel, BIND dans notre cas.

Fichiers de zone
La plupart des donnes dun chier de zone sont des enregistrements de ressource (resource records) du DNS. Les recherches dans le DNS ne tiennent pas compte de la casse des caractres ; vous pouvez donc saisir les donnes en majuscules, en minuscules ou dans un mlange des deux. Pour notre part, nous avons tendance utiliser des minuscules. Mme si la casse est sans inuence, la distinction est conserve par le DNS. Ainsi, si vous ajoutez des enregistrements pour Titanic.movie.edu, les clients recherchant titanic.movie.edu trouveront des enregistrements, mais avec un T majuscule au nom. Les enregistrements de ressource doivent commencer dans la premire colonne dune ligne. Dans nos exemples, ils respectent cette rgle mais ils peuvent apparatre diffremment en raison de la mise en page. Dans les RFC du DNS, les exemples prsentent les enregistrements de ressource dans un certain ordre. La plupart des utilisateurs ont choisi de suivre cet ordre, comme ici, mais ce nest nullement une obligation. Nous utilisons lordre suivant : Enregistrement SOA Indique qui fait autorit sur la zone. Enregistrement NS Indique un serveur de noms pour la zone. Autres enregistrements Donnes concernant les htes de la zone.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

52

Chapitre 4 Mise en uvre de BIND

Ce chapitre prsente aussi les enregistrements suivants : A Correspondance nom-adresse. PTR Correspondance adresse-nom. CNAME Nom canonique (ou alias). Ceux dentre vous qui sont dj familiers du sujet feront sans doute remarquer quil y a des moyens plus rapides pour initialiser les donnes. Dans cette premire partie de louvrage, nous nutiliserons ni abrviations, ni raccourcis, pour que vous compreniez la syntaxe complte de chaque enregistrement. Une fois que la version longue sera comprise, nous laguerons les chiers.

Commentaires
Les chiers de zone, db, sont faciles lire sils contiennent des commentaires et des lignes vides (les serveurs de noms nen tiennent pas compte). Les commentaires commencent par un point-virgule et se terminent en n de ligne.

Initialiser le TTL standard de la zone


Avant toute chose, il faut dterminer la version de BIND utilise (pour cela, il suft dexcuter la commande named v ; si cette option ne fonctionne pas, votre version de BIND est probablement antrieure 8.2), car le comportement concernant la dure de vie (Time To Live ou TTL) a chang partir de BIND 8.2. Auparavant, le dernier champ de lenregistrement SOA permettait dinitialiser le TTL standard dune zone. Juste avant la sortie de BIND 8.2, la RFC 2308 a modi la signication du champ ; il indique dsormais la dure de vie en mmoire cache dune rponse ngative (negative caching TTL). Il sagit de la dure pendant laquelle un serveur de noms distant peut conserver des rponses ngatives concernant une zone dans sa mmoire cache, cest--dire des rponses indiquant quun nom ou quun type de donne nexiste pas. partir de BIND 8.2, une nouvelle directive de contrle, $TTL, dnit la dure de vie standard de lensemble des enregistrements du chier.1 La valeur dnie dans cette directive est applique aux enregistrements qui suivent son apparition dans le chier ; plusieurs directives $TTL peuvent apparatre dans un mme chier. Elle na deffet que sur les enregistrements qui nont pas de TTL explicite. Le serveur de noms joint ce TTL ses rponses, autorisant ainsi les serveurs distants mettre ces rponses en mmoire cache pour la dure indique. Si les donnes voluent peu dans le temps, on peut utiliser sans risque un TTL de plusieurs jours, ce qui est le maximum sens. On peut aussi utiliser des valeurs aussi courtes que quelques minutes, mais nous dconseillons la valeur nulle en raison du trac DNS occasionn. Puisque nous utilisons une version rcente de BIND, nous devons dnir le TTL standard de notre zone laide de la directive $TTL. Une dure de trois heures nous semble raisonnable et nous commencerons nos chiers de donnes par :
$TTL 3h
1. NdT : Il sagit dune directive propre BIND qui napparat que dans les chiers de zone lus par BIND.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Initialiser les donnes de zone

53

Si le serveur est antrieur BIND 8.2, lutilisation de cette directive provoquera une erreur de syntaxe.

Enregistrement SOA
Lenregistrement qui suit $TTL est lenregistrement SOA (Start Of Authority). Il indique que ce serveur de noms est la meilleure source dinformations pour les donnes de cette zone. Notre serveur de noms fait autorit sur la zone movie.edu comme lindique son enregistrement SOA. Chaque chier db.DOMAINE et db.ADR doit comporter un enregistrement SOA. Il y en a un et un seul par chier. Nous ajoutons lenregistrement suivant au chier db.movie.edu :
movie.edu. IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure

Le nom movie.edu. doit commencer la premire colonne du chier. Il faut sassurer que le nom se termine par un point, comme ici, faute de quoi on pourrait avoir des surprises ! Nous expliquons pourquoi plus loin dans ce chapitre. IN signale que lenregistrement est dans la classe Internet. Il existe dautres classes, mais aucune delles nest actuellement trs utilise. Nos exemples nutilisent que la classe IN. Le champ classe est facultatif ; sil est omis, le serveur dtermine la classe partir du chier de conguration (voir plus loin). Le premier nom aprs SOA (toystory.movie.edu.) est le nom du serveur-matre primaire de la zone movie.edu. Le second nom (al.movie.edu.) est ladresse de courrier de ladministrateur du domaine (en remplaant le premier . par un @ ). Vous verrez souvent quil sagit de root, postmaster ou hostmaster. Les serveurs de noms nutilisent jamais cette valeur ; elle est l titre dinformation. Si vous avez un problme avec une zone, vous pouvez envoyer un message cette adresse. BIND fournit un autre enregistrement de ressource, RP (Responsible Person ou personne responsable), pour le mme usage. Lenregistrement RP est prsent au Chapitre 7. Les parenthses permettent de prsenter lenregistrement SOA sur plusieurs lignes. La plupart des champs lintrieur de lenregistrement SOA sont destins aux esclaves et seront expliqus lors de leur prsentation dans ce chapitre. Pour le moment, nous supposerons que les valeurs utilises sont raisonnables. On retrouve le mme enregistrement SOA au dbut des chiers db.192.249.249 et db.192.253.253. Dans ces chiers, nous avons remplac le premier nom de lenregistrement SOA, movie.edu., par le nom adquat de la zone in-addr.arpa, cest--dire par 249.249.192.in-addr.arpa. et 253.253.192.in-addr.arpa., respectivement.

Enregistrements NS
Les enregistrements suivants sont ceux des serveurs de noms, NS (Name Server). Nous en avons ajout un pour chaque serveur de noms faisant autorit sur la zone. Voici les enregistrements NS des chiers db.movie.edu :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

54
movie.edu. IN NS toystory.movie.edu. movie.edu. IN NS wormhole.movie.edu.

Chapitre 4 Mise en uvre de BIND

Ces enregistrements indiquent quil y a deux serveurs de noms dans la zone movie.edu. Ces serveurs sont implants sur les htes toystory.movie.edu et wormhole.movie.edu. Un hte multi-domicili2 comme wormhole.movie.edu, est un bon choix pour un serveur de noms, car il est bien connect. Les htes peuvent y accder directement par plusieurs rseaux et, sil sert aussi de routeur, il est a priori plus able, car surveill de prs. Nous parlerons du choix des htes accueillant un serveur de noms au Chapitre 8. Tout comme dans le cas des enregistrements SOA, nous avons ajout des enregistrements NS aux chiers db.192.249.249 et db.192.253.253.

Enregistrements dadresse et dalias


Nous tablissons ensuite la correspondance nom-adresse pour le rseau correspondant la gure 4-2 . Nous ajoutons au chier db.movie.edu, les enregistrements de ressource suivants :
monsters-inc

toystory (matre) 3

shrek

misery

shining

carrie

2 1 wormhole (esclave) 1

192.249.249

192.253.253

Figure 4-2.
; ; Adresse des htes ; localhost.movie.edu. shrek.movie.edu. toystory.movie.edu. monsters-inc.movie.edu. misery.movie.edu. shining.movie.edu. carrie.movie.edu. ; ; Htes multi-domicilis ; wormhole.movie.edu. wormhole.movie.edu. ; ; Alias ;

IN IN IN IN IN IN IN

A A A A A A A

127.0.0.1 192.249.249.2 192.249.249.3 192.249.249.4 192.253.253.2 192.253.253.3 192.253.253.4

IN A IN A

192.249.249.1 192.253.253.1

2.

NdT : cest--dire disposant de plusieurs adresses IP gnralement sur des rseaux diffrents. ,

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Initialiser les donnes de zone


toys.movie.edu. mi.movie.edu. wh.movie.edu. wh249.movie.edu. wh253.movie.edu. IN IN IN IN IN CNAME CNAME CNAME A A toystory.movie.edu. monsters-inc.movie.edu. wormhole.movie.edu. 192.249.249.1 192.253.253.1

55

Les deux premiers blocs de lignes ne sont sans doute pas surprenants. A indique une adresse et chaque enregistrement fait correspondre un nom une adresse. Visiblement, wormhole.movie.edu est multi-domicili. Deux adresses sont associes son nom, et donc deux enregistrements dadresse. la diffrence de la recherche dans une table dhtes, une recherche dans le DNS peut conduire au renvoi de plusieurs adresses par nom. La recherche de wormhole.movie.edu en renverra deux. Si le demandeur et le serveur de noms sont sur le mme rseau, certains serveurs indiqueront en premier ladresse la plus proche du demandeur. Cette caractristique est appele classement dadresses (address sorting) et est dcrite au Chapitre 10. Si le classement dadresses nest pas appliqu, lordre des adresses dans les rponses subit une permutation circulaire dune requte lautre. Ce mcanisme de tourniquet (round robin) est aussi dcrit au Chapitre 10. Le troisime bloc de lignes est une table dalias. Pour les trois premiers alias, nous avons cr des enregistrements de ressource CNAME (Canonical NAME ou nom canonique). Par contre, nous avons cr des enregistrements dadresse pour les deux autres alias (voir la description plus loin). Un enregistrement CNAME lie un alias son nom canonique. Le serveur traite les enregistrements CNAME diffremment des alias dune table dhtes. Lorsquun serveur recherche un nom et trouve un enregistrement CNAME, il remplace le nom par le nom canonique et recherche alors le nouveau nom. Par exemple, lorsque le serveur recherche wh.movie.edu, il trouve un enregistrement CNAME qui dsigne wormhole.movie.edu. Le serveur recherche alors wormhole.movie.edu et renvoie les deux adresses correspondantes. Il faut retenir la rgle suivante : un alias (tel que toys.movie.edu) ne doit jamais apparatre dans la partie droite dun enregistrement de ressource. Autrement dit, le champ des donnes dun enregistrement ne doit contenir que des noms canoniques, tels que toystory.movie.edu. Notez que lenregistrement NS cr prcdemment utilise le nom canonique. Les deux dernires lignes rsolvent un cas spcial. Supposons que vous ayez un hte multi-domicili, tel que wormhole.movie.edu, et que vous vouliez tester une de ses interfaces. Un moyen habituel consiste utiliser ping. Si vous utilisez ping wormhole.movie.edu, le serveur de noms renvoie les deux adresses correspondantes lors de la recherche. ping utilise la premire adresse renvoye, mais laquelle des deux est-ce ? Avec une table dhtes, on pourrait choisir ladresse en utilisant soit wh249.movie.edu soit wh253.movie.edu, chaque nom indiquant une adresse unique. Pour obtenir le mme rsultat avec le DNS, mieux vaut ne pas crer wh249.movie.edu et wh253.movie.edu sous la forme denregistrement CNAME, sous peine dentraner le renvoi des deux adresses de wormhole.movie.edu lors de la recherche dun des alias. Il faut utiliser des enregistrements dadresse. Ainsi, pour tester le fonctionnement de linterface 192.253.253.1 de wormhole.movie.edu, nous pouvons utiliser ping wh253.movie.edu qui ne dsigne quune adresse. Le mme principe sapplique wh249.movie.edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

56

Chapitre 4 Mise en uvre de BIND

Voici une rgle gnrale qui rsume bien tout cela : si un hte est multi-domicili (cest-dire quil a plus dune interface), il faut crer un enregistrement dadresse (A) pour chaque alias unique dadresse, ainsi quun enregistrement CNAME pour chaque alias commun toutes les adresses (voir la gure 4-3).
wh.movie.edu CNAME wormhole.movie.edu

PTR

PTR

A wormhole (esclave)

192.249.249.1

192.253.253.1

A wh249.movie.edu

A wh253.movie.edu

Figure 4-3.
Les alias wh249.movie.edu et wh253.movie.edu ne servent que pour ladministration du rseau. Si un utilisateur utilise un nom tel que wh249.movie.edu, il risque de ne pas comprendre son problme lorsque le nom ne fonctionnera pas, par exemple dans un chier .rhosts. En effet, cet endroit, il faudrait utiliser le nom renvoy par une recherche inverse partir de ladresse, cest--dire le nom canonique wormhole.movie.edu. Puisque nous avons utilis des enregistrements dadresse (A) pour les alias wh249.movie.edu et wh253.movie.edu, pourquoi nutiliserions-nous pas exclusivement ce type denregistrement ? Cela ne poserait pas de problme pour la plupart des applications qui se contentent de trouver une adresse IP qui fonctionne. Par contre, sendmail cherche remplacer les alias de len-tte de courrier par le nom canonique ; cela ne peut se faire que si le nom utilis dans len-tte a un nom canonique associ. Sans enregistrements CNAME, sendmail aurait besoin dune conguration supplmentaire pour dcrire les associations dalias. En plus du problme avec sendmail, les utilisateurs auraient des difcults choisir le nom canonique placer dans leur chier .rhosts. La recherche dun nom qui possde un enregistrement CNAME renvoie vers le nom canonique, contrairement celle dun nom ayant un enregistrement dadresse. Dans ce dernier cas, les utilisateurs devraient eux-mmes rechercher ladresse IP pour retrouver le nom canonique, comme le fait rlogind, mais nous navons jamais vu ce type dutilisateurs sur les systmes que nous grons.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Initialiser les donnes de zone

57

Enregistrements PTR
Nous crons ensuite les correspondances adresse-nom. Le chier db.192.249.249 lie les adresses du rseau 192.249.249/24 leur nom, laide des enregistrements de ressource PTR (pointeur). Il y a un enregistrement pour chaque interface dhte de ce rseau (souvenons-nous que les adresses sont considres comme des noms dans le DNS ; ladresse est reprsente en sens inverse et on y ajoute in-addr.arpa). Voici les enregistrements PTR du rseau 192.249.249/24 :
1.249.249.192.in-addr.arpa. 2.249.249.192.in-addr.arpa. 3.249.249.192.in-addr.arpa. 4.249.249.192.in-addr.arpa. IN IN IN IN PTR PTR PTR PTR wormhole.movie.edu. shrek.movie.edu. toystory.movie.edu. monsters-inc.movie.edu.

Nous pouvons faire plusieurs remarques. Premirement, les adresses doivent dsigner un seul nom, le nom canonique. Aussi 192.249.249.1 dsigne-t-il wormhole.movie.edu et non pas wh249.movie.edu. Vous pouvez crer deux enregistrements PTR, un pour wormhole.movie.edu et un pour wh249.movie.edu, mais la plupart des logiciels ne sont pas prts recevoir plus dun nom par adresse. Deuximement, mme si wormhole.movie.edu a deux adresses, vous nen voyez quune ici, car ce chier ne concerne que les connexions au rseau 192.249.249/24 et wormhole.movie.edu na quune adresse dans ce rseau. Nous crons des enregistrements similaires pour le rseau 192.253.253/24.

Les chiers de zone complets


Maintenant que nous avons prsent les diffrents enregistrements de ressource, nous pouvons les regrouper pour former les chiers dnitifs. Souvenons-nous que lordre des enregistrements na aucune importance. Voici le chier db.movie.edu :
$TTL 3h movie.edu. IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure ; ; Serveurs de noms ; movie.edu. IN NS toystory.movie.edu. movie.edu. IN NS wormhole.movie.edu. ; ; Adresses pour les noms canoniques ; localhost.movie.edu. IN A 127.0.0.1 shrek.movie.edu. IN A 192.249.249.2

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

58
toystory.movie.edu. monsters-inc.movie.edu. misery.movie.edu. shining.movie.edu. carrie.movie.edu. wormhole.movie.edu. wormhole.movie.edu. ; ; Alias ; toys.movie.edu. mi.movie.edu. wh.movie.edu. IN IN IN IN IN IN IN A A A A A A A

Chapitre 4 Mise en uvre de BIND


192.249.249.3 192.249.249.4 192.253.253.2 192.253.253.3 192.253.253.4 192.249.249.1 192.253.253.1

IN CNAME toystory.movie.edu. IN CNAME monsters-inc.movie.edu. IN CNAME wormhole.movie.edu.

; ; Noms des interfaces spcifiques ; wh249.movie.edu. IN A 192.249.249.1 wh253.movie.edu. IN A 192.253.253.1

Voici le chier db.192.249.249 :


$TTL 3h 249.249.192.in-addr.arpa. IN SOA toystory.movie.edu. al.movie.edu.( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure ; ; Serveurs de noms ; 249.249.192.in-addr.arpa. IN NS toystory.movie.edu. 249.249.192.in-addr.arpa. IN NS wormhole.movie.edu. ; ; Adresses dsignant des noms canoniques ; 1.249.249.192.in-addr.arpa. IN PTR wormhole.movie.edu. 2.249.249.192.in-addr.arpa. IN PTR shrek.movie.edu. 3.249.249.192.in-addr.arpa. IN PTR toystory.movie.edu. 4.249.249.192.in-addr.arpa. IN PTR monsters-inc.movie.edu.

Voici le chier db.192.253.253 :


$TTL 3h 253.253.192.in-addr.arpa. IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Initialiser les donnes de zone


1w 1h ) ; expiration aprs 1 semaine ; TTL rponse ngative d1 heure

59

; ; Serveurs de noms ; 253.253.192.in-addr.arpa. IN NS toystory.movie.edu. 253.253.192.in-addr.arpa. IN NS wormhole.movie.edu. ; ; Adresses dsignant des noms canoniques ; 1.253.253.192.in-addr.arpa. IN PTR wormhole.movie.edu. 2.253.253.192.in-addr.arpa. IN PTR misery.movie.edu. 3.253.253.192.in-addr.arpa. IN PTR shining.movie.edu. 4.253.253.192.in-addr.arpa. IN PTR carrie.movie.edu.

Ladresse de bouclage (loopback)


Un serveur de noms a besoin dun chier db.ADR supplmentaire pour le rseau de bouclage (loopback), rseau utilis par lhte pour communiquer avec lui-mme. Ladresse de ce rseau est toujours 127.0.0/24 et ladresse de lhte est toujours 127.0.0.1. Toutefois, le nom de ce chier est db.127.0.0, an de conserver la cohrence densemble des noms de chiers db.ADR. Voici le chier db.127.0.0 :
$TTL 3h 0.0.127.in-addr.arpa. IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure 0.0.127.in-addr.arpa. IN NS toystory.movie.edu. 0.0.127.in-addr.arpa. IN NS wormhole.movie.edu. 1.0.0.127.in-addr.arpa. IN PTR localhost.

Ce chier, en apparence anodin, est indispensable aux serveurs de noms. Personne nayant reu la dlgation pour le rseau 127.0.0/24, et ce malgr son utilisation relle pour la fonction de bouclage local, chaque serveur doit en tre responsable pour luimme. Si on omet ce chier, certes le serveur fonctionnera, mais une recherche de 127.0.0.1 chouera car le serveur de la racine contact ne peut pas faire correspondre 127.0.0.1 lhte local. Pour viter toute surprise, il faut donc fournir soi-mme la correspondance.

Les donnes indicatives sur la zone-racine


Un serveur de noms a aussi besoin de savoir o trouver les serveurs de noms de la racine. Cette information peut tre consulte sur ftp.rs.internic.net (198.41.0.6). Utilisez une session FTP anonyme pour tlcharger le chier db.cache situ dans le rpertoire domain :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

60

Chapitre 4 Mise en uvre de BIND


; Ce fichier contient les indications ncessaires linitialisation ; de la mmoire cache des serveurs de noms, concernant les ; serveurs de la racine (faites rfrence, par exemple, ce fichier ; dans la ligne cache . <fichier> du fichier de configuration de BIND). ; ; Ce fichier est mis disposition par lInterNIC ; via FTP anonyme : ; fichier : /domain/db.cache ; sur le serveur FTP.INTERNIC.NET ; ou le serveur RS.INTERNIC.NET ; ; dernire mise jour : Jan 29, 2004 ; version relative de la zone racine : 2004012900 ; ; ; anciennement NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; anciennement NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 ; ; anciennement C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; anciennement TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; anciennement NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; anciennement NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; anciennement NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Initialiser les donnes de zone


; anciennement AOS.ARL.ARMY.MIL ; . 3600000 H.ROOT-SERVERS.NET. 3600000 ; ; anciennement NIC.NORDU.NET ; . 3600000 I.ROOT-SERVERS.NET. 3600000 ; ; gr par VeriSign, Inc. ; . 3600000 J.ROOT-SERVERS.NET. 3600000 ; ; gr par RIPE NCC ; . 3600000 K.ROOT-SERVERS.NET. 3600000 ; ; gr par ICANN ; . 3600000 L.ROOT-SERVERS.NET. 3600000 ; ; gr par WIDE ; . 3600000 M.ROOT-SERVERS.NET. 3600000 ; Fin de fichier

61

NS A

H.ROOT-SERVERS.NET. 128.63.2.53

NS A

I.ROOT-SERVERS.NET. 192.36.148.17

NS A

J.ROOT-SERVERS.NET. 192.58.128.30

NS A

K.ROOT-SERVERS.NET. 193.0.14.129

NS A

L.ROOT-SERVERS.NET. 198.32.64.12

NS A

M.ROOT-SERVERS.NET. 202.12.27.33

Le nom de domaine . est celui la zone racine. Cette liste de serveurs volue de temps en temps et il ne faut pas considrer les indications ci-dessous comme dnitives ; il est donc ncessaire de tlcharger une version jour de db.cache. Vous devez grer manuellement la mise jour de ce chier. Certaines anciennes versions de BIND le faisait automatiquement. Toutefois, cette fonction a t dsactive car elle ne sest pas montre la hauteur des attentes. Le chier db.cache, pour sa part, est post de temps en temps dans les listes de diffusion bind-users ou namedroppers, prsentes au Chapitre 3. Les abonns ces listes ne manqueront probablement pas les annonces. Ce chier peut galement contenir dautres informations que celles concernant les serveurs de la racine, mais elles ne seront jamais utilises. En effet, au dmarrage, le serveur copie les donnes issues du chier vers un emplacement spcial de la mmoire cache et les considre comme des donnes indicatives sur les serveurs de la racine. Il ne les abandonne jamais (comme il le ferait avec des donnes quelconques en mmoire cache), mme si leur TTL arrive chance. Le serveur utilise ces donnes pour localiser les serveurs de la racine et leur demander la liste jour des serveurs de la racine, quil place alors en mmoire cache standard. Le serveur consulte la mmoire cache spciale pour charger une nouvelle liste jour des serveurs de la racine, lorsque la prcdente est parvenue chance.
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

62

Chapitre 4 Mise en uvre de BIND

Pourquoi le serveur de noms interroge-t-il un des serveurs de noms dnis dans le chier de donnes indicatives (cest--dire un serveur qui est probablement un serveur de la racine) pour obtenir une liste de serveurs de la racine, alors quil en dtient dj une ? Parce que le serveur interrog connat trs vraisemblablement la liste jour des serveurs de la racine, alors que le chier local pourrait tre prim. Le TTL de ces donnes est x 3600000 secondes. Dans les anciennes versions du chier, il tait 99999999 secondes3. lorigine, le chier servait initialiser la mmoire cache, et le TTL des donnes devait tre sufsamment grand pour quelles ne parviennent jamais chance. Les 99999999 secondes ne sont rien dautre quune trs longue dure, largement sufsante pour couvrir la dure de fonctionnement sans interruption dun serveur. Puisque le serveur place dsormais les donnes dans une zone spciale de sa mmoire cache, elles ne sont plus abandonnes et leur TTL nest plus ncessaire. Cependant, la valeur de 3600000 nest pas gnante ; elle fait partie du folklore de BIND transmis par les administrateurs de serveurs de noms lors du passage de tmoin.

Initialiser le chier de conguration de BIND


Le chier de conguration sert indiquer BIND quels chiers il doit utiliser. Jusquici, les chiers que nous avons prsents contiennent des donnes dont le format est dcrit dans les standards du DNS. Par contre, la syntaxe du chier de conguration est spcique BIND et nest pas dni dans les RFC. La syntaxe du chier de conguration de BIND a beaucoup volu entre les versions 4 et 8, mais na pas chang entre les versions 8 et 9. BIND 4 a disparu depuis si longtemps que nous ne prsentons plus sa syntaxe ; il vous faudra trouver une dition antrieure de ce livre (vous devriez en trouver une bon march) si vous utilisez encore un de ces animaux prhistoriques. Dans le chier de conguration, vous pouvez utiliser 3 styles de commentaires : le style C, le style C++ ou le style shell :
/* Voici un commentaire en style C */ // Voici un commentaire en style C++ # Voici un commentaire en style Shell

Habituellement, les chiers de congurations contiennent une ligne indiquant le rpertoire dans lequel sont situs les chiers de donnes. Le serveur de noms lutilise comme rpertoire de travail, ce qui permet dutiliser des chemins relatifs pour accder aux chiers de donnes. Voici la syntaxe de dnition du rpertoire de travail situ lintrieur dune directive options :
options { directory "/var/named"; // Placez ici les options complmentaires. };

3.

NdT : 3600000 secondes quivalent 1000 heures, soit environ 41 jours ; 99999999 secondes correspondent environ 27700 heures, soit 1157 jours, cest--dire un peu plus de 3 ans.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Initialiser le fichier de configuration de BIND


Une seule structure options est permise dans un chier de conguration. Toutes les options complmentaires, mentionnes ultrieurement dans cet ouvrage, doivent tre ajoutes la suite de loption directory.

63

Sur un serveur-matre primaire, le chier de conguration contient une directive zone par chier de donnes de zone lire. Chaque ligne commence par le mot cl zone, et est suivi du nom de la zone et de la classe (in pour Internet). Le type master indique au serveur quil est matre primaire pour la zone correspondante. La dernire ligne contient le nom du chier lire :
zone "movie.edu" in { type master; file "db.movie.edu"; };

Nous avons dj indiqu dans ce chapitre que si la classe nest pas explicite dans un enregistrement de ressource, le serveur dtermine la classe utiliser laide du chier de conguration. in dans la directive zone xe la classe Internet . in est aussi la valeur standard pour la directive zone ; elle peut donc tre totalement omise pour les zones de classe Internet. Voici la syntaxe pour dsigner le chier dinitialisation de la mmoire cache :
zone "." in { type hint; file "db.cache"; };

Comme nous lavons expliqu auparavant, ce chier nest pas utilis pour la mmoire cache standard, mais pour la mmoire cache spciale qui contient des indications (hints) sur les serveurs de noms de la racine4. En standard, BIND attend un chier de conguration appel /etc/named.conf. Les chiers de la zone de notre exemple sont situs dans le rpertoire /var/named. On peut utiliser nimporte quel rpertoire, mais il faut viter de le placer dans le systme de chiers racine si lespace est rduit, ainsi que faire en sorte que ce systme de chiers soit mont avant le dmarrage du serveur de noms. Voyons donc le chier de conguration complet /etc/named.conf :
// fichier de configuration de BIND options { directory "/var/named"; // Placez ici les options complmentaires. }; zone "movie.edu" in {

4.

BIND 9 dispose en fait dune zone dindications initiales prdnie ; il nest donc pas ncessaire de la dclarer dans le chier named.conf. Il nest toutefois pas gnant de le faire et cela peut viter des sueurs froides au lecteur du chier de conguration. Nous prenons donc le parti de dclarer systmatiquement cette zone.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

64
type master; file "db.movie.edu"; }; zone "249.249.192.in-addr.arpa" in { type master; file "db.192.249.249"; }; zone "253.253.192.in-addr.arpa" in { type master; file "db.192.253.253"; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; zone "." in { type hint; file "db.cache"; };

Chapitre 4 Mise en uvre de BIND

Abrviations
Nous avons maintenant cr tous les chiers ncessaires au fonctionnement dun serveur-matre primaire. Revenons en arrire pour reconsidrer les chiers de donnes de la zone ; jusquici, nous navons utilis aucune abrviation, car les formes raccourcies peuvent prter confusion. Maintenant que nous connaissons la forme dveloppe de la syntaxe, nous pouvons en aborder la forme raccourcie.

Utiliser le nom de domaine


Le second champ de la directive zone indique le nom du domaine. Ce nom est la cl de la plupart des abrviations. Ce domaine est lorigine de toutes les donnes dun chier de zone. Cette origine est ajoute tous les noms qui ne se terminent pas par un point. Elle peut tre diffrente pour chaque chier de zone. Puisque lorigine est ajoute tous les noms, au lieu dcrire ladresse de shrek.movie.edu dans le chier db.movie.edu sous la forme :
shrek.movie.edu. shrek IN A IN A 192.249.249.2

nous pouvons maintenant le faire sous la forme :


192.249.249.2

Dans le chier db.192.24.249, nous avons crit :


2.249.249.192.in-addr.arpa. IN PTR shrek.movie.edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Abrviations
Puisque 249.249.192.in-addr.arpa est son origine, nous pouvons crire :
2 IN PTR shrek.movie.edu.

65

Nous vous avions signal de ne pas oublier le point terminal lors de lutilisation des noms complets (FQDN). En cas domission, une ligne telle que :
shrek.movie.edu IN A 192.249.249.2

produirait shrek.movie.edu.movie.edu, ce qui nest pas du tout notre intention.

Notation @
Si le nom du domaine est le mme que lorigine, le nom peut tre remplac par @ . Cest dans lenregistrement SOA quon le voit le plus. Notre enregistrement SOA devient alors :
@ IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure

Rptition du dernier nom


Si le nom dun enregistrement de ressource (cest--dire la premire colonne) est un espace ou une tabulation, le nom de lenregistrement prcdent est utilis. Cest une pratique courante lorsquil existe plusieurs enregistrements de ressource pour un mme nom. Voici un exemple avec deux enregistrements de ressource pour un nom :
wormhole IN A IN A 192.249.249.1 192.253.253.1

Dans le second enregistrement dadresse, le nom wormhole est implicite. Ce type de raccourci est utilisable mme si les enregistrements de ressource sont de types diffrents.

Les chiers de zone abrgs


Maintenant que les abrviations sont dcrites, nous pouvons reprendre la totalit des chiers de donnes. Voici le nouveau chier db.movie.edu :
$TTL 3h ; ; Lorigine movie.edu est implicitement ajoute ; aux noms ne se terminant pas par un point ; @ IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

66

Chapitre 4 Mise en uvre de BIND

; ; Serveurs de noms (le nom @ est implicite) ; IN NS toystory.movie.edu. IN NS wormhole.movie.edu. ; ; Adresses pour les noms canoniques ; localhost IN A 127.0.0.1 shrek IN A 192.249.249.2 toystory IN A 192.249.249.3 monsters-inc IN A 192.249.249.4 misery IN A 192.253.253.2 shining IN A 192.253.253.3 carrie IN A 192.253.253.4 wormhole IN A IN A 192.249.249.1 192.253.253.1

; ; Alias ; toys mi wh

IN CNAME toystory IN CNAME monsters-inc IN CNAME wormhole

; ; Noms des interfaces spcifiques ; wh249 IN A 192.249.249.1 wh253 IN A 192.253.253.1

Voici le chier db.192.249.249 :


$TTL 3h ; ; Lorigine 249.249.192.in-addr.arpa est implicitement ; ajoute aux noms ne se terminant pas par un point. ; @ IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure ; ; Serveurs de noms (le nom @ est implicite) ;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Abrviations
IN NS toystory.movie.edu. IN NS wormhole.movie.edu. ; ; ; 1 2 3 4 Les adresses dsignent des noms canoniques IN IN IN IN PTR PTR PTR PTR wormhole.movie.edu. shrek.movie.edu. toystory.movie.edu. monsters-inc.movie.edu.

67

Voici le chier db.192.253.253 :


$TTL 3h ; ; Lorigine 253.253.192.in-addr.arpa est implicitement ; ajoute aux noms ne se terminant pas par un point. ; @ IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure ; ; Serveurs de noms (le nom @ est implicite) ; IN NS toystory.movie.edu. IN NS wormhole.movie.edu. ; ; ; 1 2 3 4 Les adresses dsignent des noms canoniques IN IN IN IN PTR PTR PTR PTR wormhole.movie.edu. misery.movie.edu. shining.movie.edu. carrie.movie.edu.

Voici le chier db.127.0.0 :


$TTL 3h @ IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure IN NS toystory.movie.edu. IN NS wormhole.movie.edu. 1 IN PTR localhost.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

68

Chapitre 4 Mise en uvre de BIND

En observant le nouveau chier db.movie.edu, vous avez peut-tre remarqu que nous aurions pu supprimer movie.edu des noms dhtes des enregistrements SOA et NS :
@ IN SOA toystory al ( 1 3h 1h 1w 1h ) IN NS toystory IN NS wormhole ; ; ; ; ; numro de srie rafrachissement aprs 3 heures nouvel essai aprs 1 heure expiration aprs 1 semaine TTL rponse ngative d1 heure

On ne peut pas en faire autant dans les autres chiers db, car leurs origines sont diffrentes. An que les enregistrements SOA et NS soient reproductibles dans tous les chiers de zone, nous conservons les noms totalement qualis dans db.movie.edu.

Tester les noms dhtes


Si votre serveur de noms est BIND 4.9.4 ou postrieur (et la plupart le sont), il faut tre vigilant sur lattribution des noms aux htes. En effet, partir de la version 4.9.4, BIND teste la conformit des noms dhtes la RFC 952. Si un nom nest pas conforme, BIND considre que la zone prsente une erreur de syntaxe. Il faut tout de mme savoir que ce test ne sapplique quaux noms qui sont considrs comme des noms dhtes. Souvenons-nous que les enregistrements de ressource ont un champ nom et un champ donnes :
<nom> toystory <classe> <type> <donne> IN A 192.249.249.3

Dans les enregistrements A (adresses) et MX (dcrits au Chapitre 5), les noms dhte apparaissent dans le champ nom ; en revanche, ils apparaissent dans le champ donnes des enregistrements SOA et NS. Les enregistrements CNAME nont pas se conformer aux rgles concernant les noms dhte, car ils peuvent dsigner des noms qui ne sont pas des noms dhte. Observons la rgle concernant les noms dhte : ils peuvent avoir des caractres alphabtiques et numriques dans chaque composante du nom. Les noms ci-dessous sont des noms dhte valables :
ID4 IN A 192.249.249.10 postmanring2x IN A 192.249.249.11

Le caractre - est permis sil apparat lintrieur dune composante du nom :


fx-gateway IN A 192.249.249.12

Le caractre soulign _ nest pas autoris dans un nom dhte.

Les noms qui ne sont pas des noms dhte peuvent contenir nimporte quel caractre ASCII afchable.
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Tester les noms dhtes

69

Si le champ des donnes dun enregistrement de ressource dsigne une adresse de messagerie (comme dans un enregistrement SOA), le nom le plus gauche peut contenir nimporte quel caractre imprimable, puisquil ne sagit pas dun nom dhte. Par contre, le reste du nom doit respecter la syntaxe dcrite plus haut. Par exemple, une adresse de messagerie prsente la syntaxe suivante :
<caractres ASCII>.<caractres de nom dhte>

Ainsi, si votre adresse de messagerie est key_grip@movie.edu, vous pouvez lutiliser telle quelle dans un enregistrement SOA (aprs avoir remplac le @ par un . ) malgr le caractre _ :
movie.edu. IN SOA toystory.movie.edu. key_grip.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure

La fonction de test peut causer des problmes lors du passage dune version librale de BIND une version exigeante, spcialement pour les domaines utilisant des noms contenant le caractre _ . Si vous ne pouvez pas modier les noms dhte immdiatement, la fonction de test peut tre provisoirement suspendue et ne gnrer que des messages dalerte :
options { check-names master warn; };

Les messages dalerte sont collects par syslog. La directive suivante indique de ne tenir compte daucune erreur :
options { check-names master ignore; };

Si les noms non conformes proviennent dune zone pour laquelle vous tes esclave et que vous ne contrlez pas, utilisez la dclaration suivante dans laquelle on remplace master par slave :
options { check-names slave ignore; };

Enn, si le nom tester provient dune rponse une requte et ne rsulte pas dun transfert de zone, indiquez response :
options { check-names response ignore; };

Voici les rglages standard dans BIND :


options { check-names master fail; check-names slave warn; check-names response ignore; };
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

70

Chapitre 4 Mise en uvre de BIND

Le test des noms peut tre rgl zone par zone et il est alors prioritaire sur les directives gnrales de la structure options :
zone "movie.edu" in { type master; file "db.movie.edu"; check-names fail; }; La directive contenue dans la structure options comprend trois champs (check-names master fail), alors que celle dans la structure zone nen a que deux. En effet, dans le second cas, la prcision est inutile, le contexte tant implicite.

Outils
Il serait sans doute plus confortable de disposer dun outil de conversion dune table dhtes en chiers de zone. Cest le rle de notre script Perl, h2n. Vous pouvez utiliser h2n pour initialiser les chiers de zone, puis grer manuellement leur mise jour par la suite, mais vous pouvez aussi lutiliser pour cette mise jour. Le format dune table dhtes est simple comprendre et modier ; vous pouvez donc grer un chier /etc/ hosts et excuter h2n autant de fois que ncessaire pour mettre jour les chiers de zone. Si vous envisagez dutiliser h2n, et tant donn que h2n utilise /etc/hosts, vous pouvez vous dispenser dinitialiser manuellement les chiers du DNS. Nous-mmes, nous aurions pu viter un gros travail en gnrant automatiquement les chiers des exemples de ce chapitre :
% h2n -d movie.edu -s toystory -s shrek \ -n 192.249.249 -n 192.253.253 \ -u al.movie.edu

Pour gnrer un chier de conguration pour BIND 4, ajoutez loption v 4. Les options -d et -n indiquent le nom du domaine et les adresses de rseau. Les noms des chiers de zone sont drivs de ces deux options. Loption -s dsigne les serveurs de noms pour les enregistrements NS. Loption -u (user) est ladresse de messagerie de lenregistrement SOA. Nous dcrirons h2n en dtail au Chapitre 7, aprs avoir prsent les relations entre le DNS et la messagerie.

Outils de BIND 9
BIND 9 offre de nouveaux outils pratiques pour la gestion des chiers des serveurs de noms : named-checkconf et named-checkzone. Ces outils sont placs dans le rpertoire /usr/ local/sbin. Comme leur nom lindique, named-checkconf recherche les erreurs de syntaxe dans le chier de conguration et named-checkzone recherche les erreurs de syntaxe dans les chiers de zone. Il faut tout dabord utiliser named-checkconf, qui teste /etc/named.conf par dfaut :
% named-checkconf

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Dmarrer un serveur primaire


En cas derreur, named-checkconf afche un message similaire celui-ci :
/etc/named.conf:14: zone '.': missing 'file' entry

71

Sil ny a aucune erreur, il ny a aucun afchage. Ensuite, il faut utiliser named-checkzone pour chaque chier de zone :
% named-checkzone movie.edu db.movie zone movie.edu/IN: loaded serial 4 OK

Comme vous pouvez le constater, tout est correct et le numro de srie actuel est 4 .

Dmarrer un serveur primaire


Une fois les chiers de zone crs, vous tes prt dmarrer un couple de serveurs de noms. Vous aurez besoin de dmarrer deux serveurs : un serveur primaire et un serveur-esclave. Avant de dmarrer un serveur, assurez-vous que le dmon syslog fonctionne. De cette manire, si le serveur de noms dtecte une erreur lors de la lecture du chier de conguration ou des chiers de zone, il transmettra un message syslog. Si lerreur est critique, le programme de serveur de noms sarrtera. Si vous avez pralablement excut named-checkconf et named-checkzone de BIND 9, tout est normalement oprationnel, mais il est plus prudent de surveiller les messages envoys syslog.

Dmarrer le serveur de noms


Nous supposons dsormais que votre machine dispose du serveur de noms BIND et de loutil nslookup. Consultez le manuel de named pour savoir o se trouve le chier excutable sur votre systme. Sur les systmes BSD, le programme se trouvait lorigine dans /etc, mais il peut galement tre dans /usr/sbin. Les descriptions suivantes supposent quil est dans /usr/sbin. Pour dmarrer le serveur de noms, prenez lidentit de root, car le serveur se met lcoute sur un port rserv qui requiert ce privilge. Aucun privilge nest ncessaire par la suite. La premire fois, dmarrez le serveur partir de la ligne de commande, an de tester facilement son fonctionnement. Nous indiquerons ultrieurement la faon de le faire automatiquement au dmarrage de la machine. La commande suivante dmarre le serveur de noms. Nous excutons cette commande sur lhte toystory.movie.edu :
# /usr/sbin/named

Cette commande suppose que le chier de conguration est /etc/named.conf. Le chier de conguration peut tre situ ailleurs ; il faut alors le dsigner laide de loption -c :
# /usr/sbin/named -c fichier-de-configuration

Rechercher les erreurs laide de syslog


Juste aprs le dmarrage du serveur de noms, il faut rechercher les erreurs ventuelles dans le chier gr par syslog. Consultez la documentation de syslog.conf pour comprendre le chier de conguration de syslog ou celle de syslogd pour comprendre le fonctionnement du dmon syslog. Le serveur de noms gnre des messages tiquets

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

72

Chapitre 4 Mise en uvre de BIND

daemon sous le nom named. Pour savoir o syslog enregistre les messages, cherchez le service daemon dans /etc/syslog.conf :
% grep daemon /etc/syslog.conf *.err;kern.debug;daemon,auth.notice /var/adm/messages

Ici, les messages du serveur de noms sont enregistrs dans le chier /var/adm/messages, et syslog ne mmorise que ceux suprieurs ou gaux au niveau de priorit LOG_NOTICE. Certains messages sont envoys au niveau LOG_INFO. Vous pourrez dcider de modier les niveaux denregistrement aprs la lecture du Chapitre 7 dans lequel nous dcrivons en dtail les messages de syslog. Lors de son dmarrage, le serveur de noms gnre un message starting :
% grep named /var/adm/messages Jan 10 20:48:32 toystory named[3221]: starting BIND 9.3.2 c named.boot

Ce message nest pas une erreur, mais il peut cependant tre accompagn dun message derreur). Les erreurs les plus courantes sont celles de syntaxe dans les chiers de zone ou dans le chier de conguration. Par exemple, si vous omettez le type denregistrement de ressource dans un enregistrement dadresse :
shrek IN 192.249.249.2

vous obtiendrez un message du type :


Jan 10 20:48:32 toystory named[3221]: db.movie.edu:24: Unknown RR type: 192.249.249.2

Si vous avez fait une faute dorthographe dans le mot zone du chier /etc/ named.conf :
zne "movie.edu" in {

vous verrez ce genre de message derreur avec syslog :


Mar 22 20:14:21 toystory named[1477]: /etc/named.conf:10: unknown option 'zne'

Un nom non conforme la RFC 952 produit le message syslog :


Jul 24 20:56:26 toystory named[1496]: db.movie.edu:33: a_b.movie.edu: bad owner name

En cas derreur de syntaxe, testez la ligne signale en erreur dans le message de syslog pour voir si vous pouvez rsoudre le problme. Votre connaissance de laspect des chiers de zone peut vous sufre pour reprer lerreur. Sinon, consultez lAnnexe A pour tudier en dtail la syntaxe de tous les enregistrements de ressource. Dans la mesure du possible, rsolvez le problme et relancez le serveur de noms avec ndc (BIND 8) ou rndc (BIND 9), la commande de pilotage du dmon de service de noms :
# ndc reload

an quil relise les chiers de zone5. Pour plus dinformations sur ndc et rndc pour contrler un serveur de noms, reportez-vous au Chapitre 7.

5.

Avec BIND 9, il est ncessaire dutiliser rndc, mais nous navons encore donn aucune indication sur sa conguration. Nous le dcrirons au Chapitre 7. ndc ne peut fonctionner tel quel.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Dmarrer un serveur primaire

73

Tester le serveur laide de nslookup


Si vous avez initialis correctement votre domaine et que votre connexion lInternet est fonctionnelle, vous tes en mesure denvoyer votre serveur de noms des requtes concernant des noms locaux et des noms extrieurs. Les exemples suivants vous permettront deffectuer des tests laide de la commande nslookup, intgralement dcrite au Chapitre 12.

Initialiser le nom de domaine local


Avant dutiliser nslookup, vous devez initialiser le nom de domaine local. Vous pourrez ensuite rechercher un nom local comme carrie au lieu de carrie.movie.edu, car le systme ajoutera le nom de domaine movie.edu pour vous. Il y a deux mthodes pour initialiser le nom de domaine local : hostname(1) ou /etc/ resolv.conf. Dans la pratique, la plupart des sites rglent le domaine local dans /etc/ resolv.conf. Dans cet ouvrage, nous utilisons hostname(1). Crez un chier /etc/resolv.conf contenant la ligne suivante, commenant en premire colonne (remplacez movie.edu par votre nom de domaine) :
domain movie.edu

ou utilisez hostname(1). Sur lhte toystory, nous avons utilis hostname(1) avec le paramtre toystory.movie.edu (il ne faut pas mettre de point terminal).

Rechercher un nom local


nslookup peut tre utilis pour rechercher tout type denregistrement de ressource, sur nimporte quel serveur de noms. Par dfaut, nslookup recherche des enregistrements dadresse (A) en utilisant le premier serveur de noms indiqu dans /etc/resolv.conf (en labsence de nom dans /etc/resolv.conf, nslookup interroge lventuel serveur de noms sur lhte local). Pour rechercher ladresse dun hte avec nslookup, on excute la commande nslookup avec le nom dhte rechercher comme seul paramtre. La rponse est en principe instantane lors dune recherche de nom local. Nous utilisons nslookup pour rechercher carrie :
% nslookup carrie Server: toystory.movie.edu Address: 192.249.249.3 Name: carrie.movie.edu Address: 192.253.253.4

Si la recherche locale fonctionne, le serveur de noms est correctement congur pour votre domaine. Si la recherche choue, vous obtiendrez quelque chose comme :
*** toystory.movie.edu can't find carrie: Non-existent domain

Cela signie que soit carrie nest pas dans les donnes (testez vos chiers de zone), soit vous navez pas rgl le domaine local avec hostname(1), soit une erreur du serveur de noms est survenue (peut-tre mme une erreur que vous naviez pas comprise lors de la vrication des messages syslog).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

74

Chapitre 4 Mise en uvre de BIND

Rechercher une adresse locale


Lorsque lon fournit une adresse, nslookup sait quil doit rechercher un enregistrement PTR. Utilisons nslookup pour rechercher ladresse de carrie :
% nslookup 192.253.253.4 Server: toystory.movie.edu Address: 192.249.249.3 Name: carrie.movie.edu Address: 192.253.253.4

Si la recherche dadresse fonctionne, votre domaine est correctement congur pour votre zone in-addr.arpa. Si la recherche choue, vous obtiendrez le mme type de message derreur que lors de lchec de la recherche dun nom.

Rechercher un nom extrieur


Ltape suivante consiste utiliser le serveur de noms local pour rechercher un nom extrieur, tel que ftp.rs.internic.net ou un autre systme que vous connaissez. Cette requte naboutira probablement pas aussi vite que la prcdente recherche de nom. Si nslookup choue dans lobtention dune rponse de la part de votre serveur de noms, nslookup attendra un peu plus dune minute avant de le signaler :
% nslookup ftp.rs.internic.net Server: toystory.movie.edu Address: 192.249.249.3 Name: ftp.rs.internic.net Addresses: 198.41.0.6

Si cette recherche aboutit, votre serveur de noms sait o se trouvent les serveurs de la racine et sait comment les contacter pour rechercher des informations sur les domaines autres que le vtre. Si cette recherche choue, cest que soit vous avez oubli dinitialiser le chier des indications sur les serveurs de la racine (un message syslog le signalera), soit le rseau est interrompu quelque part et vous ne pouvez pas atteindre les serveurs de noms du domaine distant. Essayez alors un autre domaine extrieur. Ces premires recherches fonctionnent ? Flicitations ! Votre serveur primaire est oprationnel. Vous tes maintenant prt initialiser votre serveur-esclave.

Un test supplmentaire
Pendant que nous y sommes, effectuons encore un test. Vrions que le serveur de la zone-parente a bien mis en place la dlgation pour votre domaine. Si votre domaineparent exige que vos deux serveurs de noms soient oprationnels avant de valider la dlgation, passez directement la section suivante. Ce test requiert deux tapes. Tout dabord, cherchons ladresse IP de lun des serveurs de noms de la zone-parente. Puis interrogeons ce serveur pour vrier les enregistrements NS (linformation de dlgation) pour lune de nos zones. Ralisons la premire tape, celle de la recherche de ladresse IP dun serveur de la zoneparente. Pour cela, demandons notre serveur de chercher lenregistrement NS de cette

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Dmarrer un serveur primaire

75

zone-parente. Utilisons nouveau nslookup, mais en ajoutant loption type=ns pour indiquer de rechercher des enregistrements de serveurs de noms. Voici un exemple. Supposons que nous soyons en cours dinitialisation de la zone hp.com ; nous devons trouver les serveurs de noms de com, notre parent :
% nslookup -type=ns com. Server: toystory.movie.edu Address: 192.249.249.3#53 Non-authoritative answer: com nameserver = i.gtld-servers.net com nameserver = j.gtld-servers.net com nameserver = k.gtld-servers.net com nameserver = l.gtld-servers.net com nameserver = m.gtld-servers.net com nameserver = a.gtld-servers.net com nameserver = b.gtld-servers.net com nameserver = c.gtld-servers.net com nameserver = d.gtld-servers.net com nameserver = e.gtld-servers.net com nameserver = f.gtld-servers.net com nameserver = g.gtld-servers.net com nameserver = h.gtld-servers.net a.gtld-servers.net a.gtld-servers.net b.gtld-servers.net b.gtld-servers.net c.gtld-servers.net d.gtld-servers.net e.gtld-servers.net f.gtld-servers.net g.gtld-servers.net h.gtld-servers.net i.gtld-servers.net j.gtld-servers.net k.gtld-servers.net l.gtld-servers.net m.gtld-servers.net internet address = 192.5.6.30 AAAA IPv6 address = 2001:503:a83e::2:30 internet address = 192.33.14.30 AAAA IPv6 address = 2001:503:231d::2:30 internet address = 192.26.92.30 internet address = 192.31.80.30 internet address = 192.12.94.30 internet address = 192.35.51.30 internet address = 192.42.93.30 internet address = 192.54.112.30 internet address = 192.43.172.30 internet address = 192.48.79.30 internet address = 192.52.178.30 internet address = 192.41.162.30 internet address = 192.55.83.30

Nous devons ensuite interroger lun de ces serveurs pour rechercher les enregistrements NS de notre zone. Nous utilisons nouveau nslookup avec type=ns, mais aussi avec loption norecurse pour indiquer de ne pas effectuer de recherche rcursive. Enn, il faut interroger directement le serveur de noms de la zone-parente, au lieu denvoyer la requte un serveur de noms local (votre serveur de noms contient des enregistrements NS de votre zone, mais ce nest pas ceux-l que vous cherchez). Pour cela, il suft dajouter le nom de lun des serveurs de la zone-parente la n de la ligne de commande nslookup. Ci-dessous, nous interrogeons b.gtld-servers.net, lun des serveurs de com, concernant lenregistrement NS de hp.com :
% nslookup -type=ns -norecurse hp.com. b.gtld-servers.net. Server: b.gtld-servers.net

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

76
Address: 192.33.14.30#53 Non-authoritative answer: hp.com nameserver = am1.hp.com hp.com nameserver = am3.hp.com hp.com nameserver = ap1.hp.com hp.com nameserver = eu1.hp.com hp.com nameserver = eu2.hp.com hp.com nameserver = eu3.hp.com am1.hp.com am3.hp.com ap1.hp.com eu1.hp.com eu2.hp.com eu3.hp.com internet internet internet internet internet internet address address address address address address = = = = = =

Chapitre 4 Mise en uvre de BIND

15.227.128. 15.243.160. 15.211.128. 16.14.64.50 16.6.64.50 16.8.64.50

Tout montre que la dlgation pour hp.com est correcte, comme nous pouvions nous en douter. Si votre serveur a recherch avec succs ftp.rs.internic.net et quil trouve aussi les serveurs de noms de votre domaine-parent, ce serveur est correctement initialis. Vous pouvez maintenant contacter le reste de lInternet. Si les serveurs de noms de votre zoneparente ne contiennent pas denregistrements NS, votre zone nest pas dclare auprs de votre parent. Dans un premier temps, ce nest pas un problme, car les htes de votre domaine peuvent rechercher des noms internes ou externes, envoyer des courriels et tablir des sessions FTP vers des htes locaux ou distants. Dans un second temps, labsence de dclaration auprs du parent posera assez rapidement de gros problmes, car les htes extrieurs votre zone ne pourront pas rechercher les noms de vos htes, vous ne pourrez peut-tre pas envoyer des courriers vers lextrieur et encore moins recevoir de rponse. Pour rsoudre ce problme, contactez le responsable de votre zoneparente et demandez lui de tester la dlgation de votre zone.

Modier les chiers de dmarrage


Une fois que tous les tests sont positifs, vous devez congurer le serveur de noms pour quil dmarre automatiquement et initialiser le nom de domaine avec hostname(1) dans les chiers de dmarrage (ou le dnir dans /etc/resolv.conf) de la machine. Des chiers de dmarrage sont peut-tre dj prts pour cela ; il vous faudra peut-tre enlever des caractres de commentaire au dbut de certaines lignes, peut-tre aussi que le chier de dmarrage testera lexistence du chier /etc/named.conf. Pour rechercher les commandes de dmarrage automatique, utilisez :
% grep named /etc/*rc*

ou si vous avez des chiers rc dans le style de System V, utilisez :


% grep named /etc/rc.d/*/S*

Si vous ne trouvez rien, ajoutez au chier de dmarrage appropri des lignes semblables aux suivantes, quelque part aprs linitialisation des interfaces rseau par ifcong :
if test -x /usr/sbin/named -a -f /etc/named.conf then

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Dmarrer un serveur-esclave
echo "Dmarrage de named" /usr/sbin/named fi

77

Pour dmarrer le service de noms, vous pouvez ventuellement attendre que la route par dfaut soit initialise ou que le dmon de routage (routed ou gated) soit dmarr, selon que ce dmon a besoin du service de noms ou quil se contente de /etc/hosts. Cherchez le chier de dmarrage qui initialise le nom dhte. Remplacez le paramtre de hostname(1) par un nom complet. Ici, nous avons remplac :
hostname toystory

par :
hostname toystory.movie.edu

Dmarrer un serveur-esclave
Pour la robustesse, il est ncessaire dinitialiser un autre serveur de noms. Vous pouvez initialiser plus de deux serveurs de noms, deux tant un minimum : si vous avez un seul serveur et quil vient sarrter, plus personne ne peut effectuer de recherche. Un second serveur partage la charge avec le premier ou la reoit en totalit si le premier est arrt. Vous pourriez initialiser un autre serveur primaire, mais cela est dconseill ; il vaut mieux dmarrer un serveur-esclave. Vous pourrez toujours le transformer en serveur primaire, si vous avez du temps consacrer lexploitation de plusieurs serveurs primaires. Un serveur sait sil est serveur primaire ou esclave dune zone grce au chier named.conf. Lenregistrement NS nindique pas qui est le serveur primaire ou qui est le serveur-esclave dune zone, il indique seulement qui sont les serveurs (cela dit, le DNS na pas besoin de le savoir : les serveurs-esclaves sont aussi valables que les serveurs primaires pour rsoudre les noms). La diffrence fondamentale entre un serveur primaire et un serveur-esclave est lorigine des donnes. Un serveur primaire obtient les donnes partir de chiers, alors quun esclave les obtient dun autre serveur de noms, via le rseau. Ce dernier processus sappelle un transfert de zone. Un serveur-esclave nest pas oblig dobtenir ses donnes dun serveur primaire ; il peut les obtenir dun autre serveur-esclave. Un serveur-esclave prsente lavantage de navoir grer quun seul jeu de donnes, celui situ sur le serveur primaire. Il est inutile de vous soucier de la synchronisation entre les serveurs de noms : les esclaves le font pour vous. Toutefois, un esclave ne se resynchronise pas instantanment : il teste rgulirement sa validit. Lintervalle de scrutation est lune des valeurs de lenregistrement SOA que nous navons pas encore dcrite (comme nous le prciserons plus loin, BIND 8 et 9 disposent dun mcanisme pour acclrer la distribution des donnes de la zone). Un serveur-esclave na pas besoin de tlcharger la totalit des chiers de zone depuis un autre serveur. Les chiers db.cache et db.127.0.0 sont les mmes sur un serveur primaire et sur un esclave. Il suft den garder une copie sur lesclave, ce qui signie que pour 0.0.127.in-addr.arpa, un esclave est serveur primaire. Bien sr, vous pourriez le

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

78

Chapitre 4 Mise en uvre de BIND

rendre esclave aussi pour 0.0.127.in-addr.arpa, mais comme les donnes de cette zone nvoluent pas, autant le rendre serveur primaire.

Initialisation
Pour initialiser un serveur-esclave, crez un rpertoire pour les chiers de zone sur lhte esclave (par exemple, /var/named) et copiez vers lesclave les chiers /etc/ named.conf, db.cache et db.127.0.0 :
# rcp /etc/named.conf hte:/etc # rcp db.cache db.127.0.0 hte:rpertoire-des-fichiers-db

Vous devez modier /etc/named.conf sur le serveur-esclave. Remplacez chaque occurrence de master par slave, sauf pour la zone 0.0.127.in-addr.arpa, et ajoutez une ligne masters contenant ladresse IP du serveur primaire, qui joue le rle du matre de lesclave pour ces zones. Si la ligne originale du chier de conguration tait :
zone "movie.edu" in { type master; file "db.movie.edu"; };

elle devient alors :


zone "movie.edu" in { type slave; file "bak.movie.edu"; masters { 192.249.249.3; }; };

Cela indique au serveur de noms quil est esclave pour la zone movie.edu et quil doit surveiller lvolution des donnes conserves sur lhte 192.249.249.3. Le serveuresclave conserve une copie de cette zone dans son chier local bak.movie.edu. Pour lUniversit du Cinma, le serveur-esclave a t plac sur lhte wormhole.movie.edu. Partons du chier de conguration de toystory.movie.edu (le serveur primaire) :
options { directory "/var/named"; }; zone "movie.edu" in { type master; file "db.movie.edu"; }; zone "249.249.192.in-addr.arpa" in { type master; file "db.192.249.249"; }; zone "253.253.192.in-addr.arpa" in {

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Dmarrer un serveur-esclave
type master; file "db.192.253.253"; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; zone "." in { type hint; file "db.cache"; };

79

Nous avons copi /etc/named.conf, db.cache et db.127.0.0 vers wormhole.movie.edu, puis modi le chier de conguration :
options { directory "/var/named"; }; zone "movie.edu" in { type slave; file "bak.movie.edu"; masters { 192.249.249.3; }; }; zone "249.249.192.in-addr.arpa" in { type slave; file "bak.192.249.249"; masters { 192.249.249.3; }; }; zone "253.253.192.in-addr.arpa" in { type slave; file "bak.192.253.253"; masters { 192.249.249.3; }; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; zone "." in { type hint; file "db.cache"; };

Le serveur de noms sur wormhole.movie.edu tlcharge movie.edu, 249.249.192.inaddr.arpa et 253.253.192.in-addr.arpa par le rseau, depuis le serveur 192.249.249.3 (toys-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

80

Chapitre 4 Mise en uvre de BIND

tory.movie.edu). Il sauvegarde galement une copie de ces chiers dans /var/named. Il est judicieux disoler les chiers dans un sous-rpertoire ou de leur ajouter un sufxe tel que bak. En effet, en cas de besoin, il sera plus facile de tous les effacer (ce qui est une opration rare). De plus, cela aidera se souvenir quil sagit de copies des chiers de zone, et dissuadera de les modier directement. Nous donnerons plus loin des prcisions sur ces chiers de sauvegarde. Dmarrez le serveur-esclave. Surveillez les messages dans le chier de syslog, comme vous lavez fait sur le serveur primaire. Comme sur ce dernier, voici la commande pour dmarrer le serveur de noms :
# /usr/sbin/named

Un test, inutile sur un serveur primaire, consiste vrier que lesclave a bien cr les chiers de sauvegarde de zone. Quelques instants aprs le dmarrage de lesclave sur wormhole.movie.edu, nous voyons apparatre bak.movie.edu, bak.192.249.249 et bak.192.253.253 dans le rpertoire /var/named. Cela signie que lesclave a charg avec succs ces zones partir du serveur primaire et en a conserv une copie dans ses chiers. Pour achever la mise en uvre de votre serveur-esclave, essayez les mmes recherches que pour le test du serveur primaire. Le serveur-esclave doit utiliser nslookup pour sinterroger lui-mme. Si le serveur-esclave fonctionne correctement, ajoutez les lignes adquates aux chiers de dmarrage automatique pour que le serveur de noms dmarre automatiquement lors du dmarrage de la machine et que hostname(1) prenne le nom du domaine comme valeur.

Fichiers de sauvegarde
Rien noblige un serveur-esclave sauvegarder une copie des donnes de la zone. Si le serveur-esclave a une copie de sauvegarde, il lutilise au dmarrage, puis il teste sa validit en regardant si le serveur-matre a une version plus rcente de la base de donnes, plutt que de la tlcharger immdiatement. Si le serveur-matre a une version plus rcente, lesclave la tlcharge et la sauvegarde. Pourquoi sauvegarder une copie ? Supposons que le serveur-matre soit arrt lors du dmarrage du serveur-esclave. Ce dernier serait incapable de transfrer la zone et, par consquent, ne pourrait fonctionner comme un serveur de noms pour cette zone tant que le matre naurait pas redmarr. Avec une copie de sauvegarde, lesclave dispose dj de donnes (qui peuvent dailleurs tre primes). Comme lesclave dpend un peu moins du matre, le systme est plus robuste. Pour fonctionner sans copie de sauvegarde, supprimez les lignes le dans le chier de conguration. Nous vous recommandons toutefois dactiver la cration de copies de sauvegarde sur tous vos esclaves. Le cot de leur mise en uvre est minime, et leur intrt est majeur.

Les champs de lenregistrement SOA


Voici notre enregistrement SOA :
movie.edu. IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Dmarrer un serveur-esclave
1h 1w 1h ) ; nouvel essai aprs 1 heure ; expiration aprs 1 semaine ; TTL rponse ngative d1 heure

81

Nous navons pas encore expliqu la signication des valeurs places entre parenthses. Le numro de srie sapplique toutes les donnes de la zone. Nous avons logiquement choisi de dmarrer notre numro de srie 1. De nombreux administrateurs trouvent plus pratique dutiliser la date pour le numro de srie, par exemple 2005012301. Ce format est AAAAMMJJNN, o AAAA est lanne, MM le mois, JJ le jour et NN le numro dordre de la modication des donnes de la zone ce jour-l. Quel que soit le format choisi, il est important que ce nombre augmente lors dune mise jour des donnes de la zone. Quand un esclave demande les donnes de la zone un serveur-matre, il recherche dabord son numro de srie. Si celui de lesclave est infrieur celui du matre, les donnes de lesclave sont primes. Dans ce cas, lesclave tlcharge une nouvelle copie de la zone. Si un esclave dmarre et quil na pas de chiers de sauvegarde, il tlcharge toujours la zone. Lorsquon modie les donnes de zone sur le serveur primaire, il faut incrmenter le numro de srie (voir le Chapitre 7). Les quatre champs suivants indiquent des intervalles de temps, par dfaut en seconde : rafrachissement (refresh) Lintervalle de rafrachissement, refresh, indique lesclave la priodicit de test de validit de ses donnes. Lesclave demande lenregistrement SOA de la zone chaque intervalle de rafrachissement. Nous avons choisi trois heures, une valeur raisonnable. Lors de linstallation de leur nouveau poste de travail, la plupart des utilisateurs tolreront un dlai dune demi-journe ouvrable pour la propagation dinformations comme celles des serveurs de noms. En fonction du niveau de service que vous fournissez et de la frquence de modication de vos donnes, augmentez ou diminuez cette valeur. Si vous fournissez un service quotidien, vous pouvez utiliser une valeur de huit heures. Si les donnes ne changent pas souvent ou si tous les esclaves sont disperss (comme les serveurs de la racine), vous pouvez mme utiliser une valeur de 24 heures. nouvel essai (retry) Si lesclave narrive pas contacter le serveur-matre au bout de la priode de rafrachissement (lhte pourrait tre arrt), il essaie de le recontacter selon la priodicit de nouvel essai (retry). Normalement, cette priodicit de nouvel essai est plus courte que celle de rafrachissement, mais ce nest pas une obligation. expiration (expire) Si lesclave narrive pas contacter le matre avant lexpiration de la zone, lesclave arrte sa fonction de serveur : il cesse de rpondre aux requtes car les donnes sont considres trop anciennes pour tre valables. En dautres termes, ce champ signie : Mieux vaut navoir aucune donne que davoir des donnes si anciennes quelles pourraient tre primes . Une expiration au bout dune semaine est une valeur courante. Vous pouvez laugmenter (jusqu un mois), si vous avez souvent des difcults pour atteindre votre serveur primaire. La dure avant expiration expire doit tre suprieure aux priodicits de rafrachissement et de nouvel essai ;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

82

Chapitre 4 Mise en uvre de BIND


si lexpiration est plus courte que la priodicit de rafrachissement, lesclave arrtera systmatiquement son service avant la n de chaque priode de rafrachissement.

TTL dune rponse ngative (negative caching TTL) Le TTL est la dure de vie (Time To Live). Cette valeur sapplique toutes les rponses ngatives envoyes par les serveurs faisant autorit sur la zone.

Avant BIND 8.2, ce champ est la fois le TTL par dfaut et le TTL sur rponse ngative pour la zone.

Ceux qui connaissent les versions prcdentes de ce livre auront not le changement de format que nous utilisons pour les valeurs numriques du SOA. Initialement, BIND ne comprenait que les valeurs en seconde (cest ce qui fait que de nombreux administrateurs savent quune semaine contient 604800 secondes). Avec toutes les versions de BIND postrieures 4.8.3, on peut utiliser des valeurs symboliques. Ainsi, on peut reprsenter un intervalle de rafrachissement de trois heures par 3h, 180m ou mme 2h60m. On peut aussi utiliser d pour les jours (days) et w pour les semaines (weeks). Choisissez ces valeurs en fonction de votre site. En gnral, des dures plus longues diminuent la charge sur vos serveurs de noms et augmentent le dlai de propagation des mises jour. Inversement, des dures plus courtes augmentent la charge sur vos systmes et acclrent la propagation. Les valeurs utilises dans ce livre devraient convenir dans la plupart des cas. La RFC 1537 recommande les valeurs suivantes pour les serveurs de noms du niveau suprieur :
rafrachissement aprs nouvel essai aprs expiration aprs TTL par dfaut 24 heures 2 heures 30 jours 4 jours

Sur un esclave, les versions de BIND antrieures 4.8.3 cessaient de rpondre aux requtes durant un chargement de zone. BIND a t modi pour taler le chargement dans le temps, de manire rduire la dure dindisponibilit. En consquence, mme en indiquant une trs courte priode de rafrachissement, un esclave ne testera pas obligatoirement sa validit aussi souvent que vous lavez indiqu. BIND tente un certain nombre de chargements de zone, puis attend quinze minutes avant de nouvelles tentatives. La propagation des modications dans une zone a t modie dans BIND 8 et 9 : la technique prcdente existe toujours, mais un mcanisme de notication asynchrone a t ajout. Si votre serveur primaire et vos serveurs-esclaves sont en version 8 ou 9, le serveur primaire signalera une modication de zone aux esclaves dans les quinze minutes suivantes ; les esclaves tenteront immdiatement un chargement de zone, ce qui reviendra raccourcir la priode de rafrachissement. Cette fonction sera dcrite en dtail au Chapitre 10.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Grer plusieurs zones

83

Serveurs-matres multiples
Dautres solutions permettent de rendre votre systme plus robuste : vous pouvez indiquer jusqu dix adresses IP de serveurs-matres. Dans un chier de conguration, ajoutez-les aprs la premire adresse IP et terminez-les par un point virgule :
zone "movie.edu" in { type slave; file "bak.movie.edu"; masters { 192.249.249.3; 192.249.249.4; }; };

Depuis BIND 9.3, vous pouvez donner un nom la liste des adresses IP des matres et utiliser ce nom par la suite, ce qui permet dviter de rpter les adresses IP dans chaque zone :
masters "movie-masters" { 192.249.249.3; 192.249.249.4; }; zone "movie.edu" in { type slave; file "bak.movie.edu"; masters { movie-masters; }; };

Lesclave essaie chaque serveur-matre, dans lordre de la liste, jusquau succs du transfert de zone. Jusqu BIND 8.1.2, lesclave transfre la zone partir du premier serveur rpondre, si celui-ci a un numro de srie plus lev que celui de lesclave. Depuis BIND 8.2, lesclave interroge tous les serveurs de noms indiqus et procde au transfert de zone partir du serveur qui a le numro de srie le plus lev. Si plusieurs serveursmatres ont le mme numro de srie, lesclave procde au transfert de zone partir du premier des serveurs de la liste. Lintrt initial de cette caractristique est de pouvoir donner toutes les adresses IP de lhte excutant le serveur primaire de la zone, si cet hte est multi-domicili. Toutefois, comme aucun test nest fait pour savoir si lhte contact est un serveur primaire ou un esclave, vous pouvez indiquer les adresses IP de tous les esclaves de la zone. Ainsi, si le premier serveur-matre est arrt ou inaccessible, le transfert peut seffectuer partir dun autre serveur-matre.

Grer plusieurs zones


Maintenant que vos serveurs de noms sont oprationnels, vous souhaiterez peut-tre prendre en charge plusieurs zones. Vous devrez simplement ajouter de nouvelles dclarations zone dans votre chier de conguration. Il est mme possible de transformer un serveur primaire en esclave pour certaines zones, et inversement (dailleurs, votre serveur-esclave est dj serveur primaire de 0.0.127.in-addr.arpa). Nous en protons pour rappeler ce que nous avons dj dit dans un chapitre prcdent : pour un serveur donn, lappellation de serveur primaire ou desclave na pas de sens profond. En effet, un serveur de noms peut faire autorit sur plus dune zone, tout en

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

84

Chapitre 4 Mise en uvre de BIND

tant serveur primaire de lune et esclave dune autre. Toutefois, la plupart des serveurs qui sont primaires dune zone, le sont galement pour toutes les zones quils servent. Il en est de mme pour les esclaves. Par consquent, lorsque nous disons quun serveur est primaire ou esclave, il lest pour la quasi totalit des zones quil charge.

Et maintenant ?
Dans ce chapitre, nous avons prsent la cration des chiers de zone dun serveur de noms, en partant de /etc/hosts transform en son quivalant pour le DNS, puis linitialisation de serveurs de noms primaire et esclave. Linitialisation de votre zone nest pas encore acheve et sera dveloppe dans les prochains chapitres : vous devez modier les donnes pour la messagerie, prparer les htes de votre zone utiliser vos serveurs, et peut-tre mme dmarrer dautres serveurs de noms. Tous ces sujets sont traits dans les prochains chapitres.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

5
DNS et courrier lectronique
ce moment, Alice commena se sentir toute somnolente, et elle se mit rpter comme si elle rvait : Est-ce que les chats mangent les chauves-souris ? Est-ce que les chats mangent les chauves-souris ? et parfois : Est-ce que les chauves-souris mangent les chats ? car voyez-vous, comme elle tait incapable de rpondre aucune des deux questions, peu importait quelle post lune ou lautre.

Aprs ce dernier chapitre, quelque peu fastidieux, abordons un sujet passionnant et fondamental pour les administrateurs de messagerie : limpact du DNS sur le courrier lectronique. Lun des avantages du systme de noms de domaine sur les tables dhtes est son apport dans le routage du courrier lectronique. Quand les outils de messagerie ne disposaient que du chier HOSTS.TXT (ou de ses drivs comme /etc/hosts), ils pouvaient au mieux livrer le courrier ladresse IP dun hte. En cas dchec, ils pouvaient tenter une nouvelle livraison, ou bien renvoyer le message lexpditeur. Pour pallier ces problmes, le DNS offre la possibilit de dsigner des htes de secours pour la livraison des courriers. Le mcanisme permet galement des htes de prendre en charge la manipulation des messages pour le compte dautres htes, tels que des stations sans disque (diskless) nexcutant pas de routeur de message. la diffrence des tables dhtes, le DNS permet de reprsenter des destinations de courrier par des noms spciques. Ainsi, de nombreux organismes sur lInternet sont joignables par courriel en utilisant directement le nom de leur zone. De mme, dans une zone, des noms reprsentant des destinations de courrier ne sont pas obligatoirement associs un hte en particulier. Enn, une adresse unique de destination peut reprsenter plusieurs serveurs de messagerie. Par contre, avec les tables dhtes, les destinations de messagerie sont des htes, point nal. Lensemble de ces caractristiques offre une grande souplesse pour la mise en uvre dune messagerie sur un rseau.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

86

Chapitre 5 DNS et courrier lectronique

Enregistrements MX
La mise en uvre des caractristiques tendues de routage se fait laide dun type unique denregistrement, lenregistrement MX. lorigine, la fonction remplie aujourdhui par lenregistrement MX tait couverte par deux enregistrements, MD (Mail Destination) et MF (Mail Forwarder). MD indiquait la destination nale de livraison dun message adress un domaine particulier et MF fournissait une adresse alternative de livraison du message en cas dindisponibilit de la destination nale. Les premires mises en uvre du DNS sur ARPAnet ont mis en vidence les problmes lis la sparation de ces deux fonctions. Pour pouvoir se dcider, un routeur de message a besoin simultanment des deux enregistrements MD et MF, sils existent. Mais la recherche explicite dun type denregistrement, MD ou MF, ne provoque le renvoi dune rponse que pour lenregistrement recherch et le stockage en mmoirecache de ce seul enregistrement. Les routeurs de message doivent alors gnrer deux requtes et ne pas tenir compte des valeurs en mmoire cache1. Le service de messagerie produit alors une surcharge plus importante que les autres, ce qui peut se rvler inacceptable. Aussi les deux enregistrements ont-ils t intgrs en un seul, lenregistrement MX. Ds lors, un routeur de message a uniquement besoin des enregistrements MX dun domaine particulier pour prendre sa dcision de routage. De plus, lutilisation de la mmoire cache est possible avec les enregistrements MX, tant que les TTL concordent. Les enregistrements MX dsignent un hte appel changeur de message (mail exchanger), qui tantt traite le courrier, tantt le transfre pour un domaine. Le traitement du courrier consiste livrer le courrier ladresse indique ou le passer un autre agent de transport, tel que X.400. Le transfert du courrier signie son envoi vers sa destination nale ou vers un autre changeur de messages plus proche de la destination, via SMTP (Simple Mail Transfer Protocol). Le transfert implique parfois le placement du message en le dattente. An dviter les boucles de route, lenregistrement MX contient un paramtre supplmentaire, la valeur de prfrence. Cette valeur est un nombre entier naturel sur 16 bits (de 0 65535) qui indique la priorit dun changeur. Dans lexemple suivant, lenregistrement MX :
peets.mpk.ca.us. IN MX 10 relay.hp.com.

indique que relay.hp.com est un changeur de message pour peets.mpk.ca.us avec une valeur de prfrence gale 10. Lensemble des valeurs de prfrence de tous les changeurs pour une destination donne indique lordre dans lequel un routeur doit utiliser les changeurs. La valeur de

1.

NdT : la RFC 973 explique bien lorigine du problme (page 4, MD and MF replaced by MX) : un routeur de message effectuant une recherche des deux types denregistrement ne peut pas utiliser la mmoire cache car celle-ci pourrait dj contenir le rsultat dune recherche de MD ou dune recherche de MF. Or la prsence de lun de ces enregistrements en mmoire cache nimplique strictement rien sur lautre type denregistrement. Par consquent, les routeurs de messages doivent systmatiquement consulter des serveurs faisant autorit ou accepter dventuelles informations incompltes.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Enregistrements MX

87

prfrence na pas dimportance en elle-mme ; elle nest utile que compare avec celles des autres changeurs. moins quil ny en ait dautres en jeu, les enregistrements :
plange.puntacana.dr. IN MX 1 listo.puntacana.dr. plange.puntacana.dr. IN MX 2 hep.puntacana.dr.

produisent le mme rsultat que :


plange.puntacana.dr. IN MX 50 listo.puntacana.dr. plange.puntacana.dr. IN MX 100 hep.puntacana.dr.

Les routeurs de message doivent dabord tenter la livraison vers les changeurs ayant la plus petite valeur de prfrence. Lchangeur choisi en premier est donc celui qui a la plus petite valeur de prfrence, ce qui nest a priori pas trs intuitif. On peut simplier la reprsentation en affectant la valeur 0 au meilleur changeur. Si la livraison vers le ou les changeurs de meilleure prfrence choue, un routeur doit tenter la livraison vers les changeurs de prfrence moindre, dans lordre croissant des valeurs de prfrence. Autrement dit, les routeurs doivent utiliser les changeurs prfrentiels avant dessayer les changeurs prfrence moindre. Plusieurs changeurs peuvent avoir la mme prfrence et le routeur doit effectuer un choix. Un routeur doit obligatoirement tenter dutiliser tous les changeurs dun mme niveau avant dessayer un changeur de prfrence moindre. Par exemple, les enregistrements MX pour oreilly.com pourraient tre :
oreilly.com. oreilly.com. oreilly.com. IN IN IN MX MX MX 0 ora.oreilly.com. 10 ruby.oreilly.com. 10 opal.oreilly.com.

Ces enregistrements MX indiquent aux routeurs de tenter dutiliser les changeurs dans lordre suivant pour crire oreilly.com : 1. ora.oreilly.com. 2. Soit ruby.oreilly.com, soit opal.oreilly.com. 3. Lchangeur de prfrence 10 non utilis en 2). Bien sr, une fois le message livr lun des changeurs de oreilly.com par le routeur, ce dernier cesse ses tentatives : un routeur ayant livr un message ora.oreilly.com na nul besoin de tenter des livraisons vers ruby.oreilly.com ou opal.oreilly.com. oreilly.com ne dsigne pas un hte mais la zone principale directe de OReilly. OReilly utilise le nom du domaine comme destination du courrier pour lensemble de son personnel. Pour un expditeur, il est effectivement plus facile de retenir oreilly.com que ruby.oreilly.com ou amber.oreilly.com, selon lemplacement de la bote aux lettres dun employ. Cela requiert que ladministrateur du routeur de messages sur ora.oreilly.com gre un chier dalias rpertoriant lensemble des utilisateurs de OReilly, an de rediriger pour chacun le courrier vers la machine sur laquelle il sera lu ou de grer un serveur permettant un accs distant un serveur de botes aux lettres, tel quun serveur POP ou IMAP . Que se passe-t-il si une destination na pas denregistrements MX mais un ou plusieurs enregistrements A ? Cela fera-t-il chouer un routeur dans la livraison dun message cette destination ? Vous pouvez compiler une version rcente de sendmail pour obtenir ce dernier comportement. Toutefois, la plupart des diteurs proposent un sendmail plus

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

88

Chapitre 5 DNS et courrier lectronique

clment : sil ny a pas denregistrements MX mais un ou plusieurs enregistrements A, le routeur tente au minimum la livraison ladresse de lhte. Il faut consulter la documentation spcique pour voir si le serveur enverra des courriers vers des destinations ne correspondant qu des enregistrements dadresse. Bien que quasiment tous les routeurs soient capables de livrer des messages vers des destinations rpertories uniquement par des enregistrements dadresse, il est bon dinitialiser au moins un enregistrement MX pour chaque destination lgitime. En effet, la plupart des routeurs, dont sendmail, recherchent dabord lenregistrement MX dune destination chaque fois quils ont besoin dy livrer un courrier. Si cette destination nest pas associe un enregistrement MX, un serveur de noms (en gnral parmi ceux faisant autorit) le signale et sendmail recherche alors des enregistrements A. Cette procdure prend du temps, ralentit la livraison des courriers et augmente lgrement la charge sur les serveurs de noms faisant autorit sur votre zone. Si, pour chaque destination, vous crez un enregistrement MX dsignant un nom associ ladresse qui serait obtenue par une recherche dadresse pour cette destination, sendmail ne gnre quune seule requte et le serveur de noms local place lenregistrement MX dans sa mmoire cache. Enn, notons que nous ne pouvons pas utiliser une adresse IP la place dun nom pour dsigner lchangeur de messages (dans le champ suivant la valeur de prfrence). En effet, certains routeurs de messagerie sont assez souple et acceptent une adresse IP mais , dautres ne le sont pas et la livraison des courriers pourrait chouer de manire imprvisible.

La messagerie lUniversit du Cinma


Dans movie.edu, nous navons quun seul changeur de messages, postmanrings2x.movie.edu. Il hberge la fois un serveur SMTP et un serveur IMAP avec un compte pour chaque utilisateur de messagerie de movie.edu. Pour indiquer aux serveurs de messages de lInternet denvoyer tous les courriers destins aux utilisateurs de movie.edu notre changeur, nous ajoutons lenregistrement MX suivant db.movie.edu :
movie.edu. IN MX 10 postmanrings2x.movie.edu.

Notre FAI gre un serveur SMTP de secours, de manire prendre en charge et mettre en attente les courriers qui nous sont destins lorsque que notre propre serveur ou notre connexion est hors service. Pour informer les routeurs de messagerie de lInternet dessayer lchangeur de notre FAI si postmanrings2x est indisponible, nous ajoutons un autre enregistrement MX au chier de zone de movie.edu :
movie.edu. IN MX 20 smtp.isp.net.

changeurs de messages
Le concept dchangeur de message est probablement nouveau pour la plupart dentre vous. Nous allons donner quelques dtails laide de lanalogie entre un changeur de message et un aroport, et de celle entre les enregistrements MX (qui indiquent aux routeurs o envoyer les messages) et les indications que vous donnez vos beaux-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

changeurs de messages

89

parents, qui reviennent de Martinique, sur laroport de destination utiliser pour quils se rendent chez vous. Vous habitez Aix-en-Provence. Les aroports les plus proches sont ceux de Marseille Marignane, puis de Lyon Saint-Exupry et enn de Paris Charles-de-Gaulle (on choisit de ne pas tenir compte des diffrences tarifaires, du trac local, etc). En faisant un parallle avec les enregistrements MX, on obtient :
aix-en-provence.fr. aix-en-provence.fr. aix-en-provence.fr. IN IN IN MX MX MX 1 marseille.fr. 2 lyon.fr. 3 paris.fr.

La liste des MX est une liste ordonne de destinations qui indique aux changeurs (les aroports) o orienter un message (vos beaux-parents) destin une certaine destination (votre maison). La valeur de prfrence les informe sur la meilleure destination viser (on peut imaginer une sorte de distance logique par rapport la destination nale ou une sorte de Top 50 des proximits entre les changeurs de messages et la destination nale). La liste ci-dessus conseille dutiliser en priorit laroport de Marseille, sinon celui de Lyon, sinon celui de Paris, dans cet ordre. Elle indique aussi que si on a choisi Lyon, il faudra prendre une correspondance pour Marseille et que si on a choisi Paris, il faudra en prendre une pour Marseille ou au pire pour Lyon. Les qualits dun bon changeur de message sont les mmes que celles dun bon aroport : Dimension Personne ne voudrait passer par le minuscule aroport de Gap pour se rendre Aix-en-Provence, car il nest pas quip pour accueillir des gros porteurs ou de nombreux voyageurs (il serait plus facile de faire atterrir un jet sur lautoroute plutt qu Gap !). De la mme manire, personne ne voudrait utiliser un hte ancien et lent comme changeur de message, car il ne supporterait pas la charge. Disponibilit Le passage par un aroport trop souvent ferm en hiver peut savrer problmatique. De mme, il serait ridicule dinstaller un changeur de message sur un hte rarement en service ou rarement disponible. Connectivit Si des voyageurs viennent de loin, il faut sassurer quils peuvent trouver un vol direct vers au moins lun des aroports de la liste. On ne va pas leur dire quils nont le choix quentre Marseille et Paris sils partent de Tombouctou. De mme, il faut sassurer quau moins un changeur de message est accessible pour chaque correspondant. Gestion La qualit de la gestion dun aroport a un impact sur sa scurit et sa facilit dutilisation. De mme, la condentialit du courrier, la rapidit de sa livraison en service normal, son traitement en cas darrt de lhte, dpendent de la qualit de la gestion de lchangeur de message. Gardons ces exemples en mmoire car nous nous y rfrerons plus loin.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

90

Chapitre 5 DNS et courrier lectronique

Algorithme des MX
Entrons maintenant dans le dtail des enregistrements MX et des changeurs de messages. Pour viter les boucles de route, les routeurs de messages utilisent un algorithme lgrement plus complexe que ce qui a t dcrit prcdemment, lorsquils choisissent la destination du courrier2. Imaginons ce qui se passerait si les routeurs ne se protgeaient pas des bouclages de route. Supposons quun courrier vantant (ou fustigeant) la qualit de ce livre parte en direction de nuts@oreilly.com, mais que ora.oreilly.com soit arrt. Regardons les enregistrements MX de oreilly.com :
oreilly.com. oreilly.com. oreilly.com. IN IN IN MX MX MX 0 ora.oreilly.com. 10 ruby.oreilly.com. 10 opal.oreilly.com.

Votre routeur choisit alors denvoyer le message ruby.oreilly.com, qui est actuellement en service. Le routeur de ruby.oreilly.com essaie ensuite de retransmettre le message vers ora.oreilly.com mais ne peut pas le faire car ora.oreilly.com est toujours larrt. Si ruby.oreilly.com nest pas attentif ce quil fait, il va envoyer le message opal.oreilly.com, ou peut-tre lui-mme. Si ruby.oreilly.com se lexpdie, il sagit dune boucle de route. Si ruby.oreilly.com envoie le message opal.oreilly.com, opal.oreilly.com le renverra son tour soit ruby.oreilly.com soit lui-mme, ce qui constitue aussi une boucle. Pour viter ces boucles, les routeurs annulent certains enregistrements MX avant de prendre leur dcision. Un routeur classe la liste des enregistrements selon la valeur de prfrence, puis cherche son propre nom canonique dans cette liste. Sil est lun des changeurs de message, il annule son enregistrement MX ainsi que tous les enregistrements MX dont la valeur de prfrence est identique ou suprieure (cest--dire ceux des changeurs moins bien placs). Cela vite que le routeur sadresse des messages luimme ou les adresse des routeurs plus loigns . Reprenons notre analogie avec les aroports. Un voyageur (un message) veut se rendre de Clermont-Ferrand Tarbes. Il ny a pas de vol direct mais il peut passer soit par Toulouse, soit par Lyon (les deux changeurs de messages suivants dans la liste). Puisque Toulouse est le plus proche de Tarbes, cest celui que choisit le passager. Une fois arriv Toulouse, il serait insens de se rendre Lyon, plus loign de la destination nale (un changeur de message prfrence moindre) ou, pire encore, de se rendre de Toulouse Toulouse. La seule solution acceptable consiste prendre un vol Toulouse/Tarbes. Le voyageur limine donc les destinations les moins utiles pour viter de tourner en rond et de perdre du temps. Attention, la plupart des routeurs de messages ne cherchent que leur nom canonique dans la liste des enregistrements MX. Ils ne recherchent pas les alias (les noms situs gauche dans les enregistrements CNAME). Si on nutilise pas exclusivement des noms canoniques dans les enregistrements MX, il nest pas garanti quun routeur trouve son propre nom dans la liste et on risque dobtenir une boucle. Si on dclare un changeur de messages laide dun alias et que ce routeur tente de se livrer un message lui-mme, la plupart des routeurs dtecteront la boucle et renver2. Cet algorithme est bas sur la RFC 974 qui dcrit le routage des messages dans lInternet.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Algorithme des MX

91

ront le courrier avec un message derreur. Voici le message renvoy par les versions rcentes de sendmail :
554 MX list for movie.edu points back to relay.isp.com 554 <root@movie.edu>... Local configuration error

Ce message remplace ltrange Je refuse de dialoguer avec moi-mme (I refuse to talk to myself) des anciennes versions de sendmail. Conclusion : dans un enregistrement MX, utilisez toujours le nom canonique de lchangeur. Attention nouveau, les changeurs de messages que vous utilisez doivent avoir des enregistrements dadresse. Un routeur a besoin de ladresse de chaque changeur pour pouvoir essayer de lui livrer le courrier. Revenons lexemple de oreilly.com. Lorsque ruby.oreilly.com reoit le message envoy par votre poste de travail, son routeur teste la liste des enregistrements MX :
oreilly.com. oreilly.com. oreilly.com. IN IN IN MX MX MX 0 ora.oreilly.com. 10 ruby.oreilly.com. 10 opal.oreilly.com.

Il trouve son nom dans la liste, associ une prfrence de 10 et abandonne alors tous les enregistrements de valeur gale ou suprieure 10 (ceux en gras dans la liste cidessous) :
oreilly.com. oreilly.com. oreilly.com. oreilly.com. IN IN IN IN MX MX MX MX 0 ora.oreilly.com. 10 ruby.oreilly.com. 10 opal.oreilly.com. 0 ora.oreilly.com.

pour ne conserver que : Puisque ora.oreilly.com est arrt, ruby.oreilly.com diffre la livraison et place le message en le dattente. Si un routeur dcouvre quil a lui-mme la meilleure prfrence (la plus petite valeur), il abandonne la liste complte. Dans certains cas, le routeur essaie encore de livrer le courrier ladresse IP de lhte de destination. Il peut sagir dune erreur, provenant du fait que le DNS dsigne ce routeur comme destination nale du courrier et que le routeur na pas t congur pour le garder. Lerreur peut aussi venir du fait que ladministrateur a mal class les enregistrements MX en attribuant de mauvaises valeurs de prfrence. Supposons que ladministrateur du domaine acme.com a ajout un enregistrement MX pour diriger le courrier adress acme.com vers son fournisseur daccs lInternet :
acme.com. IN MX 10 mail.isp.net.

La plupart des routeurs doivent tre congurs pour reconnatre leurs alias ainsi que les noms des htes pour lesquels ils traitent le courrier. moins que le routeur sur mail.isp.net ne soit congur pour conserver le courrier adress acme.com, il suppose quon lui demande de relayer le courrier et de le retransmettre vers un changeur plus proche que lui de la destination nale3. Lorsquil recherche lenregistrement MX

3.

moins, bien sr, que le routeur de mail.isp.net ne soit congur pour ne pas relayer le courrier des domaines inconnus.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

92

Chapitre 5 DNS et courrier lectronique

dacme.com, il trouve quil est lui-mme lchangeur le mieux plac et renvoie alors le courrier lexpditeur avec le classique message :
554 MX list for acme.com points back to mail.isp.net 554 <root@acme.com>... Local configuration error

De nombreuses versions de sendmail utilisent la classe w ou le chier de classe w pour dnir les destinations pour lesquels le routeur doit conserver le courrier (destinations locales ). En fonction de votre chier sendmail.cf, lajout dun alias peut se faire simplement grce laddition dune ligne au chier sendmail.cf :
Cw acme.com

Vous avez remarqu que nous utilisons des multiples de 10 pour la valeur de prfrence. Cette valeur est pratique, car elle permet dintercaler facilement des enregistrements MX provisoires dans la liste sans modier les autres enregistrements. On pourrait tout aussi bien utiliser des incrments de 100, leffet serait le mme. 4

DNS et authentication du courrier


Tous les serveurs de courrier savent utiliser les enregistrements MX congurs dans le DNS pour dterminer vers o envoyer les messages ; certains dentre eux exploitent aussi dsormais dautres informations du DNS pour authentier lauteur dun message. Plus prcisment, plusieurs mcanismes dauthentication rcents utilisent des enregistrements de ressource stockant des informations critiques. Bien quune description complte de chacun deux dpasse lobjet de ce livre, nous aimerions prsenter celui qui est le plus rpandu, en insistant plus particulirement sur ses relations avec le DNS.

Sender Policy Framework


Nous allons dcrire SPF (Sender Policy Framework) car il sagit du mcanisme dauthentication le plus rpandu et, qui plus est, il est relativement simple prsenter. SPF permet ladministrateur de la messagerie dune entreprise, ventuellement avec la collaboration de son collgue ladministrateur du DNS, dannoncer les serveurs de messagerie autoriss expdier du courrier au nom du domaine de lentreprise. On peut voir SPF comme la rciproque de la fonction des enregistrements MX, qui dnissent la liste des serveurs de messagerie auxquels il faut envoyer le courrier destination dun certain domaine, SPF annonant la liste des serveurs autoriss expdier du courrier au nom de domaine de lentreprise5. Voici un exemple simple. Supposons que le courrier lgitime au nom de oreilly.com doive tre expdi de lun des deux serveurs SMTP smtp1.oreilly.com ou smtp2.oreilly.com. Ladministrateur de la messagerie de OReilly Media peut lannoncer dans le DNS en ajoutant un enregistrement TXT associ au nom oreilly.com (ou en le demandant tout administrateur DNS de la zone oreilly.com). Voici lallure dun tel enregistrement TXT :
oreilly.com. IN TXT "v=spf1 +a:smtp1.oreilly.com +a:smtp2.oreilly.com all"

4. 5.

NdT : Pour la mme raison, il peut tre intressant dviter la valeur de prfrence 0 an de pouvoir ajouter un nouvel changeur de messages en dbut de liste. Dailleurs, SPF est issu dune proposition appele MX inverse (Reverse MX) de Hadmut Danisch.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et authentification du courrier

93

Le premier champ de la partie donnes, v=spf1, identie cet enregistrement TXT comme tant un enregistrement SPF. Il est ncessaire, car les enregistrements TXT servent de nombreuses autres fonctions, dont la publication de commentaires textuels, et il ne faudrait pas que des routeurs de messagerie cherchent interprter des commentaires comme tant des informations SPF. Sil merge, SPF se verra peut-tre attribuer un enregistrement de ressource spcique SPF et lexpression initiale deviendra inutile. Les deux champs suivant annoncent que le courrier provenant de oreilly.com peut provenir de toutes les adresses IP des serveurs smtp1.oreilly.com et smtp2.oreilly.com. Le signe + initial permet de qualier linformation et indique que les courriers expdis partir des adresses IP de ces htes sont autoriss. Les quatre valeurs de qualication possibles sont : + ~ ? Autorisation (Pass) : un serveur correspondant au schma est valide. Refus (Fail) : un serveur correspondant au schma nest pas valide. Refus probable (SoftFail) : un serveur correspondant au schma nest probablement pas valide et le message doit tre trait avec attention. Neutre (Neutral) : aucun effet.

La valeur par dfaut est + (pass) et ce signe peut tre omis. Le dernier champ, all, indique que tout autre expditeur au nom de oreilly.com nest pas valide. Un autre moyen permet dannoncer les expditeurs valides. Puisque les enregistrements MX de oreilly.com contiennent les deux serveurs SMTP smtp1.oreilly.com et smtp2.oreilly.com, le gestionnaire de la messagerie peut crer lenregistrement TXT simpli suivant :
oreilly.com. IN TXT "v=spf1 +mx all"

Lorsquil ne sont pas suivis de : et dun paramtre, les directives telles que a et mx reprennent implicitement le nom de lenregistrement. Ainsi, +mx est quivalent, ici, +mx:oreilly.com. Voici la liste des directives utilises dans les enregistrements TXT de SPF : a Dnit le nom dun serveur de messagerie dont la ou les adresses sont autorises expdier du courrier au nom utilis pour lenregistrement. mx Indique que les changeurs de message sont autoriss expdier du courrier au nom utilis pour lenregistrement. ip4 Dnit ladresse IP(v4) dun serveur de messagerie, autorise expdier du courrier au nom utilis pour lenregistrement. On peut aussi dnir un rseau, en notation CIDR (tel que 192.168.0.0/24). Notons que les quatre octets du rseau doivent tre dnis.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

94
ip6

Chapitre 5 DNS et courrier lectronique

Dnit ladresse IPv6 dun serveur de messagerie, autorise expdier du courrier au nom utilis pour lenregistrement. On peut aussi dnir un rseau, en notation RFC 3513. ptr Requiert quil existe un enregistrement PTR pour ladresse du serveur dexpdition. Lenregistrement PTR doit correspondre un nom se terminant par le nom de lenregistrement TXT ou par celui indiqu aprs le : . Ainsi, +ptr:oreilly.com indique que le courrier doit tre envoy dune adresse correspondant un nom se terminant par oreilly.com. Les enregistrements SPF supportent aussi la directive redirect qui permet plusieurs noms denregistrement de partager un ensemble de dnitions SPF. Ainsi, supposons que ladministrateur de oreilly.com veuille que les noms ca.oreilly.com et ma.oreilly.com partagent les rgles dj tablies pour oreilly.com. Pour ne pas dupliquer lenregistrement TXT de oreilly.com, il peut initialiser lenregistrement TXT suivant :
ca.oreilly.com. IN TXT "v=spf1 redirect=oreilly.com" ma.oreilly.com. IN TXT "v=spf1 redirect=oreilly.com"

Cela indique aux routeurs de se rfrer aux enregistrements SPF de oreilly.com lorsquil recherche quels sont les expditeurs valides pour ca.oreilly.com et ma.oreilly.com. De cette manire, ladministrateur na plus qu grer un seul enregistrement SPF. La directive include a une fonction similaire et permet de se rfrer une conguration SPF gre par quelquun dautre. Ainsi, si ladministrateur de oreilly.com veut aussi autoriser tout expditeur valide de isp.net envoyer du courrier au nom de oreilly.com, il peut complter lenregistrement TXT de oreilly.com :
oreilly.com. IN TXT "v=spf1 +mx include:isp.net all"

Notons que le sparateur entre include et son argument est : , alors que le sparateur entre redirect et son argument est = . Voici maintenant deux conseils. Il est bon, au dbut, dutiliser ?all ou ~all dans vos enregistrements SPF car, de manire surprenante, il est difcile dnumrer tous les expditeurs valides de votre entreprise. En effet, vous pouvez avoir des utilisateurs distants qui grent leur propre serveur de messagerie, des utilisateurs mobiles qui expdient partir de leur PDA en utilisant ladresse lectronique de lentreprise, etc. Il ne faudrait pas les isoler par inadvertance. Si vos enregistrements SPF sont longs et complexes, ils peuvent dpasser la limite autorise dans un enregistrement TXT, soit 255 octets. Dans ce cas, vous pouvez rpartir lenregistrement dans plusieurs enregistrements TXT, chacun deux commenant par une directive v=spf1. Ils seront tous concatns avant valuation. Terminons par deux mises en garde. Souvenons-nous que, mme si vous publiez une information SPF, seuls les routeurs qui supportent SPF les rechercheront et les utiliseront. ce jour, ils constituent une trs petite proportion des routeurs de lInternet (pourtant, la publication denregistrements SPF ne fait aucun mal, alors pourquoi ne pas le faire ?). De plus, il faut savoir que SPF peut changer, ne jamais vritablement merger ou tre supplant par dautres procds.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

6
Prparation des clients
trange troupe en vrit, que celle qui sassembla sur la rive : oiseaux aux plumes mouilles, animaux dont la fourrure collait au corps, tous tremps comme des soupes, mal laise et de mauvaise humeur.

Une fois les serveurs de noms du domaine oprationnels, les clients doivent tre prpars pour les utiliser ; il faut initialiser les resolvers, ce qui consiste essentiellement leur dnir les serveurs de noms interroger et leur domaine dappartenance. Ce chapitre dcrit ces diffrentes oprations ainsi que la mise en uvre des resolvers des principaux Unix et de ceux de Windows 2000, 2003 et XP (qui sont essentiellement les mmes).

Le resolver
Les resolvers ont t voqus au Chapitre 2. Le resolver est le client du systme de noms de domaine. Il transforme la question pose par un programme en requte envoye au serveur de noms et traduit la rponse reue avant de la transmettre au programme. Jusquici, il na pas encore t ncessaire de proposer une conguration de resolver. En effet, lors de linitialisation des serveurs au Chapitre 4, le comportement par dfaut du resolver tait sufsant pour les tests. Mais si nous voulons en tirer plus ou si nous voulons un comportement autre que celui par dfaut, nous devrons congurer le resolver. Le comportement du resolver dcrit dans les prochaines sections est celui de BIND 8.4.6, sans autre service de noms que le DNS. Certains resolvers commerciaux sont bass sur des versions plus anciennes ou disposent de fonctions spciales permettant de modier lalgorithme de rsolution. Les diffrences signicatives de comportement de BIND 8.4.6 et des versions prcdentes (particulirement pour les versions 4.8.3 et 4.9) seront signales lorsque ncessaire. Nous dcrirons galement certaines extensions spciques plus loin dans ce chapitre.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

96

Chapitre 6 Prparation des clients

Congurer le resolver
Dans la plupart des cas, on peut congurer au moins trois lments du comportement des resolvers : le nom du domaine local, la liste de recherche et les serveurs de noms interrogs par le resolver. De nombreux resolvers commerciaux acceptent des extensions non standard du DNS. Certaines de ces extensions sont parfois ncessaires au fonctionnement de logiciels tels que le service NIS (Network Information Services1) de Sun, dans dautres cas il sagit simplement dune valeur commerciale ajoute. Lessentiel de la conguration dun resolver se fait dans le chier /etc/resolv.conf (ou ventuellement dans /usr/etc/resolv.conf ; il est ncessaire de consulter le manuel du resolver, habituellement dans la section 4 ou 5 de la documentation Unix, pour sen assurer). Cinq directives principales apparaissent dans resolv.conf : domain, search, nameserver, sortlist et options. Elles contrlent le comportement du resolver.

Le nom du domaine local


Le nom du domaine local est le nom du domaine dans lequel se trouve le resolver. Dans la plupart des cas, cest le nom de la zone dans laquelle se trouve le resolver. Ainsi, le resolver de toystory.movie.edu utilise probablement movie.edu comme domaine local. Le resolver utilise le nom du domaine local pour interprter les noms qui ne sont pas totalement qualis. Dans un chier .rhosts, la ligne :
relay bernie

suppose que lhte de nom relay est dans le domaine local, car il serait insens de valider directement laccs tous les utilisateurs bernie de tous les htes de lInternet dont le nom quali commence par relay. Les chiers tels que hosts.equiv ou hosts.lpd fonctionnent de la mme manire. Le nom du domaine local se dduit normalement de hostname : le domaine local suit le premier . du nom. Si le nom ne comporte pas de . , on suppose que le domaine local est le domaine racine. Ainsi, hostname asylum.sf.ca.us xe le domaine local sf.ca.us, alors que hostname dogbert implique un domaine racine local (ce qui est probablement incorrect, tant donn quil ny a que trs peu dhtes immdiatement sous la racine2). On peut aussi xer le nom du domaine local laide de la directive domain dans resolv.conf. Si cette directive apparat, elle a priorit sur hostname. La syntaxe de la directive domain est simple mais rigoureuse car le resolver ne signale pas les erreurs. Le mot-cl domain doit dbuter la ligne, tre suivi dun ou de plusieurs espaces (ou tabulations), puis du nom du domaine. Le domaine local scrit sans point nal :
domain colospgs.co.us

Dans les anciennes versions de resolver de BIND (avant 4.8.3), les espaces ne sont pas autoriss en n de ligne, car ils apparaissent alors la n du nom du domaine local. La variable denvironnement LOCALDOMAIN est une autre mthode pour xer le nom

1. 2.

Le nom NIS remplace le nom Yellow Pages (pages jaunes) ou YP en raison dun copyright de la , compagnie britannique de tlphone sur le nom Yellow Pages. Certains noms un seul terme dsignent directement des adresses. Cest le cas, par exemple, de cc.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Configurer le resolver

97

du domaine local. Elle permet chaque utilisateur de rgler individuellement son domaine local. Par exemple, une machine situe dans un centre de calcul accueille de nombreux utilisateurs provenant dautres domaines. Chaque utilisateur effectue lessentiel de son travail dans son domaine dorigine. Avec LOCALDOMAIN, il peut xer le nom du domaine local celui de son domaine dorigine. Quelle mthode utiliser ? hostname, la directive domain ou la variable denvironnement LOCALDOMAIN ? Les exemples de ce livre utilisent hostname, essentiellement car cest la mthode utilise Berkeley et parce quelle parat plus claire puisquelle requiert moins de congurations explicites. De plus, certains logiciels de Berkeley (particulirement ceux qui utilisent lappel la bibliothque ruserok() pour authentier les utilisateurs) nautorisent des noms courts dans les chiers hosts.equiv que dans le cas o hostname est un nom totalement quali. Pour les logiciels qui nacceptent pas de noms dhte longs, il est possible dutiliser la directive domain. La commande hostname continue renvoyer des noms courts et le resolver utilise le nom de domaine issu de resolv.conf. Enn, LOCALDOMAIN peut tre intressante sur des htes accueillant de nombreux utilisateurs.

La liste de recherche
Le nom du domaine local, quil provienne de hostname ou de resolv.conf, xe la liste de recherche par dfaut. Cette liste facilite le travail des utilisateurs : un nom non totalement quali sera recherch parmi les domaines numrs dans cette liste. La plupart des commandes Unix (telles que telnet, ftp, rlogin et rsh) qui acceptent un nom comme argument appliquent la liste de recherche largument. La manire dont la liste par dfaut est extraite des chiers puis applique aux arguments a chang entre BIND 4.8.3 et BIND 4.9. Tous les anciens resolvers se comportent comme celui de la version 4.8.3 et tous les plus rcents (dont celui de BIND 8.4.73) se comportent comme celui de la version 4.9. Avec tout resolver BIND, un nom avec un point terminal indique un nom totalement quali4. Par exemple, le point nal dans la commande :
% telnet ftp.ora.com.

indique quil nest pas ncessaire dajouter dautres domaines au nom, car celui-ci est totalement quali. Ceci est similaire une barre oblique en dbut de chemin dans un systme de chiers Unix ou MS-DOS : les chemins sans barre oblique sont interprts relativement au rpertoire courant, alors que ceux commenant par une barre oblique sont absolus et partent de la racine.

3. 4.

Bien que lISC ait ajout de nouvelles fonctions aux serveurs de noms BIND 8 et 9, le resolver de ces nouvelles versions de BIND est globalement identique celui de BIND 4.9. Le resolver peut prendre en charge un nom avec point terminal, mais ce nest pas le cas de tous les programmes, en particulier de certains agents de messagerie : ils rejettent les adresses avant mme dessayer de les soumettre au resolver.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

98

Chapitre 6 Prparation des clients

La liste de recherche depuis BIND 4.9


La liste de recherche des resolvers depuis BIND 4.9 ne comprend que le domaine local. Pour un resolver initialis avec :
domain cv.hp.com

la liste par dfaut ne contient que cv.hp.com. De plus, la liste de recherche nest gnralement applique quaprs une recherche littrale du nom, ce qui est un comportement nouveau. Si le nom fourni par lutilisateur contient au moins un point, il est recherch tel quel avant lutilisation de la liste de recherche. Ce nest quen cas dchec que la liste de recherche est utilise. Par contre, si le nom ne contient pas de point, la liste de recherche est utilise avant la recherche du nom littral. En effet, lorsquun utilisateur fournit un nom comportant au moins un point, il sagit en gnral dun nom totalement quali sans point terminal. Il est donc plus intressant de rechercher en premier le nom saisi tel quel. Avec les anciennes versions de resolver, plusieurs requtes taient gnres avant lutilisation du nom littral. Par exemple, depuis les resolvers 4.9, lutilisation de :
% telnet pronto.cv.hp.com

provoque tout dabord la recherche de pronto.cv.hp.com (le nom contient trois points, ce qui est plus que un) avant celle de pronto.cv.hp.com.cv.hp.com. Par contre, lutilisation de :
% telnet asap

sur le mme hte provoque dabord la recherche de asap.cv.hp.com (le nom ne contient pas de point) avant celle de asap. Lutilisation de la liste de recherche cesse ds quune requte a abouti. Dans lexemple avec asap, le resolver najoute pas hp.com si asap.cv.hp.com mne une adresse.

La liste de recherche de BIND 4.8.3


La liste de recherche des resolvers BIND 4.8.3 inclut implicitement le domaine local et chacun de ses domaines-parents dont le nom contient au moins deux composants. Par exemple, avec un resolver 4.8.3 initialis avec :
domain cv.hp.com

la liste de recherche par dfaut contient en premier cv.hp.com (le domaine local), puis hp.com, mais pas com qui ne contient quun seul composant5. Si le nom fourni par lutilisateur contient au moins un point, il est recherch tel quel, aprs que le resolver a ajout chacun des lments de la liste de recherche. La saisie de :
% telnet pronto.cv.hp.com

5.

Les anciens resolvers de BIND najoutent pas le domaine de niveau suprieur car trs peu dhtes sont situs au second niveau de lespace de noms de lInternet : lajout de com ou edu au nom foo a peu de chance de conduire un hte rel et prsente linconvnient de risquer de gnrer une requte inutile vers un serveur de la racine.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Configurer le resolver

99

provoque la recherche de pronto.cv.hp.com.cv.hp.com, puis de pronto.cv.hp.com.hp.com, avant celle de pronto.cv.hp.com. La saisie de :


% telnet asap

sur le mme hte provoque la recherche de asap.cv.hp.com, puis de asap.hp.com, mais pas de asap, puisque le nom saisi ( asap ) ne contient pas de point.

La directive search
Avec tous les resolvers modernes, il est possible de xer explicitement la liste de recherche, nom de domaine par nom de domaine, laide de la directive search. Cette directive permet de modier lordre des domaines dans la liste. La syntaxe de la directive search est similaire celle de la directive domain, except pour le nombre darguments. Le mot-cl search commence en dbut de ligne et est suivi dun espace ou dune tabulation, puis de un six domaines6, dans lordre dutilisation souhait au moment dune recherche. Le premier domaine de la liste est considr comme domaine local. Les directives search et domain sont donc mutuellement exclusives. Si les deux sont utilises dans resolv.conf, celle dclare en second prdomine. Par exemple, la directive :
search corp.hp.com paloalto.hp.com hp.com

indique au resolver de rechercher en premier dans le domaine corp.hp.com, puis dans paloalto.hp.com et enn dans leur parent commun hp.com. Cette directive peut tre utile sur un hte dont les utilisateurs accdent frquemment aux htes des deux domaines corp.hp.com et paloalto.hp.com. Par contre, avec un resolver BIND 4.8.3, la directive :
search corp.hp.com

provoque la non-utilisation du domaine parent du domaine local lors de lutilisation de la liste de recherche (avec un resolver 4.9, ce domaine parent nest pas dans la liste par dfaut ; cette directive nest pas diffrente du comportement standard). Cela peut tre utile si les utilisateurs accdent uniquement des htes du domaine local ou si la connexion vers les serveurs du domaine parent nest pas bonne (rduction du nombre des requtes inutiles).
Avec lutilisation de la directive domain, la mise jour dun resolver en version 4.9 ou ultrieure de BIND, peut surprendre des utilisateurs habitus ce que le parent de leur domaine soit implicite lors dune recherche. Il est possible de reproduire lancien comportement en utilisant la directive search. Par exemple, avec BIND 4.9, BIND 8 ou BIND 9, on peut remplacer la directive domain nsr.hp.com par la directive search nsr.hp.com hp.com et obtenir le mme rsultat.

6.

Le resolver de BIND 9 accepte huit domaines dans la liste de recherche.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

100

Chapitre 6 Prparation des clients

La directive nameserver
Le Chapitre 4 dnit deux types de machines : les serveurs primaires et les serveursesclaves. Mais une machine ne faisant quutiliser le DNS na pas besoin dtre serveur. En standard, le resolver tente dutiliser un serveur de noms sur la machine elle-mme (cest ce qui sest pass lors du test des serveurs sur toystory.movie.edu ou wormhole.movie.edu laide de nslookup). Il est galement possible dindiquer au resolver dinterroger un serveur situ sur une autre machine. Lhte utilisant le resolver est appel un client DNS dans le BIND Operations Guide. La directive nameserver fournit au resolver ladresse IP dun serveur de noms interroger. Par exemple, la ligne :
nameserver 15.32.17.2

indique au resolver dinterroger le serveur de noms situ ladresse IP 15.32.17.2, plutt quun serveur situ sur le client lui-mme. Sur les htes naccueillant pas de serveur, la directive nameserver indique de contacter un serveur de noms distant. Elle sert prparer les clients pour quils interrogent les serveurs de leur domaine. Toutefois, de nombreux administrateurs ne restreignant pas les requtes, nimporte quel resolver peut tre prpar pour les interroger. Bien sr, il est impoli dutiliser le serveur de noms dautrui sans sa permission ; de plus, lutilisation de ses propres serveurs de noms offre de meilleures performances. Lutilisation dun serveur tiers doit tre rserve au dpannage. Pour indiquer un resolver dinterroger le serveur situ sur la machine elle-mme, il faut lui fournir soit ladresse IP locale, soit ladresse 0.0.0.0. Dans la plupart des mises en uvre de TCP/IP cette dernire adresse dsigne lhte local. Si ce nest pas le cas, il est , possible dutiliser ladresse de bouclage 127.0.0.1. Si un serveur de noms utilis par un resolver est arrt, le client pourra peut-tre utiliser la table dhtes locale. Une autre solution consiste indiquer jusqu trois serveurs de noms au resolver, en utilisant trois directives nameserver. Le resolver interroge ces serveurs, dans lordre de leur dclaration, jusqu la rception dune rponse. Les dclarations :
nameserver 15.32.17.2 nameserver 15.32.17.4

indiquent au resolver dinterroger dabord 15.32.17.2 puis, en cas de non rponse, 15.32.17.4. Le nombre de serveurs dclars est un facteur important du comportement des resolvers.
Lors de lutilisation de plusieurs directives nameserver, il ne faut pas utiliser ladresse de bouclage (loopback). En effet, il y a un bogue dans plusieurs mises en uvre de TCP/IP drives de Berkeley qui peuvent poser des problmes avec BIND si le serveur de noms local est arrt : la socket en mode connect du resolver ne se lie pas une nouvelle adresse dorigine locale. En consquence, le resolver envoie des requtes un serveur de secours distant, avec une adresse dorigine gale 127.0.0.1. Lorsque le serveur de secours tente de rpondre, il senvoie le message lui-mme.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Configurer le resolver

101

Avec un seul serveur de noms dclar


Si un seul serveur de noms est dclar7, le resolver interroge ce serveur. En cas de non rponse, il attend cinq secondes avant de ritrer sa requte. Si le resolver rencontre une erreur indiquant que le serveur de noms est rellement arrt ou inaccessible ou si le dlai dattente arrive chance, le dlai est doubl avant la nouvelle interrogation. Les messages derreurs possibles sont :

message ICMP port unreachable (port inaccessible), qui indique quaucun serveur de
noms nest lcoute sur le port du service de noms ;

message ICMP host unreachable ou network unreachable (hte ou rseau inaccessible),


qui signie que les requtes ne peuvent tre envoyes ladresse IP de destination. Si le domaine ou linformation recherche nexiste pas, le resolver ne ritre pas la requte. Thoriquement, chaque serveur a la mme vue de lespace de noms ; il ny a donc aucune raison de prfrer un serveur ou un autre. Par consquent, si un serveur de noms indique quun domaine nexiste pas ou que le type de donne recherche nexiste pas dans le domaine spci, tout autre serveur de noms devrait fournir la mme rponse. Si le resolver reoit un message derreur du rseau chaque fois quil envoie une requte, au bout de quatre erreurs, il dgrade son fonctionnement pour utiliser la table locale dhtes. Attention, il sagit derreurs et non pas de lcoulement de dlai dattente. Sil atteint nouveau le dlai, le resolver renvoie une rponse nulle mais ne dgrade pas son fonctionnement pour utiliser /etc/hosts.

Avec plusieurs serveurs de noms dclars


Si plusieurs serveurs de noms sont dclars, le comportement est lgrement diffrent : le resolver commence par interroger le premier serveur de noms de la liste, avec un dlai dattente de cinq secondes, comme dans le cas prcdent. Si le dlai dattente expire ou si une erreur est reue, le resolver utilise le serveur suivant dans la liste. Il linterroge avec un dlai dattente de cinq secondes. Malheureusement, parmi tous les types de messages derreurs possibles, le resolver en reoit peu. En effet, la socket utilise par le resolver est non connecte, car elle doit tre capable de recevoir une rponse de tout serveur interrog, et les sockets non connectes ne reoivent pas les messages derreur ICMP Si le . resolver interroge sans succs lensemble des serveurs, il augmente le temps dattente et recommence un nouveau cycle dinterrogation. Le dlai dattente du cycle de requte suivant est calcul sur la base du nombre de serveurs dclars dans resolv.conf. Le dlai utilis dans le second cycle est de 10 secondes divises par le nombre de serveurs dclars et arrondies par dfaut. Chaque nouveau dlai est le double du prcdent. Aprs trois cycles de retransmissions (cest--dire aprs quatre coulements de dlai pour chaque serveur), le resolver abandonne ses interrogations de serveurs de noms. Depuis BIND 8.2.1, lISC a modi le resolver an quil ne renouvelle son essai quune fois vers chaque serveur, ce qui fait un total de deux requtes pour chaque serveur de resolv.conf. Cela permet de rduire le temps dattente si aucun serveur ne rpond.

7.

Cela signie quune seule directive nameserver est utilise dans resolv.conf, ou quaucune directive nameserver nest utilise et quil y a un serveur de noms sur le client lui-mme.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

102

Chapitre 6 Prparation des clients

Pour les matheux, le tableau 6-1 montre les dlais dattente pour un, deux ou trois serveurs de noms dclars, avec les resolvers BIND 4.9 8.2.

Tableau 6-1. Dlais dattente dun resolver, de BIND 4.9 8.2


Nombre de serveurs de noms dclars dans resolv.conf Cycle 0 1 2 3 Total 5s 10s 20s 40s 75s 1 (2x) 5s (2x) 5s (2x) 10s (2x) 20s 80s 2 (3x) 5s (3x) 3s (3x) 6s (3x) 13s 81s 3

Le tableau 6-2 montre les dlais dattente depuis les resolvers BIND 8.2.

Tableau 6-2. Dlais dattente dun resolver depuis BIND 8.2.1


Nombre de serveurs de noms dclars dans resolv.conf Cycle 0 1 Total 5s 10s 15s 1 (2x) 5s (2x) 5s 20s 2 (3x) 5s (3x) 3s 24s 3

Ainsi, avec trois serveurs, le resolver interroge le premier avec un dlai dattente de cinq secondes puis, en cas de non rponse, le second et enn le troisime avec le mme dlai chaque fois. Il double ensuite le temps dattente, le divise par trois et larrondit par dfaut trois secondes (10/3 arrondis). Puis il recommence. Il sagit du pire des scnarios. Avec des serveurs de noms fonctionnant convenablement sur des machines sufsamment rapides, le resolver obtient une rponse en bien moins dune seconde. Ce nest quen cas de relle surcharge sur les trois serveurs dclars, ou de rupture du rseau, que le resolver effectue plusieurs cycles. En cas dchec complet de la recherche, le resolver renvoie un message derreur du type :
% telnet tootsie tootsie: Host name lookup failure

videmment, il peut scouler 75 secondes, voire un peu plus, avant lobtention dun tel message (voir le tableau 6-1), aussi faut-il tre patient.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Configurer le resolver

103

La directive sortlist
Depuis BIND 4.9, la directive sortlist permet de dsigner des rseaux et sous-rseaux utiliser en priorit pour atteindre certaines destinations, ce qui est particulirement utile lorsque le resolver reoit plusieurs adresses en rponse une requte unique. Exemple : une station de travail et son serveur NFS ont chacun deux interfaces de rseau, une sur un segment Ethernet 100 Mb/s correspondant au rseau IP 128.32.1/ 24 et lautre sur un segment Ethernet 1 Gb/s correspondant au rseau IP 128.32.42/24. Pour monter des systmes de chiers, la station de travail choisira probablement la premire adresse reue dans le paquet de rponse, lors de linterrogation du DNS propos du serveur NFS. La directive sortlist du chier resolv.conf permet de privilgier le rseau Ethernet en gigabit en indiquant au resolver de placer les adresses du rseau 128.32.42/24 en premire position dans la structure transmise en rponse aux programmes :
sortlist 128.32.42.0/255.255.255.0

Largument suivant la barre oblique est le masque du rseau. Pour privilgier lintgralit dun rseau, la barre et le masque de rseau peuvent tre omis :
sortlist 128.32.0.0

Dans ce dernier cas, le resolver privilgie lintgralit du rseau 128.32/16 (ici, le resolver utilise les deux premiers octets de ladresse IP pour dduire un masque de rseau correspondant un rseau non scind en sous-rseaux). Il est possible de dsigner jusqu dix rseaux privilgis :
sortlist 128.32.42.0/255.255.255.0 15.0.0.0

Le resolver classe toutes les adresses dune rponse, en plaant en premier celles apparaissant dans la directive et selon leur ordre dapparition dans cette directive, puis en plaant la n celles qui napparaissent pas dans la directive.

La directive options
La directive options a t introduite avec BIND 4.9 et permet dajuster plusieurs rglages internes au resolver. Le premier est le drapeau de dbogage, RES_DEBUG. Si le resolver a t compil avec loption DEBUG, ce qui nest gnralement pas le cas des produits commerciaux, la directive :
options debug

valide RES_DEBUG, ce qui gnre une grande quantit dinformations passionnantes de dbogage sur la sortie standard. Cette option permet danalyser un problme de resolver ou de service de noms. Le second rglage est ndots, qui dnit le nombre minimal de points que doit avoir un nom pour que le resolver le recherche avant dappliquer la liste de recherche. Par dfaut, ce comportement est celui des noms comportant au moins un point, ce qui correspond ndots:1. Il est possible de dplacer ce seuil si des utilisateurs sont plus habitus fournir des noms partiels que des noms ncessitant lapplication de la liste de recherche. Par exemple, si le domaine local est mit.edu et que les utilisateurs sont habitus utiliser :
% ftp prep.ai

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

104

Chapitre 6 Prparation des clients

avec lajout implicite de mit.edu pour produire prep.ai.mit.edu, laugmentation de ndots deux vitera linterrogation involontaire des serveurs de noms de la racine lors de lutilisation de noms situs dans le domaine ai :
options ndots:2

BIND 8.2 introduit quatre nouvelles options : attempts, timeout, rotate et no-check-names. attempts dnit le nombre de requtes que le resolver peut envoyer aux serveurs de noms dclars dans resolv.conf avant dabandonner la recherche. Si vous pensez que la nouvelle valeur de deux est trop faible pour vos serveurs de noms, vous pouvez laugmenter quatre, valeur par dfaut avant BIND 8.2.1 :
options attempts:4

La valeur maximale est de 5. timeout dnit le dlai dattente initial pour une requte envoye un serveur dclar dans resolv.conf. La valeur par dfaut est de cinq secondes. Si on souhaite que le resolver ritre ses requtes plus rapidement, on peut abaisser le dlai deux secondes :
options timeout:2

La valeur maximale est de trente secondes. chaque nouveau cycle, le resolver double le dlai initial puis le divise par le nombre de serveurs dclars dans resolv.conf. rotate indique au resolver dutiliser successivement tous les serveurs dclars dans resolv.conf, comme premier serveur interroger. Habituellement, tant que le premier serveur de la liste rpond dans le temps imparti, il est le seul tre interrog. Avec :
options rotate

chaque instance du resolver effectue un tourniquet sur la liste des serveurs : pour la premire requte, il interroge le premier serveur en premier, pour la seconde requte, il interroge le second serveur en premier, et ainsi de suite. Notons que de nombreux programmes ne peuvent pas tirer parti de cette option, car ils initialisent le resolver, effectuent une recherche puis sarrtent. Ainsi, la rotation na aucun effet sur une srie de commandes ping, car chaque processus ping initialise le resolver, interroge le premier serveur apparaissant dans resolv.conf et sarrte sans avoir appel le resolver une seconde fois. Chaque ping successif na aucune ide de lidentit du serveur appel la dernire fois par le client ou mme si ping a dj t utilis. Par contre, les processus longue dure de vie, comme le dmon sendmail, tirent bien parti de la rotation. La rotation complique le dbogage : on ne pourra jamais tre sr de lidentit du serveur, dclar dans resolv.conf, qui a rpondu au dmon sendmail lorsquil a reu cette chue rponse. Enn, no-check-names permet de dsactiver le contrle des noms au niveau du resolver8. Le contrle est activ en standard et il vrie que les noms sont conformes aux standards (seuls les caractres alphanumriques et les tirets sont accepts). Cette option permet de rechercher des noms contenant des souligns ou autres caractres non-alphnumriques. Plusieurs options peuvent tre combines sur une mme ligne de resolv.conf :
options attempts:4 timeout:2 ndots:2
8. Pour les resolvers qui le peuvent, partir de BIND 4.9.4.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Exemples de configuration de resolver

105

Commentaires
Depuis BIND 4.9, des commentaires peuvent apparatre dans le chier resolv.conf. Les lignes commenant par un dise ou un point virgule indiquent un commentaire et ne sont pas prises en compte par le resolver.

Note sur les directives du resolver version 4.9


Lors dune mise jour vers un resolver BIND 4.9, il faut tre attentif lutilisation des nouvelles directives, car il existe peut-tre, sur des programmes dj installs sur le systme, des ditions de liens statiques avec des fonctions de lancien resolver. En gnral, ce nest pas trop grave car les resolvers dans Unix ignorent les directives quils ne comprennent pas. Toutefois, ces programmes pourraient ne pas se comporter comme espr. Dans le cas de programmes utilisant un resolver antrieur 4.8.3, la directive search ne sera pas exploite. Le chier resolv.conf pourra contenir deux directives : domain en premier, puis search. Les anciens resolvers utiliseront la directive domain et ne prendront pas en compte la directive search. Les nouveaux resolvers liront la directive domain, mais la directive search sera prioritaire.

Exemples de conguration de resolver


Regardons maintenant laspect dun chier resolv.conf sur un hte rel. La conguration dun resolver change selon que lhte local est un serveur de noms ou non.

Resolver isol
Ladministrateur de movie.edu doit prparer le nouveau poste de travail dune enseignante. La machine nhberge donc pas de serveur de noms. La station est dans le domaine movie.edu, mais la professeur collabore intensivement avec la socit Pixar. Il peut tre intressant dajouter pixar.com la liste de recherche du resolver de la nouvelle station, laide dune directive search :
search movie.edu pixar.com

Cette directive place la station dans le domaine local movie.edu et recherche dans pixar.com, les noms non trouvs dans movie.edu. Le nouveau poste est dans le rseau 192.249.249/24 et ses plus proches serveurs de noms sont wormhole.movie.edu (192.249.249.1) et toystory.movie.edu (192.249.249.3). On peut se xer comme rgle dutiliser prioritairement le serveur de noms le plus proche (cest-dire celui situ sur lhte lui-mme sil existe, sinon un serveur situ sur le mme sousrseau, sinon un serveur situ sur le mme rseau). Dans ce cas, les deux serveurs cits prcdemment ont la mme priorit ; toutefois, wormhole.movie.edu est un hte plus performant. La premire directive nameserver dans resolv.conf sera alors :
nameserver 192.249.249.1

Pour consolider la conguration, le serveur toystory.movie.edu (192.249.249.3) est ajout par scurit comme serveur de secours. Si wormhole.movie.edu est indisponible, la station pourra continuer travailler (pour peu que toystory.movie.edu et le reste du rseau soient encore oprationnels).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

106
Finalement, le chier resolv.conf contiendra :
search movie.edu pixar.com nameserver 192.249.249.1 nameserver 192.249.249.3

Chapitre 6 Prparation des clients

Serveurs primaires cachs


Il existe une autre bonne raison pour indiquer au resolver dinterroger wormhole.movie.edu, lesclave, en premier. Ou plutt, il y a une bonne raison de congurer le resolver pour quil ninterroge pas le serveur primaire en premier. Nous modions quotidiennement les chiers de zone sur le serveur primaire et il y a une chance non ngligeable pour que nous ayons fait une faute ou une erreur de syntaxe. Dans ce cas, notre serveur primaire commencerait par renvoyer des rponses SERVFAIL aux requtes concernant movie.edu ou les zones inverses. Pour viter cette situation, certaines entreprises rendent cach leur serveur de noms primaire. Aucun resolver nest congur pour linterroger (en fait, dans certains cas, le serveur primaire est congur pour rejeter des requtes provenant dadresses IP autres que celles de ses esclaves). Les resolvers interrogent les serveurs secondaires ou les serveurs cache. Une erreur de syntaxe dans un chier de zone ne sera pas transfre aux esclaves, car le serveur primaire ne rpondra pas quil fait autorit tant que lerreur ne sera pas rsolue. Le serveur primaire cach napparat pas dans les enregistrements NS de la zone sur laquelle il fait autorit. De cette manire, une interruption de service provoque par des fautes de frappe dans named.conf ou un chier de zone ne conduira pas une rupture du service du point de vue des resolvers.

Resolver doubl dun serveur de noms


Le routeur de messagerie de luniversit, postmanrings2x.movie.edu, utilise le service de noms. Cette machine sert tous les groupes de movie.edu. Un serveur de noms a rcemment t install sur cette machine, an de soulager les autres serveurs de noms. Il est souhaitable de sassurer que son resolver interroge bien prioritairement ce serveur de noms local. Dans ce cas, le plus simple est de ne pas crer de chier resolv.conf car, par dfaut, le resolver utilise le serveur de noms local. hostname doit tre initialis par le nom totalement quali de lhte, an que le resolver puisse dterminer le nom du domaine local. Si nous dcidons dinstaller un serveur de noms de secours (une sage dcision), nous pourrons initialiser resolv.conf. Que nous congurions ou non un serveur de secours dpend essentiellement de la abilit du serveur de noms local. Une application named correctement mise en uvre peut fonctionner sur de longues dures sans aucun problme ; un serveur de secours nest donc pas obligatoire. Toutefois, si le serveur de noms local a occasionnellement des problmes (suspensions de service), il serait bon de dnir un serveur de secours. Pour ajouter un serveur de noms de secours, il suft dindiquer le serveur de noms local (dadresse 0.0.0.0) en premire position dans le chier resolv.conf, suivi dun ou deux

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Minimiser les contraintes

107

serveurs de secours. Mieux vaut ne pas utiliser ladresse de bouclage local, sauf si la pile TCP/IP du systme ne prsente pas le problme dcrit lavertissement de la page 106. Par scurit, ladministrateur ajoute deux serveurs de noms de secours. postmanrings2x.movie.edu est connect au rseau 192.249.249/24 ; toystory.movie.edu et wormhole.movie.edu sont donc les deux autres plus proches serveurs. Par rapport lexemple prcdent, ladministrateur choisit dinverser lordre de ces deux serveurs9, an de rpartir la charge. De plus, il ne veut pas attendre cinq secondes avant dessayer un autre serveur ; il abaisse donc le dlai dattente deux secondes. Finalement, le chier resolv.conf se prsente sous la forme suivante :
domain movie.edu nameserver 0.0.0.0 nameserver 192.249.249.3 nameserver 192.249.249. options timeout:2

Minimiser les contraintes


Quest-ce qui va changer maintenant que lhte est prt pour lutilisation du DNS ? Les utilisateurs seront-ils obligs dutiliser des noms longs ? Devront-ils changer leur adresse de courrier et leurs inscriptions dans des listes de diffusion ? Heureusement, la liste de recherche fait que la plupart des services continueront fonctionner comme prcdemment. Il y a bien sr des exceptions car certains programmes se comportent diffremment lorsquils utilisent le DNS.

Diffrences comportementales
Des programmes comme telnet, ftp, rlogin et rsh appliquent la liste de recherche aux noms non termins par un point. Pour un utilisateur situ dans le domaine local movie.edu et dont la liste de recherche inclut movie.edu, lemploi de :
% telnet misery

ou de :
% telnet misery.movie.edu

ou encore de :
% telnet misery.movie.edu.

conduit au mme rsultat. De plus, puisquun serveur de noms peut renvoyer plus dune adresse IP en rponse une recherche dadresse, les versions rcentes de Telnet, de FTP et des navigateurs web essaient de se connecter la premire adresse renvoye et, en cas dchec ou de refus, la seconde puis aux suivantes :
% ftp tootsie ftp: connect to address 192.249.249.244: Connection timed out Trying 192.253.253.244... Connected to tootsie.movie.edu.

9.

moins quil nexiste un serveur primaire cach. Dans ce cas, bien sr, nous aurons probablement besoin dun autre serveur secondaire pour participer aux rponses.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

108

Chapitre 6 Prparation des clients

220 tootsie.movie.edu FTP server (Version 16.2 Fri Apr 26 18:20:43 GMT 1991) ready. Name (tootsie: guest):

La directive sortlist de resolv.conf permet mme de contrler lordre dans lequel les applications essaient ces adresses IP . Le service NFS est lui aussi concern par le DNS. La commande mount utilise correctement les noms ; ils peuvent apparatre dans les chiers /etc/fstab (ou /etc/checklist dans certains systmes). /etc/exports dnit les systmes de chiers pouvant tre monts par des clients via NFS. /etc/netgroup permet de constituer des groupes dhtes dont les noms peuvent tre utiliss dans /etc/exports. Malheureusement, les anciennes versions de NFS nutilisent pas vraiment le DNS lors de la lecture des chiers exports ou netgroup. En effet, le client sidentie auprs du serveur laide dun message RPC (Remote Procedure Call) et lidentication utilise par le client est le nom local de lhte hostname. Le nom utilis dans les chiers exports ou netgroup doit correspondre celui du client, hostname, qui nest pas obligatoirement un nom DNS.

Courrier lectronique
Certains programmes de messagerie lectronique, dont sendmail, nutilisent pas la liste de recherche de la mme manire que les autres. Lorsquil est congur pour interroger un serveur de noms, sendmail utilise un processus appel canonisation pour convertir les noms dune adresse de messagerie en noms canoniques. Pour la canonisation, sendmail applique la liste de recherche un nom pour rechercher des informations de type ANY, cest--dire tout type denregistrement de ressource. sendmail fonctionne comme les nouveaux resolvers : si le nom canoniser contient au moins un point, ce nom est dabord essay tel quel. Si le serveur de noms interrog renvoie un enregistrement CNAME (un alias), sendmail remplace le nom recherch par le nom canonique dsign par lalias puis canonise le rsultat au cas o la cible de lalias seraitelle mme un alias. Si le serveur de noms renvoie un enregistrement A (une adresse), sendmail utilise le nom correspondant ladresse comme nom canonique. Si le serveur de noms ne trouve pas dadresse mais trouve un ou plusieurs enregistrements MX, lune des actions suivantes est effectue :

si la liste de recherche na pas encore t applique, sendmail utilise le nom correspondant aux enregistrements MX comme nom canonique ;

si un ou plusieurs lments de la liste de recherche ont dj t appliqus, sendmail


mmorise que le nom est un nom canonique potentiel puis continue appliquer les lments de la liste de recherche. Si lajout dun nouvel lment de la liste de recherche provoque le renvoi dune adresse, le nom correspondant est pris comme nom canonique. Sinon, le nom qui a conduit au premier enregistrement MX est utilis comme nom canonique10.

10. Cette procdure complexe est ncessaire pour traiter le cas des enregistrements MX gnriques que nous prsenterons au Chapitre 17.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Minimiser les contraintes

109

Lors du traitement dun message SMTP sendmail enchane plusieurs canonisations ; , celle de ladresse de destination et celle de plusieurs champs de len-tte11. sendmail initialise la macro $w la valeur canonise de hostname au moment du dmarrage de sendmail. Autrement dit, mme en utilisant un nom ne comportant quun seul lment pour hostname, sendmail canonise hostname en utilisant la liste de recherche dnie dans resolv.conf. sendmail ajoute ensuite la macro $w et tous les alias vers $w rencontrs durant la canonisation la classe $=w, qui reprsente la liste de tous les autres noms du serveur de messagerie. Tout cela est particulirement important dans la mesure o les noms de la classe $=w sont les seuls noms que sendmail reconnaisse comme nom de lhte local. sendmail tentera de retransmettre les courriers adresss un nom prsum non local. Aussi, moins que sendmail ne soit prpar pour reconnatre la totalit des alias de lhte local (en les ajoutant la classe w ou au chier de classe w comme indiqu au Chapitre 5), lhte tentera-t-il de retransmettre tous les messages expdis vers une autre adresse que le nom canonique du domaine. La mthode utilise par sendmail pour canoniser le nom local est cruciale : sendmail ne reconnat que le contenu de la classe $=w comme nom canonique de lhte local lors dune exploitation des listes de MX. Par consquent, lhte pourrait ne pas se reconnatre si on nutilise pas un nom contenu dans $=w, dans la partie droite dun enregistrement MX. Il pourrait se produite le bouclage du courrier puis son retour lexpditeur. Dernier point concernant sendmail : avec une version de sendmail antrieure la version 8, lors du dmarrage dun nouveau serveur de noms, il faut positionner loption I dans le chier sendmail.cf. Loption I xe le comportement de sendmail lors de lchec dune recherche de nom. Avec /etc/hosts, un chec de recherche de nom est fatal : il est peu probable quune seconde recherche ait plus de succs ; le routeur de messagerie renvoie donc immdiatement le message avec une erreur. Par contre, avec le DNS, un chec peut tre temporaire, en raison de pannes intermittentes de rseaux. Loption I indique sendmail de placer les messages dans une le dattente si une recherche de nom choue. Il suft dajouter OI au chier sendmail.cf.

Mettre jour les chiers .rhosts, hosts.equiv, etc.


Aprs la mise en place du DNS, les chiers dautorisation utilisant des noms dhtes doivent tre mis jour. Les noms non qualis seront supposs tre dans le domaine local. Par exemple, le chier lpd.allow sur wormhole.movie.edu pourrait contenir :
wormhole toystory monsters-inc shrek mash twins
11. Certaines anciennes versions de sendmail utilisent une autre mthode de canonisation : elles appliquent la liste de recherche puis interrogent le serveur sur les enregistrements CNAME concernant le nom recherch. Une recherche de CNAME ne renvoie que des enregistrements CNAME. Si un enregistrement est trouv, le nom est remplac par le nom situ dans la partie gauche de lenregistrement.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

110

Chapitre 6 Prparation des clients

Si les htes mash et twins sont dplacs vers la zone comedy.movie.edu, ils ne seront plus autoriss accder lpd ; les lignes correspondantes de lpd.allow nautorisent limpression que pour mash.movie.edu et twins.movie.edu. Les domaines doivent donc tre ajouts aux noms qui ne sont pas dans le domaine local du serveur lpd :
wormhole toystory monsters-inc shrek mash.comedy.movie.edu twins.comedy.movie.edu

Voici les autres chiers vrier :


hosts.equiv .rhosts X0.hosts sendmail.cf

Parfois, lapplication dun ltre de canonisation sur ces chiers (un programme de traduction des noms dhtes en noms totalement qualis avec application de la liste de recherche) suft lever les ambiguts. Voici un exemple de ltre simple de canonisation, crit en Perl :
#!/usr/bin/perl -ap # Traitement dun nom dhte dans le premier champ de chaque ligne # (comme dans un fichier .rhosts ou X0.hosts) s/$F[0]/$d/ if ($d)=gethostbyname $F[0];

Alias
Mme en modiant toutes les bases de donnes et en convertissant tous les chiers .rhosts, hosts.equiv et sendmail.cf aprs la mise en uvre du DNS, les utilisateurs devront faire preuve dadaptabilit. Heureusement, les perturbations sont mineures par rapport aux bnces apports par le DNS. Une simplication du travail des utilisateurs consiste leur fournir des alias pour dsigner les htes bien connus, qui ne sont plus accessibles par un nom familier. Par exemple, les utilisateurs sont habitus utiliser telnet doofy ou rlogin doofy pour accder une machine situe de lautre ct de la ville. Ils doivent maintenant utiliser le nom complet, doofy.maroon.com, quils ne connaissent pas encore et auquel ils auront besoin de shabituer. Fort heureusement, BIND permet de dnir des alias. Il suft pour cela que la variable denvironnement HOSTALIASES dsigne un chier contenant des correspondances entre des alias et des noms qualis. Pour dnir un alias collectif pour doofy, on peut initialiser la variable HOSTALIASES /etc/host.aliases dans les chiers dinitialisation des shells du systme et ajouter :
doofy doofy.maroon.com

dans /etc/host.aliases. Le format du chier dalias est simple : chaque ligne dnit une correspondance et doit contenir lalias, suivi despaces puis du nom non termin par un point. Lalias ne doit contenir aucun point.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Fichiers complmentaires de configuration

111

Ainsi, lorsquun utilisateur utilise telnet doofy ou rlogin doofy, le resolver substitue doofy.maroon.com doofy dans la requte dinterrogation du serveur de noms. Un message similaire ce qui suit, est renvoy lutilisateur :
Trying... Connected to doofy.maroon.com. Escape character is '^]'. IRIX System V.3 (sgi) login:

Si le resolver fonctionne en mode dgrad et utilise /etc/hosts, HOSTALIASES na aucun effet. Il peut donc tre intressant de crer un alias similaire dans /etc/hosts. Avec lhabitude, les utilisateurs commenceront associer le nom totalement quali qui apparat dans la bannire de telnet avec le tableau dafchage quils utilisent. Si ladministrateur connat les noms couramment utiliss, HOSTALIASES lui permet de secourir les utilisateurs perturbs par les changements. Les utilisateurs peuvent aussi crer leur propre chier dalias en positionnant la variable HOSTALIASES dans leur chier dinitialisation de shell.

Fichiers complmentaires de conguration


Il ne suft pas de congurer le resolver pour quil puisse interroger le DNS. Il faut aussi congurer le systme pour lui indiquer quels services il doit interroger pour des informations sur les noms et les adresses. Le chier le plus couramment utilis pour cela est nsswitch.conf, que nous allons maintenant dcrire. Certains diteurs utilisent irs.conf ou netsvc.conf.

nsswitch.conf
En ralit, nsswitch.conf permet de dnir lordre dans lequel les diffrentes sources dinformations sont consultes. On slectionne la base de donnes interroger laide dun mot-cl. Pour les services de noms, le mot-cl est hosts ; ses sources possibles sont dns, nis, nisplus et les (cette dernire dsigne le chier /etc/hosts). La syntaxe consiste simplement donner la liste des sources, dans lordre de consultation souhait, derrire le mot-cl indiquant la base de donnes. Par exemple :
hosts: dns files

indique au resolver dinterroger tout dabord le DNS, puis le chier /etc/hosts. Par dfaut, la rsolution passe dune source la suivante, si la premire source nest pas disponible ou si le nom recherch nest pas trouv. Des critres permettent de modier le comportement standard en dnissant un couple [condition=action] entre les sources. Les conditions sont : UNAVAIL La source na pas t initialise (dans le cas du DNS, il ny a ni chier resolv.conf ni serveur de noms en local). NOTFOUND Le service na pas la rponse la question (pour le DNS, le nom recherch ou le type recherch nexiste pas).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

112

Chapitre 6 Prparation des clients

TRYAGAIN La source est occupe mais pourra peut-tre rpondre plus tard (par exemple sur un coulement du dlai dattente du client aprs mission dune question). SUCCESS Le nom recherch a t trouv dans la source. Pour chacun de ces critres, il est possible dindiquer si le resolver doit poursuivre la recherche (continue) ou labandonner (return). Laction standard est return pour SUCCESS et continue pour les autres conditions. Par exemple, si on veut que le resolver interrompe la recherche sur une rception de NXDOMAIN (no such domain ou nom inexistant) mais quil utilise /etc/hosts lorsque le DNS nest pas initialis, il faut dnir :
hosts: dns [NOTFOUND=return] files

Le resolver de Windows XP
Nous dcrivons le resolver de Windows XP car la plupart des resolvers rcents de Windows Windows 2000, Windows Server 2003 lui ressemblent et fonctionnent de manire similaire. Pour y accder, cliquez sur dmarrer, puis Panneau de conguration, puis Connexions rseaux et Internet et, enn, Connexions rseau. La fentre de la gure 6-1 apparat.

Figure 6-1. Connexions rseau dans Windows XP


Effectuez un clic droit sur Connexion au rseau local et choisissez Proprits. Une fentre semblable celle de la gure 6-2 apparat. Double cliquez sur Protocole Internet (TCP/IP). La fentre de la gure 6-3 apparat.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le resolver de Windows XP

113

Figure 6-2. Proprits de Connexion au rseau local dans Windows XP

Figure 6-3. Configuration de base du resolver de Windows XP


[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

114

Chapitre 6 Prparation des clients

En choisissant Obtenir les adresses des serveurs DNS automatiquement, le resolver interrogera les serveurs de noms dsigns par le service DHCP local. En choisissant Utiliser ladresse de serveur DNS suivante, le resolver interrogera les serveurs indiqus dans Serveur DNS prfr et Serveur DNS auxiliaire12. Pour accder aux paramtres avancs du resolver, cliquez sur Avanc puis sur longlet DNS, ce qui fait apparatre la fentre de la gure 6-4.

Figure 6-4. Configuration avance du resolver de Windows XP


Si les adresses des serveurs de noms interroger ont t dnies dans la fentre de conguration de base du resolver, elles apparaissent en haut de cette fentre, sous Adresses des serveurs DNS, dans lordre dutilisation. Les boutons permettent dajouter, de modier, de supprimer ou de classer les serveurs de noms dans la liste. Il ne semble pas y avoir de limite sur le nombre de serveurs, mais il nest pas trs sens den dnir plus de trois.

12. Gloire Microsoft qui a clari sa terminologie ! Dans les versions prcdentes de Windows, les serveurs de noms sappelaient parfois DNS primaire et DNS secondaire. Certains utilisateurs comprenaient quil fallait indiquer les serveurs primaires et esclaves (serveurs secondaires) de certaines zones, ou autre chose encore. En effet, DNS semblait tre utilis pour Serveur de noms de domaine au lieu de systme de noms de domaine .

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le resolver de Windows XP

115

Le resolver de Windows XP utilise un algorithme de retransmission agressif, introduit dans Windows NT 4.0 SP4 : le resolver envoie sa premire requte au premier serveur dni. Toutefois, il nattend quune seconde avant de retransmettre la requte toujours au premier serveur dni mais simultanment pour chaque interface rseau. Sil na pas reu de rponse au bout de deux nouvelles secondes, il interroge simultanment tous les serveurs congurs pour toutes les interfaces, quils laient t statiquement ou dynamiquement via DHCP Si aucun de ces serveurs ne rpond dans les quatre secondes, le . resolver retransmet nouveau la requte tous les serveurs. Au passage, il double le temps dattente et recommence jusqu 4 retransmissions et 15 secondes dattente (pour plus de prcisions, consultez le livre blanc de Windows 2000 sur le DNS, ladresse http://www.microsoft.com/windows2000/docs/w2kdns.doc). Comme il est possible dobtenir deux rponses diffrentes une mme question, provenant de deux serveurs diffrents, le resolver de Windows XP ne prend pas en compte les rponses ngatives (no such domain name et no such data) lorsquil interroge plusieurs serveurs. Il ne renvoie la rponse ngative au demandeur que sil la reoit dun serveur qui serait congur pour toutes ses interfaces. Par contre, sil reoit une rponse positive, mme unique, il la renvoie au demandeur. En validant Ajouter des sufxes DNS principaux et spciques aux connexions, le resolver utilise le sufxe principal et les sufxes spciques aux connexions pour construire la liste de recherche. Le sufxe DNS spcique la connexion sinitialise dans le champ Sufxe DNS pour cette connexion ou via une option DHCP fournie par le serveur DHCP . Le sufxe principal sinitialise via le Panneau de conguration, puis licne Systme (dans lafchage classique), longlet Nom de lordinateur, puis en cliquant sur Modier et enn sur Autres La fentre de la gure 6-5 apparat.

Figure 6-5. Configuration du suffixe DNS principal dans Windows XP


Saisissez le sufxe dans le champ Sufxe DNS principal de cet ordinateur. Par dfaut, ce champ contient le nom du domaine Active Directory dappartenance, lorsque le poste est membre dun domaine AD. La case Ajouter des sufxes parents du sufxe DNS principal ( gure 6-4) indique au resolver de fonctionner comme celui de BIND 4.8.3, qui construit la liste de recherche partir du sufxe principal. Ainsi, si le sufxe principal est fx.movie.edu, la liste de recherche

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

116

Chapitre 6 Prparation des clients

contiendra fx.movie.edu et movie.edu. Notons que le sufxe spcique une connexion nest pas transmis (selon les termes de Microsoft) a une liste de recherche. Le bouton Ajouter ces sufxes DNS (dans lordre) indique au resolver dutiliser la liste de recherche dnie dans la fentre en dessous. Comme avec la liste des serveurs de noms, des boutons permettent dajouter, de modier, de supprimer ou de classer les sufxes dans la liste. Enn, il est intressant de mentionner les deux cases du bas de la fentre. Enregistrer les adresses de cette connexion dans le systme DNS indique au client dutiliser la mise jour dynamique pour ajouter un enregistrement dadresse A, ainsi que lenregistrement PTR correspondant, si ladresse est congure statiquement. Utiliser le sufxe DNS de cette connexion pour lenregistrement DNS permet de choisir le domaine utilis pour la mise jour dynamique : soit celui associ cette connexion, soit le sufxe principal de la machine. La mise jour dynamique permet de sassurer que le nom dun client Windows pointe bien vers son adresse IP courante, mme si cette dernire a t attribue par un serveur DHCP (en ralit, pour les clients DHCP le serveur DHCP ajoute lenregistrement PTR , de correspondance adresse-nom). Ce mcanisme scelle le destin de WINS (Windows Internet Name Service), la version propritaire et pernicieuse de Microsoft de NBNS (NetBIOS naming service). Lorsque tous vos clients fonctionneront avec une version moderne de Windows, ils pourront utiliser la mise jour dynamique pour grer leur correspondance nom-adresse, et vous pourrez enfoncer un pieu dans le cur de WINS. Nous dtaillerons lenregistrement de nom au Chapitre 17. La mise jour dynamique de zone par les clients est un d, que nous explorerons au Chapitre 17.

Mise en mmoire cache


Le resolver de Windows XP stocke chaque enregistrement dans une mmoire cache partage par tous les programmes du systme. Il conserve les enregistrements dans cette mmoire durant le temps indiqu par le champ TTL, avec un maximum de 24 heures par dfaut. Ce dlai maximal est modiable par une cl de registre :
MaxCacheTtl HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters Data type: REG_DWORD Default value: 86,400 seconds (= 24 hours)

Le resolver de Windows XP gre aussi une dure de vie sur rponse ngative, de 15 minutes par dfaut. Ce dlai est lui aussi modiable par une cl de registre :
MaxNegativeCacheTtl HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters Data type: REG_DWORD Default value: 900 seconds (= 15 minutes)

Pour dsactiver la dure de vie sur rponse ngative, il suft de mettre cette valeur 0.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le resolver de Windows XP

117

La commande ipcong /displaydns permet de visualiser le contenu de la mmoire cache, et ipcong /ushdns permet de la purger. La commande suivante permet de mettre horsservice la mmoire cache :
C:\> net stop dnscache

Ce dernier rglage ne sera effectif que jusquau prochain redmarrage. Pour mettre dnitivement hors-service la mmoire cache, il faut ouvrir lapplication Services (dans le groupe de programmes Outils dadministration) et rgler Client DNS Dsactiv.

Priorit de rseaux
Cette fonction est analogue la fonction de classement des adresses dun resolver BIND. Lorsquun resolver reoit plusieurs enregistrements dadresse correspondant un nom unique, il observe les adresses de chaque enregistrement et arrange lordre des enregistrements avant de renvoyer la liste lapplication appelante ; tout enregistrement contenant une adresse appartenant au mme rseau que le poste de travail excutant le resolver est plac en haut de la liste. Comme la plupart des applications utilisent les adresses dans lordre renvoy par le resolver, ce comportement aide contenir le trac sur les rseaux locaux. Ainsi, lUniversit du Cinma dispose de deux serveurs web en miroir, sur deux rseaux diffrents :
www.movie.edu. www.movie.edu. IN A 192.253.253.101 IN A 192.249.249.101

Supposons que le resolver de toystory.movie.edu (192.249.249.3) envoie une requte et reoive ces deux enregistrements. Ce resolver place lenregistrement contenant ladresse 192.249.249.101 en haut de la liste car toystory est sur le mme rseau que le serveur web cette adresse. Notons que ce comportement met en chec la fonction de tourniquet (round-robin) mise en uvre par la plupart des serveurs de noms, et qui consiste appliquer, au niveau des serveurs de noms, une permutation circulaire aux enregistrements dadresse multiples, lors de rponses successives, an de rpartir la charge sur les serveurs (ce principe repose sur le fait que la plupart des applications utilisent la premire adresse renvoye par le resolver). Avec la priorit aux rseaux locaux, lordre des enregistrements dadresse est modi par le resolver. La cl de registre suivante permet de mettre hors-service la priorit de rseaux :
PrioritizeRecordData HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters Data type: REG_DWORD Range: 0 - 1 Default value: 1 (Subnet prioritization enabled)

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

7
Exploitation de BIND
Eh bien, dans notre pays nous, rpondit Alice, encore un peu haletante, si lon courait trs vite pendant longtemps, comme nous venons de le faire, on arrivait gnralement quelque part, ailleurs. Un pays bien lent ! dit la Reine. Tandis quici, voyez-vous bien, il faut courir de toute la vitesse de ses jambes pour simplement rester l o on est. Si lon veut aller quelque part, ailleurs, il faut alors courir au moins deux fois plus vite que a !

Ce chapitre traite de lexploitation dun serveur de noms : pilotage, maintien jour des chiers de zone et du chier dindications sur les serveurs de la racine. Il expose aussi les messages derreur syslog standard et dcrit les statistiques gnres par BIND. Ces trois phases dexploitation ne concernent que les serveurs en tat de marche ; lanalyse des problmes et leur rsolution seront traites au Chapitre 14.

Piloter le serveur de noms


Par tradition, les administrateurs contrlent le serveur de noms BIND, named, laide de signaux Unix. Le serveur interprte la rception de certains signaux comme lordre dexcuter une action spcique, par exemple celle de recharger toutes les zones du serveur primaire ayant chang. Le problme est que le nombre de signaux possibles est limit et que les signaux ne permettent pas de transmettre des informations complmentaires, comme celle de recharger une zone spcique. Avec BIND 8.2, lISC a introduit une mthode de contrle du serveur qui consiste lui envoyer des messages via un canal de pilotage. Ce canal peut tre soit une socket du domaine Unix, soit un port TCP sur lequel le serveur est lcoute. Puisque le canal de pilotage nest pas limit par un nombre ni de signaux, cette mthode est plus souple et plus puissante. LISC prcise que le canal de pilotage est la mthode davenir et que les administrateurs doivent lutiliser en remplacement des signaux pour toutes les tches dadministration.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

120

Chapitre 7 Exploitation de BIND

Lenvoi de messages au serveur de noms via le canal de pilotage se fait laide du programme ndc (BIND 8) ou rndc (BIND 9). Avant BIND 8.2, ndc ntait quun simple script shell permettant de substituer des mnmoniques (tels que reload) aux signaux (tels que HUP). Nous prsenterons cette version de ndc plus loin.

Piloter avec ndc (BIND 8)


Excute sans arguments, la commande ndc tente de communiquer avec un serveur situ sur lhte local laide dune socket du domaine Unix. La socket sappelle habituellement /var/run/ndc, mais certains systmes dexploitation utilisent un chemin diffrent. La socket appartient normalement root et seul root peut y lire et y crire. BIND 8.2 et ses successeurs crent la socket dans le domaine Unix lors du dmarrage du dmon. On peut prciser un chemin et des droits non standard pour la socket en utilisant la directive controls. Lexemple suivant permet de changer le chemin de la socket /etc/ndc, dattribuer sa proprit au groupe named et de la rendre accessible en lecture et criture son propritaire et son groupe propritaire :
controls { unix "/etc/ndc" perm 0660 owner 0 group 53; // le groupe 53 est "named" };

La permission doit tre indique en octal (le zro initial indique que le nombre est octal). On pourra consulter la documentation de chmod(1) pour plus de prcisions. Les valeurs pour le propritaire et le groupe doivent tre numriques. LISC recommande, et nous aussi, de ne permettre laccs la socket du domaine Unix quau personnel autoris grer le serveur de noms. ndc peut aussi servir envoyer des messages un serveur, ventuellement distant, via une socket TCP Pour cela, il faut utiliser ndc avec loption c suivie du nom ou de . ladresse du serveur, dun slash et du numro du port sur lequel le serveur coute les messages de pilotage. Exemple :
# ndc -c 127.0.0.1/953

La directive controls permet de congurer le serveur pour quil coute sur un port TCP spcique :
controls { inet 127.0.0.1 port 953 allow { localhost; }; };

En standard, les serveurs BIND 8 ncoutent aucun port TCP mais les serveurs BIND 9 , coutent le port 953. Cest pour cela que nous avons choisi 953 pour nos exemples. Nous avons congur le serveur pour ncouter que ladresse locale de bouclage et pour naccepter que les messages provenant de lhte local. Toutefois, cela est imprudent, puisque nimporte qui pouvant se connecter sur lhte local peut piloter le serveur. Si nous tions encore moins prudents, nous pourrions largir la liste des htes autoriss gnrer des messages et laisser le serveur couter toutes les interfaces de rseau :
controls { inet * port 953 allow { localnets; }; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Piloter le serveur de noms

121

ndc accepte deux modes de fonctionnement : interactif ou non. En non interactif, le message passer au serveur apparat sur la ligne de commande :
# ndc reload

Si on nindique aucun paramtre en ligne de commande, on passe en mode interactif :


# ndc Type help -orndc> ndc> /h /h(elp) /e(xit) /t(race) /d(ebug) /q(uiet) /s(ilent) ndc> this text leave this program toggle tracing (protocol and system events) toggle debugging (internal program events) toggle quietude (prompts and results) toggle silence (suppresses nonfatal errors) /h if you need help.

/h renvoie la liste des commandes comprises par ndc (pas par le serveur) :

Ainsi, la commande /d indique ndc de produire des informations de dbogage sur les messages envoys au serveur de noms et les rponses reues. Elle na aucun effet sur le niveau de dbogage du serveur de noms. Pour cela, voyez la commande debug dcrite plus loin. Notons que seule /e, et non /x ou /q, permet de quitter ndc, ce qui nest pas trs intuitif. help donne la liste des commandes de pilotage de serveur disponibles :
ndc> help getpid status stop exec reload [zone] ... reconfig [-noexpired] (just sees new/gone zones) dumpdb stats trace [level] notrace querylog qrylog help quit ndc>

Les commandes start et restart ne sont pas indiques ici, bien quelles soient utilisables, car help donne la liste des commandes comprises par le serveur de noms et non pas par ndc. Or, le serveur ne peut pas lui-mme excuter la commande start, puisquil devrait dj tre en cours dexcution pour cela, et sil est en cours dexcution, il na pas besoin dtre dmarr. De mme, le serveur ne peut pas effectuer lui-mme un restart car, lorsquil sest arrt, il na aucun moyen de dmarrer une nouvelle instance de luimme. Par contre, rien nempche ndc deffectuer le start ou le restart.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

122
Voici une description des commandes :

Chapitre 7 Exploitation de BIND

getpid Afchage du numro de processus du serveur de noms. status Afchage dinformations utiles sur le serveur de noms, dont sa version, son niveau de dbogage, le nombre de transferts de zone en cours et la journalisation de requtes. start Dmarrage du serveur de noms. Si named doit tre dmarr avec des arguments en ligne de commande, ils peuvent apparatre aprs start, comme dans : start c /usr/ local/etc/named.conf. stop Arrt du serveur de noms avec criture des zones dynamiques vers les chiers de zone. restart Arrt et redmarrage du serveur. Comme avec start, des arguments pour named peuvent apparatre aprs la commande. exec Arrt et redmarrage du serveur. la diffrence de restart, on ne peut passer aucune option en ligne de commande de named ; le serveur dmarre une nouvelle copie de lui-mme avec les mmes arguments en ligne de commande. reload Rechargement du serveur de noms. Il faut envoyer cette commande un serveur primaire aprs une modication de son chier de conguration ou de lun de ses chiers de zone, ou un serveur-esclave. On peut prciser un ou plusieurs noms de zone en argument ; seules les zones indiques seront recharges. reconfig [noexpired] Test du chier de conguration pour dtecter lapparition ou la suppression de nouvelles zones. Il faut envoyer cette commande un serveur en cas dajout ou de suppression de zone, sans modication des zones dj existantes. Le drapeau -noexpired indique au serveur de ne pas renvoyer de messages derreur concernant les zones primes, ce qui est intressant si le serveur fait autorit sur des centaines de zones et que lon souhaite viter une rafale de messages dexpiration qui ne nous apprendrait rien de plus. dumpdb Gnration dune copie de la base de donnes interne du serveur de noms vers le chier named_dump.db situ dans le rpertoire de travail du serveur. stats Ajout de nouvelles statistiques au chier named.stats situ dans le rpertoire de travail du serveur.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Piloter le serveur de noms

123

trace [niveau] Ajout dinformations de dbogage au chier named.run situ dans le rpertoire de travail du serveur. Un niveau de dbogage plus lev augmente la quantit dinformation produite. Le Chapitre 13 dcrit les diffrents niveaux de dbogage. notrace Arrt de la gnration des informations de dbogage. querylog (ou qrylog) Activation ou dsactivation de la journalisation des requtes via syslog qui travaille ici au niveau de priorit LOG_INFO. named doit avoir t compil avec loption QRYLOG (ce qui est le cas par dfaut). quit Fin de la session de pilotage.

Piloter avec rndc (BIND 9)


Avec BIND 9, comme avec BIND 8, la directive controls permet de dnir le mode dcoute des messages de pilotage. La syntaxe est la mme mais seule la directive inet est accepte (BIND 9.3.2 ne gre pas les sockets du domaine Unix pour le canal de pilotage et lISC prvient que BIND 9 ne le fera sans doute jamais). En BIND 9, il nest pas ncessaire de dnir le port, le serveur coutant le port 953 en standard. Il faut aussi ajouter un argument keys :
controls { inet * allow { any; } keys { "rndc-key"; }; };

Cela dnit la cl de chiffrement utiliser pour lauthentication avec rndc pour pouvoir envoyer des messages de pilotage au serveur de noms. Si largument keys est omis, le message suivant apparat au dmarrage du serveur :
Jan 13 18:22:03 terminator named[13964]: type 'inet' control channel has no 'keys' clause; control channel will be disabled

Les cls utilises dans largument keys doivent tre dnies dans une directive key :
key "rndc-key" { algorithm hmac-md5; secret "Zm9vCg=="; };

La directive key peut apparatre directement dans le chier named.conf, mais si celui-ci est accessible en lecture pour tout le monde, il est prudent de la placer dans un autre chier, non publiquement lisible, et dinclure ce dernier dans named.conf :
include "/etc/rndc.key";

Le seul algorithme accept est HMAC-MD5, une technique utilisant lalgorithme de hachage rapide MD5 pour lauthentication1. La cl secrte, secret, est simplement le codage en base 64 dun mot de passe partag entre named et les utilisateurs autoriss de
1. Voir les RFC 2085 et 2104 au sujet de HMAC-MD5.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

124

Chapitre 7 Exploitation de BIND

rndc. Elle peut tre gnre par les programmes mmencode ou dnssec-keygen de la distribution de BIND, comme indiqu au Chapitre 11. Dans lexemple, on utilise mmencode pour gnrer le codage de foobarbaz en base 64 :
% mmencode foobarbaz CmZvb2JhcmJh

Pour utiliser rndc, il faut crer le chier rndc.conf pour lui indiquer les cls dauthentication et les serveurs de noms utiliser avec ces cls. rndc.conf est habituellement situ dans /etc. Voici un exemple de chier rndc.conf :
options { default-server localhost; default-key "rndc-key"; }; key "rndc-key" { algorithm hmac-md5; secret "Zm9vCg=="; };

La syntaxe est trs similaire celle de named.conf. laide de la directive options, on dnit le serveur de noms par dfaut auquel envoyer les messages de pilotage ainsi que le nom de la cl par dfaut prsenter ce serveur. Ces deux paramtres peuvent tre rednis en ligne de commande. La syntaxe de la directive key est la mme que celle utilise dans named.conf (voir plus haut). Le nom de la cl dans rndc.conf, ainsi que la cl secrte, doivent correspondre la dnition de cl dans named.conf.
Souvenez-vous que comme pour les cls (qui sont en fait des mots de passe) stockes dans rndc.conf et named.conf, il faut vous assurer que les chiers ne sont lisibles que par des utilisateurs autoriss grer le serveur de noms.

Si rndc-confgen est fourni avec votre exemplaire de BIND, vous pouvez utiliser cet outil pour effectuer lessentiel du travail de conguration :
# rndc-confgen > /etc/rndc.conf

Le chier /etc/rndc.conf automatiquement gnr contiendra :


# Dbut de rndc.conf key "rndc-key" { algorithm hmac-md5; secret "4XErjUEy/qgnDuBvHohPtQ=="; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Piloter le serveur de noms


}; # Fin de rndc.conf # # # # # # # # # # # # # Les directives suivantes sont placer dans le fichier named.conf, aprs aujustement de la liste allow : key "rndc-key" { algorithm hmac-md5; secret "4XErjUEy/qgnDuBvHohPtQ=="; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; Fin de named.conf

125

Comme lindique le commentaire, la seconde partie de ce chier contient les instructions placer dans /etc/named.conf ; il suft de dplacer les lignes vers /etc/named.conf et de supprimer le caractre de commentaire en dbut de ligne. Comme indiqu prcdemment, on peut placer la cl lextrieur du chier /etc/named.conf pour des raisons de scurit. Remarquons aussi que la directive controls nautorise laccs qu partir de ladresse 127.0.0.1.Cette liste peut tre ajuste.

Utiliser rndc pour grer plusieurs serveurs


Si rndc ne sert piloter quun seul serveur, sa conguration est simple. On dnit une cl dauthentication avec la mme directive key dans named.conf et rndc.conf. On dnit ensuite le serveur piloter laide de la sous-structure default-server de la structure options de rndc.conf, ainsi que la cl utiliser par dfaut laide de la sous-structure default-key. Lutilisation de rndc est alors trs simple :
# rndc reload

Si on a plusieurs serveurs piloter, on peut utiliser une cl diffrente par serveur. On dnit les cls laide de plusieurs directives key, puis on associe chaque cl un serveur laide de la directive server :
server localhost { key "rndc-key"; }; server wormhole.movie.edu { key "wormhole-key"; };

rndc doit alors tre excut avec loption s pour prciser le serveur piloter :
# rndc -s wormhole.movie.edu reload

Si on na pas associ de cl chaque serveur, on peut indiquer une cl spcique en ligne de commande laide de loption y :
# rndc -s wormhole.movie.edu -y rndc-wormhole reload

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

126

Chapitre 7 Exploitation de BIND

Enn, si un serveur coute un port non-standard (autre que 953), on doit utiliser loption p pour indiquer rndc le port auquel se connecter :
# rndc -s toystory.movie.edu -p 54 reload

Nouvelles commandes de rndc


Avec BIND 9.0.0, rndc ne comprend que la commande reload. BIND 9.3.2 prend en charge la plupart des commandes de ndc, ainsi que quelques nouvelles commandes. Voici leur description : reload Identique la commande reload de ndc. refresh zone Programmation dune maintenance immdiate pour la zone indique (ce qui comprend la recherche du SOA auprs du matre de la zone). retransfer zone Transfert immdiat de la zone indique, sans test du numro de srie. freeze zone Suspension des mises jour dynamiques de la zone indique. Voir le Chapitre 10 pour les dtails. thaw zone Reprise des mises jour dynamiques de la zone indique. Voir le Chapitre 10 pour les dtails. reconfig Identique la commande recong de ndc. stats Identique la commande stats de ndc. querylog Identique la commande querylog de ndc. dumpdb Identique la commande dumpdb de ndc. On peut prciser sil faut uniquement sauvegarder la mmoire cache laide de loption cache, les zones sur lesquelles le serveur fait autorit laide de loption zones, ou les deux, laide de loption all. stop Identique la commande stop de ndc. halt Identique stop, mais sans sauvegarde des mises jour dynamiques en cours. trace Identique la commande trace de ndc.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Piloter le serveur de noms


notrace Identique la commande notrace de ndc. flush Purge du cache du serveur de noms.

127

flushname nom Purge de tous les enregistrements associs au nom indiqu, dans la mmoire cache du serveur de noms. status Identique la commande status de ndc. recursing Sauvegarde des information concernant les recherches rcursives en cours, vers le chier named.recursing dans le rpertoire de travail du serveur de noms.

Utiliser des signaux


Avant lapparition de ndc, donc avant BIND 8.2, tout ce dont nous disposions pour piloter les serveurs de noms taient les signaux. Nous indiquons dans le tableau cidessous la correspondance entre les commandes de ndc et les signaux. Si vous utilisez la version script shell de ndc (de BIND 4.9 8.1.2), il est inutile de sintresser au nom des signaux, car ndc se contente de traduire une commande en son signal quivalent. Avec BIND 9, il est indispensable dutiliser rndc pour toutes les tches (sauf pour le rechargement et larrt du serveur pour lesquels il existe encore des signaux) car le mcanisme des signaux nest pas mis en uvre.
Signal HUP INT ILL USR1 USR2 WINCH TERM Signaux de BIND 8 rechargement du serveur sauvegarde de la base de donnes sauvegarde des statistiques incrmentation du niveau de dbogage mise hors-service du dbogage mise en/hors-service de la journalisation des requtes arrt du serveur quivalent ndc ndc reload ndc dumpdb ndc stats ndc trace ndc notrace ndc querylog ndc stop Signaux de BIND 9 quivalent rndc

rechargement du rndc reload serveur arrt du serveur non utilis non utilis non utilis non utilis arrt du serveur rndc dumpdb rndc stats rndc trace rndc notrace rndc querylog rndc stop

Ainsi, pour valider ou invalider le mcanisme de journalisation avec une ancienne version de ndc, on pourrait utiliser :
# ndc querylog

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

128

Chapitre 7 Exploitation de BIND

de la mme manire quon le ferait avec une version rcente de ndc. Lancienne version de ndc rcupre le PID de named et lui envoie le signal WINCH. Si on ne dispose pas de ndc, il faut effectuer manuellement les oprations : trouver le PID du processus named et lui envoyer le signal appropri. Le PID de BIND est enregistr dans un chier, appel chier pid, qui est habituellement /var/run/named.pid ou, pour certains systmes, /etc/named.pid (voir la documentation de named). Comme le PID du serveur est la seule information enregistre dans le chier pid, il suft dexcuter la commande suivante pour envoyer le signal HUP :
# kill -HUP `cat /var/run/named.pid`

Si le chier pid est introuvable, il faut utiliser ps. Par exemple avec Unix BSD :
% ps -ax | grep named

ou avec Unix System V :


% ps -ef | grep named

Attention, on peut trouver plus dun processus named lors de lutilisation de ps. Cela peut provenir de la construction multithreaded de named dans Linux, qui est alors vu comme plusieurs processus. Si ps rvle plusieurs serveurs de noms, la commande pstree permet de rechercher le processus-parent. Bien que cela puisse paratre une vidence, nous prcisons que lon ne peut envoyer un signal quau processus-parent.

Mettre jour les chiers de zone


Les rseaux sont en constante volution : arrive dune nouvelle machine, suppression dune ancienne machine, dplacement dune machine dun rseau lautre. chaque fois, les chiers de zone doivent tre modis. On peut soit effectuer manuellement les modications, soit utiliser un outil spcialis. Nous recommandons lutilisation dun outil pour crer les chiers de zone, ne serait-ce que pour incrmenter automatiquement le numro de srie, mais aussi car la syntaxe des chiers est elle-mme une source derreur. Ainsi, la sparation des enregistrements dadresse et des enregistrements inverses dans des chiers distincts complique le travail. Comme il est toujours difcile de savoir ce qui se passe en dtail avec un outil, nous indiquons dabord comment effectuer manuellement les modications, puis prsentons ensuite loutil h2n.

Ajouter et supprimer des htes


La liste qui suit rappelle les oprations dajout ou de suppression dhtes. Elles doivent tre effectues sur le serveur primaire. Si on les applique sur un serveur esclave, elles seront prises en compte par ce dernier, mais seront perdues au transfert de zone suivant.

Mise jour du numro de srie dans db.DOMAINE. Ce numro est en gnral plac
vers le dbut du chier, pour faciliter son reprage.

Ajout des enregistrements A (adresse), CNAME (alias) et MX (changeur de


messages) adquats au chier db.DOMAINE. Par exemple, les enregistrements suivants sont ajouts au cher db.movie.edu lors du rattachement du nouvel hte cujo, au rseau :
cujo IN A 192.253.253.5 ; adresse IP de cujo

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Mettre jour les fichiers de zone


IN MX 10 cujo IN MX 20 toystory ; si possible, email direct vers cujo ; sinon, livraison vers notre changeur

129

Mise jour du numro de srie et ajout de lenregistrement PTR chaque chier


db.ADR pour lequel lhte a une adresse. Comme cujo nen a quune, sur le rseau 192.253.253/24, il faut ajouter lenregistrement PTR suivant au chier db.192.253.253 :
5 IN PTR cujo.movie.edu.

Rechargement du serveur primaire avec les nouvelles donnes :


# rndc reload

Si le serveur de noms est en BIND 9.1 ou postrieur, on peut ne recharger que les
zones modies :
# rndc reload movie.edu

Le serveur primaire charge les nouvelles donnes de zone. Les serveurs-esclaves les tlchargeront en fonction de lintervalle de rafrachissement dni dans lenregistrement SOA. Avec un serveur-matre et des esclaves en BIND 8 ou 9, lesclave se synchronise rapidement car le serveur primaire annonce aux esclaves quil y a eu des modications, dans les 15 minutes suivant la mise jour. Pour supprimer un hte, il suft denlever ses enregistrement de ressource du chier db.DOMAINE et de chaque chier db.ADR. Il faut ensuite incrmenter le numro de srie dans chaque chier de zone modi, puis recharger le serveur de noms primaire.

Numro de srie des SOA


Chaque chier de zone a un numro de srie, qui doit tre incrment chaque modication de chier. Si le numro de srie nest pas incrment, les serveurs-esclaves de la zone ne tlchargeront jamais les nouvelles donnes. Lincrmentation du numro de srie est simple. Si le chier de zone contient lenregistrement SOA suivant :
movie.edu. IN SOA toystory.movie.edu. al.movie.edu. ( 100 ; numro de srie 3h ; rafrachissement 1h ; nouvel essai 1w ; expiration 1h ) ; TTL rponse ngative d1 heure

le chier de zone mis jour contiendra :


movie.edu. IN SOA toystory.movie.edu. al.movie.edu. ( 101 ; numro de srie 3h ; rafrachissement 1h ; nouvel essai 1w ; expiration 1h ) ; TTL rponse ngative d1 heure

Cette petite modication est la cl de la synchronisation des serveurs-esclaves. Loubli dincrmentation du numro de srie est lerreur la plus courante lors de la mise jour dune zone. Si on ne loublie gnralement pas au dbut, il arrive quon lomette par la suite et les serveurs-esclaves ne chargent pas les nouvelles donnes. On a donc tout intrt utiliser un outil standard, comme h2n, voire un outil maison.
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

130

Chapitre 7 Exploitation de BIND

Il existe plusieurs manires dutiliser des nombres entiers. La meilleure consiste incrmenter un compteur entier chaque modication de chier. Une autre mthode consiste driver le numro de srie partir de la date pour obtenir un numro de la forme AAAAMMJJ. Par exemple, le 15 janvier 2005, le numro de srie sera 20050115. Cette forme ne permet quune modication par jour, ce qui peut tre insufsant. Avec deux chiffres supplmentaires en queue du numro, on peut distinguer jusqu 100 modications par jour. Avec lexemple prcdent, la premire modication du jour a le numro de srie 2005011500, la suivante 2005011501, etc. Cette forme prsente la date de dernire incrmentation du numro de srie. h2n, utilis avec loption -y, gnre un numro de srie bas sur la date. Dans tous les cas, le numro de srie doit tenir dans un entier cod sur 32 bits.

Redmarrer avec un nouveau numro de srie


Si un numro de srie devient accidentellement trop grand dans une ou plusieurs zones, une solution de dpannage fonctionne avec toutes les versions de BIND, une autre partir de BIND 4.8.1 et une dernire partir de BIND 4.9. La mthode gnrale consiste purger de lancien numro de srie tous les esclaves et redmarrer avec un nouveau numro. Tout dabord, on modie le numro de srie sur le serveur primaire que lon redmarre. On se connecte ensuite sur chaque esclave et on stoppe le processus named avec la commande rndc stop. On supprime les copies des chiers de zone (par exemple avec rm bak.movie.edu bak.192.249.249 bak.192.253.253). On redmarre lesclave. Puisque les copies de sauvegarde ont disparu, lesclave doit tlcharger une nouvelle version des chiers de zone et donc un nouveau numro de srie. Ce processus doit tre rpt pour chaque esclave. Si un esclave est gr par un autre administrateur, il faut contacter ce dernier pour quil effectue lopration. Si tous les esclaves sont postrieurs BIND 4.8.1 (et nous prions pour que vous nutilisiez pas 4.8.1), mais antrieurs BIND 8.2, on peut tirer avantage du numro de srie 0. En initialisant le numro de srie 0, chaque esclave transfre la zone lors de son prochain test de version de base de donnes, car il le force transfrer la zone chaque fois quil vrie sa cohrence avec le matre. Il ne faut donc pas oublier dincrmenter le numro de srie lorsque tous les esclaves se sont synchroniss sur un numro de srie gal 0. Mais attention, il y a une contrainte sur cette incrmentation. Lautre mthode pour rednir le numro de srie pour les serveurs de version 4.9 ou postrieure est plus comprhensible si on explique pralablement le fonctionnement interne. Le numro de srie est cod sur un entier non sign de 32 bits. Sa valeur varie donc de 0 4294967295. Les numros de srie du DNS utilisent une arithmtique particulire dans laquelle la moiti des nombres (cest--dire 2147483647) sont plus petits que le numro de srie considr, et lautre moiti des nombres sont plus grands que le numro de srie considr, et ce pour tout nombre. Considrons lexemple suivant, en prenant un numro de srie gal 5. Les nombres de 6 (5 + 2147483647) sont suprieurs au numro de srie, et les nombres de (5 + 2147483649) 4 lui sont infrieurs. En effet, le numro de srie boucle sur lui-mme et revient vers 4 aprs avoir atteint 4294967295. Le nombre (5 + 2147483648) est exclu car il est mi-chemin et pourrait tre aussi bien infrieur 5 que suprieur, selon les mises en uvre. Il vaut donc mieux ne pas lutiliser.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Mettre jour les fichiers de zone

131

Ainsi, si le numro de srie est gal 25000 et que lon veut redmarrer 1, il faut modier les numros en deux tapes. Il faut tout dabord ajouter la plus grande valeur possible au numro de srie (25000 + 2147483647 = 2147508647). Si le nombre obtenu est suprieur 4294967295 (la plus grande valeur dun nombre sur 32 bits), il a en fait boucl vers le dbut de lespace des nombres, par soustraction de 4294967296. Aprs cette modication, il faut attendre que tous les esclaves aient tlcharg une nouvelle copie de la zone. Ensuite, il faut nouveau modier le numro de srie, pour lui donner sa valeur dnitive (1), qui est maintenant suprieure au numro de srie actuel (2147508647). Lorsque tous les esclaves seront synchroniss, lopration de modication du numro de srie sera acheve.

Nouveaux types denregistrement de ressource


Par la suite, vous aurez peut-tre envie dajouter des enregistrements de ressource pour faciliter la gestion de zone : localisation des htes, type dhtes, etc. Les administrateurs ont de plus en plus de machines grer et les serveurs de noms peuvent permettre de garder leur trace. Ces informations peuvent aussi permettre des utilisateurs distants de contacter plus facilement les administrateurs dun domaine. Nous avons dj dcrit les enregistrements SOA, NS, A, CNAME, PTR et MX. Ces enregistrements sont essentiels au bon fonctionnement des serveurs de noms et ils servent quotidiennement aux applications. Toutefois, le DNS dnit dautres types denregistrement. TXT et RP sont les plus utiles et permettent dindiquer lemplacement dun hte et lidentit de la personne responsable dun hte. Une liste des enregistrements de ressource plus ou moins courants apparat lAnnexe A.

Information textuelle
TXT signie TeXT (texte). Un enregistrement de ce type est simplement constitu dune liste de chanes caractres dau plus 255 caractres chacune. Le contenu dun enregistrement TXT est libre ; il peut servir noter lemplacement dun hte :
cujo IN TXT "Emplacement : niche de la salle des machines"

Lenregistrement TXT de BIND est limit 2 kilo-octets, mais il peut tre constitu de plusieurs chanes :
cujo IN TXT "Emplacement :" "niche de la salle des machines"

Personne responsable
RP signie personne responsable (Responsible Person). Un enregistrement RP peut tre attach tout nom, que ce soit un nud intermdiaire ou une feuille. Il dsigne le responsable dun hte ou dune zone. Il peut servir localiser aussi bien le responsable de lhte qui envoie des requtes, que celui de lhte recherch. Cet enregistrement requiert deux arguments : une adresse lectronique et un nom qui dsigne des donnes complmentaires concernant le contact. Ladresse lectronique est dans le mme format que celui utilis dans lenregistrement SOA : le @ est remplac par un . . Le nom dsigne un enregistrement TXT qui peut contenir, par exemple, les rfrences du responsable. Si le deuxime argument de lenregistrement RP est inutile, il faut indiquer le domaine racine ( . ).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

132

Chapitre 7 Exploitation de BIND

Voici des exemples denregistrements RP et denregistrements TXT associs :


shrek hotline sn IN IN IN IN RP RP TXT TXT root.movie.edu. hotline.movie.edu. snewman.movie.edu. sn.movie.edu. "Support rseau de lUniversit du Cinma, (415) 555-4111" "Sommer Newman, (415) 555-9612"

Des enregistrements TXT pour root.movie.edu et snewman.movie.edu sont inutiles, car ce ne sont pas des noms rels, mais une forme dadresse lectronique.

Crer des chiers de zone partir des tables dhtes


Comme prsent au Chapitre 4, notre outil Perl h2n automatise le processus de cration des donnes. Il permet dviter les erreurs de syntaxe et les incohrences dans les chiers, supposer que nous ayons programm h2n correctement. Une incohrence courante consiste crer un enregistrement A (adresse) sans enregistrement PTR (pointeur) associ, et rciproquement. Cette erreur est aise commettre en raison de la sparation des enregistrements en deux chiers distincts. partir du chier /etc/hosts et de quelques options en ligne de commande, h2n cre les chiers de zone. Ladministrateur doit juste tenir jour sa table dhtes ; h2n reconstruit chaque utilisation les chiers de zone partir de zro en incrmentant le numro de srie. Il peut tre excut manuellement ou priodiquement avec cron. Lutilisation de h2n garantit lvolution du numro de srie. h2n a dabord besoin de connatre le nom de la zone (pour la rsolution directe) et les adresses de rseau (pour en dduire les noms de zones pour la rsolution inverse), an de crer les chiers de zone adquats : les donnes de la zone movie.edu vont dans le chier db.movie et les donnes du rseau 192.249.249/24 vont dans le chier db.192.249.249. Le nom du domaine et ladresse de rseau sont respectivement indiqus laide des options -d et -n : d domaine Nom du domaine pour la rsolution directe. n adresse de rseau Adresse du rseau. Pour plusieurs rseaux dans le mme domaine, utiliser plusieurs fois loption -n. Omettre les zros en queue du numro ainsi que les indications de masque de sous-rseau. h2n requiert loption -d et au moins une option -n ; il ny a pas de valeur par dfaut. Par exemple, voici la commande h2n pour crer les chiers de la zone movie.edu, qui contient deux rseaux :
% h2n -d movie.edu -n 192.249.249 -n 192.253.253

h2n accepte dautres options : s serveur Les serveurs de noms signals par les enregistrements NS. Comme avec loption -n, utiliser plusieurs options -s pour plusieurs serveurs primaires ou esclaves. Un serveur en version 8 ou 9 annoncera (NOTIFY) une modication des donnes cette liste de serveurs. La valeur par dfaut est lhte sur lequel h2n est utilis.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Mettre jour les fichiers de zone

133

h hte Lhte pour le champ MNAME de lenregistrement SOA. Cet hte doit tre le serveur primaire an de garantir un fonctionnement correct de la fonction NOTIFY. La valeur par dfaut est lhte sur lequel h2n est utilis. u administrateur Ladresse lectronique de ladministrateur des donnes de la zone. La valeur par dfaut est lutilisateur root de lhte sur lequel h2n est utilis. o autres Autres valeurs du SOA, numro de srie exclu, spares par : . La valeur par dfaut est 10800:3600:604800:86400. f fichier Fichier de conguration de h2n, pratique lorsque les options sont nombreuses. v 4|8 Gnration des chiers pour une version 4 ou une version 8 (valeur par dfaut). Le format du chier de conguration de BIND 9 tant fondamentalement le mme que celui de BIND 8, on peut utiliser -v 8 pour un serveur BIND 9. y Gnration du numro de version partir de la date. Voici un exemple utilisant toutes les options dcrites ci-dessus :
% h2n -f opts

Contenu du chier opts :


-d -n -n -s -s -u -h -o -v -y movie.edu 192.249.249 192.253.253 toystory.movie.edu wormhole al toystory 10800:3600:604800:86400 8

Un hte peut tre dsign par son nom totalement quali (par exemple toystory.movie.edu) ou juste par son nom dhte (par exemple toystory). Dans ce dernier cas, h2n construit un nom totalement quali en y ajoutant le nom du domaine indiqu dans loption -d (si un point terminal est ncessaire, h2n lajoute). La liste complte des options de h2n est disponible dans sa documentation. Certains types denregistrement ne sont pas aiss gnrer partir du chier /etc/hosts. Ces enregistrements peuvent tre ajouts manuellement aux chiers de la zone, mais h2n les perd lors de la gnration suivante de la base de donnes. Pour rsoudre ce problme, h2n propose une solution. Les enregistrements complmentaires peuvent tre placs dans un chier spcl.DOMAINE, o DOMAINE est le

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

134

Chapitre 7 Exploitation de BIND

premier membre du nom de la zone. Lorsque h2n trouve ce chier, il linclut dans la base de donnes en ajoutant la ligne :
$INCLUDE spcl.DOMAINE

la n du chier db.DOMAINE (la directive $INCLUDE est dcrite plus loin dans ce chapitre). Par exemple, ladministrateur de movie.edu peut ajouter des enregistrements MX dans le chier spcl.movie an que les utilisateurs puissent crire directement movie.edu. Lorsquil trouve le chier, h2n ajoute la ligne :
$INCLUDE spcl.movie

la n du chier db.movie.

Maintenance des renseignements sur la racine


Comme cela a t dit au Chapitre 4, le chier des indications sur les serveurs de la zone racine indique un serveur de noms o se trouvent ces serveurs. Ce chier doit tre priodiquement mis jour ; les serveurs de la racine ne changent pas souvent, mais cela peut arriver. Il est bon de tester la cohrence du chier mensuellement ou bimestriellement. Le Chapitre 4 proposait de tlcharger la liste des serveurs par FTP partir de ftp.rs.internic.net, et cest probablement la meilleure solution. Lutilitaire dig, une commande incluse dans la distribution de BIND (voir sa description au Chapitre 12), permet de tlcharger facilement de la liste des serveurs de la racine :
% dig @a.root-servers.net . ns > db.cache

Organiser les chiers


Dans le premier exemple de cration de zone, lorganisation tait simple : il y avait un ensemble de chiers placs dans un unique rpertoire et un chier de conguration. Si des rseaux sont ajouts (et donc des zones in-addr.arpa), si un sous-domaine est cr ou si le serveur devient serveur secondaire de zones concernant dautres sites, il peut tre intressant de modier la structuration. cette n, BIND dispose de plusieurs fonctionnalits. Le chier de conguration de BIND peut contenir une directive de contrle, include, qui permet dinclure un chier de conguration dans un autre, permettant ainsi de scinder un grand chier de conguration en plusieurs petits chiers. Les chiers de zone de toutes les versions de BIND peuvent contenir deux directives de contrle2, $ORIGIN et $INCLUDE. $ORIGIN modie lorigine dun chier de zone et $INCLUDE insre un nouveau chier dans le chier courant. Ces directives de contrle ne sont pas des enregistrements de ressource ; elles sont l pour faciliter le travail sur les chiers de la base de donnes, notamment lors de la division dun domaine en sousdomaines, en permettant denregistrer les donnes de chaque sous-domaine dans des chiers spars.

2.

Trois, si on compte $TTL, apparue avec BIND 8.2.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Organiser les fichiers

135

Utiliser plusieurs rpertoires


On peut aussi organiser les chiers de zone dans des rpertoires spars. Si un serveur est primaire pour plusieurs zones, chaque groupe de chiers de zone peut avoir son propre rpertoire. Une autre organisation possible consiste placer tous les chiers correspondant une fonction de serveur primaire dans un rpertoire et tous ceux correspondant une fonction desclave dans un autre. Voici lexemple dun chier de conguration dans le cas dun serveur assurant des fonctions de matre et desclave :
options { directory "/var/named"; }; // // Fichiers non spcifiques une zone // zone "." { type hint; file "db.cache"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; }; // // Fichiers de la fonction serveur primaire // zone "movie.edu" { type master; file "primary/db.movie.edu"; }; zone "249.249.192.in-addr.arpa" { type master; file "primary/db.192.249.249"; }; zone "253.253.192.in-addr.arpa" { type master; file "primary/db.192.253.253"; }; // // Fichiers de la fonction serveur-esclave // zone "ora.com" { type slave; file "slave/bak.ora.com"; masters { 198.112.208.25; }; }; zone "208.112.192.in-addr.arpa" { type slave; file "slave/bak.198.112.208"; masters { 198.112.208.25; }; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

136

Chapitre 7 Exploitation de BIND

Une variante de cette organisation consiste diviser en trois le chier de conguration : un chier principal, un chier contenant les dclarations pour la fonction de serveur primaire et un chier contenant les dclarations pour la fonction desclave. Voici un exemple :
options { directory "/var/named"; }; // // Fichiers non spcifiques une zone // zone "." { type hint; file "db.cache"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; }; include "named.conf.primary"; include "named.conf.slave";

Voici le chier named.conf.primary :


// // Fichiers de la fonction serveur primaire // zone "movie.edu" { type master; file "primary/db.movie.edu"; }; zone "249.249.192.in-addr.arpa" { type master; file "primary/db.192.249.249"; }; zone "253.253.192.in-addr.arpa" { type master; file "primary/db.192.253.253"; };

Voici le chier named.conf.slave :


// // Fichiers de la fonction serveur-esclave // zone "ora.com" { type slave; file "slave/bak.ora.com"; masters { 198.112.208.25; }; }; zone "208.112.192.in-addr.arpa" { type slave; file "slave/bak.198.112.208"; masters { 198.112.208.25; }; };
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Organiser les fichiers

137

On pourrait penser quil serait prfrable de placer le chier de conguration contenant les directives master dans le sous-rpertoire primary, dni dans le chier de conguration principal, en ajoutant une nouvelle directive directory pour dsigner ce sous-rpertoire et en supprimant le chemin primary/ pour chaque nom de chier, puisque ce sousrpertoire est dsormais le rpertoire de travail du serveur. On pourrait procder de la mme manire pour les lignes contenant slave. Mais cela ne fonctionnerait pas. Les serveurs BIND ne permettent pas de dnir plus dun rpertoire de travail. Le changement de contexte entre les rpertoires perturberait le serveur : les chiers de sauvegarde de la fonction de serveur-esclave aboutiraient dans le dernier rpertoire activ par le serveur, par exemple.

Modier lorigine dans un chier de zone


Avec BIND, lorigine par dfaut des chiers de zone est le second champ de la directive zone du chier named.conf. Lorigine est un nom de domaine ajout automatiquement tous les noms ne se terminant pas par un point. Elle peut tre modie dans un chier de zone laide de la directive $ORIGIN suivie dun nom de zone (ne pas oublier le point terminal dans le cas dun nom complet). Tous les noms ne se terminant pas par un point sont complts par la nouvelle origine. Si une zone (par exemple movie.edu) contient plusieurs sous-domaines, la directive $ORIGIN permet de simplier lcriture des chiers. Exemple :
$ORIGIN classics.movie.edu. maltese IN A 192.253.253.100 casablanca IN A 192.253.253.101 $ORIGIN comedy.movie.edu. mash IN A 192.253.253.200 twins IN A 192.253.253.201

La cration de sous-domaines est dcrite au Chapitre 9.

Incorporer des chiers de zone


Une fois quune zone est divise comme ci-dessus, il peut tre pratique de placer les enregistrements concernant chaque sous-domaine dans des chiers spars. La directive $INCLUDE facilite cette opration :
$ORIGIN classics.movie.edu. $INCLUDE db.classics.movie.edu $ORIGIN comedy.movie.edu. $INCLUDE db.comedy.movie.edu

Le chier inclure et la nouvelle origine peuvent tre placs sur une seule ligne :
$INCLUDE db.classics.movie.edu classics.movie.edu. $INCLUDE db.comedy.movie.edu comedy.movie.edu.

Lorsque lorigine et le chier inclure sont dclars sur une seule ligne, la nouvelle origine ne concerne que le chier indiqu dans cette directive. Par exemple, lorigine comedy.movie.edu ne concerne que les noms du chier db.comedy.movie.edu. Aprs linclusion du chier db.comedy.movie.edu, lorigine a la mme valeur quavant la direc-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

138

Chapitre 7 Exploitation de BIND

tive $INCLUDE, mme si une directive $ORIGIN a t utilise lintrieur du chier db.comedy.movie.edu.

Emplacement des chiers


BIND permet de modier le nom et lemplacement des chiers associs : named.pid, named-xfer, named_dump.db et named.stats. La plupart dentre vous nauront pas besoin dutiliser cette fonctionnalit ; ce nest pas parce que cela est possible quil faut le faire. Si lemplacement des chiers gnrs par le serveur (named.pid, named_dump.db ou named.stats) est modi pour des raisons de scurit, leur rpertoire ne doit pas tre mis en criture publique. Mme si aucune faille de scurit lie lcriture dans ces chiers nest recense, il est conseill de suivre les recommandations qui suivent. Le chemin vers named.pid est habituellement /var/run ou /etc. Si plusieurs serveurs de noms sont activs sur une machine unique, lemplacement peut tre modi. Le Chapitre 10 donne un exemple dexcution de deux serveurs sur un mme hte (et expose la logique menant ce choix). Un chier named.pid peut tre dni pour chaque serveur dans le chier de conguration :
options { pid-file "server1.pid"; };

Le chemin vers named-xfer est habituellement /usr/sbin ou /etc. named-xfer est habituellement utilis par un esclave pour le transfert de zone. La construction et le test dune nouvelle version de BIND dans un rpertoire spcial peuvent amener rednir lemplacement de named-xfer ; la version de test de named peut tre congure pour utiliser la version locale de named-xfer :
options { named-xfer "/home/rudy/named/named-xfer"; };

Puisque BIND 9 nutilise pas named-xfer, la directive ci-dessus na pas lieu dtre invoque avec BIND 9. Le serveur cre named_dump.db dans son rpertoire de travail lorsquon lui demande de gnrer une copie de sa base de donnes. Voici un exemple de modication de son emplacement :
options { dump-file "/home/rudy/named/named_dump.db"; };

Le serveur cre named.stats dans son rpertoire de travail lorsquon lui demande de gnrer ses statistiques. Voici un exemple de modication de son emplacement :
options { statistics-file "/home/rudy/named/named.stats"; };

Messages gnrs par BIND


BIND dispose dun vaste systme de journalisation qui crit des messages dans un chier et en envoie galement syslog. Ce systme est gourmand en ressources ; il est donc ncessaire den connatre les principes avant de lutiliser. Si vous navez pas le temps dexprimenter les paramtres, commencez avec les valeurs par dfaut, vous aurez toujours le temps dy revenir, si cela savre ncessaire. La gnration des messages est base sur deux lments : les canaux et les catgories. Un canal indique o doivent tre envoys les messages : syslog, dans un chier, vers la sortie standard derreur de named ou nulle part. Une catgorie dnit les donnes

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Messages gnrs par BIND

139

surveiller. Dans le code-source de BIND, la plupart des messages sont classs selon la fonction remplie par le code auxquels ils se rfrent. Ainsi, un message produit par la partie de code qui gre les mises jour dynamiques est probablement dans la catgorie update. Les catgories sont prsentes plus loin. Chaque catgorie de message peut tre envoye vers un canal unique ou vers un ensemble de canaux. la gure 7-1, les requtes sont enregistres dans un chier, alors que les statistiques sont enregistres dans ce chier et envoyes syslog.
transfert de zone canal syslog

catgorie "requte"

canal fichier

Figure 7-1. Association de catgories des canaux


Les canaux permettent de ltrer les messages en fonction de leur gravit (severity). Voici une liste des niveaux de gravit, de la plus svre la moindre :
critical error warning notice info debug [level] dynamic

Les cinq premiers niveaux de gravit (critical, error, warning, notice et info) correspondent ceux utiliss par syslog. Les deux suivants (debug et dynamic) sont spciques BIND. debug permet de prciser le niveau de dbogage de BIND ; la valeur standard est 1 . Si un niveau de dbogage diffrent est choisi, des informations de ce niveau sont gnres ds la mise en service du dbogage. Ainsi, en indiquant debug 3 , des informations de niveau 3 sont directement gnres, mme si on nenvoie quune seule commande trace au serveur de noms. Par contre, avec le niveau de gravit dynamic, le serveur de noms gnre des messages selon le niveau de dbogage courant : si on envoie une seule commande trace au serveur de noms, le serveur enregistre les informations de niveau 1 ; si on en envoie trois, le serveur gnre des informations de niveau 1 3. Le niveau de gravit par dfaut est info, ce qui signie quon ne verra pas de messages de dbogage tant quon naura pas prcis la gravit.
On peut congurer un canal pour enregistrer dans un chier aussi bien les messages de dbogage que les messages de syslog. Par contre, lenvoi de lensemble syslog est impossible, les messages de dbogage ne pouvant pas lui tre envoys.

Lexemple suivant illustre la conguration de deux canaux. Le premier canal est dirig vers syslog ; les messages sont envoys vers le service daemon au niveau de gravit info, ce qui inclut implicitement les niveaux de gravit infrieurs. Le second est dirig vers un

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

140

Chapitre 7 Exploitation de BIND

chier qui rcupre les messages de tout niveau de gravit, ainsi que les messages envoys syslog. Voici la structure logging correspondante :
logging { channel mon_syslog { syslog daemon; // Les messages de dbogage ne sont pas envoys syslog ; il ny // a donc aucun intrt utiliser les niveaux de gravit debug // ou dynamic. Utilisation du plus bas niveau de syslog : info. severity info; }; channel mon_fichier { file "/tmp/log.msgs"; // Rglage du niveau de gravit dynamic, afin // de voir tous les messages de dbogage. severity dynamic; }; };

Il faut maintenant indiquer au serveur de noms ce quil doit envoyer aux deux canaux. Mettons en uvre le cas de la gure 7-1, dans lequel les statistiques sont envoyes syslog et crites dans un chier et o les requtes sont enregistres dans ce mme chier. Cette conguration se fait aussi dans la structure logging. Il suft de complter la structure prcdente :
logging { channel mon_syslog { syslog daemon; severity info; }; channel mon_fichier { file "/tmp/log.msgs"; severity dynamic; }; category xfer-out { mon_syslog; mon_fichier; }; category queries { mon_fichier; }; };

Il faut ensuite dmarrer le serveur de noms et lui envoyer quelques requtes. Si rien nest crit dans le chier log.msgs, il faut valider le dbogage pour mmoriser les requtes :
# rndc trace

Les requtes sont alors enregistres dans le chier log.msgs. On constate aussi quun nouveau chier, named.run, a t cr dans le rpertoire de travail du serveur. Il contient tous les autres messages de dbogage (autres que les requtes). Si on souhaite viter cela, on peut utiliser la catgorie default. Si aucun canal nest associ une catgorie donne, les messages de cette dernire sont attachs au canal de la catgorie default, que lon peut ignorer en les redirigeant vers le canal null :
logging {

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Messages gnrs par BIND


channel mon_syslog { syslog daemon; severity info; }; channel mon_fichier { file "/tmp/log.msgs"; severity dynamic; }; category default { null; }; category xfer-out { mon_syslog; mon_fichier; }; category queries { mon_fichier; }; };

141

En dmarrant le serveur et en validant le dbogage au niveau 1 (si ncessaire), les requtes sont enregistres dans log.msgs ; named.run a aussi t cr, mais le chier est vide. Au bout de quelques jours, lun des administrateurs constate que le serveur envoie beaucoup moins dinformations syslog que ce quil devrait. Que se passe-t-il ? En effet, en standard, la catgorie default est congure pour envoyer les messages la fois vers syslog et vers le chier de dbogage named.run. En redirigeant la catgorie default vers le canal null, les autres messages de syslog disparaissent aussi. Voici la conguration qui aurait d tre utilise :
category default { mon_syslog; };

Les messages de syslog sont bien envoys syslog, mais les informations de dbogage ou de syslog ne sont pas crites dans un chier. Il sera sans doute ncessaire dessayer plusieurs congurations avant dobtenir exactement ce que lon souhaite. Lexemple ci-dessus donne quelques indications sur ce quil est possible de faire.

La directive logging
Voici la syntaxe complte de la directive logging. Elle est impressionnante et nous prsenterons plusieurs exemples de son utilisation.
logging { [ channel nom_canal{ ( file chemin [ versions ( nombre | unlimited ) ] [ size taille ] | syslog ( kern | user | mail | daemon | auth | syslog | lpr | news | uucp | cron | authpriv | ftp | local0 | local1 | local2 | local3 | local4 | local5 | local6 | local7 ) | stderr | null ); [ severity ( critical | error | warning | notice | info | debug [ level ] | dynamic ); ]

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

142
[ print-category yes_or_no; ] [ print-severity yes_or_no; ] [ print-time yes_or_no; ] }; ] [ category catgorie { nom_canal; [ nom_canal; ... ] }; ] ... };

Chapitre 7 Exploitation de BIND

Voici maintenant les canaux crs en standard. Le serveur de noms les cre dofce, mme si on nen veut pas. Ces canaux ne sont pas modiables ; on ne peut que crer dautres canaux :
channel default_syslog { syslog daemon; // Envoi au service daemon de syslog. severity info; // Envoi des messages de gravit info ou plus. }; channel default_debug { file "named.run"; severity dynamic; }; channel default_stderr { // stderr; // // // severity info; // }; channel null { null; }; criture dans stderr. Seul BIND 9 permet de dfinir son propre canal stderr ; BIND 8 utilise le canal interne default_stderr. Envoi des messages de gravit info ou plus.

// // // //

criture dans named.run situ dans le rpertoire de travail. Envoi des messages selon le niveau actuel de dbogage du serveur.

// Rejet de tout ce qui est envoy ce canal.

Si aucun canal nest associ aux catgories default, panic, packet et eventlib, un serveur de noms leur attribue dofce les canaux suivants en BIND 8 :
logging { category category category category }; default { default_syslog; default_debug; }; panic { default_syslog; default_stderr; }; packet { default_debug; }; eventlib { default_debug; };

ou, en BIND 9 :
logging { category default { default_syslog;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Messages gnrs par BIND


default_debug; }; };

143

Comme cela a t indiqu prcdemment, la catgorie default aboutit la fois dans syslog et dans le chier de dbogage, named.run, en standard : tous les messages de type syslog de gravit info et suprieure sont envoys syslog et, lorsque le dbogage est activ, ils sont enregistrs dans named.run en plus des messages de dbogage.

Prcisions sur les canaux


Un canal peut tre associ un chier, syslog ou null.

Canal de type chier


Pour quun canal soit associ un chier, il faut indiquer le chemin du chier. Loption versions permet de prciser le nombre dinstances possibles du chier et loption size, la taille maximale du chier. Si on indique quil peut exister trois instances du chier, BIND cre les chiers le, le.0, le.1 et le.2. Lors de son dmarrage ou de son rechargement, le serveur renomme le.1 en le.2, le.0 en le.1, le en le.0 puis commence crire dans un nouveau chier le. Si on ne prcise aucune valeur, BIND conserve 99 instances. En indiquant une taille maximale de chier, BIND cesse dcrire dans le chier ds quil a atteint la taille maximale. la diffrence de la sous-structure versions, il ny a pas de renommage de chiers et cration dun nouveau chier vide pour poursuivre les critures. Si on ne prcise aucune taille maximale, le chier grossit indniment. Voici un exemple de canal associ un chier, utilisant les structures versions et size :
logging{ channel mon_fichier { file "log.msgs" versions 3 size 10k; severity dynamic; }; };

La valeur de la taille peut inclure lunit : k ou K dsigne des kilo-octets, m ou M des mga-octets et g ou G des giga-octets. Pour voir les messages de dbogage, il est important de xer la gravit soit debug, soit dynamic. La gravit par dfaut est info, qui ne montre que les messages de syslog.

Canal de type syslog


Si un canal est associ syslog, on peut indiquer lun des services suivants : kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, authpriv, ftp, local0, local1, local2, local3, local4, local5, local6 ou local7. La valeur par dfaut est daemon, nous recommandons dutiliser cette valeur ou lune des valeurs locales. Voici un exemple de canal associ syslog et utilisant le service local0 la place de daemon :
logging { channel mon_syslog {

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

144
syslog local0; severity info; }; };

Chapitre 7 Exploitation de BIND


// Envoi vers le service local0 de syslog. // Envoi uniquement de priorit info ou plus.

Canal stderr
Le canal prdni default_stderr permet dcrire des messages sur le descripteur de chiers stderr. Avec BIND 8, on ne peut pas dnir dautre descripteur de chiers pour utiliser stderr, alors quon peut le faire avec BIND 9.

Canal null
Le canal prdni null permet dliminer des messages.

Mise en forme des donnes dans un canal


Le mcanisme de journalisation de BIND permet dajouter des lments aux messages : estampille temporelle, catgorie ou niveau de gravit. Voici un exemple de message de dbogage auquel on a ajout chacun de ces lments :
01-Feb-1998 13:19:18.889 config: debug 1: source = db.127.0.0

La catgorie de ce message est cong et sa gravit est debug au niveau 1. Voici maintenant un exemple de conguration correspondant ces trois ajouts :
logging { channel mon_fichier { file "log.msgs"; severity debug; print-category yes; print-severity yes; print-time yes; }; };

Lajout dune estampille temporelle un message destin syslog ne prsente aucun intrt, car syslog ajoute lui-mme la date et lheure.

Prcisions sur les catgories


BIND 8 et BIND 9 disposent tous deux de nombreuses catgories, mais elles sont malheureusement diffrentes. Pour en prendre connaissance, le mieux est de congurer un serveur pour quil imprime tous les messages possibles, avec leur catgorie et leur niveau de gravit, puis de slectionner celles qui nous intressent.

Catgories de BIND 8
default Si une catgorie nest associe aucun canal, les messages correspondants sont attribus la catgorie default. En quelque sorte, default est synonyme de toute catgorie . Toutefois, certains messages nappartiennent aucune catgorie. Donc, mme en associant toutes les catgories possibles des canaux, des messages aboutiront dans la catgorie default.
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Messages gnrs par BIND


Si aucun canal nest associ default, le systme en attribue un dofce :
category default { default_syslog; default_debug; };

145

cname Erreur sur CNAME (message ... has CNAME and other data). config Traitement de haut niveau du chier de conguration. db Opration sur une base de donnes. eventlib vnement au niveau du systme ; doit tre associ un canal unique de type chier. La valeur standard est :
category eventlib { default_debug; };

insist chec lors dun test interne de cohrence. lame-servers Dlgation dautorit dfectueuse. load Chargement de zone. maintenance Opration priodique de maintenance (telle quune requte du systme). ncache vnement li la mmoire cache des rponses ngatives. notify Notication asynchrone de modication de zone. os Problme avec le systme dexploitation. packet Dcodage de paquets reus et envoys ; doit tre associ un canal unique de type chier. La valeur standard est :
category packet { default_debug; };

panic Problme causant larrt du serveur. Ce problme est signal la fois dans la catgorie panic et dans sa catgorie native. La valeur standard est :
category panic { default_syslog; default_stderr; };

parser Analyse de bas niveau du chier de conguration.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

146
queries Journalisation des requtes.

Chapitre 7 Exploitation de BIND

response-checks Rponse malforme, information complmentaire hors sujet, etc. security Requte accepte/refuse. statistics Rapport priodique dactivit. update vnement de mise jour dynamique. update-security Rejet de mise jour dynamique (en 8.4.0, ces messages aboutissent dans leur propre catgorie, ce qui permet de mieux les reprer). xfer-in Transfert de zone dun serveur distant vers le serveur local. xfer-out Transfert de zone du serveur local vers un serveur distant.

Catgories de BIND 9
default Comme avec BIND 8, la catgorie default de BIND 9 correspond toute catgorie non associe un canal. Par contre, la catgorie default de BIND 9 nenglobe aucun message non affect une catgorie. general Cette catgorie contient tous les messages non explicitement catalogus. client Traitement de requte de client. config Analyse et traitement du chier de conguration. database Message relatif la base de donnes interne de BIND ; utilise pour enregistrer les donnes de la zone ainsi que la mmoire cache des enregistrements. dnssec Traitement des rponses signes DNSSEC. lame-servers Dlgation dautorit dfectueuse (depuis BIND 9.1.0 ; dans les premires versions de BIND 9, ces informations appartenaient la catgorie resolver).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Messages gnrs par BIND


network Opration rseau. notify Notication asynchrone de modication de zone. queries Journalisation des requtes (ajout BIND 9.1.0).

147

resolver Rsolution de nom, dont le traitement des requtes rcursives venant dun resolver. security Requte accepte/refuse. update vnement de mise jour dynamique. update-security Rejet de mise jour dynamique. Voyez la remarque dans la description des catgories de BIND 8 (ajout en 9.3.0). xfer-in Transfert de zone dun serveur distant vers le serveur local. xfer-out Transfert de zone du serveur local vers un serveur distant.

Enregistrer toutes les catgories de messages


La conguration du serveur pour quil enregistre tous les messages dans un chier, avec catgorie et gravit, est un bon moyen pour dcouvrir le systme de journalisation. Les catgories congures en standard ont dj t prsentes. Voici celles de BIND 8 :
logging { category category category category }; default { default_syslog; default_debug; }; panic { default_syslog; default_stderr; }; packet { default_debug; }; eventlib { default_debug; };

Et celles de BIND 9 :
logging { category default { default_syslog; default_debug; }; };

En standard, la catgorie et la gravit ne sont pas incluses dans les messages dirigs vers le canal default_debug. Pour enregistrer tous les messages possibles, avec leur catgorie et leur gravit, il faut modier soi-mme la conguration. Voici un exemple de conguration de logging effectuant ce type denregistrement pour BIND 8 :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

148
logging { channel mon_fichier { file "log.msgs"; severity dynamic; print-category yes; print-severity yes; }; category category category category category }; default panic packet eventlib queries { { { { {

Chapitre 7 Exploitation de BIND

default_syslog; mon_fichier; }; default_syslog; mon_fichier; }; mon_fichier; }; mon_fichier; }; mon_fichier; };

La conguration pour BIND 9 ne contiendrait pas les catgories panic, packet et eventlib. Chaque catgorie a t dnie pour inclure le canal mon_chier. Par rapport la conguration prcdente, la catgorie queries a t ajoute. En effet, les requtes ne sont pas mmorises moins que lon ne congure cette catgorie. En dmarrant le serveur et en initialisant le dbogage au niveau un, on obtient dans le chier log.msgs des messages similaires aux suivants (BIND 9 ne montrerait que le message de requte car il ne gnre plus les autres messages) :
queries: default: default: default: info: debug debug debug XX 1: 1: 1: /192.253.253.4/foo.movie.edu/A req: nlookup(foo.movie.edu) id 4 type=1 class=1 req: found 'foo.movie.edu' as 'foo.movie.edu' (cname=0) ns_req: answer -> [192.253.253.4].2338 fd=20 id=4 size=87

Une fois que lon a repr les messages que lon veut mmoriser, on peut recongurer le serveur pour nenregistrer que ceux-l.

Le secret de la russite
Il est important dtre inform dun problme avant quil ne devienne critique. De plus, une intervention prcoce, avant la dgradation complte du systme, permet souvent de rsoudre plus facilement le problme. Il ne sera pas question ici de localiser une panne suite au dveloppement dun problme (un chapitre entier y sera consacr), mais daction prventive. Les deux parties qui suivent traitent de lobservation priodique du chier de syslog et de lanalyse des statistiques du serveur de noms an danticiper les problmes.

Messages courants de syslog


named peut gnrer de nombreux types de messages syslog. La plupart dentre eux sont dcrits ici, sauf ceux signalant des erreurs de syntaxe dans les chiers de donnes de la zone. chaque dmarrage de named, un message de priorit LOG_NOTICE est gnr. Celui de BIND 8 a lallure suivante :
Jan 10 20:48:32 toystory named[3221]: starting. named 8.2.3 Tue May 16 09:39:40

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite

149

MDT 2000 cricket@huskymo.boulder.acmebw.com:/usr/local/src/bind-8.2.3/src/bin/ named

Celui de BIND 9 a t fortement abrg :


Jul 27 16:18:41 toystory named[7045]: starting BIND 9.3.2

Ce message indique que named vient de dmarrer et prcise la version de BIND utilise, ainsi que, dans le cas de BIND 8, lauteur et lhte de la compilation. Si on nest pas certain de la version de BIND que lon utilise, il suft de consulter ce chier et de rechercher ce message. chaque fois que named reoit une commande reload, un serveur envoie un message avec une priorit LOG_NOTICE. Voici celui de BIND 8 :
Jan 10 20:50:16 toystory named[3221]: reloading nameserver

et celui de BIND 9 :
Jul 27 16:27:45 toystory named[7047]: loading configuration from '/etc/named.conf'

Ce message indique que named a recharg la base de donnes (comme consquence dune commande reload). Il peut aider dterminer pendant combien de temps un mauvais enregistrement de ressource a t en service ou pendant combien de temps une zone complte a t dfectueuse suite un incident pendant une mise jour. Voici un autre message qui peut apparatre peu de temps aprs le dmarrage dun serveur :
Jan 10 20:50:20 toystory named[3221]: cannot set resource limits on this system

Il indique que le serveur a dtect que le systme dexploitation ne gre pas les appels systme getrlimit() et setrlimit(), utiliss lors de la dnition de coresize, datasize, stacksize ou les. Ce message apparat systmatiquement, mme si ces quatre instructions ne sont pas utilises dans le chier de conguration ; dans ce cas, le message peut tre ignor. Par contre, si ces instructions sont utilises et si on pense que le systme dexploitation comprend getrlimit() et setrlimit(), il faut recompiler BIND en dnissant HAVE_GETRUSAGE. Ce message a un niveau de priorit LOG_INFO. Si le serveur est situ sur un hte multi-domicili, et tout particulirement sur un hte possdant des interfaces virtuelles, le message suivant peut apparatre peu de temps aprs le dmarrage du serveur ou mme aprs une priode de bon fonctionnement :
Jan 10 20:50:31 toystory named[3221]: fcntl(dfd, F_DUPFD, 20): Too many open files Jan 10 20:50:31 toystory named[3221]: fcntl(sfd, F_DUPFD, 20): Too many open files

Il indique que BIND est court de descripteurs de chiers. BIND utilise un nombre raisonnable de descripteurs de chiers : deux pour chaque interface de rseau coute (un pour UDP et un pour TCP) et un pour ouvrir les chiers de donnes de zone. Si cest plus que ce que le systme dexploitation ne peut attribuer un processus, BIND gnre le message ci-dessus. Le niveau de priorit du message dpend de la section de BIND qui sest vue refuser lattribution dun descripteur de chiers : plus cest critique, plus le niveau de priorit est lev.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

150

Chapitre 7 Exploitation de BIND

La solution consiste, soit amener BIND utiliser moins de descripteurs de chiers, soit lever la limite impose par le systme dexploitation :

sil nest pas ncessaire que BIND coute toutes les interfaces rseau (en particulier
les interfaces virtuelles), utilisez linstruction listen-on pour indiquer BIND quelles interfaces il doit couter. Le Chapitre 10 dtaille la syntaxe de listen-on ;

si le systme dexploitation comprend getrlimit() et setrlimit() (voir plus haut), congurez le serveur de noms pour quil utilise un plus grand nombre de chiers, laide de linstruction les. Le Chapitre 10 dcrit lutilisation de les ;

si le systme dexploitation est trop restrictif sur le nombre de chiers quun


processus peut ouvrir, repoussez la limite avant le dmarrage de named laide de la commande ulimit. chaque fois que BIND charge une zone, il envoie un message avec une priorit LOG_INFO :
Jan 10 21:49:50 toystory named[3221]: zone movie.edu/IN loaded serial 2005011000

Ce message indique quel moment une zone a t charge, en prcisant la classe (IN dans ce cas) et le numro de srie de lenregistrement SOA de la zone. Toutes les heures environ, BIND 8 gnre des statistiques la priorit LOG_INFO :
Feb 18 14:09:02 toystory named[3565]: USAGE 824681342 824600158 CPU=13.01u/3.26s CHILDCPU=9.99u/12.71s Feb 18 14:09:02 toystory named[3565]: NSTATS 824681342 824600158 A=4 PTR=2 Feb 18 14:09:02 toystory named[3565]: XSTATS 824681342 824600158 RQ=6 RR=2 RIQ=0 RNXD=0 RFwdQ=0 RFwdR=0 RDupQ=0 RDupR=0 RFail=0 RFErr=0 RErr=0 RTCP=0 RAXFR=0 RLame=0 Ropts=0 SSysQ=2 SAns=6 SFwdQ=0 SFwdR=0 SDupQ=5 SFail=0 SFErr=0 SErr=0 RNotNsQ=6 SNaAns=2 SNXD=1

BIND 9 ne fournit pas les statistiques sous la forme de messages de journalisation. Les deux premiers nombres de chaque message sont des estampilles temporelles ; en soustrayant le second au premier, on obtient le temps coul en secondes depuis le dmarrage du serveur. CPU indique le temps utilis par le serveur en mode utilisateur (13,01 secondes) et en mode systme (3,26 secondes). CPU donne les mmes renseignements pour les processus-ls. NSTATS indique le nombre de requtes reues, par type. XSTATS fournit des statistiques supplmentaires. NSTATS et XSTATS sont dcrits en dtail plus loin dans ce chapitre. La dcouverte dun nom non conforme la RFC 952 provoque la gnration du message suivant vers syslog :
Jul 24 20:56:26 toystory named[1496]: ID_4.movie.edu IN: bad owner name (check-names)

avec la priorit LOG_ERROR (voir le Chapitre 4 pour les rgles sur les noms dhtes). Le message syslog suivant est une alerte signalant un problme dans les donnes de la zone, il est envoy avec la priorit LOG_ERROR :
Jan 10 20:48:38 toystory2 named[3221]: ts2 has CNAME and other data (invalid)

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite

151

Ce message signale un problme dans les donnes de zone. Il peut provenir, par exemple, des enregistrements suivants :
ts2 ts2 toystory2 toystory2 IN IN IN IN CNAME MX A MX toystory2 10 toystory2 192.249.249.10 10 toystory2

Lenregistrement MX pour ts2 est incorrect ; cest ce qui gnre le message ci-dessus. ts2 est un alias de toystory2, qui est un nom canonique. Comme cela a dj t indiqu, lorsquun serveur recherche un nom et dcouvre un enregistrement CNAME, il remplace le nom original par le nom canonique et utilise ce dernier pour poursuivre la recherche. Si le serveur recherche linformation MX pour ts2, il trouve dabord un enregistrement CNAME et recherche alors lenregistrement MX pour toystory2 ; il nutilise donc jamais lenregistrement MX pour ts2. Ce dernier nest donc pas valable. En rsum, tous les enregistrements de ressource concernant un hte doivent utiliser le nom canonique ; lutilisation dun alias la place du nom canonique est une erreur. Le message suivant indique quun esclave BIND 8 narrive pas atteindre un matre lors dune tentative de transfert de zone :
Jan 10 20:52:42 wormhole named[2813]: zoneref: Masters for secondary zone "movie.edu" unreachable

En BIND 9, le message est :


Jul 27 16:50:55 toystory named[7174]: transfer of 'movie.edu/IN' from 192.249.249.3#53: failed to connect: timed out

Ce message est envoy avec la priorit LOG_NOTICE en BIND 8 et avec la priorit LOG_ERROR en BIND 9, et ce uniquement lors du premier chec de transfert de zone. Lorsque le transfert ni par seffectuer, BIND gnre un autre message syslog. Si le message dchec apparat, il nest pas ncessaire dintervenir immdiatement : le serveur-esclave effectue plusieurs tentatives de transfert, selon la priodicit indique dans lenregistrement SOA. Au bout de quelques jours (ou la moiti du dlai dexpiration), il faut regarder si le transfert a eu lieu. Si un serveur na pas gnr de message syslog de succs de transfert, on peut tester lestampille temporelle du chier de sauvegarde de zone ; en effet, lorsquun transfert se fait correctement, un nouveau chier de sauvegarde est cr. Lorsquun esclave constate quune zone est jour, lestampille temporelle du chier de sauvegarde est modie (comme le ferait la commande Unix touch). La commande ls -l /usr/local/named/db* indique alors quand lesclave a t synchronis pour la dernire fois. Les problmes de transferts de zone seront dcrits au Chapitre 14. Un message avec la priorit LOG_INFO apparat sur le serveur-matre lorsque lesclave charge de lui-mme de nouvelles donnes ou lorsquun outil, tel que nslookup, transfre une zone :
Mar 7 07:30:04 toystory named[3977]: client 192.249.249.1#1076: transfer of 'movie.edu/IN':AXFR started

Si linstruction allow-transfer (dcrite au Chapitre 11) est utilise pour restreindre la liste des serveurs pouvant charger une zone, le message peut indiquer denied la place de started :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

152

Chapitre 7 Exploitation de BIND

Jul 27 16:59:26 toystory named[7174]: client 192.249.249.1#1386: zone transfer 'movie.edu/AXFR/IN' denied

Le message syslog suivant apparat uniquement au niveau LOG_INFO :


Jan 10 20:52:42 wormhole named[2813]: Malformed response from 192.1.1.1

Le plus souvent, ce message indique quun bogue dans le serveur de noms a provoqu le renvoi dun paquet erron, en rponse une requte. Lerreur vient plutt du serveur de noms distant (192.1.1.1) que du serveur local (wormhole). Le diagnostic prcis ncessiterait une capture du paquet en cause, puis son analyse. Une analyse manuelle de paquet dpasse le cadre de cet ouvrage. Ce type derreur apparat lorsque le paquet indique quil contient plusieurs rponses dans la section des rponses (par exemple, quatre enregistrements de ressource dadresse) alors quil ny en a quune. La seule action possible consiste prvenir ladministrateur de lhte dfectueux par courriel (en esprant que lon puisse obtenir le nom de cet hte partir de son adresse). Ce type derreur peut aussi se produire lorsque le rseau sous-jacent altre les paquets UDP de rponse. Comme le contrle derreur sur les paquets UDP est optionnel, le problme peut ne pas tre dtect bas niveau. Lorsque des donnes concernant une autre zone sont introduites dans ses chiers de zone, named gnre le message suivant en BIND 8 :
Jun 13 08:02:03 toystory named[2657]: db.movie.edu:28: data "foo.bar.edu" outside zone "movie.edu" (ignored)

et le suivant en BIND 9 :
Jul 27 17:07:01 toystory named[7174]: dns_master_load: db.movie.edu:28: ignoring out-of-zone data

Avec les donnes de zone suivantes :


shrek toystory IN A 192.249.249.2 IN A 192.249.249.3

; ajout de cette entre dans la mmoire cache du serveur de noms foo.bar.edu. IN A 10.0.7.13

des informations concernant la zone bar.edu apparaissent lintrieur des chiers de notre zone movie.edu. Ce message syslog est enregistr avec la priorit LOG_WARNING. Il nest pas possible dutiliser un CNAME dans le champ des donnes dun enregistrement de ressources. BIND 8 signale ce type derreur :
Jun 13 08:21:04 toystory named[2699]: "movie.edu IN NS" points to a CNAME (mi.movie.edu)

Jusquen 9.3.0, BIND 9 ne signale rien. Voici un exemple correspondant ce dernier type derreur :
@ IN IN toystory.movie.edu. IN monsters-inc.movie.edu. IN mi.movie.edu. IN NS NS A A CNAME toystory.movie.edu. mi.movie.edu. 192.249.249.3 192.249.249.4 monsters-inc.movie.edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite

153

Le second enregistrement NS devrait contenir monsters-inc.movie.edu au lieu de mi.movie.edu. Le message derreur napparat pas immdiatement aprs le dmarrage du serveur.

Ce message syslog napparat que lorsque les donnes incorrectes sont consultes. Il est gnr par BIND 8 avec la priorit LOG_INFO.

Le message suivant indique que le serveur sest peut-tre protg lui-mme dune attaque :
Jun 11 11:40:54 toystory named[131]: Response from unexpected source ([204.138.114.3].53)

Le serveur a envoy une requte un serveur distant et la rponse reue ne vient pas dune adresse correspondant au serveur interrog. Il est possible quil sagisse dune attaque : un intrus a provoqu linterrogation dun serveur distant par le serveur local et, simultanment, a envoy des rponses (en prtendant que ces rponses venaient du serveur distant) an que le serveur local les place dans sa mmoire cache. Il a pu, par exemple, envoyer un faux enregistrement PTR, qui dsignerait ladresse dun de ses propres htes comme appartenant un domaine privilgi du point de vue du serveur local. Une fois que lenregistrement PTR est stock en mmoire cache, lintrus peut utiliser une des r commandes de BSD (comme rlogin) pour se connecter au systme. Cette situation peut aussi se prsenter si un serveur-parent dune zone ne connat quune seule des adresses IP dun serveur multi-domicili de cette zone. Dans ce cas, le serveur-parent nindiquera que ladresse IP quil connat, alors que le serveur lui-mme rpondra peut-tre par lautre adresse IP Ce cas ne devrait pas se prsenter si le serveur . utilise BIND, car BIND prend soin dutiliser pour la rponse la mme adresse que celle utilise pour la requte. Le message syslog est enregistr avec la priorit LOG_INFO. Voici un autre type de message syslog :
Jun 10 07:57:28 toystory named[131]: No root name servers for class 226

Les seules classes dnies ce jour sont la classe 1 pour lInternet (IN), la classe 3 pour Chaos (CH), et la classe 4 pour Hesiod (HS). La classe 226 nexistant pas, on ne peut rien faire de cette requte. De plus, si le champ classe est corrompu, il se peut que le reste de la requte le soit galement. Ce type de problme peut venir dun serveur distant dfectueux ou dun datagramme UDP corrompu. Le message syslog est enregistr avec la priorit LOG_INFO. Le message suivant peut apparatre sur un serveur secondaire :
Jun 7 20:14:26 wormhole named[29618]: Zone "253.253.192.in-addr.arpa" (class 1) SOA serial# (3345) rcvd from [192.249.249.10] is < ours (563319491)

Ici, ladministrateur de 253.253.192.in-addr.arpa a chang le format du numro de srie sans prvenir qui que ce soit. Pour rsoudre le problme, il suft darrter le service de noms sur lesclave, puis deffacer les chiers de sauvegarde de la zone et enn de red-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

154

Chapitre 7 Exploitation de BIND

marrer le serveur. De cette manire, le serveur-esclave oublie lancien numro de srie de lenregistrement SOA et tlcharge une nouvelle copie des chiers, avec le nouveau numro de srie. Le message syslog est enregistr avec la priorit LOG_NOTICE. Si ladministrateur responsable de lerreur sur le numro de srie utilise BIND 8 ou 9, il peut avoir omis un message gnr par son serveur, lui indiquant que son numro de srie a boucl. Sur un serveur BIND 8, le message ressemble
Jun 7 19:35:14 toystory named[3221]: WARNING: new serial number < old (zp->z_serial < serial)

En BIND 9, le message serait :


Jun 7 19:36:41 toystory named[9832]: dns_zone_load: zone movie.edu/IN: zone serial has gone backwards

Ce message est journalis au niveau LOG_NOTICE. Dans tous les cas, il peut tre bon de rappeler ladministrateur fautif de consulter les chiers de journalisation (syslog) aprs toute modication sur le serveur de noms. En BIND 8, le message suivant signale une mauvaise dlgation dans lInternet :
Aug 21 00:59:06 toystory named[12620]: Lame server on 'foo.movie.edu' (in 'MOVIE.EDU'?): [10.0.7.125].53 'NS.HOLLYWOOD.LA.CA.US': learnt (A=10.47.3.62,NS=10.47.3.62)

En BIND 9, le message serait :


Jan 15 10:20:16 toystory named[14205]: lame server on 'foo.movie.edu' (in 'movie.EDU'?): 10.0.7.125#53

Visiblement, un serveur-parent dlgue la gestion dun sous-domaine un serveurenfant mais ce dernier ne fait pas autorit sur le sous-domaine. Dans lexemple, le serveur de edu dlgue movie.edu 10.0.7.125, alors que le serveur situ sur cet hte ne fait pas autorit sur movie.edu. moins de connatre ladministrateur de movie.edu, il ny a rien faire. Un message de priorit LOG_INFO est envoy syslog. Si le chier de conguration contient :
logging { category queries { default_syslog; }; };

un message de priorit LOG_INFO est envoy syslog chaque rception de requte :


Feb 20 21:43:25 toystory named[3830]: XX /192.253.253.2/carrie.movie.edu/A Feb 20 21:43:32 toystory named[3830]: XX /192.253.253.2/4.253.253.192.in-addr.arpa/PTR

Le format a lgrement chang en BIND 9 :


Jan 13 18:32:25 toystory named[13976]: client 192.253.253.2#1702: query: carrie.movie.edu IN A + Jan 13 18:32:42 toystory named[13976]: client 192.253.253.2#1702: query: 4.253.253.192.in-addr.arpa IN PTR +

Ces messages comprennent ladresse IP de lhte qui a envoy la requte, et la requte elle-mme. partir de BIND 8.2.1, les requtes rcursives sont marques XX+ au lieu de XX. Un serveur BIND 9 marque les requtes rcursives par un + et les non-rcursives par un - . BIND 8.4.3 et BIND 9.3.0 et leurs successeurs marquent les requtes

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite

155

EDNS0 par un E et les requtes signes par TSIG par un S (nous parlerons de EDNS0 au Chapitre 10 et de TSIG au Chapitre 11). Il est ncessaire de sassurer que lon dispose de sufsamment despace sur disque avant denregistrer ce type de messages (sur un serveur actif, la commande querylog permet de valider ou dinhiber lenregistrement de ces messages). Les messages syslog suivants peuvent apparatre partir de BIND 8.1.2 :
May 19 11:06:08 named[21160]: bind(dfd=20, [10.0.0.1].53): Address already in use May 19 11:06:08 named[21160]: deleting interface [10.0.0.1].53 May 19 11:06:08 named[21160]: bind(dfd=20, [127.0.0.1].53): Address already in use May 19 11:06:08 named[21160]: deleting interface [127.0.0.1].53 May 19 11:06:08 named[21160]: not listening on any interfaces May 19 11:06:08 named[21160]: Forwarding source address is [0.0.0.0].1835 May 19 11:06:08 named[21161]: Ready to answer queries.

En BIND 9, ils deviennent :


Jul 27 17:15:58 toystory named[7357]: 127.0.0.1#53 Jul 27 17:15:58 toystory named[7357]: Jul 27 17:15:58 toystory named[7357]: 206.168.194.122#53 Jul 27 17:15:58 toystory named[7357]: Jul 27 17:15:58 toystory named[7357]: 206.168.194.123#53 Jul 27 17:15:58 toystory named[7357]: Jul 27 17:15:58 toystory named[7357]: address in use listening on IPv4 interface lo, binding TCP socket: address in use listening on IPv4 interface eth0, binding TCP socket: address in use listening on IPv4 interface eth1, binding TCP socket: address in use couldn't add command channel 0.0.0.0#953:

Ici, un second serveur a t dmarr sur le mme hte alors que le premier continue fonctionner. Le second serveur effectue un service normal mais nest lcoute daucune interface.

Interprter les statistiques de BIND


Lanalyse priodique des statistiques permet de connatre la charge dun serveur. Nous allons tudier un exemple rel, en commenant par dtailler un ensemble dchanges. En fonctionnement normal, les serveurs de noms traitent de nombreuses requtes et rponses ; il est donc logique de commencer par lanalyse dun change typique. La lecture des statistiques est ardue si on na pas une vision claire du mcanisme de recherche de noms. La gure 7-2 dcrit une recherche suite la requte de nom effectue par une application FTP Ici, FTP interroge un serveur local. Ce dernier a dj recherch . des informations dans la zone distante concerne ; il connat donc lidentit de ses serveurs. Il les interroge tous, et deux fois pour lun dentre eux, an de trouver la rponse. Pendant ce temps, le dlai dattente au niveau de lapplication est arriv chance et la requte a t ritre.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

156

Chapitre 7 Exploitation de BIND

application ftp requte temps

serveur de noms local


rception requte 1 par serveur local requte 1 serveur local vers serveur distant 1
dpassement de dlai

serveurs de noms distants

1 application

requte 2 serveur local vers serveur distant 2


dpassement de dlai

requte 2 application

rception requte 2 par serveur local


in at io du n pl iq u e

rception requte 1 envoi rponse requte 1

l im

re

dpassement de dlai

qu

te

requte 3 serveur local vers serveur distant 3


dpassement de dlai

requte 4 ser veur local vers serveur distant 1 rception requte 2 envoi rponse requte 2 rception et traitement rponse par application envoi rponse requte 1 application rception rponse requte 1 rception requte 4

1
rception rponse requte 2 envoi rponse requte 4 requte 3 perdue (machine arrte) rception rponse requte 4

re

qu lim t in e d at up ion liq u e

Figure 7-2. Un exemple de cycle de requtes/rponses


Rappelons quune requte envoye par un serveur vers un serveur distant peut ne pas tre reue correctement. La requte a pu tre retarde ou perdue dans le rseau sousjacent, ou le serveur distant peut tre occup par une autre application. Un serveur BIND ne peut dtecter la duplication dune requte que sil est encore en train de traiter la requte initiale. Dans lexemple, le serveur local dtecte la duplication de requte car il travaille encore sur cette requte. Par contre, le serveur distant numro 1 ne dtecte pas la duplication parce quil a dj rpondu la requte initiale. Ds que le serveur local a reu la rponse en provenance du serveur distant numro 1, toutes les autres rponses potentielles sont considres comme des duplications et sont abandonnes. Lensemble du dialogue est rsum dans le suivant :

re

qu lim t in e d at up ion liq u e

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite

157

change application vers serveur local serveur local vers application serveur local vers serveur distant numro 1 serveur distant numro 1 vers serveur local serveur local vers serveur distant numro 2 serveur distant numro 2 vers serveur local serveur local vers serveur distant numro 3 serveur distant numro 3 vers serveur local 2 requtes 1 rponse 2 requtes 2 rponses 1 requte 1 rponse 1 requte 0 rponses

Nombre

Ces changes contribuent aux statistiques du serveur de noms local :


Statistique 2 requtes reues 1 requte duplique 1 rponse envoye 3 rponses reues 2 rponses dupliques 2 requtes A Cause en provenance de lapplication sur lhte local en provenance de lapplication sur lhte local vers lapplication sur lhte local en provenance de serveurs distants en provenance de serveurs distants requtes dinformation dadresse

Dans lexemple, le serveur local reoit des requtes en provenance dune application unique, puis les redirige vers des serveurs distants. Dans le cas gnral, le serveur local recevrait galement des requtes en provenance de serveurs distants. En effet, de mme quil interroge des serveurs distants pour trouver les informations dont il a besoin, des serveurs distants interrogent le serveur local pour trouver les informations qui leur sont ncessaires. Pour simplier la gure et les tableaux, nous navons pas reprsent les requtes distantes.

Statistiques de BIND 8
Aprs cette prsentation, nous allons tudier des cas plus complexes de statistiques. Pour capturer les statistiques dun serveur BIND 8, utilisez la commande ndc :
# ndc stats

Il faut attendre quelques secondes avant de consulter le chier named.stats dans le rpertoire de travail du serveur de noms. Si aucune statistique napparat dans ce chier, cest que named a probablement t compil sans que loption STATS ait t dnie, ce qui fait que les statistiques ne sont pas collectes. Les statistiques qui suivent proviennent dun serveur BIND 4.9.3 de Paul Vixie. Un serveur BIND 8 prsente les mmes rubri-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

158

Chapitre 7 Exploitation de BIND

ques, mais dans un ordre diffrent et sans RNotNsQ. Les statistiques de BIND 9 sont totalement diffrentes et sont prsentes plus loin.
+++ Statistics Dump +++ (800708260) Wed May 17 03:57:40 1995 746683 time since boot (secs) 392768 time since reset (secs) 14 Unknown query types 268459 A queries 3044 NS queries 5680 CNAME queries 11364 SOA queries 1008934 PTR queries 44 HINFO queries 680367 MX queries 2369 TXT queries 40 NSAP queries 27 AXFR queries 8336 ANY queries ++ Name Server Statistics ++ (Legend) RQ RR RIQ RNXD RFwdQ RFwdR RDupQ RDupR RFail RFErr RErr RTCP RAXFR RLame ROpts SSysQ SAns SFwdQ SFwdR SDupQ SFail SFErr SErr RNotNsQ SNaAns SNXD (Global) 1992938 112600 0 19144 63462 60527 194 347 3420 0 5 2235 27 35289 0 14886 1927930 63462 60527 107169 10025 119 0 1785426 805592 35863 [15.255.72.20] 485 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 485 0 0 0 0 0 0 0 485 0 [15.255.152.2] 441 137 0 1 2 108 0 0 0 0 0 0 0 0 0 13 439 85 7 84 0 0 0 0 431 0 [15.255.152.4] 770 89 0 1 4 69 0 0 0 0 0 0 0 0 0 14 766 68 5 7 0 0 0 0 755 0 ... <lignes supprimes>

Si les statistiques du serveur BIND 8 ne prsentent aucune section par adresse IP la suite de (Global) , il faut initialiser host-statistics yes dans la directive options si on souhaite surveiller le trac par hte :
options { host-statistics yes; };

Bien sr, une telle surveillance demande une quantit de mmoire importante et il ne faut pas lactiver en permanence, moins de vouloir btir un prol de lactivit du serveur. Analysons maintenant les statistiques, ligne par ligne.
+++ Statistics Dump +++ (800708260) Wed May 17 03:57:40 1995

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite

159

Cette ligne indique quand cette nouvelle srie de statistiques a t gnre. Le nombre entre parenthses (800708260) est le nombre de secondes depuis l Epoch dUnix (le 1er janvier 1970). Heureusement, BIND lafche aussi dans un format humainement comprhensible, ce qui donne ici le 17 mai 1995 3 h 57 mn 40 s. La ligne :
746683 time since boot (secs)

indique, en secondes, la dure dactivit du serveur. Pour convertir en jours, il faut diviser par 86400 (606024), ce qui donne ici environ 8,5 jours. La ligne :
392768 time since reset (secs)

indique le temps coul depuis le dernier rechargement. Ce nombre ne diffre probablement du prcdent que sur un serveur primaire. Les esclaves obtiennent automatiquement leurs donnes par tlchargement et ne sont gnralement pas rechargs. Puisque ce serveur a t rinitialis, il est sans doute serveur primaire. La ligne :
14 Unknown query types

indique que ce serveur a reu 14 requtes concernant des types quil na pas reconnus : soit quelquun exprimente des nouveaux types de donnes, soit un serveur est dfectueux, soit Paul a besoin de mettre son serveur jour. La ligne :
268459 A queries

signale quil y a eu 268459 requtes dadresse. Ces requtes sont les plus courantes. La ligne :
3044 NS queries

montre quil y a eu 3044 requtes de recherche de serveur de noms. En interne, les serveurs gnrent des requtes NS lorsquils recherchent les serveurs de la racine. En externe, des applications comme dig ou nslookup peuvent aussi tre utilises pour rechercher des enregistrements NS.
5680 CNAME queries

Certaines versions de sendmail effectuent des recherches de type CNAME an de canoniser une adresse de courrier (remplacer un alias par le nom canonique). Dautres versions de sendmail utilisent plutt les requtes de type ANY, que nous verrons plus loin. Les autres requtes de type CNAME proviennent souvent de dig ou de nslookup.
11364 SOA queries

Les requtes de SOA sont gnres par les serveurs-esclaves qui vrient ainsi sils sont jour. Sils ne sont pas jour, ils envoient ensuite une requte AXFR pour provoquer le transfert de zone. Lexemple signalant des requtes AXFR, on peut en conclure que des serveurs-esclaves chargent des donnes en provenance de ce serveur. La ligne :
1008934 PTR queries

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

160

Chapitre 7 Exploitation de BIND

comptabilise les requtes de PTR qui reprsentent les correspondances dadresse vers nom. De nombreux logiciels recherchent les noms partir des adresses IP : inetd, rlogind, rshd, les logiciels de gestion ou de capture sur rseau. La ligne :
44 HINFO queries

indique le nombre de requtes dinformation sur les htes, HINFO, qui correspondent souvent des oprations manuelles.
680367 MX queries

Les routeurs de messagerie, tels que sendmail, effectuent des recherches dchangeur de messagerie.
2369 TXT queries

Pour que cette valeur soit aussi leve, il faut que les requtes correspondantes proviennent dapplications telles que Harvest, outil de recherche dinformation et de rcupration de donnes dvelopp lUniversit du Colorado.
40 NSAP queries

NSAP est un type denregistrement relativement rcent, utilis pour mettre en correspondance des noms et des adresses de point daccs des rseaux OSI.
27 8336 AXFR queries ANY queries

Les esclaves effectuent des requtes AXFR pour dclencher des transferts de zone. Les requtes ANY recherchent tout type de donnes correspondant un nom. Elles sont le plus souvent utilises par sendmail. Comme sendmail recherche les enregistrements CNAME, MX ou dadresse correspondant une destination de courrier, il gnre une requte de type ANY an que tous les enregistrements de ressource soient rapatris vers le serveur local et stocks dans sa mmoire cache. Les statistiques suivantes sont prsentes hte par hte. Une premire lecture permet dapprcier lactivit du serveur car on peut trouver des centaines, voire des milliers dhtes, qui ont chang des donnes avec le serveur local. Leur format brut est illisible, aussi un outil est-il ncessaire pour mettre en forme ces statistiques. Nous en avons crit un, bstat, dont voici un exemple du format de sortie :
hpcvsop.cv.hp.com 485 queries received 485 responses sent to this name server 485 queries answered from our cache relay.hp.com 441 queries received 137 responses received 1 negative response received 2 queries for data not in our cache or authoritative data 108 responses from this name server passed to the querier 13 system queries sent to this name server 439 responses sent to this name server 85 queries sent to this name server 7 responses from other name servers sent to this name server
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite
84 duplicate queries sent to this name server 431 queries answered from our cache hp.com 770 89 1 4 69 14 766 68 5 7 755 queries received responses received negative response received queries for data not in our cache or authoritative data responses from this name server passed to the querier system queries sent to this name server responses sent to this name server queries sent to this name server responses from other name servers sent to this name server duplicate queries sent to this name server queries answered from our cache

161

Dans le format brut, chaque adresse IP dhte est suivie dune table de valeurs dont la signication est indique au dbut de la section des statistiques hte par hte (Legend). La lgende est rpartie sur plusieurs lignes, mais les statistiques par hte sont prsentes sur une seule. Nous allons dcrire chaque champ en observant le cas de lhte dadresse IP 15.255.152.2 (relay.hp.com). Pour clarier lexplication, la valeur pour relay sera prcde de la lgende correspondante.

RQ 441 RQ est le nombre de requtes reues de relay. Il sagit ici de requtes envoyes par relay pour obtenir des informations servies par le serveur local. RR 137 RR est le nombre de rponses reues de relay. Il sagit ici de rponses envoyes par relay vers le serveur local. Il ny a aucun lien entre RR et RQ. RQ dnombre les questions poses par relay au serveur local et RR dnombre les rponses que relay a donnes au serveur local. RIQ 0 RIQ est le nombre de requtes inverses reues de relay. Les requtes inverses servaient initialement la correspondance adresse-nom ; on utilise aujourdhui les enregistrements PTR. Danciennes versions de nslookup utilisent encore les requtes inverses au dmarrage, donc RIQ peut ne pas tre nul. RNXD 1 RNXD comptabilise les rponses no such domain reues de relay. RFwdQ 2 RFwdQ est le nombre de requtes reues (RQ) de relay et qui ncessitent un traitement complmentaire avant de pouvoir rpondre la requte initiale. La valeur est plus leve pour les htes dont le resolver (via son chier resolv.conf) envoie toutes ses requtes vers le serveur local. RFwdR 108 RFwdR est le nombre de rponses reues (RQ) de relay rpondant la requte initiale et qui sont transmises lapplication qui a gnr la requte initiale.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

162

Chapitre 7 Exploitation de BIND

RDupQ 0 RDupQ est le nombre de requtes dupliques en provenance de relay. Celles-ci ne peuvent apparatre que si le chier resolv.conf de relay est congur pour interroger le serveur local. RDupR 0 RDupR est le nombre de rponses dupliques en provenance de relay. Une rponse est duplique lorsque le serveur local ne peut pas trouver la requte originale dans sa liste des requtes en attente de rponse. RFail 0 RFail est le nombre de rponses SERVFAIL reues de relay. Une rponse SERVFAIL signale une anomalie de serveur distant, par exemple lorsquil lit les chiers de zone et quil dcouvre une erreur de syntaxe. Toutes les requtes adresses la zone comportant le chier dfectueux produiront une rponse SERVFAIL de la part du serveur distant. Il sagit probablement du cas le plus courant de rponse SERVFAIL. Les rponses signalant un serveur dfectueux apparaissent aussi en cas de pnurie de mmoire sur le serveur distant ou lorsque la zone est parvenue chance sur lesclave distant. RFErr 0 RFErr est le nombre de rponses FORMERR reues de relay. FORMERR indique que le serveur distant a dtect une erreur de format dans la requte reue en provenance du serveur local. RErr 0 RErr est le nombre derreurs qui ne sont ni SERVFAIL ni FORMERR. RTCP 0 RTCP est le nombre de requtes reues via des connexions TCP en provenance de relay (la plupart des requtes parviennent en UDP). RAXFR 0 RAXFR est le nombre de transferts de zone. La valeur indique que relay nest pas un serveur-esclave dune des zones servies par le serveur local. RLame 0 RLame est le nombre de mauvaises dlgations reues. Si RLame est non nul, une zone est dlgue au serveur local mais ce serveur ne fait pas autorit sur cette zone. ROpts 0 ROpts est le nombre de paquets reus contenant des options IP . SSysQ 13 SSysQ est le nombre de requtes gnres linitiative du serveur local et envoyes relay. La plupart se font destination des serveurs de la racine car elles servent tenir jour la liste de ces serveurs. Elles peuvent aussi tre utilises pour dcouvrir ladresse dun serveur de noms si son enregistrement de ressource dadresse (A) parvient chance avant que ce ne soit le cas pour son enregistrement de
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite

163

ressource de serveur (NS). Comme relay nest pas un serveur de la racine, il sagit ici du second cas.

SAns 439 SAns est le nombre de rponses envoyes relay. Ici, le serveur local a rpondu 439 des 441 requtes (RQ) envoyes par relay. Il ny a aucune indication sur ce quil est advenu des deux requtes restes sans rponse... SFwdQ 85 SFwdQ est le nombre de requtes envoyes (rediriges) relay lorsque le serveur local na pas la rponse dans ses donnes de zone ou dans sa mmoire cache. SFwdR 7 SFwdR est le nombre de rponses envoyes par un serveur de noms quelconque et envoyes (rediriges) relay. SDupQ 84 SDupQ est le nombre de requtes dupliques envoyes relay. Cette valeur nindique pas obligatoirement un fonctionnement dfectueux. En effet, la valeur pour relay est incrmente si la requte a dabord t envoye un autre serveur et mme si relay rpond ds sa premire sollicitation. SFail 0 SFail est le nombre de rponses SERVFAIL envoyes relay. SFErr 0 SFErr est le nombre de rponses FORMERR envoyes relay. SErr 0 SErr est le nombre dappels systme sendto() qui chouent lorsque la destination est relay. RNotNsQ 0 RNotNsQ est le nombre de requtes reues et ne provenant pas du port 53, port ofciel dun serveur de noms. Avant BIND 8, toutes les requtes issues dun serveur de noms provenaient de ce port. Celles qui arrivaient dun autre port provenaient obligatoirement dun resolver. Les serveurs de noms BIND 8 peuvent expdier leurs requtes partir dun autre port ; cette statistique ne permettant plus de diffrencier les requtes provenant dun resolver de celles provenant dun serveur de noms, elle devient inutile. Aussi napparat-elle plus sur les serveurs BIND 8. SNaAns 431 SNaAns est le nombre de rponses ne faisant pas autorit envoyes relay. Parmi les 439 rponses envoyes relay (SAns), 431 sont issues de la mmoire cache. SNXD 0 SNXD est le nombre de rponses pas de nom correspondant (no such domain) envoyes relay.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

164

Chapitre 7 Exploitation de BIND

Statistiques de BIND 9
BIND 9.1.0 est la premire version de BIND 9 proposer des statistiques. On utilise rndc pour indiquer BIND 9 de gnrer des statistiques :
% rndc stats

Le serveur de noms gnre ses statistiques, de la mme manire que BIND 8, dans un chier named.stats situ dans son rpertoire de travail. Toutefois, elles ont un format totalement diffrent de celles de BIND 8. Voici le contenu dun chier de statistiques, gnr sur lun de nos serveurs de noms en BIND 9 :
+++ Statistics success 9 referral 0 nxrrset 0 nxdomain 1 recursion 1 failure 1 --- Statistics +++ Statistics success 651 referral 10 nxrrset 11 nxdomain 17 recursion 296 failure 217 --- Statistics Dump +++ (979436130)

Dump --- (979436130) Dump +++ (979584113)

Dump --- (979584113)

Le serveur de noms ajoute un nouvel ensemble de statistiques (la section situe entre +++ Statistics Dump +++ et --- Statistics Dump --- ) chaque rception dune commande stats. Le nombre entre parenthses (979436130) indique, comme prcdemment, la dure coule en secondes depuis lorigine dUnix. Malheureusement, BIND neffectue pas de conversion vers un format plus lisible mais, pour cela, on peut utiliser la commande Unix date. Ainsi, pour convertir 979584113 secondes depuis lorigine dUnix (le 1er janvier 1970), on peut excuter la commande suivante :
% date -d '1970-01-01 979584113 sec' Mon Jan 15 18:41:53 MST 2001

Dtaillons maintenant les statistiques ligne ligne :

success 651 Reprsente le nombre de requtes traites avec succs par le serveur et qui nont pas abouti des rfrences ou des erreurs. referral 10 Reprsente le nombre de requtes traites par le serveur et qui ont abouti des rfrences. nxrrset 11 Reprsente le nombre de requtes traites par le serveur et qui ont abouti des rponses indiquant que le type denregistrement demand nexiste pas pour le nom recherch.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Le secret de la russite

165

nxdomain 17 Reprsente le nombre de requtes traites par le serveur et qui ont abouti des rponses indiquant que le nom recherch nexiste pas. recursion 296 Reprsente le nombre de requtes reues et demandant une recherche rcursive. failure 217 Reprsente le nombre de requtes reues qui ont abouti une erreur autre que celles comptabilises dans nxrrset et nxdomain.
Manifestement, BIND 9 ne mmorise pas autant de statistiques que BIND 8, mais les prochaines rvision de BIND 9 en gnreront probablement davantage.

Exploiter les statistiques de BIND


Ce serveur de noms se porte-t-il bien, et comment le savoir ? En raison dune dure dobservation trop courte, ces statistiques sont bien insufsantes pour donner une conclusion. Pour dtecter un problme, il est important tout dabord de se faire une ide des valeurs lors du fonctionnement normal. En effet, il ny a pas dabsolu car les statistiques peuvent varier normment dun serveur lautre, selon le type des applications effectuant les requtes, le type de serveur (serveur primaire, esclave, serveur cache) et la position des zones gres dans lespace de noms. Un lment surveiller est le nombre de requtes reues par le serveur en une seconde. Pour le calculer, il faut diviser le nombre de requtes reues par la dure de fonctionnement du serveur de noms. Le serveur BIND 4.9.3 de Paul a reu 1992938 requtes en 746683 secondes, cest--dire environ 2,7 requtes par seconde, ce qui correspond un serveur peu sollicit. Si la valeur semble trop leve, il faut regarder quels serveurs distants effectuent les requtes et se demander, serveur par serveur, si cela parat normal. On pourrait alors en dduire quil est ncessaire dajouter des serveurs pour supporter la charge. Cette ventualit est dcrite dans le chapitre suivant.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

8
Expansion de domaine
Quelle taille veux-tu avoir ? demanda la Chenille. Oh ! je ne suis pas tellement difficile pour ce qui est de la taille, rpondit Alice. Ce quil y a dennuyeux, cest de changer si souvent de taille, voyez-vous Es-tu satisfaite de ta taille actuelle ? demanda la Chenille. Ma foi, si a vous tait gal, jaimerais bien tre un tout petit peu plus grande.

Choisir le nombre de serveurs


Au Chapitre 4, deux serveurs de noms ont t mis en place. Cependant, ils seront sans doute trs insufsants pour grer un rseau de grande taille. Il nest pas rare davoir grer quatre serveurs ou plus, dont certains sur des sites distants. Le choix du nombre total de serveurs incombe chaque domaine. Voici quelques pistes pour guider ladministrateur dans son choix :

Installer au moins un serveur de noms par rseau ou sous-rseau an de saffranchir


des pannes de routeur (utiliser au maximum les machines multi-domicilies qui, par dnition, sont connectes plusieurs rseaux).

Installer un serveur de noms sur les serveurs de stations sans disque, pour servir
spciquement ces dernires.

Installer les serveurs de noms proximit des machines multi-utilisateurs importantes (voire directement sur ces machines) qui gnreront a priori de nombreuses requtes. Il faut toutefois valuer les risques davoir un serveur de noms, donc une ressource critique du point de vue de la scurit, sur une machine accessible de nombreuses personnes.

Installer au moins un serveur de noms sur un site distant, pour rendre les donnes
accessibles mme si le rseau local est hors-service. Il peut sembler inutile de chercher garantir le service de noms dans le cas o le rseau local est inaccessible ; en fait, le serveur distant est surtout utile lorsque le rseau local est accessible mais quaucun

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

168

Chapitre 8 Expansion de domaine

serveur de noms interne nest oprationnel. Si on entretient une relation troite avec un organisme de lInternet (par exemple une universit, un FAI ou un partenaire commercial), il pourrait tre prt mettre en uvre un serveur-esclave pour notre compte. La gure 8-1 prsente un exemple de ce type de topologie.
a b c d e

Figure 8-1. Exemple de topologie de rseau


En suivant les conseils prcdents, on peut reprer les machines idales pour laccueil dun serveur de noms : lhte d (le serveur de chiers des htes a, b et c) ou lhte g (une machine multi-utilisateurs). Le meilleur choix est probablement lhte f (une machine multi-domicilie) ; dans ce cas, un seul serveur de noms suft. Si on veut plus dun serveur par rseau, les htes d et g peuvent convenir.

O installer les serveurs de noms ?


Il faut non seulement dterminer le nombre de serveurs, mais aussi leur position (sur des serveurs de chiers, des machines multi-domicilies, etc). Des critres comme la qualit de la connexion, le logiciel utilis (BIND ou autre), lhomognit ou la scurit des serveurs sont aussi prendre en compte : Connectivit Les serveurs de noms doivent disposer dune connectivit de grande qualit : lutilisation dune machine puissante ne prsente aucun intrt si lhte est relgu dans un sous-rseau annexe lextrmit dune liaison srie lente. Il est prfrable dopter pour une machine proche de laccs Internet du site ou de rechercher un hte distant bien connect pour accueillir un serveur-esclave. Il faut aussi essayer de placer les serveurs de noms proximit des concentrateurs.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Choisir le nombre de serveurs

169

La connexion du serveur primaire doit tre particulirement soigne : les serveurs primaires doivent pouvoir transfrer les zones vers les esclaves sans aucune difcult. Scurit An dviter quun serveur de noms dun domaine ne serve de relais des attaques contre les machines de son propre domaine ou de lInternet, il doit tre install sur une machine scurise. Il vaut mieux viter les grosses machines multi-utilisateurs sur lesquelles sont connects des utilisateurs que lon ne connat pas toujours. Les machines ddies aux services rseau en gnral et nacceptant pas les connexions des utilisateurs, sont prfrables. Si on ne dispose que de peu de machines scurit garantie, il vaut mieux leur rserver laccueil du serveur primaire, car la compromission de cette machine serait plus grave que celle dun esclave. Logiciel La meilleure solution logicielle consiste prendre un systme dexploitation dont le serveur de noms DNS bncie dune maintenance par lditeur, est issu de BIND 9.2 ou 9.3, et dont la mise en uvre de TCP/IP est robuste, de prfrence base sur Unix BSD 4.3 ou 4.4 (nous sommes des fans de Berkeley). Il est bien sr possible de compiler son propre serveur BIND 9.2 ou 9.3 partir du code-source (ce nest pas difcile et les dernires versions sont vraiment ables), mais lutilisation dun produit fourni par un diteur est un gain de temps, notamment pour la maintenance. Si BIND 9 nest pas utilisable dans votre architecture, vous pourrez contourner le problme en excutant le portage ralis par votre diteur partir dun code BIND plus ancien et bncier par la mme occasion dun support, ce qui nest pas ngligeable. Homognit Lhomognit des serveurs de noms dun domaine vite une perte de temps dans le portage de scripts dexploitation dun systme lautre ou dans la recherche de la position de nslookup ou de named.conf dun Unix lautre. Lutilisation de plusieurs versions commerciales dUnix entranera probablement lutilisation de plusieurs niveaux de version de BIND, ce qui peut poser des problmes de fonctionnalits. Si la scurit fournie par BIND 9 est ncessaire, il faut choisir une plate-forme pour laquelle BIND 9 est maintenu sur tous les systmes concerns. Bien que ces lments puissent paratre secondaires, il est bon de les avoir prsents lesprit pour oprer des choix. Il est toutefois plus important dinstaller un serveur de noms sur un rseau adquat que sur lhte parfait.

valuer la charge
Si les htes dun domaine sont trs nombreux ou si les utilisateurs gnrent de nombreuses requtes, le nombre de serveurs conseill prcdemment peut savrer insufsant pour absorber la charge. De plus, les conseils peuvent convenir un instant donn, mais le service de noms peut se dgrader dans le temps, mesure que des htes sont ajouts ou que des applications sollicitant beaucoup le DNS sont installes. Les applications suivantes interrogent massivement les serveurs de noms : le Web, le courrier lectronique (et plus particulirement les serveurs de listes de diffusion

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

170

Chapitre 8 Expansion de domaine

grande chelle), les programmes gnrant de nombreux appels de procdures distantes vers un grand nombre dhtes, certains environnements graphiques tels que X Window et ses drivs, qui interrogent le serveur de noms pour exploiter les listes de contrle daccs (access lists). Un administrateur prudent et consciencieux se demandera donc comment savoir si ses serveurs sont surchargs. Lutilisation de la mmoire est probablement laspect le plus important surveiller. named peut en utiliser une grande quantit sur les serveurs faisant autorit sur plusieurs zones. Si la taille totale de la mmoire utilise par named et les autres processus dpasse celle de la mmoire physique, la machine risque dutiliser lespace secondaire de sa mmoire virtuelle (habituellement appel swap dans le monde Unix et chier dchange dans le monde Windows) de manire importante et donc de ne plus rien excuter convenablement. Mme si la taille de la mmoire physique est amplement sufsante, les serveurs de noms BIND 4 grant de grandes zones sont lents dmarrer et se recharger. Il faut aussi surveiller la charge de lunit centrale provoque par named. Les serveurs correctement congurs ne chargeant pas excessivement le processeur, une surcharge provenant dun serveur de noms indique souvent une erreur de conguration. Un programme tel que top1 permet de dterminer le taux de charge induit par le serveur de noms. Malheureusement, aucune rgle ne prcise quelles sont les valeurs acceptables. Voici toutefois quelques indications : un taux de charge de 5% est probablement acceptable et une valeur de 10% est a priori trop leve, moins que lhte ne soit consacr exclusivement au service de noms. Voici un exemple dafchage par top pour un serveur peu charg :
last pid: 14299; load averages: 0.11, 0.12, 0.12 18:19:08 68 processes: 64 sleeping, 3 running, 1 stopped Cpu states: 11.3% usr, 0.0% nice, 15.3% sys, 73.4% idle, 0.0% intr, 0.0% ker Memory: Real: 8208K/13168K act/tot Virtual: 16432K/30736K act/tot Free: 4224K PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 89 root 1 0 2968K 2652K sleep 5:01 0.00% 0.00% named

Voici maintenant un exemple dafchage par top sur un serveur de noms occup, mais pas surcharg :
load averages: 0.30, 0.46, 0.44 system: relay 16:12:20 39 processes: 38 sleeping, 1 waiting Cpu states: 4.4% user, 0.0% nice, 5.4% system, 90.2% idle, 0.0% unk5, 0.0% unk6, 0.0% unk7, 0.0% unk8 Memory: 31126K (28606K) real, 33090K (28812K) virtual, 54344K free Screen #1/ 3 PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 21910 root 1 0 2624K 2616K sleep 146:21 0.00% 1.42% /etc/named
1. top, de Bill LeFebvre, afche en temps rel lutilisation du processeur par les processus. Il est intgr dans de nombreuses versions dUnix et de Linux. La dernire version de top est disponible sur http://www.unixtop.org/.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Choisir le nombre de serveurs

171

Un autre paramtre surveiller est le nombre de requtes reues par minute (ou seconde dans le cas dun serveur charg) par un serveur de noms. Ici non plus, il ny a pas de rgle absolue : un processeur rapide excutant FreeBSD peut probablement grer des milliers de requtes par seconde sans faiblir, alors quun vieil hte Unix peut avoir de srieuses difcults au-del de quelques requtes par seconde. Pour dterminer ce nombre, il suft dobserver les statistiques internes du serveur de noms, priodiquement crites dans syslog : le serveur peut tre congur pour gnrer les statistiques toutes les heures (cest le cas par dfaut de BIND 8). Il suft ensuite de comparer entre eux les rsultats reus toutes les heures
options { statistics-interval 60; };

BIND 9 ne dispose pas de la directive statistics-interval, mais on peut utiliser rndc pour lui demander de gnrer des statistiques toutes les heures, par exemple avec un chier crontab :
0 * * * * /usr/local/sbin/rndc stats

Il faut tre particulirement attentif aux pics de charge. Le lundi matin est souvent trs charg, car de nombreux utilisateurs rpondent massivement aux courriers reus durant le week-end. Le dbut daprs-midi est souvent charg, lui aussi, lorsque les employs reviennent en masse de leur repas. Bien sr, si lentreprise est disperse sur plusieurs fuseaux horaires, il faut utiliser son intuition pour valuer quel est le moment le plus charg. Voici un extrait de chier syslog correspondant un serveur BIND 8 :
Aug 1 11:00:49 toystory named[103]: NSTATS 965152849 959476930 A=8 NS=1 SOA=356966 PTR=2 TXT=32 IXFR=9 AXFR=204 Aug 1 11:00:49 toystory named[103]: XSTATS 965152849 959476930 RR=3243 RNXD=0 RFwdR=0 RDupR=0 RFail=20 RFErr=0 RErr=11 RAXFR=204 RLame=0 ROpts=0 SSysQ=3356 SAns=391191 SFwdQ=0 SDupQ=1236 SErr=0 RQ=458031 RIQ=25 RFwdQ=0 RDupQ=0 RTCP=101316 SFwdR=0 SFail=0 SFErr=0 SNaAns=34482 SNXD=0 RUQ=0 RURQ=0 RUXFR=10 RUUpd=34451 Aug 1 12:00:49 toystory named[103]: NSTATS 965156449 959476930 A=8 NS=1 SOA=357195 PTR=2 TXT=32 IXFR=9 AXFR=204 Aug 1 12:00:49 toystory named[103]: XSTATS 965156449 959476930 RR=3253 RNXD=0 RFwdR=0 RDupR=0 RFail=20 RFErr=0 RErr=11 RAXFR=204 RLame=0 ROpts=0 SSysQ=3360 SAns=391444 SFwdQ=0 SDupQ=1244 SErr=0 RQ=458332 RIQ=25 RFwdQ=0 RDupQ=0 RTCP=101388 SFwdR=0 SFail=0 SFErr=0 SNaAns=34506 SNXD=0 RUQ=0 RURQ=0 RUXFR=10 RUUpd=34475

Le champ RQ (en gras) contient le nombre de requtes reues. Pour calculer le nombre de requtes reues en une heure, il suft de soustraire la premire valeur RQ la seconde : 458332 458031 = 301.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

172

Chapitre 8 Expansion de domaine

Mme si le serveur est sufsamment puissant pour rpondre toutes les requtes reues, il faut sassurer que le trac li au DNS ne surcharge pas le rseau local. Sur la plupart des LAN, le trac DNS est ngligeable compar au trac global ; par contre il faut se soucier de celui qui est induit sur des liaisons loues lentes ou sur des liaisons RTC. Pour estimer le volume du trac DNS sur un LAN, on peut dterminer la bande passante utilise en multipliant la somme des requtes reues (RQ) et des rponses envoyes (SAns) en une heure, par 800 bits (les paquets DNS ont une taille moyenne de 100 octets) puis en divisant le rsultat par 3600. Cela donne une ide approximative du trac DNS sur le rseau local2. Le dernier rapport de trac NSFNET (en avril 1995) montrait que le trac DNS ne constituait que 5% du volume global (en octets) de son pine dorsale. Cette valeur a t obtenue par observation du trac et non par calcul partir de statistiques issues de serveurs de noms3. Rien nempche den faire autant sur son propre rseau local, laide dun analyseur de protocoles, si lon souhaite avoir des valeurs prcises. Si lon constate quun serveur est surcharg, il faut tout dabord regarder sil nest pas bombard de requtes par un programme fou, en recherchant lorigine de toutes les requtes. Si le serveur est en BIND 8, les statistiques indiquent quels resolvers et quels serveurs de noms linterrogent. Les statistiques sont enregistres hte par hte, ce qui permet de reprer les gros utilisateurs du serveur. Depuis BIND 8.2, ces statistiques ne sont pas conserves en standard ; pour conserver des statistiques machine par machine, il faut utiliser la directive host-statistics dans la structure options4 :
options { host-statistics yes; };

Voici un exemple :
+++ Statistics Dump +++ (829373099) Fri Apr 12 23:24:59 1996 970779 time since boot (secs) 471621 time since reset (secs) 0 Unknown query types 185108 A queries 6 NS queries 69213 PTR queries 669 MX queries 2361 ANY queries ++ Name Server Statistics ++ (Legend) RQ RR RIQ RNXD RFwdQ RFwdR RDupQ RDupR RFail RFErr
2. 3. 4. bindgraph, de Nigel Campbell, permet une analyse automatique des statistiques de BIND. Voir lURL http://www.dns.net/dnsrd/tools.html, la page des outils du rpertoire des ressources du DNS. Il nest pas certain que les valeurs actuelles soient identiques, mais il nest pas possible dobtenir des donnes quivalentes auprs des organismes commerciaux qui ont succd NSFNET. Jusquen 9.1.0, BIND 9 ne dispose, ni de la directive host-statistics, ni de la facult denregistrer des statistiques par hte.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Choisir le nombre de serveurs


RErr RTCP RAXFR RLame ROpts SSysQ SAns SFwdQ SFwdR SDupQ SFail SFErr SErr RNotNsQ SNaAns SNXD (Global) 257357 20718 0 8509 19677 19939 1494 21 0 0 0 7 0 1 0 824 236196 19677 19939 7643 33 0 0 256064 49269 155030 [15.17.232.4] 8736 0 0 0 717 24 0 0 0 0 0 0 0 0 0 0 8019 0 717 0 0 0 0 8736 2141 5722 [15.17.232.5] 115 0 0 0 8 0 21 0 0 0 0 0 0 0 0 0 86 0 1 0 0 0 0 115 0 7 [15.17.232.8] 66215 0 0 0 6910 148 633 0 0 0 0 5 0 0 0 0 58671 0 6695 0 15 0 0 66215 33697 6541 [15.17.232.16] 31848 0 0 0 3593 209 74 0 0 0 0 0 0 0 0 0 28185 0 3563 0 0 0 0 31848 8695 15359 [15.17.232.20] 272 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 272 0 0 0 0 0 0 272 7 0 [15.17.232.21] 316 0 0 0 52 14 3 0 0 0 0 0 0 0 0 0 261 0 51 0 0 0 0 316 30 30 [15.17.232.24] 853 0 0 0 65 1 3 0 0 0 0 2 0 0 0 0 783 0 64 0 0 0 0 853 125 337 [15.17.232.33] 624 0 0 0 47 1 0 0 0 0 0 0 0 0 0 0 577 0 47 0 0 0 0 624 2 217 [15.17.232.94] 127640 0 0 0 1751 14 449 0 0 0 0 0 0 0 0 0 125440 0 1602 0 0 0 0 127640 106 124661 [15.17.232.95] 846 0 0 0 38 1 0 0 0 0 0 0 0 0 0 0 809 0 37 0 0 0 0 846 79 81 -- Name Server Statistics ---- Statistics Dump --- (829373099) Fri Apr 12 23:24:59 1996

173

la suite de Global, chaque hte distant est dsign par son adresse IP entre paren, thses. La lgende indique que la premire valeur correspond RQ (Received Queries), cest--dire au nombre de requtes reues. Les htes 15.17.232.8, 15.17.232.16 et 15.17.232.94 sont responsables de 88% des requtes. Si le serveur est BIND 9, la seule mthode pour reprer les resolvers et serveurs de noms qui linterrogent de faon excessive ncessite la mise en uvre du dbogage (voir le Chapitre 13). La liste des machines qui envoient des requtes est dj signicative ; on peut aussi reprer les htes qui gnrent rptitivement des requtes et plus particulirement ceux qui demandent plusieurs fois les mmes donnes. Ces informations peuvent suggrer quun programme appelant est mal congur, ou quil contient des bogues, ou quun serveur de noms distant bombarde de requtes le serveur local. Si toutes les requtes paraissent lgitimes, il est temps dajouter un nouveau serveur de noms, en utilisant les statistiques pour dterminer le meilleur emplacement. Si le trac DNS surcharge dj la bande passante, il ne sert rien dajouter un serveur au hasard. Il faut tenir compte de lorigine des requtes. Voici quelques indications :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

174

Chapitre 8 Expansion de domaine

Reprer les requtes issues des resolvers des htes se partageant un mme serveur de
chiers. Ce dernier constitue un bon emplacement de serveur DNS.

Reprer les requtes issues des resolvers des htes multi-domicilis. Ces derniers constituent un bon emplacement de serveur DNS.

Reprer les requtes issues des resolvers des htes situs sur un autre sous-rseau. Ces
resolvers devraient utiliser un serveur situ sur le mme sous-rseau queux. Sil ny en a pas, il faut en crer un.

Reprer les requtes issues des resolvers des htes situs sur un mme commutateur.
En connectant un serveur sur ce commutateur, le trac ne sera pas diffus vers le reste du rseau.

Reprer les requtes issues de resolvers distants, accessibles travers un rseau peu
charg. Le serveur peut tre install sur ce rseau.

Ajouter des serveurs


Pour ajouter de nouveaux serveurs de noms, le plus simple est de crer des serveursesclaves, ce qui a t dcrit au Chapitre 4. Toutefois, lajout inconsidr de serveursesclaves peut conduire des problmes. Si les serveurs-esclaves dune zone sont trop nombreux, le serveur de noms primaire peut se retrouver ponctuellement surcharg par les tests de synchronisation issus des serveurs-esclaves. Plusieurs moyens permettent de rsoudre ce genre de problmes :

Cration de plusieurs matres primaires. Pour certains esclaves, chargement de leur zone partir dautres esclaves. Cration de serveurs cache. Cration desclaves partiels .

Serveurs-matres primaires et serveurs-esclaves


La cration de plusieurs serveurs de noms primaires implique plus de travail de maintenance, car la synchronisation de /etc/named.conf et des chiers de zone doit se faire manuellement. Si cela est toutefois ncessaire, des outils comme rdist ou rsync5 simplient le mcanisme de distribution des chiers. Voici un exemple de chier distle6 de synchronisation de deux serveurs de noms primaires :
dup-primary: # copie du fichier named.conf vers le second serveur primaire /etc/named.conf -> wormhole install ; # copie du contenu de /var/named (fichiers de zone...) # vers le second serveur primaire
5. 6. rsync est un programme de synchronisation qui ne transmet que les diffrences entre chiers. Il est dcrit sur http://rsync.samba.org. La commande rdist lit le chier distle pour savoir quels chiers mettre jour.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Ajouter des serveurs

175

/var/named -> wormhole install ;

ou de plusieurs serveurs primaires :


dup-primary: primaries = ( wormhole carrie ) /etc/named.conf -> {$primaries} install ; /var/named -> {$primaries} install ;

On peut aussi indiquer aux serveurs de recharger leur conguration en utilisant loption special de rdist :
special /var/named/* "rndc reload" ; special /etc/named.conf "rndc reload" ;

Cette option indique rdist dexcuter la commande entre guillemets si le chier indiqu change sur le serveur cible. Certains serveurs-esclaves peuvent aussi tlcharger leur zone partir dautres serveursesclaves plutt qu partir dun serveur-matre primaire. Dans ce cas, le serveur-esclave na aucun moyen de savoir sil tlcharge la zone partir dun serveur primaire ou dun autre esclave. Il suft que le serveur rpondant la demande de transfert de zone soit un serveur faisant autorit sur la zone. La mise en uvre est simple : au lieu dindiquer ladresse IP du serveur primaire dans le chier de conguration de lesclave, on indique ladresse dun autre serveur-esclave. Voici le chier named.conf correspondant :
// cet esclave se synchronise partir de wormhole, un autre esclave zone "movie.edu" { type slave; masters { 192.249.249.1; }; file "bak.movie.edu"; };

Lutilisation dun serveur-esclave intermdiaire peut conduire doubler le dlai de propagation entre le serveur primaire et tous les esclaves. Souvenons-nous que lintervalle de rafrachissement dtermine la frquence laquelle un serveur-esclave doit tester la validit de la zone. Par consquent, il peut scouler une priode complte avant que le serveur-esclave intermdiaire ne se soit synchronis avec le serveur-matre primaire, puis une nouvelle priode complte avant que le serveur-esclave nal ne se soit synchronis avec le serveur-esclave intermdiaire. Par consquent, le temps de propagation du matre primaire jusqu tous les esclaves peut tre du double de lintervalle de rafrachissement. La fonction NOTIFY permet dviter ce dlai de propagation. Cette fonction, active par dfaut, permet de dclencher rapidement des transferts de zone aprs une mise jour de la zone sur le matre primaire. La fonction NOTIFY sera dcrite en dtail au Chapitre 10.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

176

Chapitre 8 Expansion de domaine

En cas de mise en uvre de serveurs-esclaves intermdiaires, il faut faire attention ne pas crer de boucles. Si wormhole est congur pour se synchroniser sur monsters-inc, et que monsters-inc est congur pour se synchroniser sur wormhole, aucun des deux ne chargera jamais les donnes du serveur primaire. Ils testeront mutuellement leur numro de srie et tous deux concluront linni quils sont jour.

Serveur cache
Un serveur cache constitue une autre alternative lors de lajout de serveurs. Ce sont des serveurs qui ne font autorit sur aucune zone (sauf sur 0.0.127.in-addr.arpa). Le nom de ces serveurs ne signie pas quils soient les seuls disposer dune mmoire cache (les serveurs primaires et les serveurs-esclaves en ont aussi) mais que cest la seule fonction quils mettent en uvre : ils recherchent des donnes pour le compte de resolvers et les placent dans leur mmoire cache. Tout comme pour les autres types de serveur, ils ont besoin dun chier dindications sur les serveurs de la racine et dun chier db.127.0.0. Le chier named.conf dun serveur cache contient les lignes suivantes :
options { directory "/var/named"; // ou tout autre rpertoire de travail }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; }; zone "." { type hint; file "db.cache"; };

Un serveur cache peut interroger les serveurs de noms de tout domaine, tout comme le font les serveurs primaires ou les serveurs-esclaves. La diffrence est que lorsquun serveur cache recherche un nom pour la premire fois dans une zone, il nit obligatoirement par interroger le matre primaire ou un esclave de la zone, car il ne dispose daucune donne en local. Pour toute recherche de noms, il doit obtenir lidentit des serveurs dune zone auprs des serveurs de son domaine parent, car il nest pas possible damorcer la mmoire cache dun serveur cache avec lidentit du matre primaire ou des esclaves, notamment laide du chier db.cache qui sert dcouvrir lidentit des serveurs de la racine. De plus, il est prfrable dobtenir la liste des serveurs faisant autorit auprs des serveurs de la zone parente car cela permet de tester la dlgation (le maintien dans la zone dune liste des serveurs faisant autorit pourrait poser des problmes de mise jour). Lutilit dun serveur cache apparat lorsque sa mmoire cache commence se remplir. chaque fois que le serveur cache interroge un serveur faisant autorit et quil obtient une rponse, il place lenregistrement correspondant dans sa mmoire cache. Peu peu, la mmoire cache grossit et contient les informations les plus demandes par les resolvers qui interrogent le serveur cache. De plus, comme les serveurs cache nont pas besoin de se synchroniser, il ny aucune charge induite par un transfert de zone.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Ajouter des serveurs

177

Serveurs-esclaves partiels
Il existe une notion intermdiaire entre serveur cache et serveur-esclave : le serveursecondaire partiel (nous sommes probablement les seuls lappeler de cette manire) qui est esclave uniquement pour une partie de la zone locale. Supposons que movie.edu soit constitu de vingt rseaux de taille /24 (lancienne classe C) ainsi que des vingt zones correspondantes dans in-addr.arpa. Plutt que de crer un serveur-esclave pour les 21 zones (tous les sous-domaines de in-addr.arpa plus movie.edu), on pourrait crer un serveur-esclave partiel pour movie.edu et les seules zones de in-addr.arpa contenant le serveur-esclave partiel lui-mme. Si le serveur a deux interfaces rseau, il devrait tre esclave pour trois zones : movie.edu et deux zones de in-addr.arpa. Par exemple, lhte zardoz.movie.edu dispose de deux interfaces rseau dadresses IP 192.249.249.9 et 192.253.253.9. zardoz peut donc hberger un serveur-esclave partiel dont le chier de conguration named.conf contient :
options { directory "/var/named"; }; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; }; zone "249.249.192.in-addr.arpa" { type slave; masters { 192.249.249.3; }; file "bak.192.249.249"; }; zone "253.253.192.in-addr.arpa" { type slave; masters { 192.249.249.3; }; file "bak.192.253.253"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; }; zone "." { type hint; file "db.cache"; };

Ce serveur est esclave pour la zone movie.edu et pour seulement 2 des 20 zones correspondantes de in-addr.arpa. Le chier named.conf dun serveur-esclave complet contiendrait 21 dclarations diffrentes de zone.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

178

Chapitre 8 Expansion de domaine

Les serveurs-esclaves partiels sont faciles grer car leur chier named.conf nvolue gure dans le temps, alors que sur un serveur faisant autorit sur la totalit des zones de in-addr.arpa, il faudrait modier chaque serveur-esclave en cas dvolution du rseau (ajout ou suppression de zones), une tche consquente pour un gros rseau. Un serveur-esclave partiel peut directement rpondre la plupart des requtes quil reoit, car la plupart de ces requtes concernent la zone movie.edu et les deux zones de in-addr.arpa. En effet, la plupart des htes qui interrogent le serveur sont connects lun des deux rseaux 192.249.249 ou 192.253.253, et il est probable que ces htes communiquent avant tout entre eux. Les requtes de donnes dans in-addr.arpa correspondent donc au rseau local.

Enregistrer des serveurs


Lenregistrement de la totalit des serveurs primaires et esclaves dun domaine dans la zone parente nest pas indispensable. Seuls les serveurs qui doivent rpondre aux requtes des serveurs dautres zones ont besoin dtre ofcialiss. tudions le cas dune zone possdant neuf serveurs dont seulement quatre sont dclars dans la zone parente (gure 8-2). Les neuf serveurs sont utilisables lintrieur de la zone. Cinq dentre eux ne seront consults que par des resolvers explicitement congurs pour les interroger ( laide du chier resolv.conf, par exemple). Les serveurs parents ne leur dlgueront jamais de responsabilit, puisquils ne connaissent pas leur existence. Seuls les quatre serveurs ofciels sont interrogs par dautres serveurs de noms, y compris les serveurs cache et les serveurs-esclaves partiels.

requtes provenant de serveurs

Serveurs de noms
dclars non dclars

Machines

requte provenant dun serveur requte provenant dun resolver

serveur faisant autorit

serveur cache

Figure 8-2. Enregistrement dune partie des serveurs de noms


[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Enregistrer des serveurs

179

Le nombre de serveurs enregistrs est limit, non seulement par ltendue des ressources que lon accepte de consacrer au service des requtes externes, mais aussi par une limite physique, due au nombre de serveurs que lon peut indiquer dans un paquet de rponse UDP On peut y placer une dizaine denregistrements de ressource NS, en . fonction du nombre de domaines contenant les serveurs7. De toutes faons, lenregistrement de plus de 10 serveurs naurait probablement pas beaucoup de sens : si aucun des 10 serveurs nest accessible, il y a de fortes chances que lensemble du rseau soit totalement inaccessible. Si lon veut enregistrer un nouveau serveur faisant autorit (un serveur qui possde une copie des chiers de zone), il faut contacter les administrateurs de chacune de ses zones parentes. Par exemple, si on veut ofcialiser le serveur zardoz, il faut contacter les administrateurs des zones edu et in-addr.arpa (pour savoir qui gre une zone parente, consultez le Chapitre 3). Avant de contacter les administrateurs dune zone parente, il faut suivre les procdures disponibles, si elles existent, sur le site web de la zone parente. Sinon, il faut fournir le nom de la zone sur laquelle le nouveau serveur fait autorit. Si ce serveur est dans la nouvelle zone, il faut galement fournir son adresse IP Bien quil ny ait aucun format . normalis pour soumettre ces informations, il est bon de fournir la liste complte des serveurs ofciels de la zone, accompagne de leurs adresses, de prfrence au format des chiers de zone, ce qui vite de possibles confusions. tant donn que les rseaux de notre exemple ont t initialement attribus par lInterNIC, nous utilisons le formulaire Network Modication sur http://www.arin.net/ library/templates/netmod.txt pour modier lenregistrement. En labsence de formulaire standard, on peut envoyer un message de demande (en anglais) ladministrateur de inaddr.arpa :
Bonjour, Nous venons de mettre en uvre un nouveau serveur de noms sur lhte zardoz.movie.edu pour les zones 249.249.192.in-addr.arpa et 253.253.192.in-addr.arpa. Pourriez-vous ajouter les enregistrements NS correspondants la zone in-addr.arpa de manire obtenir la dlgation dautorit suivante ? 253.253.192.in-addr.arpa. 86400 IN NS toystory.movie.edu. 253.253.192.in-addr.arpa. 86400 IN NS wormhole.movie.edu. 253.253.192.in-addr.arpa. 86400 IN NS zardoz.movie.edu. 249.249.192.in-addr.arpa. 86400 IN NS toystory.movie.edu. 249.249.192.in-addr.arpa. 86400 IN NS wormhole.movie.edu. 249.249.192.in-addr.arpa. 86400 IN NS zardoz.movie.edu. Merci davance. Cordialement, Albert LeDomaine - al@movie.edu

7.

Les noms des serveurs de la racine de lInternet ont t changs pour cette raison : tous les serveurs ont t dplacs dans le mme domaine, root-servers.net, pour tirer parti de la compression de noms et, de cette manire, pouvoir indiquer un maximum de serveurs de la racine dans un unique paquet UDP .

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

180

Chapitre 8 Expansion de domaine

Les enregistrements NS ont des TTL explicites car les serveurs parents du domaine ne font pas autorit sur ces enregistrements, la diffrence des serveurs de noms du domaine. En prcisant les valeurs de TTL, ladministrateur du domaine indique son propre choix pour sa zone, car les administrateurs du domaine parent pourraient avoir une autre politique de gestion. Un enregistrement A de recolage pour chacun des serveurs de noms nest pas ncessaire, puisque les noms des serveurs ne sont pas dans les zones in-addr.arpa. Ils sont situs dans la zone movie.edu, ce qui fait quun serveur faisant rfrence toystory.movie.edu ou wormhole.movie.edu peut trouver leur adresse en suivant la dlgation vers les serveurs de movie.edu. Lenregistrement dun serveur partiel nest pas souhaitable, car ce dernier ne fait autorit que sur une fraction des zones in-addr.arpa. Du point de vue de la gestion, il est plus simple denregistrer uniquement des serveurs faisant autorit sur la totalit dune zone, ce qui vite davoir grer une liste de correspondance entre les serveurs partiels et les fractions de zone correspondantes. De cette manire, toutes les zones parentes peuvent dlguer lautorit au mme ensemble de serveurs : le matre primaire et les esclaves complets. Toutefois, si le nombre de serveurs est faible, il peut tre facile de se souvenir de la zone dautorit de chaque serveur et on peut alors se permettre denregistrer des serveurs partiels. Un serveur cache ne devra jamais tre enregistr. En effet, il na que rarement des informations compltes sur lensemble dune zone ; il ne dispose que des informations quil a rcemment recherches. Si un serveur parent indiquait un serveur distant dinterroger un serveur cache, le serveur distant enverrait une requte non rcursive au serveur cache. Ce dernier pourrait trs bien connatre la rponse comme ne pas la connatre8. Dans ce dernier cas, le serveur cache rpondrait en fournissant la liste des serveurs les mieux placs, qui contient le serveur cache lui-mme. Ainsi, le serveur distant nobtiendrait jamais de rponse sa question. Ce type de conguration (la dlgation dune zone un serveur ne faisant pas autorit sur la zone) sappelle une mauvaise dlgation (lame delegation).

Ajuster les valeurs de TTL


Un administrateur expriment doit savoir comment rgler au mieux le TTL de ses zones. Le TTL dun enregistrement de ressources est la dure de maintien de lenregistrement dans la mmoire cache dun serveur. Le TTL est exprim en secondes. Si le TTL dun enregistrement est de 3600 secondes et quun serveur hors du rseau a mmoris cet enregistrement dans sa mmoire cache, ce serveur devra effacer lenregistrement au bout dune heure. Sil a nouveau besoin de la mme information, il devra effectuer une nouvelle recherche. Le choix dune valeur de TTL permet dimposer une politique sur la dure de vie des donnes aux autres serveurs. Cette politique a un impact sur la charge des serveurs du
8. Plus grave encore : mme si le serveur cache dispose de linformation, il prcisera quil ne fait pas autorit. Le serveur qui a pos la question, et qui pense sadresser un serveur faisant autorit, ignorera la rponse.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Ajuster les valeurs de TTL

181

domaine : un TTL faible signie que les serveurs distants devront interroger plus souvent les serveurs locaux. Les valeurs de TTL peuvent tre modies au cours du temps et les administrateurs expriments les ajusteront priodiquement. Supposons que lhte grant la vidothque de movie.edu doive tre dplac vers un autre rseau. Cet hte fournit un service toute la communaut de lInternet. Lors doprations normales, les serveurs extrieurs au domaine conservent ladresse de lhte dans leur mmoire cache en accord avec le TTL indiqu, soit par la directive $TTL, soit dans lenregistrement SOA pour les serveurs antrieurs BIND 8.2. Dans lexemple, le TTL de movie.edu a t x trois heures. Un serveur plaant lancien enregistrement dadresse dans sa mmoire cache juste avant la modication va conserver la mauvaise information durant trois heures, ce qui peut produire une inaccessibilit du service. Pour minimiser cette gne, on peut pralablement rduire le TTL an que les serveurs distants ne conservent que peu de temps un enregistrement dadresse. En diminuant le TTL, on force les serveurs externes mettre jour leurs donnes plus souvent. De cette manire, toutes les modications effectues seront propages plus rapidement. Malheureusement, on ne peut pas xer le TTL zro, ce qui indiquerait de ne placer aucun enregistrement en mmoire cache, car certaines vieilles versions de BIND 4 ne peuvent pas renvoyer denregistrement avec un TTL nul et renvoient alors des rponses nulles ou des erreurs SERVFAIL. Par contre, les petites valeurs de TTL (30 secondes par exemple), ne posent aucun problme. La mthode la plus simple consiste modier la structure de contrle $TTL dans le chier db.movie.edu. Si un enregistrement de ressource autre que le SOA ne comporte pas de TTL explicite, le serveur utilise le TTL par dfaut pour cet enregistrement spcique. En rduisant la valeur du TTL par dfaut, la nouvelle valeur de TTL sapplique tous les enregistrements dadresse et pas seulement celui concernant lhte qui va tre dplac. La consquence de cette approche est que le serveur va devoir rpondre plus de requtes que dordinaire. Par consquent, il vaut mieux ne diminuer le TTL que sur lenregistrement modi. Pour ajouter une valeur de TTL explicite dans un enregistrement de ressource, il faut la placer devant IN du champ class. La valeur de TTL est en secondes en standard, mais on peut aussi prciser des units (m pour minutes, h pour heures, d pour jours et w pour semaines) sous la mme forme que dans la structure de contrle $TTL. Voici un exemple de TTL explicite pour db.movie.edu :
cujo 1h IN A 192.253.253.5 ; TTL explicite fix 1 heure

Un serveur-esclave renvoie les mmes valeurs de TTL quun serveur-matre primaire. Lesclave ne tient pas compte du temps coul depuis le dernier chargement de zone pour dcrmenter le TTL. Par consquent, si le TTL dun enregistrement est rduit une valeur infrieure au minimum, les serveurs primaires et esclaves fourniront cette valeur rduite. Si un esclave a atteint la limite de validit de la zone, il met la totalit de la zone hors service ; il ninvalide jamais isolment un enregistrement de ressource. BIND permet donc de xer explicitement le TTL de chaque enregistrement de ressource en fonction des besoins de modication des informations. Malheureusement, peu dadministrateurs protent de cette possibilit, ce qui occasionne des pertes de connectivit pendant quelque temps.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

182

Chapitre 8 Expansion de domaine

Heureusement, les htes qui bougent beaucoup sont rarement des machines-cl dun domaine, ce qui occasionne peu de perturbation. Par contre, le dplacement et linaccessibilit dun changeur de messagerie, dun serveur web ou dun serveur ftp durant une journe est inacceptable. Si lon souhaite changer leur adresse, il faut anticiper lopration en rduisant le TTL sur leurs enregistrements. Attention, la valeur de TTL doit tre diminue bien avant le changement de ladresse : il ne faut pas rduire simultanment le TTL et modier linformation, car il se pourrait que lenregistrement dadresse vienne dtre stock dans la mmoire cache dun serveur distant et il serait valide tant que le TTL dorigine ne se serait pas coul. Il faut aussi tenir compte de la frquence de synchronisation des serveurs-esclaves. Si le TTL minimal est de 12 heures et que lintervalle de rafrachissement est de 3 heures, il faut rduire le TTL au moins 15 heures avant la modication dadresse, de manire ce que les enregistrements associs lancien long TTL soient arrivs expiration. Bien sr, si tous les serveurs savent utiliser la fonction NOTIFY, il ne faudra plus tenir compte de la dure de synchronisation.

Modier les autres champs dun SOA


Nous avons dj parl de lajustement de lintervalle de rafrachissement dans le cadre de la matrise de la charge dun serveur primaire. Nous allons maintenant en discuter plus en dtail, ainsi que des autres valeurs de lenregistrement SOA. Lintervalle de rafrachissement (refresh) indique un serveur-esclave la priodicit de test de validit de sa zone. La priodicit de nouvel essai (retry) prend la relve ds le premier chec de contact avec un serveur-matre. La dure avant expiration (expire) indique la dure maximale de maintien des donnes lorsquun matre est inaccessible. Enn, sur les serveurs antrieurs BIND 8.2, le TTL minimal indique combien de temps des informations peuvent tre conserves en mmoire cache. Avec les versions rcentes de BIND, le dernier champ du SOA indique la dure de validit dune rponse ngative. Pour quun esclave vrie sa validit toutes les heures, il faut initialiser lintervalle de rafrachissement une heure dans tous les chiers de zone (ou utiliser loption -o de la commande h2n). Puisque la priodicit de nouvel essai est lie lintervalle de rafrachissement, il faut adapter cette priodicit, par exemple 15 minutes. La priodicit de nouvel essai est habituellement infrieure lintervalle de rafrachissement, mais ce nest pas une obligation9. La diminution de lintervalle de rafrachissement permet de rduire le dlai de propagation des modications vers les serveurs-esclaves, mais elle augmente la charge du matre, puisque les esclaves le contactent plus souvent. La charge additionnelle nest pas phnomnale ; chaque esclave effectue une seule requte de SOA par intervalle de rafrachissement pour vrier la validit de ses donnes. Par consquent, avec seulement deux serveurs-esclaves, un intervalle de rafrachissement gal une heure ne produit que quatre requtes de SOA (par zone) vers le serveur primaire de plus quavec un intervalle de trois heures. Si tous les esclaves utilisent BIND 8 ou 9 et que la directive NOTIFY est mise en uvre, la porte de lintervalle de rafrachissement est moindre. Mais sil y a au moins un esclave en BIND 4, la valeur de lintervalle est fondamentale.
9. Les serveurs BIND 8 prviennent ladministrateur si lintervalle de rafrachissement est infrieur au dixime de la priodicit de nouvel essai.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Anticiper les pannes

183

Par ailleurs, certaines versions de BIND peuvent aussi se synchroniser plus souvent que lintervalle de rafrachissement. Toutes les versions rcentes de BIND (depuis la 4.9) attendent un temps alatoire compris entre la moiti (pour BIND 8) ou les trois-quarts (pour BIND 9) et la totalit de lintervalle de rafrachissement avant de tester les numros de srie. Une dure avant expiration dune semaine, voire plus sil est difcile de contacter le serveur-matre, est une valeur normale. Cette dure doit toujours tre trs suprieure lintervalle de rafrachissement et la priodicit de nouvel essai ; si la dure avant expiration est infrieure lintervalle de rafrachissement, les esclaves abandonnent les informations avant de tenter une synchronisation. BIND 8 se plaint si la dure avant expiration est infrieure la somme de lintervalle de rafrachissement et de la priodicit de nouvel essai, infrieure au double de la priodicit de nouvel essai, infrieure sept jours ou suprieure six mois (BIND 9 ne se plaint pas pour le moment). Un choix rpondant tous les critres de BIND 8 conviendra la plupart des situations. Si les informations changent peu, il est intressant daugmenter le TTL par dfaut. On utilise souvent un TTL de un jour. Un TTL gal une semaine semble tre la valeur maximale qui ait encore un sens pour une dure de vie. Au-del, il devient difcile de mettre jour dans un temps raisonnable des informations errones et dj enregistres dans une mmoire cache.

Anticiper les pannes


Un rseau nit toujours par tomber en panne : dfaillances matrielles, bogues dans les logiciels, erreurs humaines. Les consquences peuvent tre mineures (perte de connexion pour quelques utilisateurs), mais elles sont parfois catastrophiques (perte de donnes importantes ou de travaux fondamentaux). Puisque le DNS sappuie fortement sur les rseaux, il est particulirement vulnrable aux ruptures de connexion. Heureusement, sa conception prend en compte les imperfections du rseau : il autorise des serveurs de noms multiples et redondants, des redirections de requtes, des tentatives multiples de chargement de zone, etc. Le DNS ne peut pas se protger tout seul contre toutes les calamits, mais avec un minimum dinvestissement, on peut minimiser limpact des problmes.

Interruptions de service
Les coupures dlectricit sont monnaie courante. Dans certaines rgions des USA, les temptes et tornades peuvent conduire lisolement dun site pendant de longues dures. dautres endroits, des typhons, des volcans ou des travaux peuvent provoquer des coupures lectriques. Et en Californie, on ne peut jamais savoir si on ne va pas tre victime dun dlestage en raison dun manque de capacit de production lectrique. Si tous les htes dun domaine sont arrts, le service de noms est inutile. Les problmes surgissent au retour de llectricit. Les serveurs de noms sont souvent installs sur de grosses machines de service qui sont parfois les dernires redmarrer (elles doivent franchir avec succs de nombreuses tapes telles que lexcution de fsck sur les disques). Les machines redmarrage rapide doivent donc pouvoir dmarrer en labsence du service de noms.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

184

Chapitre 8 Expansion de domaine

Cela est une source de difcults et dpend de la manire dont sont crits les chiers de dmarrage. Les htes Unix excutent souvent une variante de :
/usr/sbin/ifconfig lan0 inet `hostname` netmask 255.255.128.0 up /usr/sbin/route add default site-router 1

pour dmarrer leur interface de rseau et initialiser une route par dfaut. Lutilisation de noms dhtes dans les commandes (`hostname` est remplac par le nom local de lhte et site-router est le nom du routeur local) est intressante car elle permet un administrateur de modier les adresses IP des quipements sans devoir mettre jour les chiers de dmarrage. Malheureusement, lexcution de la commande route choue en labsence dun service de noms. Il en est de mme pour la commande ifcong si le nom local et ladresse IP napparaissent pas dans le chier /etc/hosts. Il faut donc initialiser au moins ces informations dans le chier /etc/hosts de chaque hte. Au moment o la squence de dmarrage excute la commande route, lhte essaie dutiliser un service de noms pour associer le nom du routeur son adresse IP Puisque . lhte na pas de route par dfaut tant que la commande route na pas encore t excute, les seuls serveurs de noms joignables ce moment-l sont ceux situs sur le mme rseau que lhte. Si lhte en cours de dmarrage peut contacter un serveur de noms sur le mme rseau, il peut excuter la commande route avec succs. Dans la situation qui nous intresse ici, ces serveurs de noms ne sont pas encore disponibles. Ce quil advient dpend du contenu du chier resolv.conf. Avec BIND, le resolver naboutit la consultation de la table locale que si un seul serveur de noms est dsign dans resolv.conf (ou si aucun serveur de noms nest dsign et que le resolver consulte par dfaut un serveur de noms situ sur lhte local). Si un seul serveur de noms est dni, le resolver linterroge, et si le rseau renvoie une erreur chaque expdition de requte, le resolver consulte la table locale. Les erreurs pouvant gnrer cette situation sont :

la rception dun message ICMP port unreachable ; la rception dun message ICMP network unreachable ; limpossibilit denvoyer un paquet UDP (par exemple en raison dune pile rseau
pas encore active sur lhte local)10. Si le serveur de noms dsign est totalement inaccessible, le resolver ne reoit aucune erreur ; le serveur se comporte comme un trou noir. Aprs environ 75 secondes dessais, le resolver renvoie une rponse nulle lapplication qui a demand une rsolution de nom. Par contre, si lhte hbergeant le serveur de noms est accessible mais que la fonction de service de noms nest pas encore active, le resolver reoit un message ICMP port unreachable. En gnral, la conguration o un seul serveur est dni dans resolv.conf, fonctionne sil y a un serveur de noms disponible sur chaque rseau, mais ce nest pas trs lgant. Si le serveur de noms local na pas ni de dmarrer lorsquun hte de son rseau redmarre, la commande route choue.
10. Consultez le Chapitre 6 pour prendre connaissance des spcicits des diffrentes versions commerciales.
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Anticiper les pannes

185

Il en va diffremment si plusieurs serveurs de noms sont dnis dans resolv.conf. Dans ce cas, BIND naboutit jamais la consultation de la table locale aprs linitialisation de linterface rseau primaire par ifcong. Le resolver interroge cycliquement les serveurs de noms jusqu une rponse ou jusqu lcoulement du temps dattente maximal de 75 secondes. Ceci ne pose problme que durant la squence de dmarrage : si aucun des serveurs dsigns ne rpond, le resolver atteint le temps dattente maximal et choue dans lacquisition de la route par dfaut.

Recommandations
Nous recommandons de placer ladresse IP du routeur par dfaut (et non pas son nom), dans le chier de dmarrage ou, comme sur certains systmes, dans un chier externe tel que /etc/defaultrouter. Cela permettra de garantir le dmarrage. On peut aussi ne dsigner, dans resolv.conf, quun unique serveur de noms condition quil soit particulirement able et situ sur le rseau local. Cela permet dutiliser le nom du routeur par dfaut dans le chier de dmarrage, condition que le nom de ce routeur apparaisse avec son numro IP dans /etc/hosts, au cas o le serveur de noms ne serait pas encore actif au moment du dmarrage. Certaines versions spciques de BIND permettent de prciser lordre dinterrogation des sources dinformation ; dautres utilisent /etc/hosts si le DNS ne fournit pas de rponse. Dans le premier cas, on peut rgler le resolver pour quil interroge en premier lieu un /etc/hosts minimal. Dans tous les cas, il faut initialiser un chier /etc/hosts minimal sur chaque hte, contenant le nom de lhte ainsi que le routeur par dfaut. Il y a toutefois quelques risques utiliser un chier /etc/hosts : moins que vous ne fassiez attention le maintenir bien jour, linformation quil contient peut devenir obsolte. Leur mise jour serait une excellente tche pour rsync. Que se passe-t-il si la route par dfaut est correctement initialise mais que les serveurs de noms continuent ne pas rpondre ? Cela peut perturber sendmail (qui ne fera pas de canonisation correcte des noms) ou NFS (dont les montages peuvent chouer). Un serveur de noms devrait en fait tre install sur un hte branch un onduleur quip de batteries, ce qui sufra si les coupures sont rares. Si les coupures durent trop longtemps et que le service de noms est une application critique, il faudra envisager linstallation dun groupe lectrogne. Si cela nest pas possible, il faut reprer lhte le plus rapide dmarrer et y installer le serveur de noms. Les htes utilisant des systmes de chiers avec journalisation sont dans ce cas, car il nexcutent pas la commande fsck. Les htes possdant de petits systmes de chiers sont eux aussi rapides dmarrer. Une fois que lhte adquat est identi, il faut que son adresse IP soit inscrite dans la conguration du resolver de chaque hte ayant besoin dun service de noms permanent. On indiquera en gnral les serveurs de secours en dernier, puisquen fonctionnement normal, les clients utiliseront le serveur de noms le plus proche. Ainsi, en cas de coupure lectrique, les applications critiques pourront encore atteindre le service de noms, au prix dun lger sacrice en performances.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

186

Chapitre 8 Expansion de domaine

Traiter les pannes


Quand une catastrophe frappe, il vaut mieux savoir lavance comment ragir. Si vous savez quen cas de tremblement de terre, vous devez vous cacher sous une table ou un bureau, vous viterez peut-tre de vous retrouver coinc sous un cran dordinateur qui se serait effondr. Si vous savez comment teindre le gaz, vous viterez peut-tre un incendie la maison. De mme, si vous savez comment ragir en cas de catastrophe dans le rseau (ou mme en cas dincident mineur), vous parviendrez peut-tre maintenir votre rseau en fonctionnement. Vivant en Californie, nous avons une certaine exprience de ce sujet, ainsi que quelques suggestions.

Interruptions de longue dure ( jours)


Avec des interruptions longues, les serveurs peuvent rencontrer des problmes. Sils perdent longtemps la connectivit vers les serveurs de la racine, ils cessent de rsoudre les requtes ne concernant pas la zone sur laquelle ils font autorit. Si les serveursesclaves ne peuvent pas contacter leur serveur-matre, ils nissent mme par faire expirer leur propre zone. Pour dpanner, un chier /etc/hosts temporaire peut tre mis en place. Dans la plupart des cas, il faudra renommer resolv.conf (en resolv.bak), arrter le serveur de noms local (sil y en a un) et utiliser /etc/hosts. Ce nest pas instantan, mais cela peut tre utile. On peut aussi transformer temporairement un serveur-esclave qui ne peut pas contacter son matre, en serveur primaire, en modiant named.conf et en remplaant le type de serveur (slave) dans la structure zone par le nouveau type (master). Si plus dun esclave de la mme zone sont isols du reste du monde, on peut en congurer temporairement un en serveur primaire et indiquer aux autres de se synchroniser sur ce nouveau matre.

Interruptions de trs longue dure (semaines)


Si une trs longue interruption isole une zone de lInternet, il est ncessaire de rtablir articiellement la connectivit vers les serveurs de la racine. Tout serveur est amen priodiquement contacter un serveur de la racine. Pour cela, il faut crer temporairement ses propres serveurs de la racine, quil faudra supprimer ds le rtablissement de la connexion dorigine. Les serveurs annonant quils sont serveurs de la racine alors quil ne connaissent pas grand chose sur les domaines de niveau suprieur, sont une des plus grandes abominations de lInternet. Les serveurs congurs pour interroger une mauvaise liste de serveurs de la racine sont aussi source de graves problmes. Cela dit, voici ce quil y a faire pour congurer son propre serveur de la racine. Crez dabord un chier db.root (le chier de la zone racine) qui dlguera lautorit aux zones de plus haut niveau du rseau isol. Par exemple, si movie.edu est isol du reste de lInternet, il faut crer le chier db.root suivant pour toystory :
$TTL 1d . IN SOA toystory.movie.edu. al.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Traiter les pannes


1h 1w 1h ) ; nouvel essai aprs 1 heure ; expiration aprs 1 semaine ; TTL rponse ngative d1 heure

187

IN NS toystory.movie.edu. ; toystory est la racine temporaire. ; Le serveur de la racine ne connat que movie.edu et ; les deux domaines in-addr.arpa. movie.edu. IN NS toystory.movie.edu. IN NS wormhole.movie.edu. 249.249.192.in-addr.arpa. IN NS toystory.movie.edu. IN NS wormhole.movie.edu. 253.253.192.in-addr.arpa. IN NS toystory.movie.edu. IN NS wormhole.movie.edu. toystory.movie.edu. wormhole.movie.edu. IN A 192.249.249.3 IN A 192.249.249.1 IN A 192.253.253.1

Il faut ensuite ajouter les lignes suivantes au chier named.conf de toystory :


// On suspend les indications sur la zone racine. // zone . { // type hint; // file "db.cache"; // }; zone "." { type master; file "db.root"; };

Sur tous les serveurs de noms (hormis le nouveau serveur temporaire de la racine), il faut ensuite installer un chier db.cache qui inclut le nouveau serveur temporaire de la racine (le mieux est de renommer lancien chier de cache, an de le retrouver lors du retour en conguration normale). Voici le contenu du chier db.cache :
. 99999999 IN NS toystory.movie.edu. toystory.movie.edu. 99999999 IN A 192.249.249.3

Cela rendra oprationnelle la rsolution de noms dans movie.edu durant linterruption de connexion. Une fois cette connexion rtablie, il faudra dtruire la nouvelle structure zone et rtablir les indications sur la zone racine dans le chier named.conf de toystory ainsi que le chier cache dorigine sur les autres serveurs de noms.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

9
Gestion de sous-domaines
Pour dbarbouiller ses enfants, Dinah sy prenait de la faon suivante : dabord elle plaquait le pauvre petit animal au sol en lui appuyant une patte sur loreille ; puis, de lautre patte, elle lui frottait rebrousse-poil toute la figure, en commenant par le bout du nez. Or, au moment qui nous occupe, comme je viens de le dire, elle tait en train de sescrimer de toutes ses forces sur la minette blanche, qui restait allonge parfaitement immobile, et sessayait ronronner (comprenant sans nul doute que tout cela tait pour son bien).

Lorsquun domaine devient trop grand ou lorsque lon dcide de rpartir sa gestion entre plusieurs entits, il est ncessaire de le diviser en sous-domaines. Ceux-ci deviennent les enfants du domaine courant dans lespace de noms, le domaine courant tant le parent. La responsabilit des sous-domaines tant dlgue, chaque sous-domaine dispose de sa propre zone, diffrente de la zone parente. Une bonne gestion des sous-domaines comprend le dcoupage du domaine, le choix du nom des sous-domaines et la dlgation ces sous-domaines pour crer de nouvelles zones. Comme tout parent responsable, le domaine parent sassure en permanence de la prennit des liens entre sa zone et celles de ses enfants. En raison de limportance du service de noms pour la navigation entre sites, cette bonne gestion est fondamentale pour le fonctionnement correct du rseau. Une dlgation incorrecte vers des serveurs de noms peut conduire linaccessibilit dun site alors que la perte de connectivit vers les serveurs de la zone parente peut empcher les htes dun site de contacter tout hte situ lextrieur de la zone. Il sagit ici de prsenter notre point de vue sur la cration de sous-domaines et de dcrire en dtail les moyens dy parvenir. Il sera question de la gestion des relations entre parents et enfants et de la gestion du processus de dcoupage dun grand domaine en petits sous-domaines, avec un minimum dinterruption et de perturbation.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

190

Chapitre 9 Gestion de sous-domaines

Crer des sous-domaines


Nous navons pas la prtention de vous enseigner quand il est bon de crer des sousdomaines, mais nous serons sufsamment audacieux pour vous donner quelques indications. Voici quelques raisons pouvant mener la cration de sous-domaines :

le besoin de rpartir la gestion dun domaine entre plusieurs organismes ; les difcults lies la grande taille du domaine ; le fractionnement peut faciliter la
gestion et rduire la charge des serveurs de noms faisant autorit ;

la ncessit de distinguer lappartenance des htes en les plaant dans des sousdomaines spciques. Une fois que la dcision de crer des sous-domaines est prise, reste en dnir le nombre.

Nombre de sous-domaines
Il ne suft pas de dcider de crer des sous-domaines, il faut aussi choisir leur position dans lespace de noms. Si une socit est organise en quatre secteurs dactivit, on peut choisir de crer quatre sous-domaines, un par secteur. Doit-on crer des sous-domaines pour chaque site, chaque dpartement ou pour chaque secteur dactivit ? vrai dire, le DNS permet une grande souplesse. On peut aussi bien crer de nombreux petits sous-domaines que ne crer que quelques grands sousdomaines. Tout est affaire de compromis. Une dlgation comptant un petit nombre de grands sous-domaines nengendre que peu de travail au domaine parent, car il y a peu de dlgations surveiller. Mais les grands domaines ont besoin de serveurs plus rapides et dots de plus de mmoire ; de plus, leur gestion nest pas distribue. En outre, en mettant en uvre des sous-domaines au niveau dun site, mme les groupes autonomes devront se partager une zone unique et devront tre grs par une seule entit. La dlgation un grand nombre de petits sous-domaines peut tre un casse-tte pour ladministrateur du domaine parent. Pour tenir jour les informations de dlgation, il faut contrler en permanence lidentit des htes qui hbergent les serveurs de noms ainsi que lidentit des zones sur lesquelles ils font autorit. Les informations voluent chaque ajout dun serveur de noms dans un sous-domaine ou lorsque ladresse dun serveur est modie. Si tous les sous-domaines sont grs par des personnes diffrentes, cela ncessite un grand nombre de prises de contact et donc une surcharge de travail. Dun autre ct, les sous-domaines sont plus petits et plus faciles grer, et les administrateurs des zones sont plus proches de leurs utilisateurs. Au vu de ces avantages et inconvnients, il peut sembler difcile de faire un choix. Le mieux est probablement de suivre lorganisation naturelle de lentreprise. Certaines socits grent les machines et les rseaux au niveau du site ; dautres ont des groupes de travail dcentraliss et relativement autonomes, qui grent tout eux-mmes. Voici quelques rgles pour faciliter la division de lespace de noms :

Ne pas forcer une entreprise entrer dans une structure trop rigide. Faire rentrer 50
divisions indpendantes dans 4 sous-domaines rgionaux peut faciliter le travail de ladministrateur mais aussi ternir sa rputation. Des oprations dcentralises et

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Nom des sous-domaines

191

autonomes requirent des zones diffrentes ; cest la raison dtre du systme de noms de domaine.

La structure dun domaine devrait suivre celle de lentreprise, entre autres en raison
de son organisation technique. Si une entit exploite des rseaux, attribue des adresses IP et gre des htes, cette entit doit aussi grer son sous-domaine.

Si ladministrateur na pas ladhsion de tout le monde sur la faon dorganiser


lespace de noms, il doit tenter de xer des rgles prcisant partir de quel moment un groupe peut obtenir son propre sous-domaine (nombre dhtes requis pour le crer, niveau de support technique que doit fournir le groupe).

Nom des sous-domaines


Il faut maintenant choisir les noms des sous-domaines, dans la mesure du possible en collaboration avec ladministrateur et les membres du futur sous-domaine, ne serait-ce que par courtoisie. Le choix du nom peut tre une source de problme. Il est conseill dutiliser un schma de noms cohrent entre les sous-domaines, an de faciliter le reprage de la part des utilisateurs et la mmorisation des noms. En laissant le champ totalement libre ladministrateur du sous-domaine, on peut arriver un espace de noms chaotique. Certains administrateurs voudront utiliser des noms gographiques, dautres des noms lis leur organisme. Certains voudront des noms abrgs, dautres des noms complets, etc. Voici quelques suggestions bases sur notre exprience :

Dans certaines socits dynamiques, le nom des dpartements change souvent, en


fonction des projets. Un nom de sous-domaine bas sur ces noms serait une erreur. Il vaut mieux utiliser des noms non signicatifs et stables dans le temps.

Les noms gographiques sont plus stables que ceux des organismes, mais ils peuvent
paratre obscurs en dehors de lentreprise.

Il ne faut pas sacrier la lisibilit laspect pratique. Des noms sur deux lettres sont
rapides taper, mais impossibles reconnatre. Ainsi, labrviation pour lItalie est it , qui peut tre facilement confondue avec labrviation de Information Technology .

Trop dentreprises utilisent des noms de domaine cabalistiques : plus lentreprise est
grande, plus les noms de domaine sont indchiffrables !

Il ne faut pas utiliser des noms existants ou rservs aux domaines de niveau suprieur pour un nom de sous-domaine. Il peut sembler intressant dutiliser des abrviations gographiques en deux lettres pour des sous-domaines internationaux ou dutiliser des noms de domaine de niveau suprieur, tel que net pour un dpartement rseau (network), mais cela peut poser des problmes. En nommant com le sousdomaine du dpartement Communication, on risque davoir des difcults pour communiquer avec les htes du domaine de niveau suprieur com. Supposons que les administrateurs du sous-domaine com appellent leur nouvelle station Sun sun et leur nouvel HP 9000 hp (quel manque dimagination !). Les utilisateurs du domaine qui enverraient du courrier destination de sun.com ou hp.com, verraient leur

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

192

Chapitre 9 Gestion de sous-domaines

courrier aboutir dans le sous-domaine com1, puisque le nom de la zone parente est susceptible de se trouver dans la liste de recherche de certains htes.

Devenir parent
Une fois que les noms sont choisis, la cration des sous-domaines est aise. Il faut tout dabord dcider du niveau dautonomie coner aux sous-domaines. A priori, la volont de dlguer est sous-jacente la dcision de crer un sous-domaine ; dans ce cas, une nouvelle zone va tre cre. Mais cela nest pas ncessairement le cas. Jusque l, nous avons suppos que la cration dun sous-domaine tait justie par la volont den dlguer la gestion un autre organisme. Mais cette situation nest pas obligatoire. Il faut bien se gurer la manire dont les machines et les rseaux sont grs dans un sous-domaine avant de dcider si on va dlguer ou non la gestion. Une dlgation un sous-domaine na pas de sens si ce dernier ne gre pas lui-mme ses quipements. Dans une grande entreprise, le service du personnel ne gre probablement pas lui-mme ses machines. La cration dun sous-domaine pour le service du personnel ne doit donc pas tre accompagne dune dlgation.

Crer un sous-domaine dans la zone parente


On peut crer un sous-domaine sans le dlguer, en crant des enregistrements de ressource qui font rfrence au sous-domaine, dans la zone parente. Lhte brazil du service du personnel de movie.edu stocke la totalit de la base de donnes des employs et des tudiants. Pour placer brazil dans le domaine personnel.movie.edu il faut ajouter des enregistrements db.movie.edu :
brazil.personnel IN IN IN employeedb.personnel IN db.personnel IN A MX MX CNAME CNAME 192.253.253.10 10 brazil.personnel.movie.edu. 100 postmanrings2x.movie.edu. brazil.personnel.movie.edu. brazil.personnel.movie.edu.

Les utilisateurs peuvent maintenant se connecter db.personnel.movie.edu pour consulter la base de donnes. Cette conguration est intressante pour les employs du service du personnel ; si on ajoute personnel.movie.edu la liste de recherche de leurs poste de travail, ils nont qu taper telnet db pour se connecter la machine souhaite. En utilisant la structure de contrle $ORIGIN, ladministrateur peut utiliser des noms plus courts, ce qui facilitera son travail :
$ORIGIN personnel.movie.edu. brazil IN A 192.253.253.10 IN MX 10 brazil.personnel.movie.edu. IN MX 100 postmanrings2x.movie.edu. employeedb IN CNAME brazil.personnel.movie.edu. db IN CNAME brazil.personnel.movie.edu.
1. En ralit, les routeurs de messagerie ne prsentent pas tous ce problme, mais certains sendmail lont. Tout dpend de la forme de canonisation utilise. Voir la section Courrier lectronique au Chapitre 6 (page 108).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Devenir parent

193

Si on ajoute de nombreux enregistrements pour le service du personnel, on peut aussi crer un chier spar et utiliser la directive $INCLUDE pour linclure dans db.movie.edu et modier simultanment lorigine. Il ny a pas denregistrement SOA pour personnel.movie.edu : lenregistrement SOA de movie.edu indique une autorit sur lensemble de la zone movie.edu. En labsence de dlgation, personnel.movie.edu est une partie de la zone movie.edu.

Crer et dlguer un sous-domaine


Pour dlguer un sous-domaine, il en va tout autrement. Nous allons crer le sous-domaine fx.movie.edu, nouveau sous-domaine de movie.edu, pour le laboratoire des effets spciaux. Comme la gestion va tre dlgue, une nouvelle zone va tre cre. Les machines bladerunner et outland, toutes deux situes dans le laboratoire, serviront de serveurs de noms (bladerunner sera le serveur primaire). Nous avons choisi de crer deux sous-domaines pour la zone par redondance, car un serveur unique pour fx.movie.edu constituerait un risque important disolement de la zone en cas de panne. tant donn le petit nombre de machines dans la zone, deux serveurs devraient sufre. Le laboratoire des effets spciaux est situ sur le nouveau sous-rseau 192.253.254/24 de movie.edu. Voici un extrait du chier /etc/hosts correspondant :
192.253.254.1 movie-gw.movie.edu movie-gw # serveur primaire de fx 192.253.254.2 bladerunner.fx.movie.edu bladerunner br # esclave de fx 192.253.254.3 outland.fx.movie.edu outland 192.253.254.4 starwars.fx.movie.edu starwars 192.253.254.5 empire.fx.movie.edu empire 192.253.254.6 jedi.fx.movie.edu jedi

Il faut dabord crer un chier de zone contenant les enregistrements pour tous les htes de fx.movie.edu. Voici le contenu de db.fx.movie.edu :
$TTL 1d @ IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure IN NS bladerunner IN NS outland ; MX records for fx.movie.edu IN MX 10 starwars IN MX 100 wormhole.movie.edu. ; starwars prend en charge le courrier de bladerunner ; wormhole est le routeur de messagerie de movie.edu

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

194

Chapitre 9 Gestion de sous-domaines

bladerunner IN A 192.253.254.2 IN MX 10 starwars IN MX 100 wormhole.movie.edu. br outland IN CNAME bladerunner

IN A 192.253.254.3 IN MX 10 starwars IN MX 100 wormhole.movie.edu. IN A 192.253.254.4 IN MX 10 starwars IN MX 100 wormhole.movie.edu. IN A 192.253.254.5 IN MX 10 starwars IN MX 100 wormhole.movie.edu. IN A 192.253.254.6 IN MX 10 starwars IN MX 100 wormhole.movie.edu.

starwars

empire

jedi

On cre ensuite le chier db.192.253.254 :


$TTL 1d @ IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure IN IN 1 2 3 4 5 6 IN IN IN IN IN IN NS NS PTR PTR PTR PTR PTR PTR bladerunner.fx.movie.edu. outland.fx.movie.edu. movie-gw.movie.edu. bladerunner.fx.movie.edu. outland.fx.movie.edu. starwars.fx.movie.edu. empire.fx.movie.edu. jedi.fx.movie.edu.

Lenregistrement PTR pour 1.254.253.192.in-addr.arpa dsigne volontairement moviegw.movie.edu, le routeur vers les autres rseaux de movie.edu ; il nappartient pas rellement au domaine fx.movie.edu et il nest donc pas ncessaire, dans 254.253.192.inaddr.arpa, que tous les enregistrements PTR correspondent une zone unique, condition quils correspondent au nom canonique de ces htes. Il faut ensuite initialiser le chier named.conf du serveur primaire :
options { directory "/var/named"; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Devenir parent

195

zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; }; zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; }; zone "254.253.192.in-addr.arpa" { type master; file "db.192.253.254"; }; zone "." { type hint; file "db.cache"; };

Si on utilise h2n, il suft dexcuter :


% h2n v 8 -d fx.movie.edu -n 192.253.254 -s bladerunner -s outland \ -u hostmaster.fx.movie.edu -m 10:starwars -m 100:wormhole.movie.edu

ce qui vite une frappe fastidieuse. h2n conduirait approximativement aux mmes chiers db.fx.movie.edu, db.192.253.254 et named.conf. Il faut maintenant prparer le resolver de bladerunner. Il nest pas encore ncessaire de crer un chier resolv.conf. Si on initialise hostname sur bladerunner par son nouveau nom, bladerunner.fx.movie.edu, le resolver peut extraire le nom du domaine local partir du nom totalement quali. On peut enn dmarrer le processus named sur bladerunner et surveiller syslog pour les erreurs. Si named dmarre correctement et quil ny a pas de renvoi derreur vers syslog, nslookup servira pour les tests en recherchant des noms dans fx.movie.edu et dans 254.253.192.in-addr.arpa :
Default Server: bladerunner.fx.movie.edu Address: 192.253.254.2 > jedi Server: bladerunner.fx.movie.edu Address: 192.253.254.2 Name: jedi.fx.movie.edu Address: 192.253.254.6 > set type=mx > empire Server: bladerunner.fx.movie.edu Address: 192.253.254.2

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

196

Chapitre 9 Gestion de sous-domaines

empire.fx.movie.edu

preference = 10, mail exchanger = starwars.fx.movie.edu empire.fx.movie.edu preference = 100, mail exchanger = wormhole.movie.edu fx.movie.edu nameserver = outland.fx.movie.edu fx.movie.edu nameserver = bladerunner.fx.movie.edu starwars.fx.movie.edu internet address = 192.253.254.4 wormhole.movie.edu internet address = 192.249.249.1 wormhole.movie.edu internet address = 192.253.253.1 bladerunner.fx.movie.edu internet address = 192.253.254.2 outland.fx.movie.edu internet address = 192.253.254.3 > ls -d fx.movie.edu [bladerunner.fx.movie.edu] $ORIGIN fx.movie.edu. @ 1D IN SOA

bladerunner hostmaster ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum bladerunner outland 10 starwars 100 wormhole.movie.edu. 192.253.254.2 10 starwars 100 wormhole.movie.edu. bladerunner 192.253.254.5 10 starwars 100 wormhole.movie.edu. 192.253.254.6 10 starwars 100 wormhole.movie.edu. 192.253.254.3 10 starwars 100 wormhole.movie.edu. 192.253.254.4 10 starwars 100 wormhole.movie.edu. bladerunner hostmaster ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum

bladerunner

br empire

jedi

outland

starwars

1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D 1D

IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN

NS NS MX MX A MX MX CNAME A MX MX A MX MX A MX MX A MX MX SOA

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Devenir parent
> set type=ptr > 192.253.254.3 Server: bladerunner.fx.movie.edu Address: 192.253.254.2 3.254.253.192.in-addr.arpa name = outland.fx.movie.edu

197

> ls -d 254.253.192.in-addr.arpa. [bladerunner.fx.movie.edu] $ORIGIN 254.253.192.in-addr.arpa. @ 1D IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum 1D IN NS 1D IN NS 1D IN PTR 1D IN PTR 1D IN PTR 1D IN PTR 1D IN PTR 1D IN PTR 1D IN SOA bladerunner.fx.movie.edu. outland.fx.movie.edu. movie-gw.movie.edu. bladerunner.fx.movie.edu. outland.fx.movie.edu. starwars.fx.movie.edu. empire.fx.movie.edu. jedi.fx.movie.edu. bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum

1 2 3 4 5 6 @

> exit

Les informations obtenues semblent correctes. Il serait bon de dmarrer maintenant un serveur-esclave et de dlguer lautorit fx.movie.edu partir de movie.edu.

Esclave de fx.movie.edu
Linitialisation du serveur-esclave de fx.movie.edu est simple : copie de named.conf, de db.127.0.0 et de db.cache partir de bladerunner, puis modication de named.conf et de db.127.0.0 selon les instructions du Chapitre 4. Voici le nouveau chier named.conf :
options { directory "/var/named"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

198

Chapitre 9 Gestion de sous-domaines

zone "fx.movie.edu" { type slave; masters { 192.253.254.2; }; file "bak.fx.movie.edu"; }; zone "254.253.192.in-addr.arpa" { type slave; masters { 192.253.254.2; }; file "bak.192.253.254"; }; zone "." { type hint; file "db.cache"; };

Tout comme bladerunner, outland na pas rellement besoin dun chier resolv.conf si hostname est initialis outland.fx.movie.edu. On peut enn dmarrer named et surveiller les erreurs renvoyes vers syslog. Sil ny en a pas, on peut tester le serveur en linterrogeant sur des enregistrements de fx.movie.edu.

Sur le serveur primaire de movie.edu


Il reste maintenant dlguer lautorit sur le sous-domaine fx.movie.edu aux nouveaux serveurs, bladerunner et outland, en ajoutant des enregistrements NS db.movie.edu :
fx 86400 86400 IN IN NS NS bladerunner.fx.movie.edu. outland.fx.movie.edu.

Selon la RFC 1034, les noms apparaissant dans la partie spcique de lenregistrement de ressources NS (la partie droite, contenant bladerunner.fx.movie.edu et outland.fx.movie.edu) doivent tre les noms canoniques des serveurs de noms. Un serveur distant se rfrant la dlgation doit trouver au moins un enregistrement dadresse attach ces noms, mais pas denregistrement dalias (CNAME). La RFC tend cette restriction tout enregistrement de ressource incluant un nom ; ce dernier doit donc tre obligatoirement un nom canonique. Les deux enregistrements prcdents ne sufsent donc pas pour suivre la dlgation. Comment un serveur de noms situ lextrieur de fx.movie.edu pourrait-il y rechercher des informations ? Les serveurs de movie.edu doivent pouvoir donner tous les lments pour pouvoir contacter les serveurs de fx.movie.edu or ces deux enregistrements ne donnent que leur nom mais pas leur adresse IP qui nest actuellement dclare que dans la zone fx.movie.edu. Dans ltat actuel de la conguration, seuls les serveurs de noms de fx.movie.edu peuvent fournir ces adresses aux serveurs distants. Un rel problme de poule et duf ! La solution consiste inclure les adresses des serveurs de fx.movie.edu dans le chier de zone db.movie.edu. Bien quelles ne fassent pas rellement partie de la zone movie.edu, elles sont ncessaires la dlgation vers fx.movie.edu. Bien sr, si les serveurs de fx.movie.edu ne sont pas dans la zone fx.movie.edu, ces enregistrements dadresse, appels enregistrements de recollage (glue records), ne sont pas ncessaires. Un serveur distant

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Devenir parent

199

trouvera les adresses de ces serveurs externes en interrogeant dautres serveurs. Ici, il faut donc ajouter les enregistrements de recollage suivants au chier db.movie.edu :
fx 86400 IN NS 86400 IN NS bladerunner.fx.movie.edu. outland.fx.movie.edu. bladerunner.fx.movie.edu. outland.fx.movie.edu. 86400 IN A 192.253.254.2 86400 IN A 192.253.254.3

Il faut prendre garde ne pas ajouter denregistrements de recollage superus dans le chier. Les serveurs BIND 8 et 9 BIND ignorent automatiquement les informations de recollage qui ne sont pas strictement ncessaires et le signalent via syslog. Si on ajoute un enregistrement NS pour movie.edu, qui dsigne un serveur situ sur un autre site, ns1.isp.net et quon fait lerreur dinclure ladresse de ce serveur dans db.movie.edu sur le serveur primaire de movie.edu, on trouvera les messages suivants dans syslog :
Aug 9 14:23:41 toystory named[19626]: dns_master_load: db.movie.edu:55: ignoring out-of-zone data

Il ne faut surtout pas oublier de tenir jour les informations de recollage. Si on ajoute une nouvelle interface de rseau bladerunner, et donc un nouveau numro IP il faut , ajouter un nouvel enregistrement A aux informations de recollage. On peut aussi crer des alias pour chaque hte quon dplace de movie.edu vers fx.movie.edu. Si on dplace plan9.movie.edu, un important serveur accessible au public, vers fx.movie.edu, il faut crer un alias dans movie.edu, liant lancien nom au nouveau :
plan9 IN CNAME plan9.fx.movie.edu.

Ceci permettra aux utilisateurs extrieurs movie.edu, datteindre plan9 tout en continuant utiliser son ancien nom plan9.movie.edu. Attention la zone laquelle appartient cet alias. Lalias plan9 est dans la zone movie.edu et a sa place dans le chier db.movie.edu. Lalias p9.fx.movie.edu dsignant plan9.fx.movie.edu est dans la zone fx.movie.edu et a sa place dans le chier db.fx.movie.edu. Si on place un enregistrement concernant lextrieur dune zone dcrite par un chier de zone, le serveur de noms nen tiendra pas compte, comme nous lavons montr avec les enregistrements de recollage inutiles.

Dlguer une zone de in-addr.arpa


La dlgation de la zone 254.253.192.in-addr.arpa est un peu plus dlicate que celle de fx.movie.edu, car la zone parente est gre par une autre entit. Nous devons dabord dterminer ladministrateur et la zone parente de la zone 254.253.192.in-addr.arpa (voir le Chapitre 3). La zone 192.in-addr.arpa est le parent de la zone 254.253.192.in-addr.arpa. Ladministrateur de in-addr.arpa na aucune raison de dlguer lautorit sur 253.192.in-addr.arpa ou sur 192.in-addr.arpa une entit. En effet, moins que le rseau 192.253/16 ne constitue un seul gros bloc CIDR, les rseaux tels que 192.253.253/24 et 192.253.254/24 nont rien voir entre eux ; ils peuvent correspondre des entreprises totalement diffrentes. Pour trouver qui gre 192.in-addr.arpa, nous utilisons nslookup ou whois (voir le Chapitre 3). Voici comment utiliser nslookup pour trouver ladministrateur :
% nslookup Default Server: toystory.movie.edu
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

200
Address: 0.0.0.0#53 > set type=soa > 192.in-addr.arpa. Server: toystory.movie.edu Address: 0.0.0.0#53 Non-authoritative answer: 192.in-addr.arpa origin = chia.arin.net mail addr = bind.arin.net serial = 2005112714 refresh = 1800 retry = 900 expire = 691200 minimum = 10800

Chapitre 9 Gestion de sous-domaines

Authoritative answers can be found from: 192.in-addr.arpa nameserver = chia.arin.net. 192.in-addr.arpa nameserver = dill.arin.net. 192.in-addr.arpa nameserver = basil.arin.net. 192.in-addr.arpa nameserver = henna.arin.net. 192.in-addr.arpa nameserver = indigo.arin.net. 192.in-addr.arpa nameserver = epazote.arin.net. 192.in-addr.arpa nameserver = figwort.arin.net. chia.arin.net has AAAA address 2001:440:2000:1::21 basil.arin.net internet address = 192.55.83.32 henna.arin.net internet address = 192.26.92.32 indigo.arin.net internet address = 192.31.80.32

ARIN (American Registry of Internet Numbers) est responsable de la zone 192.in-addr.arpa (voir le Chapitre 3). Il faut utiliser le formulaire http://www.arin.net/library/templates/netend-user.txt pour demander lenregistrement de la zone inverse.

Ajouter un serveur-esclave de movie.edu


Si le laboratoire des effets spciaux vient grossir, il peut tre intressant dinstaller un serveur-esclave pour le domaine movie.edu lintrieur du rseau 192.253.254/24. De cette manire, une grande proportion des requtes issues des htes de fx.movie.edu pourra tre traite localement. Le plus simple est dinstaller le serveur-esclave de movie.edu sur un des serveurs dj existants de fx.movie.edu, ce qui vite de mettre en uvre un nouveau serveur. Nous avons choisi que bladerunner serait serveur-esclave de movie.edu, ce qui ninterfrera pas avec la mission principale de bladerunner, cest--dire avec sa fonction de serveur primaire pour fx.movie.edu. Un serveur de noms sufsamment pourvu en mmoire peut faire autorit sur des milliers de zones. Un mme serveur de noms peut tre serveur primaire pour certaines zones et serveur-esclave pour dautres2.
2. Un serveur de noms ne peut tre la fois le serveur primaire et le serveur-esclave dune mme zone. Il charge les donnes soit partir dun chier local (cas du serveur primaire), soit partir dun autre serveur (cas du serveur-esclave).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Sous-domaines de in-addr.arpa

201

Les modications apporter sont simples : il faut ajouter une directive au chier named.conf de bladerunner pour indiquer named de charger la zone movie.edu en utilisant ladresse IP du serveur primaire de movie.edu, cest--dire celle de toystory.movie.edu. Voici le contenu du nouveau chier named.conf :
options { directory "/var/named"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; }; zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; }; zone "254.253.192.in-addr.arpa" { type master; file "db.192.253.254"; }; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; }; zone "." { type hint; file "db.cache"; };

Sous-domaines de in-addr.arpa
La division en sous-domaines nest pas rserve aux domaines servant la rsolution directe. Si un espace de noms in-addr.arpa est trop grand, on peut le fractionner. Dans la pratique, on divise le domaine correspondant au numro de rseau, en sous-domaines correspondants aux sous-rseaux. Tout dpend donc du type de rseau utilis et du masque de sous-rseau correspondant.

Sous-rseau exactement dlimit au niveau de loctet


Puisque lUniversit du Cinma a trois numros de rseau en /24 (de taille dune classe C), un par segment, il ny a aucun intrt diviser ces rseaux. Par contre, une universit partenaire, Altered State, dispose dun rseau de classe B, 172.20/16. Ce rseau a t divis en plaant une limite entre le troisime et le quatrime octet de ladresse IP ; le masque de sous-rseau correspondant est donc 255.255.255.0. Il existe aussi plusieurs

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

202

Chapitre 9 Gestion de sous-domaines

sous-domaine du domaine altered.edu, dont fx.altered.edu pour les effets spciaux, makeup.altered.edu pour les arrangements et foley.altered.edu pour les trucages. Puisque chacun de ces dpartements dispose de son propre sous-rseau (172.20.2/24 pour les effets spciaux, 172.20.15/24 pour les arrangements et 172.20.25/24 pour les trucages), il serait judicieux de diviser lespace de noms in-addr.arpa. La dlgation des sous-domaines de in-addr.arpa est identique celle des domaines servant la rsolution directe. Dans le chier de zone db.172.20, pour dlguer chaque sous-domaine au serveur de noms adquat, il faut ajouter les enregistrements NS suivants :
2 2 15 15 25 25 86400 86400 86400 86400 86400 86400 IN IN IN IN IN IN NS NS NS NS NS NS gump.fx.altered.edu. toystory.fx.altered.edu. prettywoman.makeup.altered.edu. priscilla.makeup.altered.edu. blowup.foley.altered.edu. muppetmovie.foley.altered.edu.

Remarque importante : pour Altered States, il ne faut utiliser que le troisime octet de sous-rseau dans le premier champ, car lorigine par dfaut est 20.172.in-addr.arpa. Il est ncessaire dutiliser des noms totalement qualis pour les serveurs dans la partie droite des enregistrements NS an dviter lajout de lorigine. Enn, il ny a aucun intrt utiliser des enregistrements dadresse de recollage puisque les noms des serveurs auxquels les zones sont dlgues ne se terminent pas par le nom de la zone dlgue.

Sous-rseau non exactement dlimit au niveau de loctet


Pour les sous-rseaux qui ne sont pas exactement dlimits au niveau de loctet, il nest pas possible deffectuer la dlgation en suivant les sous-rseaux. Il ny a que deux possibilits : soit il y a plusieurs sous-rseaux par zone de in-addr.arpa, soit il y a plusieurs zones de in-addr.arpa par sous-rseau. Aucune de ces deux solutions nest idale.

Rseaux /8 (taille de classe A) et /16 (taille de classe B)


tudions le cas du rseau 15/8 (taille de classe A) dont le masque de sous-rseau est 255.255.248.0 (un champ sous-rseau de 13 bits et un champ hte de 11 bits, cest--dire potentiellement 8192 sous-rseaux de 2048 htes). Dans ce cas, le sous-rseau 15.1.200.0 commence en 15.1.200.0 et se termine en 15.1.207.255. Le chier db.15, correspondant la dlgation pour 15.in-addr.arpa, contient :
200.1.15.in-addr.arpa. 200.1.15.in-addr.arpa. 201.1.15.in-addr.arpa. 201.1.15.in-addr.arpa. 202.1.15.in-addr.arpa. 202.1.15.in-addr.arpa. 203.1.15.in-addr.arpa. 203.1.15.in-addr.arpa. 204.1.15.in-addr.arpa. 204.1.15.in-addr.arpa. 205.1.15.in-addr.arpa. 86400 86400 86400 86400 86400 86400 86400 86400 86400 86400 86400 IN IN IN IN IN IN IN IN IN IN IN NS NS NS NS NS NS NS NS NS NS NS ns-1.cns.hp.com. ns-2.cns.hp.com. ns-1.cns.hp.com. ns-2.cns.hp.com. ns-1.cns.hp.com. ns-2.cns.hp.com. ns-1.cns.hp.com. ns-2.cns.hp.com. ns-1.cns.hp.com. ns-2.cns.hp.com. ns-1.cns.hp.com.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Sous-domaines de in-addr.arpa
205.1.15.in-addr.arpa. 206.1.15.in-addr.arpa. 206.1.15.in-addr.arpa. 207.1.15.in-addr.arpa. 207.1.15.in-addr.arpa. 86400 86400 86400 86400 86400 IN IN IN IN IN NS NS NS NS NS ns-2.cns.hp.com. ns-1.cns.hp.com. ns-2.cns.hp.com. ns-1.cns.hp.com. ns-2.cns.hp.com.

203

Cest beaucoup pour la dlgation dun seul sous-rseau ! Heureusement, BIND 8 depuis sa version 8.2 et BIND 9 depuis sa version 9.1.0 disposent dune structure de contrle $GENERATE. Elle permet de crer un groupe denregistrements de ressources qui ne diffrent les uns des autres que dun incrment de boucle. Ainsi, on peut crer simplement les 16 enregistrements NS suivants :
$GENERATE 200-207 $.1.15.in-addr.arpa. 86400 IN NS ns-1.cns.hp.com. $GENERATE 200-207 $.1.15.in-addr.arpa. 86400 IN NS ns-2.cns.hp.com.

La syntaxe est trs simple : lorsque le serveur lit la structure de contrle, il effectue une itration dans la plage indique dans le premier champ et remplace chaque signe $ du prototype par la valeur courante de litration.

Rseaux /24 (taille de classe C)


tudions le cas des sous-rseaux /24, tels que 192.253.254/24 (de la taille dune classe C) dont le masque de sous-rseau a t x 255.255.255.192. Il ny a quun sous-domaine de in-addr.arpa, 254.253.192.in-addr.arpa, qui correspond aux sous-rseaux 192.253.254.0/26, 192.253.254.64/26, 192.253.254.128/26 et 192.253.254.192/26. La dlgation de la gestion de la rsolution inverse pour chaque sous-rseau pose un problme. Il y a trois solutions, mais aucune nest vraiment simple.

Solution 1. La premire solution consiste grer la zone 254.253.192.in-addr.arpa comme une seule entit et mme essayer de ne pas dlguer. Cela requiert une coopration entre les administrateurs des quatre sous-rseaux concerns ou lutilisation dun outil tel que Webmin (http://www.webmin.com/) pour permettre chaque administrateur de grer ses propres informations. Solution 2. La seconde solution consiste dlguer au niveau du quatrime octet, ce qui est plus laborieux que la dlgation /8 ci-dessus. Cela ncessite au moins un couple denregistrements NS par adresse IP dans le chier db.192.253.254 :
1.254.253.192.in-addr.arpa. 1.254.253.192.in-addr.arpa. 2.254.253.192.in-addr.arpa. 2.254.253.192.in-addr.arpa. ... 65.254.253.192.in-addr.arpa. 65.254.253.192.in-addr.arpa. 66.254.253.192.in-addr.arpa. 66.254.253.192.in-addr.arpa. ... 86400 86400 86400 86400 IN IN IN IN NS NS NS NS relay.bar.com. gw.bar.com. relay.bar.com. gw.bar.com. 86400 86400 86400 86400 IN IN IN IN NS NS NS NS ns1.foo.com. ns2.foo.com. ns1.foo.com. ns2.foo.com.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

204

Chapitre 9 Gestion de sous-domaines

129.254.253.192.in-addr.arpa. 129.254.253.192.in-addr.arpa. 130.254.253.192.in-addr.arpa. 130.254.253.192.in-addr.arpa.

86400 86400 86400 86400

IN IN IN IN

NS NS NS NS

mail.baz.com. www.baz.com. mail.baz.com. www.baz.com.

et ainsi de suite jusqu 254.254.253.192.in-addr.arpa. On peut fortement condenser ces dclarations laide de $GENERATE :
$GENERATE 0-63 $.254.253.192.in-addr.arpa. 86400 IN NS ns1.foo.com. $GENERATE 0-63 $.254.253.192.in-addr.arpa. 86400 IN NS ns2.foo.com. $GENERATE 64-127 $.254.253.192.in-addr.arpa. 86400 IN NS relay.bar.com. $GENERATE 64-127 $.254.253.192.in-addr.arpa. 86400 IN NS gw.bar.com. $GENERATE 128-191 $.254.253.192.in-addr.arpa. 86400 IN NS mail.baz.com. $GENERATE 128-191 $.254.253.192.in-addr.arpa. 86400 IN NS www.baz.com.

Bien sr, dans le chier named.conf de ns1.foo.com, il faut :


zone "1.254.253.192.in-addr.arpa" { type master; file "db.192.253.254.1"; }; zone "2.254.253.192.in-addr.arpa" { type master; file "db.192.253.254.2"; };

et dans le chier db.192.253.254.1, lunique enregistrement PTR suivant :


$TTL 1d @ IN SOA ns1.foo.com. 1 3h 1h 1w 1h ns1.foo.com. ns2.foo.com. thereitis.foo.com. root.ns1.foo.com. ( ; numro de srie ; rafrachissement aprs 3 heures ; nouvel essai aprs 1 heure ; expiration aprs 1 semaine ; TTL rponse ngative d1 heure

IN IN IN

NS NS PTR

Notons que lenregistrement PTR est attach au nom de la zone, puisque ce nom correspond une seule adresse IP Dsormais, lorsquun serveur de noms de 254.253.192.in. addr.arpa reoit une requte denregistrement PTR pour 1.254.253.192.in-addr.arpa, il rpond en indiquant dinterroger ns1.foo.com ou ns2.foo.com, qui rpondront par lenregistrement PTR dans la zone.

Solution 3. Finalement, il existe une solution astucieuse qui vite de maintenir un chier de zone spar pour chaque adresse IP Le responsable de lensemble du .

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Sous-domaines de in-addr.arpa

205

rseau /24 cre un enregistrement CNAME pour chacun des noms de la zone. Ces enregistrements CNAME dsignent des noms dans les nouveaux sous-domaines, chacun de ses noms tant dlgu son propre serveur. Ces nouveaux sous-domaines peuvent tre appels, par exemple, 0-63, 64-127, 128-191 et 192-255, ce qui a le mrite dindiquer clairement la plage dadresses gre par chaque serveur dans le cadre de la rsolution inverse. Chaque sous-domaine contient uniquement les enregistrements PTR le concernant. Voici un extrait du chier db.254.253.192 :
1.254.253.192.in-addr.arpa. IN CNAME 1.0-63.254.253.192.in-addr.arpa. 2.254.253.192.in-addr.arpa. IN CNAME 2.0-63.254.253.192.in-addr.arpa. ... 0-63.254.253.192.in-addr.arpa. 0-63.254.253.192.in-addr.arpa. 86400 86400 IN IN NS NS ns1.foo.com. ns2.foo.com.

65.254.253.192.in-addr.arpa. IN CNAME 65.64-127.254.253.192.in-addr.arpa. 66.254.253.192.in-addr.arpa. IN CNAME 66.64-127.254.253.192.in-addr.arpa. ... 64-127.254.253.192.in-addr.arpa. 64-127.254.253.192.in-addr.arpa. 86400 86400 IN IN NS NS relay.bar.com. gw.bar.com.

129.254.253.192.in-addr.arpa. IN CNAME 129.128-191.254.253.192.in-addr.arpa. 130.254.253.192.in-addr.arpa. IN CNAME 130.128-191.254.253.192.in-addr.arpa. ... 128-191.254.253.192.in-addr.arpa. 128-191.254.253.192.in-addr.arpa. 86400 86400 IN IN NS NS mail.baz.com. www.baz.com.

nouveau, ces enregistrements peuvent tre condenss laide de $GENERATE :


$GENERATE 1-63 $ IN CNAME $.0-63.254.253.192.in-addr.arpa. 0-63.254.253.192.in-addr.arpa. 0-63.254.253.192.in-addr.arpa. 86400 86400 IN IN NS NS ns1.foo.com. ns2.foo.com.

$GENERATE 65-127 $ IN CNAME $.64-127.254.253.192.in-addr.arpa. 64-127.254.253.192.in-addr.arpa. 64-127.254.253.192.in-addr.arpa. 86400 86400 IN IN NS NS relay.bar.com. gw.bar.com.

Le chier de la zone 0-63.254.253.192.in-addr.arpa, db.192.253.254.0-63, ne contient que les enregistrements PTR pour les adresses IP allant de 192.253.254.1 192.253.254.63. Voici un extrait du chier db.192.253.254.0-63 :
$TTL 1d @ IN SOA ns1.foo.com. 1 root.ns1.foo.com. ; numro de srie (

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

206
3h 1h 1w 1h ) IN IN 1 IN 2 IN 3 IN ... NS NS PTR PTR PTR ns1.foo.com. ns2.foo.com. thereitis.foo.com. setter.foo.com. mouse.foo.com. ; ; ; ;

Chapitre 9 Gestion de sous-domaines


rafrachissement aprs 3 heures nouvel essai aprs 1 heure expiration aprs 1 semaine TTL rponse ngative d1 heure

Le fonctionnement de cette conguration est un peu ardu. Un resolver recherche, par exemple, lenregistrement PTR de 1.254.253.192.in-addr.arpa, induisant ainsi une recherche par son serveur local. Ce dernier serveur nit par interroger un serveur de noms de 254.253.192.in-addr.arpa qui rpond avec lenregistrement CNAME, indiquant que 1.254.253.192.in-addr.arpa est en ralit un alias de 1.0-63.254.253.192.in-addr.arpa et que lenregistrement PTR est associ ce nom. La rponse contient aussi les enregistrements NS, qui annoncent ainsi au serveur local que les serveurs qui font autorit sur 0-63.254.253.192.in-addr.arpa sont ns1.foo.com et ns2.foo.com. Le serveur local interroge alors soit ns1.foo.com, soit ns2.foo.com, demande lenregistrement PTR de 1.063.254.253.192.in-addr.arpa et reoit lenregistrement recherch.

Lien correct de parent


Maintenant que la dlgation vers les serveurs de fx.movie.edu est oprationnelle, ladministrateur du domaine parent peut tester la dlgation laide de host. Ce programme pour Unix est disponible http://www.weird.com/~woods/projects/host.html. Pour construire host, il faut dabord lextraire :
% zcat host.tar.Z | tar -xvf -

puis le compiler :
% make

host facilite le test de la dlgation. Avec host, on peut rechercher les enregistrements NS dune zone sur les serveurs de noms de sa zone parente. Si les rsultats sont concluants, on peut ensuite utiliser host pour interroger chaque serveur de noms et demander le SOA de la zone. La requte est non-rcursive ; le serveur interrog ninterroge donc pas son tour un autre serveur pour trouver lenregistrement SOA. Si le serveur rpond, host vrie la rponse pour voir si le bit aa (authoritative answer, rponse faisant autorit) est positionn. Si cest le cas, on vrie que le message contient une rponse. Si tous ces critres sont remplis, le serveur de noms est rput faire autorit sur la zone, sinon il ne fait pas autorit et host renvoie un message derreur. Une dlgation incorrecte peut ralentir la rsolution de noms ou provoquer la propagation dinformations anciennes et errones. Un serveur de noms distant perdra du temps en suivant des enregistrements NS incorrects, simplement parce quil aura reu des indications comme quoi vos serveurs ne font pas autorit sur leur zone. Le serveur distant sera forc dinterroger un serveur dsign par un autre enregistrement NS, ce

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Lien correct de parent

207

qui augmentera le temps de rsolution. Pire encore, le serveur de noms distant placera lenregistrement NS incorrect en mmoire cache et le propagera ainsi aux autres serveurs de lInternet, ampliant ainsi le problme.

Utiliser host
Si nous avons russi vous convaincre de limportance dune dlgation correcte, vous avez sans doute envie dapprendre utiliser host an de vrier que vous ntes pas dans les rangs des mcrants. La premire tape consiste utiliser host pour rechercher les enregistrements NS de votre zone sur un serveur de votre zone parente an de vrier leur validit. Ci-dessous, nous vrions les enregistrements NS de fx.movie.edu sur lun des serveurs de movie.edu :
% host -t ns fx.movie.edu. toystory.movie.edu.

Si les enregistrements NS sont corrects, ils sont afchs tels quels :


fx.movie.edu name server bladerunner.fx.movie.edu fx.movie.edu name server outland.fx.movie.edu

Cela conrme la validit des enregistrements NS de dlgation de fx.movie.edu toystory.movie.edu (le format dafchage peut varier selon la version de host, mais le contenu reste le mme). Nous utilisons ensuite le mode de test du SOA pour interroger chacun des serveurs dclars par un enregistrement NS et leur demander lenregistrement SOA de la zone fx.movie.edu. Le test vrie aussi que la rponse fait autorit :
% host -C fx.movie.edu.

Normalement, les enregistrements NS vus plus haut sont nouveau afchs, mais complts par le contenu du SOA de la zone fx.movie.edu :
Nameserver bladerunner.fx.movie.edu: fx.movie.edu SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. 1 10800 3600 608400 3600 Nameserver outland.fx.movie.edu: fx.movie.edu SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. 1 10800 3600 608400 3600

Le message suivant indique que lun des serveurs de fx.movie.edu, par exemple outland, est mal congur :
Nameserver bladerunner.fx.movie.edu: fx.movie.edu SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. 1 10800 3600 608400 3600 nxdomain.com has no SOA record

Ce message indique quil y a bien un serveur actif sur outland, mais quil ne fait pas autorit sur fx.movie.edu. Le message suivant indique que lun des serveurs de fx.movie.edu ne rpond pas :
Nameserver bladerunner.fx.movie.edu: fx.movie.edu SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. 1 10800 3600 608400 3600 ;; connection timed out; no servers could be reached

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

208

Chapitre 9 Gestion de sous-domaines

Dans ce cas, le message connection timed out indique que host a envoy une requte outland et quil na pas obtenu de rponse dans le temps imparti. Nous aurions pu utiliser nslookup ou dig pour tester la dlgation de fx.movie.edu, mais les puissantes options en ligne de commande de host facilitent la tche.

Grer la dlgation
Si le laboratoire des effets spciaux stend encore, des serveurs additionnels peuvent tre ncessaires. Le Chapitre 8 explique comment procder et quelles informations faire parvenir ladministrateur de la zone parente. Par contre, nous navons pas encore expliqu ce que doit effectuer cet administrateur. Son travail est relativement simple, surtout si les administrateurs du sous-domaine lui font parvenir toutes les informations. Supposons que le laboratoire des effets spciaux mette en uvre un nouveau rseau, 192.254.20/24. alien.fx.movie.edu en est le nouveau serveur. Les administrateurs de fx.movie.edu envoient un email ladministrateur de la zone parente :
Bonjour, Nous venons dinitialiser alien.fx.movie.edu (192.254.20.3) comme serveur pour fx.movie.edu. Pourriez-vous mettre jour les informations de dlgation ? Vous trouverez ci-dessous les enregistrements NS ajouter. Cordialement, Albert Muda amu@fx.movie.edu ----- couper ici ----fx.movie.edu. 86400 IN NS bladerunner.fx.movie.edu. fx.movie.edu. 86400 IN NS outland.fx.movie.edu. fx.movie.edu. 86400 IN NS alien.fx.movie.edu. bladerunner.fx.movie.edu. 86400 IN A 192.253.254.2 outland.fx.movie.edu. 86400 IN A 192.253.254.3 alien.fx.movie.edu. 86400 IN A 192.254.20.3

Ladministrateur de movie.edu doit ajouter les enregistrements NS et A db.movie.edu. Si ladministrateur de la zone parente a utilis h2n pour crer les informations, il peut placer les nouvelles donnes dans le chier spcl.movie que h2n inclut ($INCLUDE) la n du chier db.movie quil cre. La dernire tche de ladministrateur de fx.movie.edu consiste envoyer un message similaire hostmaster@arin.net (ladministrateur de la zone 192.in-addr.arpa) en lui demandant de dlguer le sous-domaine 20.254.192.in-addr.arpa alien.fx.movie.edu, bladerunner.fx.movie.edu et outland.fx.movie.edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Grer la transition vers des sous-domaines

209

Grer la dlgation la source


Avec les versions rcentes de BIND, il nest pas ncessaire de grer manuellement les informations de dlgation. Les serveurs BIND 8 et 9 acceptent la fonction exprimentale zone source (stub zones), qui permet un serveur de recueillir automatiquement les informations de dlgation. Les serveurs de noms congurs comme source pour une zone effectuent priodiquement des requtes denregistrements SOA et NS de cette zone, ainsi que la requte des enregistrements de recollage ncessaires. Le serveur utilise les enregistrements NS pour dlguer une zone partir de son parent, lenregistrement SOA xe la frquence de ces requtes. Ainsi, lorsque ladministrateur dun sous-domaine modie les serveurs de noms du sous-domaine, il ne fait que mettre jour ses enregistrements NS (et incrmente le numro de srie dans lenregistrement SOA). Les serveurs faisant autorit de la zone parente, congurs comme source pour la zone enfant, rcuprent ces informations au plus tard dans lintervalle de rafrachissement. Voici le chier named.conf modi pour les serveurs de movie.edu :
zone "fx.movie.edu" { type stub; masters { 192.253.254.2; }; file "stub.fx.movie.edu"; };

Notons quavec des serveurs BIND 9, il faut congurer tous les serveurs de movie.edu en mode source (stub) pour fx.movie.edu. BIND 9 ne propage pas les informations de dlgation de fx.movie.edu vers la zone parente, aussi la dlgation de zone fx.movie.edu nest pas incluse dans les transferts de zone. Linitialisation de tous les serveurs de movie.edu en mode source pour le sous-domaine assure quils restent tous synchroniss.

Grer la transition vers des sous-domaines


Lexemple prsent du domaine fx.movie.edu nest pas raliste pour plusieurs raisons. La premire est laspect magique des htes du laboratoire. Dans un cas rel, le laboratoire aurait dmarr avec quelques htes placs dans la zone movie.edu. Ce nest que plus tard que le sous-domaine aurait t cr. Entre temps, de nombreux htes se seraient fait connatre par leur nom dans movie.edu. Nous avons brivement expos lutilisation denregistrements CNAME dans la zone parente (voir lexemple de plan9.movie.edu) pour aider les utilisateurs suite au dplacement dune machine. Mais les mthodes seront diffrentes pour le dplacement dun rseau ou dun sous-rseau dans son intgralit. Nous recommandons dutiliser des enregistrements CNAME de la mme manire mais plus grande chelle. h2n permet den crer en masse. Cela permet un utilisateur de continuer utiliser lancien nom pour les htes qui ont migr. Lors de connexions entrantes telnet ou ftp (ou autres) vers ces htes, les applications afchent le nom dhte rel dans fx.movie.edu :
% telnet plan9 Trying... Connected to plan9.fx.movie.edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

210
Escape character is '^]'.

Chapitre 9 Gestion de sous-domaines

HP-UX plan9.fx.movie.edu A.09.05 C 9000/735 (ttyu1) login:

Certains utilisateurs ne voient mme pas ce changement inme. Il peut tre bon de les en informer. Sur lhte fx.movie.edu, qui utilise une vieille version de sendmail, il est aussi ncessaire de congurer sendmail pour quil accepte celui libell aux noms du nouveau domaine. Les versions rcentes de sendmail canonisent les noms dhtes apparaissant dans les adresses de destination des en-ttes de message en utilisant un serveur de noms avant denvoyer le message. Cela convertit un alias movie.edu en un nom canonique dans fx.movie.edu. Si sendmail sur la machine de destination est ancien et code en dur le nom dhte local, il faut changer manuellement le nom du nouveau domaine. Cela ne requiert habituellement quune simple modication de la classe w ou de la classe de chier w dans sendmail.cf (voir la section Algorithme des MX, page 90). h2n effectue tout le travail de cration des alias pour les htes des rseaux de fx.movie.edu (192.253.254/24 et 192.254.20/24) et dindication des nouveaux noms pour les htes dans le chier /etc/hosts. Par exemple, lutilisation de la table dhte de fx.movie.edu permet de gnrer facilement les alias dans movie.edu pour tous les htes de fx.movie.edu. Contenu partiel de /etc/hosts :
192.253.254.1 movie-gw.movie.edu movie-gw # serveur primaire de fx 192.253.254.2 bladerunner.fx.movie.edu bladerunner br # esclaves de fx 192.253.254.3 outland.fx.movie.edu outland 192.253.254.4 starwars.fx.movie.edu starwars 192.253.254.5 empire.fx.movie.edu empire 192.253.254.6 jedi.fx.movie.edu jedi 192.254.20.3 alien.fx.movie.edu alien

Loption -c de h2n utilise un nom de zone comme argument. Lorsque h2n trouve un hte de cette zone sur le rseau, il lui cre des alias dans la zone courante (indiqu par loption -d) :
% h2n -d movie.edu -n 192.253.254 -n 192.254.20 \ -c fx.movie.edu -f options

options contient dautres options pour la construction dinformations partir dautres domaines de movie.edu. La commande ci-dessus cre dans movie.edu un alias pour tout hte de fx.movie.edu.

Supprimer les alias au niveau du parent


Bien que les alias au niveau du domaine parent soient utiles pour minimiser limpact du dplacement des htes, ils sont en fait un vritable boulet : ils compliquent lespace de noms, alors que le but initial tait la diminution de la taille du domaine parent. De plus, ils empchent dattribuer des noms utiliss dans le sous-domaine des machines du domaine parent.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Cycle de vie dun parent

211

lissue dune priode transitoire, et aprs avoir prvenu les utilisateurs, il faudra supprimer les alias, sauf ventuellement pour des machines offrant un service notoire sur lInternet. Durant la priode transitoire, les utilisateurs auront pu shabituer aux nouveaux noms et modier en consquence leurs scripts, chiers .rhosts et autres. Il ne faut pas tre tent de prenniser tous les alias dans la zone parente ; cela soppose au principe de dlgation du DNS et empche les administrateurs des deux zones de nommer les htes de manire autonome. Plutt que de conserver ternellement des enregistrements CNAME pour des htes-cls utiliss partir de lInternet et ne pouvant accepter une perte de connectivit, il vaut mieux choisir de laisser ces htes dans la zone parente. h2n, laide de loption -c, permet de supprimer des alias, mme si les enregistrements pour les htes du sous-domaine sont mlangs dans la table dhtes ou mlangs des htes du mme rseau situs dans dautres zones. Loption -e indique de supprimer tous les enregistrements contenant le nom spci. La commande ci-dessous supprime tous les enregistrements CNAME concernant fx.movie.edu, tout en ajoutant un enregistrement A pour movie-gw.movie.edu (qui est sur le rseau 192.253.254/24) :
% h2n -d movie.edu -n 192.253.254 -n 192.254.20 \ -e fx.movie.edu -f options

Cycle de vie dun parent


Le cycle de vie dun parent pourrait ressembler ceci :

Une zone unique contenant la totalit des htes. Dcoupage de la zone en sous-domaines, dont certains ventuellement dans la mme
zone que le parent. Cration denregistrements CNAME dans la zone parente vers les htes notoires dplacs dans les sous-domaines.

lissue dune priode transitoire, suppression des enregistrements CNAME. Mise jour manuelle ou par zone source et test priodique de la dlgation.
Nous allons maintenant tudier les caractristiques avances des serveurs de noms.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

10
Fonctionnalits avances
quoi leur sert davoir des noms, demanda le Moucheron, sils ne rpondent pas ces noms ?

Les dernires versions de BIND, les versions 8.4.7 et 9.3.2, introduisent de nombreuses nouveauts, dont les plus importantes sont la mise jour dynamique, lannonce asynchrone de modication de zone (NOTIFY) et le transfert incrmental de zone. Les autres nouveauts importantes concernent la scurit : possibilit dindiquer un serveur de noms qui rpondre, qui proposer des transferts de zone et de qui accepter des mises jour dynamiques. Les fonctions de scurit peuvent tre inutiles lintrieur dun rseau dentreprise, par contre les autres mcanismes sont un plus pour les administrateurs de tous les serveurs. Ce chapitre dcrit ces caractristiques et leur intgration dans larchitecture du DNS. La plupart des lments utiles dans les architectures pare-feu seront traits au chapitre suivant.

Liste dadresses et ACL


Avant de prsenter les nouvelles caractristiques de BIND, il est bon de dcrire les listes dadresses. BIND 8 et 9 les utilisent notamment pour la gestion de la scurit, mais pas uniquement. Une liste dadresses est une liste de termes dsignant une ou plusieurs adresses IP Ses . lments peuvent tre des adresses IP individuelles, des prxes IP ou une liste nomme dadresses1. Un prxe IP a le format :
rseau-en-notation-dcimale-pointe/nombre-de-bits-du-masque-de-rseau

Daprs cette dnition, le rseau 15.0.0.0 avec un masque de rseau 255.0.0.0 (8 bits contigus 1) scrit 15/8, ce qui pourrait aussi se dcrire par le rseau 15 de classe A . Le rseau ayant les adresses IP comprises entre 192.168.1.192 192.168.1.255 scrit
1. Les listes dadresses postrieures BIND 8.3.0 et de BIND 9 peuvent contenir des adresses et des prxes IPv6.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

214

Chapitre 10 Fonctionnalits avances

192.168.1.192/26, ce qui correspond au rseau 192.168.1.192 de masque de rseau 255.255.255.192 (26 bits contigus 1). Voici une liste dadresses incluant les deux rseaux qui viennent dtre prsents :
15/8; 192.168.1.192/26;

Une liste nomme de contrle daccs doit avoir t pralablement dnie laide dune directive acl, dont la structure est simple, dans named.conf :
acl nom_acl { liste_dadresses; };

nom_acl devient alors quivalent la liste explicite dadresses. Bien que le nom de la directive, acl, signie access control list et semble donc dvolue la scurit, on peut utiliser nom_acl partout o une liste dadresses est accepte, mme si cela na rien voir avec un contrle daccs. Si des termes sont rcurrents, il est bon dutiliser une directive acl pour les associer un nom. Associons par exemple 15/8 un nom qui correspond sa signication : HP-NET. De la mme manire, associons 192.168.1.192/26 au nom internal :
acl "HP-NET" { 15/8; }; acl "internal" { 192.168.1.192/26; };

Ces noms peuvent dsormais tre utiliss dans dautres listes daccs, rendant ainsi le chier named.conf non seulement plus facile grer, mais aussi beaucoup plus lisible. Il est conseill dencadrer les noms dACL par des guillemets, an dviter des conits potentiels avec des mots-cls utilisables dans named.conf. Quatre listes daccs sont prdnies : none Aucune adresse IP . any Toutes les adresses IP . localhost Chacune des adresses IP de la machine locale (celle qui contient le serveur). localnets Chacun des rseaux auxquels est connecte la machine courante, dtermins en combinant chacune des adresses IP associes une interface avec le masque de rseau attach.

Mise jour dynamique


LInternet et les rseaux TCP/IP en gnral sont en perptuelle volution. De nombreuses grandes entreprises utilisent DHCP pour contrler lattribution des adresses IP Il en est de mme pour les FAI avec leurs clients sur ligne tlphonique ou . par cble. Le DNS doit donc fournir un mcanisme dajout et de suppression dynamiques denregistrements, ce que dcrit la RFC 2136. BIND 8 et 9 mettent en uvre la fonction de mise jour dynamique dcrite dans la RFC 2136, qui permet un acteur autoris, un updater, dajouter ou de supprimer des
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Mise jour dynamique

215

enregistrements de ressource une zone. Lupdater doit dabord tablir la liste des serveurs faisant autorit partir des enregistrements NS de la zone. Si le serveur recevant un message autoris de mise jour nest pas le serveur primaire de la zone, il le retransmet son serveur-matre (update forwarding). Si celui-ci est lui-mme un esclave, il retransmet aussi la mise jour. Seul le serveur primaire dune zone dispose des chiers de zone modiables ; tous les esclaves obtiennent leurs chiers de zone du serveur primaire, que ce soit directement ou indirectement (via un esclave). Une fois que le serveur primaire a trait la mise jour dynamique et modi la zone, les esclaves peuvent en obtenir une nouvelle copie par transfert de zone. La mise jour dynamique permet plus quun simple ajout ou suppression denregistrements. Les updaters peuvent ajouter ou supprimer des enregistrements de ressource individuels, supprimer des ensembles denregistrements de ressource (RRset) de mme nom, classe ou type (par exemple toutes les adresses Internet de www.movie.edu), ou mme supprimer tous les enregistrements associs un nom. Une mise jour peut aussi prciser que certains enregistrements doivent exister ou ne pas exister dans la zone avant que la mise jour ne prenne effet. Par exemple, une mise jour peut ajouter lenregistrement dadresse :
armageddon.fx.movie.edu. 300 IN A 192.253.253.15

condition que le nom armageddon.fx.movie.edu ne soit pas dj utilis ou que armageddon.fx.movie.edu nait pas dj denregistrement dadresse.
Avant la version 9.1.0, les serveurs BIND ne retransmettent pas les mises jour. Si on utilise des serveurs plus anciens, il faut donc sassurer que les requtes arrivent directement au serveur primaire faisant autorit sur la zone mettre jour. Pour cela, il faut tenir jour le champ MNAME de lenregistrement SOA de la zone. En effet, la plupart des procdures de mise jour utilisent ce champ comme une indication sur lidentit du serveur auquel envoyer la requte.

La mise jour dynamique est surtout utilise par des programmes tels que les serveurs DHCP qui attribuent automatiquement des adresses aux machines et qui ont besoin de , dclarer les correspondances nom-adresse et adresse-nom. Certains de ces programmes utilisent la procdure du resolver ns_update() pour crer les messages de mise jour et pour les envoyer vers un serveur faisant autorit sur la zone mettre jour. Il est galement possible de gnrer manuellement des messages de mise jour laide de la commande nsupdate, intgre la distribution de BIND. nsupdate lit les paramtres en ligne de commande et les traduit en messages de mise jour. Les commandes peuvent provenir de lentre standard ou dun chier, dont le nom est pass comme argument nsupdate. Les commandes non spares par une ligne vide sont incorpores dans un message unique de mise jour, tant quil y a de la place. nsupdate comprend les commandes suivantes : prereq yxrrset nom type [donnes] Lexistence dun ensemble denregistrements de ressource (RRset) de type type et de nom nom devient une condition de mise jour pour une srie de commandes update. Si donnes est dni, la valeur doit aussi exister.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

216

Chapitre 10 Fonctionnalits avances

prereq nxrrset nom type Linexistence dun ensemble denregistrements de ressource (RRset) de type type et de nom nom devient une condition de mise jour pour une srie de commandes update. prereq yxdomain nom Lexistence du nom nom devient une condition de mise jour. prereq nxdomain nom Linexistence du nom nom devient une condition de mise jour. update delete nom [type] [donnes] Cette commande supprime le nom indiqu ou, si type est aussi indiqu, supprime lensemble denregistrements correspondant ou, si donnes est aussi indiqu, supprime lenregistrement correspondant simultanment nom, type et donnes. update add nom ttl [classe] type donnes Cette commande ajoute lenregistrement indiqu la zone. Le TTL, le type et les donnes propres lenregistrement doivent obligatoirement tre indiqus. La classe est facultative ; sa valeur par dfaut est IN. La commande :
% > > > nsupdate prereq nxdomain mib.fx.movie.edu. update add mib.fx.movie.edu. 300 A 192.253.253.16 send

demande au serveur dajouter une adresse pour mib.fx.movie.edu condition que ce nom nexiste pas encore. Avec les versions BIND 8 de nsupdate, une dernire ligne, vide, donne le signal de la mise jour, la place de la commande send. Subtil, nest-ce-pas ? La commande suivante vrie dabord que mib.fx.movie.edu dispose dun enregistrement MX et, dans lafrmative, le supprime et le remplace par deux nouveaux enregistrements :
% > > > > > nsupdate prereq yxrrset mib.fx.movie.edu. MX update delete mib.fx.movie.edu. MX update add mib.fx.movie.edu. 600 MX 10 mib.fx.movie.edu. update add mib.fx.movie.edu. 600 MX 50 postmanrings2x.movie.edu. send

Comme avec les requtes, les serveurs qui traitent les mises jour dynamique rpondent par des messages DNS indiquant si la mise jour sest bien droule et, si non, ce qui sest mal pass. Une mise jour peut chouer pour de nombreuses raisons, par exemple le serveur de nom ne fait pas rellement autorit sur la zone en cours de mise jour ou les pr-requis ne sont pas satisfaits ou, encore, parce que le demandeur nest pas autoris. Il y a quelques limites la mise jour dynamique : on ne peut ni supprimer une zone (cest--dire quon ne peut supprimer ni lenregistrement SOA ni le dernier enregistrement NS) ni en crer une.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Mise jour dynamique

217

Mise jour dynamique et numros de srie


Lorsquun serveur traite une mise jour dynamique, il modie une zone et doit donc incrmenter son numro de srie an de signaler aux esclaves la modication de la zone. Cette incrmentation est automatique mais na pas ncessairement lieu chaque mise jour dynamique. Un serveur de noms BIND 8 diffre lincrmentation du numro de srie jusqu 5 minutes ou 100 mises jour, en fonction de la premire des deux limites atteinte. Ce dlai sert de compromis entre la capacit du serveur traiter les mises jour dynamiques et celle effectuer des transferts de zone : cette dernire opration peut tre longue sur de grandes zones. Lorsque le serveur nit par incrmenter le numro de srie de la zone, il envoie une annonce asynchrone de modication de zone, ou NOTIFY, (dcrite plus loin dans ce chapitre) aux serveurs-esclaves, pour les prvenir que le numro de srie a chang. Les serveurs de noms BIND 9 mettent jour le numro de srie chaque fois quune mise jour dynamique est traite.

Mise jour dynamique et chiers de zone


Comme pour toute modication de zone, la mise jour dynamique doit provoquer une modication des chiers de zone. Toutefois, la modication de ces chiers chaque ajout ou suppression denregistrement serait trs coteuse. En effet, lcriture des chiers prend du temps alors quun serveur peut tout fait recevoir des dizaines ou des centaines de mises jour par seconde. Au lieu de cela, lorsquils reoivent une mise jour, les serveurs BIND 8 ou 9 ajoutent simplement un enregistrement un chier de journalisation2. La modication est immdiatement applique la zone stocke en mmoire, mais le serveur ncrira la totalit des chiers qu intervalles de temps prdtermins (habituellement une heure). Les serveurs BIND 8 effacent alors le chier de journalisation, puisquil nest plus utile (la zone stocke sur disque est maintenant quivalente celle rsidant en mmoire). Les serveurs en BIND 9 conservent le chier de journalisation, car il servira aussi au transfert incrmental de zone (voir plus loin dans ce chapitre). BIND 8 utilise un autre chier pour le transfert incrmental de zone. Avec BIND 8, le chier de journalisation est construit en ajoutant .log au nom du chier de zone. Avec BIND 9, le nom du chier de journalisation, galement appel chier journal, est celui du chier de zone, termin par .jnl. Il ne faut donc pas tre surpris de voir apparatre ces chiers lorsquon utilise la mise jour dynamique. En BIND 8, le chier de journalisation devrait disparatre toutes les heures (il peut bien sr rapparatre trs rapidement si le serveur reoit beaucoup de mises jour dynamiques) mais galement lorsque le serveur sarrte proprement. En BIND 9, le chier ne disparat jamais. Si un chier de journalisation existe au moment du dmarrage de BIND 8 ou 9, les enregistrements quil contient sont incorpors la zone. Le chier de journalisation de BIND 8 a un format directement comprhensible. En voici lillustration :
2. Ce principe est bien connu des administrateurs de systme de chiers journalisation.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

218

Chapitre 10 Fonctionnalits avances

;BIND LOG V8 [DYNAMIC_UPDATE] id 8761 from [192.249.249.3].1148 at 971389102 (named pid 17602): zone: origin movie.edu class IN serial 2000010957 update: {add} almostfamous.movie.edu. 600 IN A 192.249.249.215

Celui de BIND 9 nest pas lisible par un tre humain (en tous cas, pas par ceux que nous connaissons).

Contrle daccs pour une mise jour dynamique


Compte tenu de la puissance donne aux updaters sur une zone, il est ncessaire den contrler la liste. Par dfaut, ni BIND 8, ni BIND 9 ne permettent la mise jour dynamique sur les zones sur lesquelles ils font autorit. Pour utiliser la mise jour dynamique, il faut ajouter une structure allow-update ou update-policy la structure zone correspondant la zone que lon veut pouvoir mettre jour dynamiquement. Le paramtre de allow-update est une liste dadresses dsignant les seuls htes autoriss mettre la zone jour. Il est prudent de restreindre cette liste le plus possible :
zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; allow-update { 192.253.253.100; }; // uniquement notre serveur DHCP };

Un updater autoris utilisant allow-update peut effectuer nimporte quelle modication dans la zone : destruction de tout enregistrement (except le SOA), ajout de tout enregistrement.

Mise jour signe par TSIG


partir de BIND 9.1.0, les serveurs-esclaves peuvent faire suivre les mises jour. Le contrle daccs bas sur les adresses dorigine nest donc plus trs utile. En effet, si le serveur primaire autorise les mises jour provenant de ladresse de tous ses esclaves, toute mise jour retransmise sera elle aussi autorise, quel que soit le demandeur initial, ce qui nest pas trs bon3. Pour viter ce problme, une mthode consiste prciser, au niveau dun esclave, les mises jour qui peuvent tre retransmises. La sous-structure allow-update-forwarding prend une liste dadresses comme argument. Seules les requtes provenant dune adresse IP correspondant cette liste seront retransmises. Ainsi, avec la dclaration suivante, seules les mises jour issues du Dpartement des Effets Spciaux sont retransmises :
zone "fx.movie.edu" { type slave; file "bak.fx.movie.edu"; allow-update-forwarding { 192.253.254/24; }; };
3. Lorsquon tente dutiliser le contrle daccs bas sur des adresses IP BIND 9.1.0 et ses successeurs , signalent quil nest pas sr.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Mise jour dynamique

219

Une autre mthode consiste utiliser des requtes signes par TSIG (qui sera dcrit en dtail au Chapitre 11). Pour le moment, il suft de savoir quune mise jour signe par TSIG porte la signature lectronique du demandeur initial, y compris lors dune retransmission. En vriant la signature, on obtient le nom de la cl de chiffrement utilise pour signer la mise jour. Ce nom ressemble un nom DNS et est souvent le nom de lhte sur lequel la cl est dclare. En BIND 8, depuis la version 8.2, une liste dadresses peut contenir une ou plusieurs cls TSIG :
zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; allow-update { key dhcp-server.fx.movie.edu.; }; // autorise uniquement les mises // jour signes avec la cl // TSIG du serveur DHCP };

Cela permet tout updater signant une mise jour dynamique avec la cl TSIG dhcpserver.fx.movie.edu deffectuer toute modication sur la zone fx.movie.edu. Malheureusement, il nest pas possible dy ajouter des restrictions bases sur les adresses IP des updaters. BIND 9 dispose dun mcanisme plus n, galement bas sur les signatures TSIG, grce la nouvelle directive de zone, update-policy. Elle permet de dnir les cls pouvant provoquer la mise jour denregistrements spciques. Cette directive ne sert en gnral que sur les serveurs primaires, puisque les serveurs-esclaves sont seulement censs faire suivre les mises jour. Le droit de mise jour est dni par le nom de la cl utilise pour signer la requte, et par le nom et le type des enregistrements concerns. Voici la syntaxe de update-policy :
(grant | deny) identit type_de_nom nom [types]

grant et deny permettent dautoriser ou dinterdire la mise jour spcique. identit fait rfrence au nom de la cl utilise pour signer la mise jour. type_de_nom prend lune des valeurs suivantes : name Le nom mettre jour doit tre le mme que celui indiqu dans le champ nom. subdomain Le nom mettre jour doit tre un sous-domaine ou situ dans un sous-domaine du domaine indiqu dans le champ nom (le nom du sous-domaine doit bien sr se trouver dans la zone). wildcard Le nom mettre jour doit correspondre lexpression indique dans le champ nom. self Le nom mettre jour doit tre le mme que celui indiqu dans le champ identit (pas nom), cest--dire lorsque le nom modier est le mme que celui de la cl

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

220

Chapitre 10 Fonctionnalits avances

utilise pour signer la mise jour. Dans cette conguration, le champ nom nest pas pris en compte, mais il doit toutefois tre initialis (voir lexemple). Le champ nom doit bien sr tre du type dni par le champ type_de_nom. Ainsi, si le champ type_de_nom est wildcard, le champ nom doit contenir un mta-caractre. Le champ types est optionnel et peut dsigner tout type denregistrement de ressource, sauf NSEC (on peut prciser plusieurs types, spars par des espaces). ANY est un raccourci pour tout type sauf NSEC . Si types nest pas dni, tous les types sont concerns, sauf les types SOA, NS, RRSIG et NSEC.

Il y a une priorit dans les rgles de update-policy : cest la premire correspondance trouve qui est applique et non la plus spcique.

Ainsi, si la machine mummy.fx.movie.edu utilise une cl nomme mummy.fx.movie.edu pour signer ses mises jour dynamiques, on peut restreindre mummy.fx.movie.edu la seule mise jour de tous les enregistrements de ressource qui la concernent :
zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; update-policy { grant mummy.fx.movie.edu. self mummy.fx.movie.edu.; }; };

ou uniquement de son enregistrement dadresse :


zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; update-policy { grant mummy.fx.movie.edu. self mummy.fx.movie.edu. A; }; };

Plus gnralement, on peut autoriser tout client mettre jour son propre enregistrement dadresse :
zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; update-policy { grant *.fx.movie.edu. self fx.movie.edu. A; }; };

Nous pouvons autoriser notre serveur DHCP utiliser la cl dhcp-server.fx.movie.edu pour mettre jour tout enregistrement A, TXT ou PTR attach au domaine fx.movie.edu :
zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; update-policy { grant dhcp-server.fx.movie.edu. wildcard *.fx.movie.edu. A TXT PTR; }; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS NOTIFY (annonce de modification)


Au cas o vous seriez surpris, la diffrence entre :
grant dhcp-server.fx.movie.edu. subdomain fx.movie.edu.

221

et :
grant dhcp-server.fx.movie.edu. wildcard *.fx.movie.edu.

est que le premier autorise la cl dhcp-server.fx.movie.edu modier les enregistrements attachs fx.movie.edu (par exemple, les enregistrements NS de la zone), alors que le seconde ne le permet pas. Puisque le serveur DHCP na pas besoin de modier tout enregistrement attach au nom de la zone, la seconde forme est plus sre. Voici un exemple plus complexe : pour autoriser un client modier tous les enregistrements, sauf les enregistrements SRV, dont le nom correspond la cl, sans autoriser matrix.fx.movie.edu mettre jour les enregistrements SRV, A ou CNAME associs Active Directory (dans les sous-domaines _udp.fx.movie.edu, _tcp.fx.movie.edu, _sites.fx.movie.edu et _msdcs.fx.movie.edu), on peut utiliser :
zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; update-policy { grant matrix.fx.movie.edu. subdomain _udp.fx.movie.edu. SRV CNAME A; grant matrix.fx.movie.edu. subdomain _tcp.fx.movie.edu. SRV CNAME A; grant matrix.fx.movie.edu. subdomain _sites.fx.movie.edu. SRV CNAME A; grant matrix.fx.movie.edu. subdomain _msdcs.fx.movie.edu. SRV CNAME A; deny *.fx.movie.edu. self *.fx.movie.edu. SRV; grant *.fx.movie.edu. self *.fx.movie.edu. ANY; }; };

Puisque les rgles de update-policy sont values dans lordre de leur apparition, les clients ne peuvent pas mettre jour leur enregistrement SRV, mais peuvent modier les autres enregistrements les concernant. Si on veut utiliser les apports de la mise jour dynamique signe par TSIG, mais que les logiciels dont on dispose ne peuvent gnrer de requtes signes, on peut utiliser une version rcente de nsupdate (voir le Chapitre 11).

DNS NOTIFY (annonce de modication)


Traditionnellement, les esclaves BIND effectuent un test pour savoir sils ont besoin dun transfert de zone. Lintervalle entre deux sondages sappelle la priode de rafrachissement. Dautres paramtres de lenregistrement SOA dune zone sont aussi utiliss dans le mcanisme de sondage. Mais avec un mcanisme par sondage, il peut scouler un temps quivalent la priode de rafrachissement avant quun esclave ne dtecte les modications et procde un transfert de zone partir de son serveur-matre, ce qui provoquerait des ravages dans un environnement mise jour dynamique. Un mcanisme par lequel un serveur primaire informerait les serveurs-esclaves dune modication de zone serait prfrable. En effet, le serveur primaire a connaissance des modications : soit il a reu un ordre de rechargement, soit il a reu et trait une mise jour dynamique. Lannonce diffuse par

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

222

Chapitre 10 Fonctionnalits avances

le serveur primaire pourrait survenir trs rapidement aprs une modication, ce qui viterait dattendre lexpiration de la priode de rafrachissement sur les esclaves4. La RFC 1996 propose un tel mcanisme, permettant un serveur primaire dannoncer une modication de zone. BIND 8 et 9 le mettent en uvre sous le nom de NOTIFY. Avec NOTIFY, lorsquun serveur primaire dtecte que le numro de srie dune zone a chang, il envoie une annonce tous les esclaves de cette zone. Il en dtermine la liste par la recherche des enregistrements NS de la zone et aprs avoir limin celui qui dsigne le serveur indiqu dans le champ MNAME de lenregistrement SOA de la zone ainsi que lhte local. Quand un serveur de noms remarque-t-il une modication ? Le redmarrage dun serveur primaire provoque systmatiquement lannonce ses esclaves du numro de srie de toutes ses zones, car le serveur primaire na aucun moyen de savoir si les chiers de zone ont t modis depuis son arrt. Le rechargement dune ou plusieurs zones avec un nouveau numro de srie provoque aussi une annonce aux serveurs-esclaves. Enn, une mise jour dynamique assortie dune mise jour du numro de srie provoque aussi une annonce de modication. Lannonce NOTIFY est identie par son code-opration dans len-tte de la requte. Pour la plupart des requtes, le code est QUERY. Les messages NOTIFY, que ce soit dannonce ou de rponse, utilisent le code NOTIFY. Un message NOTIFY est similaire la rponse une requte denregistrement SOA de zone ; il inclut lenregistrement SOA de la zone dont le numro de srie a chang et le bit signalant une rponse faisant autorit est positionn. Lorsquun esclave reoit un message NOTIFY en provenance de lun de ses serveursmatres, il renvoie une rponse NOTIFY qui signale au matre que lannonce a t reue et quil peut cesser de lenvoyer. Puis lesclave se comporte comme si la priode de rafrachissement venait de scouler : il demande lenregistrement SOA de la zone au serveurmatre. Si le numro de srie est suprieur celui connu par lesclave, lesclave transfre la zone. On voit bien que lors de la rception de la requte NOTIFY, lesclave ne transfre pas immdiatement la zone, mais lance dabord une requte de SOA. Cette vrication permet dliminer les fausses annonces NOTIFY, parfois mal intentionnes : les transferts de zone inutiles qui en dcoulent surchargent les rseaux et les serveurs, et provoquent des refus de service. La RFC 1996 indique quun esclave doit gnrer lui-mme des requtes NOTIFY en direction des autres serveurs faisant autorit sur une zone, sil dcide de transfrer la zone. De cette manire, les serveurs-esclaves incapables de communiquer directement avec le serveur-matre primaire et utilisant un autre esclave comme serveur-matre sont informs dune modication dans la zone. Toutefois, seuls BIND depuis la version 8.2.3 et toutes les versions 9 se comportent de cette manire. Les premires versions de BIND 8 ne propagent pas les annonces et les versions intermdiaires ne mettent en uvre cette fonction que lors dune conguration explicite.
4. En ralit, dans le cas dun rechargement de zone, le serveur de noms peut ne pas envoyer immdiatement les messages NOTIFY. Pour viter des rafales de requtes de rafrachissement en provenance des esclaves, les serveurs BIND rechargeant des zones attendent une fraction de chaque intervalle de rafrachissement de zone avant denvoyer un message NOTIFY pour cette zone.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS NOTIFY (annonce de modification)

223

La gure 10-1 rappelle la structure de notre rseau, o toystory.movie.edu est le serveurmatre primaire de la zone movie.edu et o wormhole.movie.edu et zardoz.movie.edu sont des serveurs-esclaves.
primaire de movie.edu

toystory.movie.edu

transferts de zone

wormhole.movie.edu

zardoz.movie.edu

Figure 10-1. Transferts de zone dans movie.edu


Lorsquon modie et recharge ou quon met dynamiquement jour la zone movie.edu sur toystory.movie.edu, celui-ci envoie des annonces NOTIFY vers wormhole.movie.edu et zardoz.movie.edu. Les deux esclaves rpondent toystory.movie.edu, indiquant ainsi quils ont reu lannonce. Ils vrient alors le numro de srie de movie.edu pour voir sil a volu et, le cas chant, transfrent la zone. Si wormhome.movie.edu et zardoz.movie.edu sont en BIND 8.2.3 (ou ultrieur) ou BIND 9, ils annoncent aussi les modications par NOTIFY. Mais puisque wormhole.movie.edu nest pas le serveur-matre de zardoz.movie.edu et inversement, chacun des deux esclaves ne tient pas compte de lannonce de lautre esclave. Un serveur BIND 8 mmorise les annonces NOTIFY par syslog. Voici ce quenregistre toystory.movie.edu aprs le rechargement de movie.edu :
Oct 14 22:56:34 toystory named[18764]: Sent NOTIFY for "movie.edu IN SOA 2000010958" (movie.edu); 2 NS, 2 A Oct 14 22:56:34 toystory named[18764]: Received NOTIFY answer (AA) from 192.249.249.1 for "movie.edu IN SOA" Oct 14 22:56:34 toystory named[18764]: Received NOTIFY answer (AA) from 192.249.249.9 for "movie.edu IN SOA"

La premire ligne est lannonce NOTIFY envoye par toystory.movie.edu, qui signale aux deux esclaves (2 NS) que le numro de srie de movie.edu est maintenant 2000010958. Les deux lignes suivantes montrent la conrmation de rception par les deux esclaves. Un serveur BIND 9 ne journaliserait que la ligne suivante :
Oct 14 22:56:34 toystory named[18764]: zone movie.edu/IN: sending notifies (serial 2000010958)

Voici maintenant un enchanement plus complexe de transfert de zone, dans lequel a est le serveur primaire dune zone ainsi que le serveur-matre de b, mais b est un serveurmatre pour c. De plus, b est connect deux rseaux ( gure 10-2).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

224

Chapitre 10 Fonctionnalits avances

matre-primaire

a
transferts de zone

b
transferts de zone

matre et esclave

c
esclave

Figure 10-2. Exemple complexe de transfert de zone


Dans ce scnario, a annonce une mise jour de la zone b et c. b vrie le numro de srie de la zone et entreprend un transfert de zone. En revanche, c ne prend pas en compte lannonce NOTIFY en provenance de a, car la conguration de c lui indique que cest b son serveur-matre et pas a. Si b excute BIND depuis la version 8.2.3 ou une version 9, ou sil est explicitement prpar annoncer les modications c, b le fait ds quil a termin de transfrer la zone. c reoit lannonce NOTIFY en provenance de b et teste le numro de srie de la zone sur b. Si c excute lui aussi BIND depuis la version 8.2.3 ou une version 9, il envoie une annonce NOTIFY b ds quil a ni de transfrer la zone. b ne prend bien sr pas en compte cette annonce. De plus, si lannonce NOTIFY est susceptible de parvenir c en partant dune interface quelconque de b, toutes les adresses de b doivent apparatre dans la structure masters pour la zone de la conguration de c an que c ne rejette aucune des annonces NOTIFY. Les serveurs-esclaves qui ne connaissent pas loption NOTIFY, dont BIND 4, rpondent par un message derreur NOTIMP (Not Implemented, non mis en uvre). Notons que le serveur DNS de Microsoft gre NOTIFY. Avec BIND 8 ou 9, NOTIFY est actif par dfaut, mais il peut tre dsactiv :
options { notify no; };

On peut activer ou dsactiver NOTIFY pour une zone particulire, par exemple si on sait que tous les serveurs-esclaves de fx.movie.edu utilisent BIND 4 et ne comprennent donc pas les requtes NOTIFY. La structure zone suivante :
zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; notify no; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Transfert incrmental de zone (IXFR)

225

empche lenvoi dannonces NOTIFY aux esclaves de fx.movie.edu. Un rglage spcique une zone est prioritaire sur un rglage global. Malheureusement, ni BIND 8, ni BIND 9 ne permettent deffectuer un rglage serveur par serveur. BIND 8 et 9 permettent dajouter des serveurs une liste dannonce, en plus de ceux apparaissant dans les enregistrements NS. On peut effectivement avoir plusieurs serveurs non ofciels (voir le Chapitre 8) que lon veut pourtant mettre rapidement jour. On peut aussi avoir un ancien esclave en BIND 8, matre dun autre esclave, et qui ncessite lenvoi de messages NOTIFY. La sous-structure also-notify de la structure zone permet dajouter des serveurs la liste :
zone "fx.movie.edu" { type slave; file "bak.fx.movie.edu"; notify yes; also-notify { 15.255.152.4; }; // esclave BIND 8, explicitement // configur pour envoyer des // annonces ses esclaves };

partir de BIND 8.2.2, on peut aussi utiliser also-notify dans la structure options. Ce rglage sappliquera toutes les zones pour lesquelles NOTIFY est valid (et qui nont pas leur propre sous-structure also-notify). partir de BIND 8.3.2 et 9.1.0, loption explicit provoque la suppression des annonces NOTIFY tous les serveurs sauf ceux indiqus dans la liste also-notify. Les deux dclarations suivantes indiquent au serveur de noms de nenvoyer des messages NOTIFY qu lesclave dadresse IP 192.249.249.20 :
options { also-notify { 192.249.249.20; }; notify explicit; };

On peut aussi utiliser allow-notify pour indiquer au serveur daccepter les annonces provenant dautres serveurs que le serveur-matre de la zone :
options { allow-notify { 192.249.249.17; }; // acceptation des messages NOTIFY en // provenance de 192.249.249.17 };

Utilise dans la structure options, allow-notify concerne toutes les zones. Utilise dans une structure zone, allow-notify rinitialise toutes les dnitions globales allow-notify pour cette zone.

Transfert incrmental de zone (IXFR)


Avec la mise jour dynamique et lannonce de modication, une zone est mise jour au fur et mesure des changements de ltat du rseau, les modications se propageant trs rapidement vers tous les serveurs faisant autorit sur la zone. Le tableau semble ainsi complet.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

226

Chapitre 10 Fonctionnalits avances

Toutefois, imaginons une trs vaste zone contenant des milliers de postes dans Active Directory et dmarrant par DHCP donc mise jour dynamiquement une frquence , trs leve. Chaque client met lui-mme jour son enregistrement dadresse dans la zone et le contrleur de domaine met jour les enregistrements qui indiquent au client les services quil doit fournir (le Chapitre 17 donne plus de dtails sur Active Directory). chaque rception de mise jour sur le serveur primaire, le numro de srie de la zone est incrment et une annonce NOTIFY est envoye vers les serveurs-esclaves. chaque rception dune annonce NOTIFY, chaque serveur-esclave vrie le numro de srie de la zone sur son serveur-matre et, ventuellement, demande un transfert de zone. Plus la zone est vaste, plus le temps de transfert est lev,et plus les risques darrive dune mise jour durant ce temps est importante. Lesclave peut donc tre amen transfrer la zone en permanence ! Les serveurs passeront beaucoup de temps transfrer la totalit de la zone, alors que la modication apporte la zone est probablement minime (par exemple, ajout dun enregistrement dadresse). Le transfert incrmental de zone (Incremental zone transfer ou IXFR) rsout ce problme : lesclave indique au matre le numro de srie de la zone quil possde et demande au matre de ne lui transfrer que les modications entre cette version et la nouvelle version. Cette mthode permet de rduire considrablement la taille et la dure du transfert. IXFR est le type pour une requte de transfert incrmental de zone, au lieu de AXFR pour un transfert complet de zone. La requte contient lenregistrement SOA actuel de lesclave dans la section des serveurs faisant autorit. Lorsque le serveur-matre reoit une requte de transfert incrmental, il recherche la trace des modications apportes la zone entre la version dont dispose lesclave et celle dont dispose le matre. Si cette trace nexiste pas, le matre effectue un transfert de zone complet. Si elle existe, le matre nenvoie que les diffrences entre les deux versions.

Limites de IXFR
IXFR prsente plusieurs restrictions. Tout dabord, IXFR ne fonctionne pas bien avant BIND 8.2.3. Tous les serveurs BIND 9 mettent en uvre IXFR correctement et peuvent interagir avec BIND 8.2.3. Ensuite, IXFR ne fonctionne habituellement que lorsquon modie une zone par des mises jour dynamiques et non par des mises jour manuelles. En effet, les mises jour dynamiques conservent une trace des modications apportes une zone, ainsi que le numro de srie de zone associ chaque mise jour, ce qui correspond exactement aux besoins dun serveur-matre pour rpondre une requte IXFR en provenance dun serveur-esclave. Par contre, un serveur rechargeant la totalit dun chier de zone aurait calculer les diffrences entre cette zone et la version prcdente de la zone, comme sil effectuait un diff entre les versions. On peut donc en conclure que pour tirer au mieux parti de IXFR, il faut modier une zone par mise jour dynamique et ne jamais modier les chiers manuellement.

IXFR partir des diffrences


BIND 9.3.0 a introduit le support pour calculer les rponses IXFR par comparaison dun chier de zone avec les donnes de zone dj en mmoire. Cette fonction signie

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Transfert incrmental de zone (IXFR)

227

que lon peut maintenant (ou nouveau) modier manuellement les chiers de zone. Il faut toutefois sassurer que les chiers que lon modie contiennent bien la dernire version de la zone et que les mises jour dynamique sont refuses pendant que lon travaille sur les chiers (les mises jour dynamiques pourraient modier les donnes en mmoire et le chier en cours de modication ne reprsenterait plus ltat en mmoire). La directive ixfr-from-differences permet de mettre uvre cette fonction. On peut lutiliser indiffremment dans une structure options ou une structure zone. Lexemple cidessous dcrit la mise en uvre pour toutes les zones :
options { directory "/var/named"; ixfr-from-differences yes; };

La commande freeze de rndc gnre une nouvelle version du chier de zone et de suspendre les mises jour dynamique :
% rndc freeze zone [classe [vue]]

La commande rndc thaw permet de dgeler la zone en relisant le chier de zone et permettant les mises jour dynamiques :
% rndc thaw zone [classe [vue]]

Il faut viter de geler une zone trop longtemps, particulirement si lon craint de perdre des mises jour importantes.

Fichiers IXFR
Un serveur BIND 8 garde une trace des transferts IXFR dans un chier distinct de celui pour la mise jour dynamique. Tout comme ce dernier, le chier de journalisation IXFR est modi chaque fois quun serveur reoit une mise jour. Par contre, il nest jamais dtruit, bien que le serveur puisse tre congur pour le purger lorsquil dpasse une certaine taille. En BIND 8, le nom de ce chier est celui du chier de zone suivi du sufxe .ixfr. Un serveur BIND 9 utilise le chier de journalisation de la mise jour dynamique, ou chier journal, pour construire les rponses IXFR et pour maintenir lintgrit dune zone. Puisquun serveur primaire ne sait jamais quand il pourra avoir besoin dune information sur une modication spcique de la zone, il ne dtruit jamais le chier journal. Un esclave BIND 9 sauvegarde le chier journal mme sil reoit un transfert intgral de zone, car il peut servir de matre pour un ou plusieurs esclaves.

Congurer IXFR en BIND 8


Cette conguration est simple. Tout dabord, il faut crer une sous-structure maintainixfr-base dans la structure options sur le serveur-matre. Elle indique au serveur-matre de grer un chier de journalisation des transferts IXFR pour toutes les zones, mme sil est esclave pour lune delles, car il peut lui-mme avoir des esclaves gnrant des requtes IXFR :
options { directory "/var/named";

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

228
maintain-ixfr-base yes; };

Chapitre 10 Fonctionnalits avances

Il faut ensuite indiquer aux esclaves denvoyer des requtes IXFR vers leur serveurmatre, laide de la sous-structure support-ixfr de la structure server :
server 192.249.249.3 { support-ixfr yes; };

Et cest tout, moins quon ne veuille modier le nom du chier de journalisation des transferts IXFR sur le matre, laide de la sous-structure ixfr-base de la structure zone :
zone "movie.edu" { type master; file "db.movie.edu"; ixfr-base "ixfr.movie.edu"; };

Enn, on peut indiquer au serveur de noms de limiter la taille du chier5 de journalisation IXFR une valeur prdtermine :
options { directory "/var/named"; maintain-ixfr-base yes; max-ixfr-log-size 1M; };

// limite le fichier de journalisation IXFR // 1 mga-octet

Lorsque la taille du chier de journalisation dpasse la limite de 100 kilo-octets, le serveur de noms le ramne sa limite. Cette valeur de dpassement de 100 kilo-octets permet dviter que le chier ne soit redimensionn chaque mise jour. En utilisant le format many-answers lors dun transfert de zone, les performances peuvent tre meilleures (voir les transferts de zone many-answers plus loin dans ce chapitre).

Congurer IXFR en BIND 9


Il est encore plus facile de congurer BIND 9 pour IXFR, puisquil ny a rien faire en ralit : IXFR est actif en standard. Pour dsactiver IXFR pour un esclave spcique (ce qui ne se fait pas a priori, tout esclave tant susceptible de demander un transfert incrmental), il faut utiliser la sous-structure provide-ixfr de server, dont la valeur standard est yes :
server 192.249.249.1 { provide-ixfr no; };

provide-ixfr peut aussi apparatre dans la structure options ; dans ce cas, il concerne tous les esclaves qui nont pas de directive provide-ixfr dans la structure server.

5.

Avant BIND 8.2.3, il faut indiquer la taille en octets, au lieu des abrviations telles que 1M , en raison dun bogue.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Redirection (forwarding)

229

Puisque les serveurs-matres BIND 9 effectuent des transferts de zone many-answers en standard, la conguration transfer-format est inutile. La sous-structure request-ixfr peut apparatre dans les structures options ou server. Si on a un mlange de serveurs capables de fonctionner en IXFR et de serveurs ne pouvant pas le faire, on peut adapter les requtes de transfert de zone partir des esclaves aux possibilits de leur matre :
options { directory "/var/named"; request-ixfr no; }; server 192.249.249.3 { request-ixfr yes; };

// seul toystory accepte IXFR dans notre parc

BIND 9 ne gre pas la sous-structure max-ixfr-log-size. Depuis sa version 9.3.0, BIND 9 gre la conguration de la taille maximale du chier de journalisation laide de la directive max-journal-size de la structure options.

Redirection ( forwarding)
Certaines connexions dissuadent denvoyer de grandes quantits de donnes lextrieur dun site, peut-tre en raison dun lien lent fort dlai, comme les liaisons par satellite. Dans ce cas, il est souhaitable de limiter le trac DNS vers lextrieur. BIND propose le mcanisme de la redirection (forwarding). La redirection sert galement lier la rsolution de noms un serveur particulier. Ainsi, si une seule machine dune entreprise dispose dune connectivit Internet et que cette machine hberge un serveur de noms, on peut congurer les autres serveurs, internes lentreprise, pour quils utilisent cette machine comme redirecteur des requtes de noms (cette architecture sera tudie en dtail lorsque nous prsenterons les pare-feu dans le Chapitre 11). En dsignant certains serveurs dun site comme tant ceux qui redirigent, la totalit des requtes concernant lextrieur leur est dabord transmise. Les redirecteurs ( forwarders) traitent la totalit des requtes vers lextrieur dun site et peuvent ainsi btir une mmoire cache riche en informations. La probabilit quun redirecteur puisse rpondre immdiatement une requte vers une zone distante partir des informations dans sa mmoire cache est leve, ce qui vite aux serveurs internes denvoyer des paquets en dehors du site. Il ny a rien de particulier faire pour transformer un serveur en redirecteur ; par contre, il faut modier les autres serveurs du site an quils transmettent leurs requtes aux redirecteurs. Le mode de fonctionnement dun serveur primaire ou dun serveur-esclave change lorsquil utilise un redirecteur. Si linformation recherche se trouve dans les informations sur lesquelles il fait autorit ou dans sa mmoire cache, il rpond directement ; sinon, le serveur envoie la requte au redirecteur et attend un court dlai avant de reprendre un fonctionnement habituel et de dmarrer le processus de recherche itrative. Ce mode est appel forward rst. Ici, ce qui est diffrent de lhabitude est que le serveur envoie une requte rcursive au redirecteur, en esprant obtenir une rponse

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

230

Chapitre 10 Fonctionnalits avances

complte. Dans tous les autres cas, le serveur envoie des requtes itratives (non rcursives) vers les autres serveurs de noms. Voici la sous-structure redirecteurs de BIND 8 et 9, pour les serveurs de movie.edu. wormhole.movie.edu et toystory.movie.edu sont les redirecteurs du site. Cette directive forwarders est ajoute au chier de conguration de chaque serveur, sauf pour les forwarders eux-mmes :
options { forwarders { 192.249.249.1; 192.249.249.3; }; };

Lors de lutilisation de forwarders, il faut construire la conguration la plus simple possible.


Il ne faut pas chaner les forwarders, en demandant au serveur A de rediriger les requtes au serveur B, et au serveur B de les rediriger au serveur C (ou pire encore, au serveur A). Cela entranerait une dure leve de rsolution et crerait une conguration fragile dans laquelle la panne de tout forwarder affaiblirait la rsolution.

Serveur de noms restreint


Il est possible de restreindre encore plus un serveur de noms local en lui interdisant de contacter lui-mme lextrieur, mme lorsque son redirecteur ne rpond pas. Pour cela on le congure pour quil utilise le mode simple redirecteur (forward-only). Il sagit dune variante de serveur base sur les forwarders. Comme pour tout serveur, il rpond aux requtes partir des donnes sur lesquelles il fait autorit ou partir de celles stockes dans sa mmoire cache. Par contre, il sappuie totalement sur les redirecteurs pour effectuer des recherches lextrieur, sans jamais en effectuer lui-mme. Voici un exemple de chier de conguration :
options { forwarders { 192.249.249.1; 192.249.249.3; }; forward only; };

La ligne forwarders doit apparatre dans le chier de conguration. Lutilisation seule de la ligne forward-only ne suft pas. la cration dun serveur forward-only et avec un serveur antrieur BIND 8.2.3, il est intressant de citer plusieurs fois les adresses IP des forwarders :
options { forwarders { 192.249.249.1; 192.249.249.3; 192.249.249.1; 192.249.249.3; }; forward only; };

En effet, un serveur contacte une seule fois chaque redirecteur et attend quelques instants larrive dune rponse. En indiquant plusieurs fois chaque redirecteur, le serveur peut ritrer ses requtes vers les redirecteurs, ce qui augmente avantageusement le temps dattente de rponse en provenance des redirecteurs.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Redirection (forwarding)
Notre exprience nous a montr que le mode redirecteur simple mne en ralit une rsolution de noms plus prvisible que le mode forward-rst (le mode par dfaut). En effet, en cas de problme, le dlai dattente vers les redirecteurs est si long que le serveur dmarre entre temps une rsolution itrative et que le resolver qui a gnr la requte a dj abandonn ou est sur le point dabandonner sa requte. Il en rsulte que le resolver obtient des rsultats incohrents : certaines requtes, dont la rsolution est rapide, mnent une rponse et dautres naboutissent jamais.

231

Redirection par zone


Habituellement, lutilisation de redirecteurs noffre pas dautres possibilits : soit on utilise des redirecteurs pour rsoudre la totalit des requtes auxquelles le serveur de noms ne sait pas rpondre lui-mme, soit on nen utilise pas du tout. Dans certaines situations, il serait intressant de disposer dun rglage plus n, par exemple pour que les recherches concernant certains domaines utilisent un redirecteur spcique, mais que les autres recherches se fassent en mode itratif. BIND 8.2 introduit une nouvelle fonction, la redirection par zone, qui permet de nutiliser des forwarders que lors des recherches dans certains domaines (la redirection par zone avec BIND 9 napparat quen version 9.1.0). Ainsi, on peut congurer un serveur de noms pour rediriger les recherches concernant les noms se terminant par pixar.com vers un couple de serveurs de Pixar :
zone "pixar.com" { type forward; forwarders { 138.72.10.20; 138.72.30.28; }; };

Quel est lintrt dagir ainsi, plutt que de laisser le serveur suivre la dlgation des serveurs de com vers ceux de pixar.com ? Imaginons que lon dispose dune liaison spcialise vers Pixar et que lon sache quil faut utiliser un ensemble spcial de serveurs, visibles uniquement de notre rseau, pour rsoudre les noms de pixar.com. Bien que les rgles de redirection soient dnies dans la structure zone, elles sappliquent tous les noms se terminant par le domaine indiqu. Ainsi, que le nom recherch, foo.bar.pixar.com, soit dans la zone pixar.com ou non, la rgle sapplique parce que ce nom se termine par pixar.com (ce qui revient dire que la rgle sapplique parce que le nom est dans le domaine pixar.com). On peut aussi dnir des rgles qui fonctionnent en sens inverse du prcdent : elles permettent de dnir des requtes spciques qui ne seront pas rediriges. Elles ne peuvent sappliquer qu des serveurs qui ont des forwarders dnis dans la structure options, ce qui sapplique normalement toutes les requtes. Cela se fait dans une structure zone qui nest pas du type forward. Il sagit de zones standard (master, slave ou stub) avec une sous-structure forwarders. Pour ne pas prendre en compte la redirection congure dans la structure options, nous dnissons une liste vide de redirecteurs :
options { directory "/var/named";

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

232

Chapitre 10 Fonctionnalits avances


forwarders { 192.249.249.3; 192.249.249.1; };

}; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; forwarders {}; };

Mais pourquoi dsactiver la redirection dans cette situation ? Souvenons-nous que les rgles de redirection sappliquent toutes les requtes de noms se terminant par le nom de la zone. Ainsi, cette rgle sapplique seulement toute requte de nom concernant les sous-domaines de movie.edu, comme fx.movie.edu. Sans la rgle de redirection, ce serveur aurait retransmis une requte concernant matrix.fx.movie.edu vers les serveurs 192.249.249.3 et 192.249.249.1. Avec la rgle, le serveur utilise les enregistrements NS contenus dans la zone movie.edu et interroge directement les serveurs de fx.movie.edu. La redirection par zone est fondamentale dans les congurations avec pare-feu (voir le Chapitre 11).

Slection de redirecteur
Avec BIND 8 depuis la version 8.2.3 ou BIND 9 depuis la version 9.3.0, il nest pas utile de nommer plusieurs fois les redirecteurs. En effet, ces versions ninterrogent pas ncessairement les redirecteurs dans lordre dans lequel ils apparaissent ; elles interprtent les serveurs de la liste comme des redirecteurs candidats et en choisissent un en fonction du temps daller-retour, dtermin par le temps pass attendre une rponse lors de la prcdente requte. Cela est un rel bnce en cas de dfaillance dun redirecteur. Les anciennes versions de BIND continuaient interroger les redirecteurs en panne et attendaient avant dinterroger le suivant dans la liste. Les nouvelles versions se rendent rapidement compte que le redirecteur ne rpond pas et, par la suite, en interrogeront un autre en premier.

Vues
BIND 9 introduit les vues (views), mcanisme trs utile dans les environnements avec pare-feu. Les vues permettent un serveur de noms de prsenter un certain aspect un ensemble dhtes et un autre aspect un autre ensemble dhtes. Cela est particulirement pratique si le serveur reoit des requtes aussi bien des htes internes que des htes sur lInternet (cette architecture sera dcrite au Chapitre 11). Si on ne congure pas de vue, BIND 9 en cre une unique automatiquement, quil montre tout hte linterrogeant. Pour crer explicitement une vue, il faut utiliser la structure view, dont largument est le nom de la vue :
view "internal" { };
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Vues

233

Il est bon que le nom dune vue soit reprsentatif de sa fonction. Il est conseill de mettre son nom entre guillemets, an dviter des conits potentiels avec les mots rservs de BIND. La structure view ne peut apparatre quaprs la structure options, mais pas ncessairement immdiatement aprs. La sous-structure match-clients de view permet de dnir les clients concerns par une vue. Son argument est une liste dadresses. Si on ne dnit aucun groupe dhtes laide de match-clients, la vue sadresse tous les clients. Construisons une vue de la zone fx.movie.edu uniquement visible du Dpartement des Effets Spciaux. Pour cela, nous pouvons crer une vue accessible par les htes de ce sous-rseau uniquement :
view "internal" { match-clients { 192.253.254/24; }; };

On peut dnir une structure acl pour amliorer la lisibilit :


acl "fx-subnet" { 192.253.254/24; }; view "internal" { match-clients { "fx-subnet"; }; };

LACL doit tre dni lextrieur de view. On peut aussi dnir qui peut voir une vue laide de la structure match-destinations de la structure view, qui, comme match-clients, reoit une liste dadresses comme argument. match-destinations est adapte aux serveurs disposant de plusieurs adresses IP : des clients interrogeant lune des adresses IP auront accs une certaine vue, ceux interrogeant une autre des adresses IP accderont une autre vue. match-clients et match-destinations peuvent tre utilises en commun an de slectionner les requtes provenant dun certain client et destines une adresse particulire. Il existe mme une directive boolenne match-recursive-only qui permet de distinguer les requtes rcursives des requtes itratives. On peut quasiment tout faire lintrieur dune structure view (sauf dnir une directive acl) : dnir une zone avec la structure zone, dcrire un serveur de noms distant avec la structure server ou congurer les cls TSIG avec la structure key. On peut utiliser la plupart des sous-structures de options, en les dnissant toutefois directement dans la structure view :
acl "fx-subnet" { 192.253.254/24; }; view "internal" { match-clients { "fx-subnet"; }; recursion yes; // active la rcursivit pour cette vue (elle // est globalement dsactive dans la structure options) };

Toute option de conguration qui apparat dans view est prioritaire sur une option globale de mme nom (cest--dire une option dnie dans la structure options) pour tout hte qui correspond match-clients.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

234

Chapitre 10 Fonctionnalits avances

La liste complte des directives utilisables dans une structure view en fonction de la version de BIND 9 utilise (il y a des diffrences entre les versions) apparat dans le chier doc/misc/options de la distribution de BIND. Voici maintenant le chier named.conf complet pour le Laboratoire des Effets Spciaux, ce qui montre la puissance des vues :
options { directory "/var/named"; }; acl "fx-subnet" { 192.253.254/24; }; view "interne" { // aspect interne des zones match-clients { "fx-subnet"; }; zone "fx.movie.edu" { type master; file "db.fx.movie.edu"; }; zone "254.253.192.in-addr.arpa" { type master; file "db.192.253.254"; // fichier de zone vu de lintrieur }; }; view "externe" { // aspect des zones prsentes au reste du monde match-clients { any; }; // Implicite. recursion no; // En dehors du sous-rseau, il ne // devrait pas y avoir de rcursivit. zone "fx.movie.edu" { type master; file "db.fx.movie.edu.external"; // fichier de zone vu de lextrieur }; zone "254.253.192.in-addr.arpa" { type master; file "db.192.253.254.external"; }; };

Chaque vue contient une dnition de zone pour fx.movie.edu et 254.253.192.inaddr.arpa, mais le contenu des chiers de zone est diffrent entre les vues interne et externe. Cela permet de prsenter au monde un aspect diffrent de celui expos en interne. Lordre des structures view est important car la premire vue correspondant un hte est celle qui lui sera prsent. Si la vue externe tait indique en premier dans la liste, elle occulterait la vue interne, car la vue externe correspond toutes les adresses.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Rpartition de charge par tourniquet

235

Un dernier point (avant de retrouver nouveau les vues au Chapitre 11) : si on dnit ne serait-ce quune vue, toutes les structures zone doivent apparatre dans des vues explicites.

Rpartition de charge par tourniquet


Depuis la version 4.9, BIND inclut en standard une rpartition de charge ; elle existait auparavant sous la forme de patches. Bryan Beecher a crit ceux de BIND 4.8.3 pour mettre en uvre ce quil appelait des enregistrements dadresse permuts . Il sagit denregistrements dadresse dun type spcial que le serveur permute entre les rponses. Par exemple, si le nom foo.bar.baz est associ trois adresses IP permutes , 192.168.1.1, 192.168.1.2 et 192.168.1.3, un serveur modi les fournit dans lordre suivant :
192.168.1.1 192.168.1.2 192.168.1.3

puis :
192.168.1.2 192.168.1.3 192.168.1.1

et enn, avant de recommencer dans le mme ordre que la premire fois :


192.168.1.3 192.168.1.1 192.168.1.2

Cette fonction est particulirement utile si on a plusieurs ressources quivalentes, telles que des serveurs FTP en miroir, des serveurs web ou des serveurs de terminaux, et quon veut rpartir la charge entre eux. On xe des noms correspondant au groupe de ressources, on congure les clients pour quils accdent ce nom, et le serveur de noms rpartit les connexions entre les diffrentes adresses IP indiques6. Avec BIND 8 et 9, les serveurs font tourner les adresses lorsquun nom a plusieurs enregistrements A (en fait, le serveur permute tous les types lorsquun nom correspond plusieurs valeurs7). Les enregistrements :
foo.bar.baz. foo.bar.baz. foo.bar.baz. 60 60 60 IN IN IN A A A 192.168.1.1 192.168.1.2 192.168.1.3

sur des serveurs BIND 8 et 9, produisent le mme rsultat que les enregistrements dadresse permuts dun serveurs 4.8.3 modi. La documentation de BIND appelle ce mcanisme un tourniquet (round robin). Comme le montre cet exemple, il est bon de rduire le TTL. De cette manire, si les adresses sont stockes dans la mmoire cache dun serveur intermdiaire qui ne pratique pas le round robin, elles disparatront rapidement de la mmoire. Si le serveur intermdiaire recherche nouveau le nom, le serveur faisant autorit sur les adresses peut nouveau leur appliquer un round robin. Il sagit de rpartition de charge, et non dquilibrage, puisque les serveurs renvoient les adresses selon un schma totalement dterministe, indpendamment de la charge ou

6.

7.

NdR : Comme nous lavons vu plus haut, certains resolvers rordonnent les adresses reues en fonction de leur rseau an de privilgier les adresses les plus proches. Ces resolvers rendent la permutation inefcace. Avant BIND 9, les enregistrements PTR ne sont pas permuts. BIND 9 permute tous les types.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

236

Chapitre 10 Fonctionnalits avances

de la capacit des serveurs traitant la requte. Dans lexemple, le serveur dadresse 192.168.1.3 pourrait tre un 486DX33 sous Linux et les autres des serveurs HP9000 Superdomes ; malgr cela, le systme Linux recevrait un tiers des requtes. Ce comportement ne changerait pas, mme en citant plusieurs fois ladresse dun serveur grande capacit, car BIND limine les enregistrements dupliqus.

CNAME multiples
Du temps de BIND 4, certains administrateurs craient un tourniquet avec plusieurs enregistrements CNAME plutt quavec plusieurs enregistrements dadresse :
foo1.bar.baz. foo2.bar.baz. foo3.bar.baz. foo.bar.baz. foo.bar.baz. foo.bar.baz. 60 60 60 60 60 60 IN IN IN IN IN IN A 192.168.1.1 A 192.168.1.2 A 192.168.1.3 CNAME foo1.bar.baz. CNAME foo2.bar.baz. CNAME foo3.bar.baz.

Cela paratra bizarre ceux qui nous entendent rabcher quil est dangereux dassocier nimporte quoi des enregistrements CNAME. Mais les serveurs de noms BIND 4 ne reconnaissent pas cette conguration comme une erreur (ce quelle est pourtant) et renvoient simplement les enregistrements CNAME pour foo.bar.baz en appliquant un tourniquet sur lordre8. Les serveurs de noms BIND 8 sont plus vigilants et nludent pas cette erreur. On peut toutefois congurer BIND 8 explicitement pour quil accepte des enregistrements CNAME multiples pour un seul nom :
options { multiple-cnames yes; };

Notez que vous ne devriez jamais utiliser cette directive. Les serveurs de noms BIND 9 ne relvent pas lerreur de CNAME multiples avant la version 9.1.0. BIND 9.1.0 dtecte le problme mais noffre pas la possibilit dattribuer plusieurs enregistrements CNAME laide de loption multiple-cnames. Nous pensons que cest la bonne approche : lassociation de plusieurs enregistrements CNAME un nom unique est une violation des normes du DNS (en particulier de la RFC 2181). Ne le faites pas.

Sous-structure rrset-order
Parfois, on prfrerait quun serveur de noms nutilise pas de tourniquet. Ainsi, si un serveur web sert de secours, le serveur de noms doit toujours renvoyer son adresse aprs celle du serveur web principal, ce qui nest pas possible cause du tourniquet. Depuis BIND 8.2 et partir de la version 9.1.0 pour BIND 9, on peut dsactiver le tourniquet pour certains noms ou types denregistrement. Ainsi, pour renvoyer toujours dans le mme ordre les adresses de www.movie.edu, on peut utiliser la directive rrsetorder :

8.

La bonne manire pour raliser cette conguration serait dassocier les adresses de foo1.bar.baz, foo2.bar.baz et foo3.bar.baz directement au nom foo.bar.baz.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Rpartition de charge par tourniquet


options { rrset-order { class IN type A name "www.movie.edu" order fixed; }; };

237

En diminuant le TTL sur les adresses de www.movie.edu, un serveur de noms ne garderait pas longtemps les adresses en mmoire cache et participerait rapidement au tourniquet. Les rglages class, type et name dterminent les enregistrements auxquels sapplique lordre. En standard, la classe est IN, le type ANY et le nom *, ce qui revient dire que tous les enregistrements sont concerns. La structure :
options { rrset-order { order random; }; };

indique que le serveur doit renvoyer les enregistrements dans un ordre alatoire. La dnition du nom peut contenir un mta-caractre dans le membre le plus gauche :
options { rrset-order { type A name "*.movie.edu" order cyclic; }; };

On ne peut dnir quune seule sous-structure rrset-order, mais on peut y xer plusieurs directives dordre. Le serveur applique la premire directive possible. On peut dnir trois types dordre avec rrset-order : fixed Les enregistrements sont toujours renvoys dans le mme ordre. random Les enregistrements sont renvoys dans un ordre alatoire. cyclic Les enregistrements sont renvoys dans un ordre cyclique (tourniquet). Malheureusement, BIND 9.3.2 ne prend pas encore totalement en compte lordre xed9. La valeur par dfaut est :
options { rrset-order { class IN type ANY name "*" order cyclic; }; };

9.

Lordre xed ne fonctionne que si les enregistrements sont dclars dans lordre de DNSSEC (voir le Chapitre 11).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

238

Chapitre 10 Fonctionnalits avances

La conguration par rrset-order est encore loin dtre une solution complte car, malheureusement, les mmoires caches des resolvers et des serveurs peuvent interfrer avec cette opration. Les enregistrements SRV prsentent une solution long terme (voir le Chapitre 17).

Classement dadresses par un serveur


Parfois, aucun mcanisme de gestion de lordre des rponses ne convient. Quand on contacte un serveur multi-domicili, le choix dune interface particulire en fonction de ladresse du client peut tre la meilleure mthode. Aucune sous-structure rrset-order ne peut offrir cette solution. Si le serveur multi-domicili est local et partage un rseau avec le client, une des adresses du serveur est forcment plus proche que les autres. Si lhte multi-domicili est distant, il est possible quune des interfaces conduise de meilleures performances que les autres, mais il est souvent difcile de dterminer laquelle. Jadis, net 10 (la premire pine dorsale dARPAnet) tait toujours proche de toute adresse distante. Avec la croissance dInternet, il ny aura aucun gain de performance en choisissant un rseau plutt quun autre pour atteindre un serveur multi-domicili, mais nous exposons tout de mme les diffrentes solutions possibles. Avant dtudier le classement des adresses par un serveur de noms, il faut considrer le classement fait par les resolvers et voir sil nest pas sufsant (voir la section La directive sortlist, page 103). Puisquun resolver et un serveur peuvent se trouver sur des rseaux diffrents, il est souvent plus efcace quun resolver classe les adresses en fonction de son propre point de vue. Le classement au niveau dun serveur fonctionne correctement, mais il peut ne pas tre optimal pour lensemble des resolvers. Le classement des adresses nest pas mis en uvre dans les premires versions de BIND 8, car les auteurs ont estim que sa place ntait pas dans le serveur. Le classement a t r-introduit et amlior en BIND 8.2. En BIND 9, il a fallu attendre la version 9.1.0 pour bncier du classement au niveau du serveur. Le mcanisme pour mettre en uvre le classement est la sous-structure sortlist de options. Cette sous-structure reoit une liste dadresses comme argument, quelle ninterprte pas comme dans le cas dun contrle daccs. Chaque valeur de la liste est ellemme une liste dadresses un ou deux lments. Si une valeur na quun seul lment, elle est utilise pour tester ladresse IP de lexpditeur de la requte. Si cette dernire correspond la liste, le serveur de noms classe les adresses dans la rponse, an que toute adresse en correspondance apparaisse en premier dans la rponse. Voici un exemple :
options { sortlist { { 192.249.249/24; }; }; };

La seule valeur de cette liste na quun seul lment. Les adresses appartenant au rseau 192.249.249/24 sont classes en premier dans les rponses aux demandeurs qui sont euxmmes sur ce rseau. Ainsi, si le client dadresse 192.249.249.101 recherche un nom

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Serveurs de noms prfrentiels sur certains rseaux

239

correspondant deux adresses, 192.249.249.87 et 192.253.253.87, le serveur de noms placera 192.249.249.87 au dbut de la rponse. Si une valeur a deux lments, le premier est utilis pour tester ladresse IP de lexpditeur de la requte. Si cette dernire correspond la liste, le serveur de noms classe les adresses dans la rponse, de manire ce que toute adresse en correspondance avec le second lment apparaisse en premier dans la rponse. Le second lment peut tre en ralit une liste dadresses comprenant plusieurs valeurs. Dans ce cas, la premire adresse ajoute la rponse est la premire qui apparat dans la liste. Voici un exemple :
options { sortlist { { 192.249.249/24; { 192.249.249/24; 192.253.253/24; }; }; }; };

Cette liste concerne les demandeurs du rseau 192.249.249/24. Les adresses appartenant au rseau 192.249.249/24 sont classes en premier dans les rponses aux demandeurs qui sont eux-mmes sur ce rseau. Elles sont suivies des adresses appartenant au rseau 192.253.253/24. Les lments de la liste peuvent aussi tre des sous-rseaux ou mme des htes :
options { sortlist { { 15.1.200/21; { 15.1.200/21; 15/8; }; }; }; };

// si le demandeur est sur 15.1.200/21, alors // privilgier les adresses de ce sous-rseau // ou du moins celles du rseau 15/8

Serveurs de noms prfrentiels sur certains rseaux


Le fonctionnement de cette caractristique de BIND 8 est semblable celle de sortlist, mais elle ne sapplique quau choix des serveurs de noms (cette fonction nest disponible en BIND 9 qu partir de la version 9.3.2). Nous avons dj dcrit comment BIND effectue son choix entre plusieurs serveurs faisant autorit sur une zone : il choisit celui dont le temps daller-retour (roundtrip time ou RTT) est le plus court. Mais ce nest pas tout fait exact. Plus prcisment, BIND 8 rpartit les serveurs distants en classes de 64 millisecondes lors de la comparaison des RTT. La premire classe ne stend que sur 32 millisecondes, de 0 32 millisecondes. La suivante va de 33 96 millisecondes, etc. Les classes ont t dtermines an que des serveurs situs sur des continents diffrents appartiennent des classes diffrentes. Le principe consiste favoriser les serveurs des premires classes mais traiter quitablement tous les serveurs dune mme classe. Si un serveur de noms compare les RTT de deux serveurs distants et que lun deux est situ dans une classe antrieure, cest ce dernier qui est retenu. Mais sil sont tous les deux dans la mme classe, le serveur cherchera si lun deux est topologiquement plus proche .

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

240

Chapitre 10 Fonctionnalits avances

La structure topology permet dintroduire une nouvelle notion dans le choix du serveur de noms interroger. Cette structure permet de favoriser les serveurs dun rseau spcique. topology reoit en paramtre une liste ordonne dadresses, reprsentant des rseaux, selon le privilge souhait (du plus fort au plus faible). La structure :
topology { 15/8; 172.88/16; };

indique au serveur local de prfrer les serveurs du rseau 15/8 tous les autres, puis les serveurs du rseau 172.88/16 tous les serveurs autres que ceux du rseau 15/8. Si un serveur a le choix entre un serveur sur le rseau 15/8, un serveur sur le rseau 172.88/16 et un serveur sur le rseau 192.168.1/24, et que ces trois serveurs sont dans la mme classe de RTT, il choisira dinterroger le serveur situ sur le rseau 15/8. On peut galement inverser les valeurs de manire pnaliser les serveurs dun certain rseau. Plus la correspondance avec une valeur inverse apparat tt dans la liste, plus la pnalit est grande. Ce mcanisme vitera aussi quun serveur local nenvoie des requtes vers les serveurs distants dun rseau particulirement sollicit.

Serveur de noms itratif


Par dfaut, les resolvers BIND envoient des requtes rcursives et les serveurs BIND rpondent au mieux ces requtes (voir le Chapitre 2). En cherchant la rponse la requte rcursive, le serveur construit une mmoire cache contenant des informations sur dautres zones et sur lesquelles il ne fait pas autorit. Parfois, il nest pas souhaitable quun serveur de noms prenne en charge lui-mme le surcrot de travail pour rpondre une requte rcursive ou pour construire une mmoire cache. Les serveurs de la racine en sont un bon exemple. Ces serveurs sont tellement occups quils ne peuvent pas se permettre de rpondre aux requtes rcursives ; leurs rponses ne doivent contenir que des informations sur lesquelles ils font autorit. Ces rponses peuvent parfois tre compltes, mais elles contiennent le plus souvent une rfrence vers dautres serveurs de noms. Et puisque les serveurs de la racine nacceptent pas les requtes rcursives, ils ne construisent pas de mmoire cache, ce qui limite lespace mmoire occup10. On peut demander BIND de fonctionner en mode itratif (non rcursif) :
options { recursion no; };

De cette manire, le serveur traite une requte rcursive comme si elle ne ltait pas. En conjonction avec loption recursion no, loption fetch-glue vite quun serveur ne cre une mmoire cache :
10. Un serveur de la racine ne reoit habituellement pas de requte rcursive, moins quun administrateur nait congur son serveur pour utiliser le serveur de la racine comme forwarder, quun administrateur nait congur le resolver de son hte pour quil utilise un serveur de la racine comme serveur ou quun utilisateur nait interrog le serveur de la racine laide de nslookup ou dig. Tout cela arrive bien plus souvent que lon ne pourrait imaginer.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

liminer les serveurs dfectueux


options { fetch-glue no; };

241

Cette option indique au serveur de ne pas rechercher les informations manquantes lorsquil construit une rponse. Les serveurs BIND 9 ne le faisant jamais, la sous-structure fetch-glue est obsolte en BIND 9. Si on choisit dinstaller un serveur itratif, il ne faut pas le citer dans les chiers resolv.conf. Bien quon puisse fabriquer un serveur itratif, aucune option ne permet de congurer un resolver pour quil puisse travailler avec un serveur itratif11. Si un serveur doit continuer servir un ou plusieurs resolvers, on peut utiliser la sous-structure allowrecursion, disponible depuis BIND 8.2.1. allow-recursion est suivie dune liste dadresses ; tous les htes rpertoris peuvent envoyer des requtes rcursives, mais celles-ci sont traites comme si elles ne ltaient pas :
options { allow-recursion { 192.253.254/24; }; // seuls les resolvers du rseau FX // peuvent envoyer des requtes rcursives };

La valeur par dfaut de allow-recursion est de permettre la rcursivit toutes les adresses IP . Il ne faut pas citer un serveur itratif comme redirecteur. Lorsquun serveur utilise un autre serveur comme redirecteur, il lui transmet sa requte sous forme rcursive. Sur le redirecteur, on peut utiliser allow-recursion pour nautoriser que certains serveurs rediriger des requtes. On peut dclarer un serveur itratif comme lun des serveurs faisant autorit sur une zone (on peut demander un serveur-parent de rpondre aux requtes concernant une zone en faisant rfrence ce serveur). Cela fonctionne car les serveurs senvoient des requtes itratives entre eux.

liminer les serveurs dfectueux


Un serveur distant dfectueux peut renvoyer des informations errones, cest--dire trop anciennes, incorrectes, mal construites, voire dlibrment trompeuses. On peut soit tenter de prvenir son administrateur, soit congurer ses propres serveurs pour quils ninterrogent pas ce serveur dfectueux, ce qui est possible avec BIND 8 et BIND 9 depuis la version 9.1.0 :
server 10.0.0.2 { bogus yes; };

Il faut bien sr indiquer la bonne adresse IP pas celle de lexemple. , Si le serveur dsign est le seul de sa zone, il devient impossible de rechercher des noms dans cette zone. Heureusement, il y a dautres serveurs dans cette zone pour renvoyer des informations correctes.
11. En gnral, des programmes construits pour envoyer des requtes itratives ou qui peuvent tre congurs pour envoyer de telles requtes, tels que nslookup ou dig, peuvent encore fonctionner.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

242

Chapitre 10 Fonctionnalits avances

Pour interdire linterrogation dun serveur, on peut aussi utiliser une liste noire (blackhole). Un serveur ninterrogera pas les serveurs de la liste et ne rpondra pas leurs requtes12. blackhole est une sous-structure de options dont largument est une liste dadresses :
options { /* Ne pas perdre de temps rpondre aux requtes en provenance des rseaux privs dfinis dans la RFC 1918 */ blackhole { 10/8; 172.16/12; 192.168/16; }; };

Cela vite au serveur de tenter de rpondre des requtes provenant des adresses prives dnies dans la RFC 1918. LInternet ne route pas ces adresses et une tentative de rponse vers ces adresses serait une perte de temps CPU et de bande passante. La sous-structure blackhole est apparue avec la version 8.2 de BIND 8 et la version 9.1.0 de BIND 9.

Paramtrer le systme
Les valeurs de conguration par dfaut conviennent la plupart des sites, mais il peut savrer ncessaire dafner certains rglages. Cette section dcrit tous les paramtres permettant dajuster le fonctionnement dun serveur de noms.

Transferts de zone
Les transferts de zone peuvent normment surcharger les serveurs. BIND propose donc des mcanismes permettant de limiter la charge lie aux transferts de zone, induite par les esclaves sur leurs matres.

Limiter le nombre de transferts la demande dun serveur


Sur un serveur-esclave, il est possible de limiter le nombre de zones quun serveur peut demander au mme serveur-matre, chose importante pour ce dernier si plusieurs centaines de zones sont concernes. Voici la conguration :
options { transfers-per-ns 2; };

BIND 9 permet aussi de limiter les transferts serveur par serveur. Pour cela, il faut utiliser la sous-structure transfers lintrieur des structures server pour lesquelles on veut mettre en uvre une limitation :

12. Alors que les demandeurs qui apparaissent dans une liste allow-query reoivent un message leur indiquant que leur requte a t refuse, ceux qui apparaissent dans une liste noire ne reoivent rien du tout.
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Paramtrer le systme
server 192.168.1.2 { transfers 2; };

243

Ce rglage est prpondrant sur toutes les limitations globales effectues dans la structure options. La limite par dfaut est de deux transferts simultans par serveur-matre, ce qui peut paratre faible. Dtaillons le principe en prenant lexemple dun serveur qui a besoin de transfrer quatre zones partir dun serveur-matre unique. Le serveur commence transfrer les deux premires zones. Ds quil a termin de transfrer lune delles, il commence le transfert de la troisime. Ds quil ny a plus quun transfert en cours, il passe enn celui de la quatrime zone. Le rsultat nal est le mme quavant la mise en place de la limitation, mais le travail est mieux rparti. Il est possible daugmenter cette limite, si on constate que la synchronisation de la totalit des zones avec le serveur-matre est trop longue cause de lenchanement en squence et pas de la lenteur du rseau ou des serveurs. Ce besoin napparat probablement que dans le cas de serveurs grant plusieurs centaines ou milliers de zones. Avant daugmenter la limite, il faut sassurer que le serveur-matre et le rseau peuvent absorber laugmentation de charge due aux transferts simultans.

Limiter le nombre total de transferts


La limite prcdente ne correspondait qu des transferts de zone en provenance dun serveur-matre unique. Cette nouvelle limitation concerne les transferts demands par plusieurs serveurs-matres. On peut limiter le nombre total de transferts demands simultanment par un serveur, quel que soit le serveur-matre interrog. La valeur par dfaut est de 10. Nous avons vu plus haut que le serveur demande deux transferts au plus simultanment un mme serveur-matre. Si le serveur transfre deux zones par serveur, la limite de dix est atteinte pour cinq serveurs-matres. Dans ce cas, le serveur sollicit diffre tout transfert supplmentaire en attendant davoir termin lun des dix premiers. Voici le chier de conguration named.conf pour BIND 8 et 9 :
options { transfers-in 10; };

Si un hte ou un rseau ne peut pas supporter 10 transferts simultans, il faut diminuer la limite. Si le serveur gre plusieurs centaines ou milliers de zones et que lhte et le rseau peuvent supporter la charge, on peut augmenter la limite. Dans ce cas, il peut aussi savrer ncessaire daugmenter la limitation par serveur (par exemple, un serveur charge des zones partir de quatre serveurs distants seulement ; seulement huit transferts peuvent prendre place simultanment ; la seule augmentation de la limite totale naurait ici aucun effet).

Limiter le nombre total de transferts de zone servis


BIND 9 peut limiter le nombre de transferts de zone servis simultanment, ce qui est plus pratique que de limiter le nombre de transferts demands ; sans cela, il faut faire conance ladministrateur qui gre les serveurs-esclaves pour quil ne surcharge pas le serveur-matre. Voici la structure propose par BIND 9 :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

244
options { transfers-out 10; };

Chapitre 10 Fonctionnalits avances

La valeur par dfaut est xe 10.

Limiter la dure dun transfert


BIND permet de limiter la dure dun transfert. Par dfaut, la limite est de 120 minutes (2 heures). Un transfert dpassant 120 minutes est probablement corrompu et risque de ne jamais sachever ; le processus occupe inutilement des ressources. Pour diminuer ou augmenter cette valeur (par exemple si le rseau est trs faible dbit), il faut utiliser la sous-structure suivante :
options { max-transfer-time-in 180; };

La limite de dure peut tre xe zone par zone en plaant max-transfer-time-in dans une structure zone. Par exemple, si le transfert de la zone rinkydink.com prend toujours trois heures en raison de la liaison trs lente mais que le transfert des autres zones ne pose aucun problme et accepterait une limite dune heure, on peut utiliser :
options { max-transfer-time-in 60; }; zone "rinkydink.com" { type slave; file "bak.rinkydink.com"; masters { 192.168.1.2; }; max-transfer-time-in 180; };

BIND 9 propose aussi la sous-structure max-transfer-time-out, utilisable aux mmes endroits (cest--dire soit dans la structure options soit dans la structure zone), et qui gre la dure dun transfert de zone en sortie (cest--dire vers un esclave). Comme pour maxtransfer-time-in, la valeur par dfaut est de 120 minutes. BIND 9 dispose mme dune limitation de la dure dinactivit lors dun transfert de zone, cest--dire du temps coul depuis que les dernires informations dun transfert de zone ont t changes. Les deux sous-structures, max-transfer-idle-in et max-transferidle-out, grent respectivement les dures de suspension dun transfert entrant et dun transfert sortant. Comme les sous-structures prcdentes, elles peuvent tre utilises dans la structure globale options ou dans une structure zone. Leur valeur par dfaut est xe 60 minutes.

Limiter la frquence des transferts de zone


Un intervalle de rafrachissement trop faible pour une zone peut entraner une dfaillance dun serveur-esclave pour cette zone. En effet, si est un serveur est esclave pour plusieurs milliers de zones et que ladministrateur de certaines dentre elles a x leur priodicit de rafrachissement une trs faible valeur, le serveur-esclave peut ne pas russir effectuer les rafrachissements la frquence xe (ladministrateur dun

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Paramtrer le systme

245

tel serveur-esclave doit absolument consulter la section Limiter les requtes de SOA (page 248) car il peut savrer ncessaire dajuster le nombre de requtes simultanes de SOA). lautre extrme, un administrateur inexpriment peut xer un intervalle de rafrachissement si grand que des incohrences prolonges peuvent apparatre entre le serveur primaire dune zone et les serveurs-esclaves. Depuis BIND 9.1.0, on peut encadrer lintervalle de rafrachissement avec max-refreshtime et min-refresh-time pour lensemble des zones gres (structure options) ou pour une zone spcique (structure zone). La valeur est exprime en secondes :
options { max-refresh-time 86400; min-refresh-time 1800; }; // rafrachissement maxi d1 jour // et mini de 30 minutes

Depuis BIND 9.1.0, on peut aussi limiter lintervalle de nouvel essai avec les sous-structures max-retry-time et min-retry-time, dont la syntaxe est la mme.

Transferts de zone plus efcaces


Un transfert de zone est constitu de nombreux messages envoys de bout en bout travers une connexion TCP Les transferts de zone standard ne placent quun enregistre. ment de ressource par message, ce qui nest pas optimal car il faut un en-tte complet chaque fois. Cest un peu comme dtre lunique passager dun norme 4x4. Or un message TCP pour le DNS pourrait vhiculer simultanment plusieurs enregistrements, jusqu un maximum de 64 kilo-octets. Les serveurs BIND 8 et 9 acceptent un nouveau format de transfert, appel manyanswers. Ce format place autant denregistrements que possible dans un message DNS unique. De cette manire, un transfert de zone utilise moins de bande passante, car il y a moins de perte et moins de temps machine pass remettre en ordre les messages. La sous-structure transfer-format xe le format utilis par un matre pour transfrer les zones ses esclaves. transfer-format est utilisable dans la structure options et dans la structure server : utilise comme option, transfer-format contrle le comportement global des transferts de zone partir du serveur. Par dfaut, an dassurer la compatibilit avec les serveurs BIND 4, la valeur de loption en BIND 8 correspond au format one-answer. En BIND 9, le format par dfaut est many-answers. La structure :
options { transfer-format many-answers; };

modie le comportement par dfaut pour la totalit des esclaves, moins quune spcicit napparaisse dans une structure server :
server 192.168.1.2 { transfer-format one-answer; };

Pour bncier au maximum du nouveau format de transfert de zone, il faut :

soit xer le format global de transfert many-answers (voire ne rien faire avec BIND
9) si la plupart des esclaves utilisent BIND 8, BIND 9 ou le serveur DNS de Microsoft, qui comprend lui aussi ce format ;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

246

Chapitre 10 Fonctionnalits avances

soit xer le format global de transfert one-answer si la plupart des esclaves utilisent
BIND 4. Il faut ensuite utiliser transfer-format au niveau des structures server pour modier le rglage global pour un serveur spcique. Noublions pas que si on utilise BIND 9, il faut explicitement ajouter une structure server pour chaque serveur-esclave BIND 4, an de ramener le format de transfert oneanswer.

Limiter les ressources


Il peut tre intressant de limiter les ressources utilises par un serveur de noms : taille de la mmoire, nombre de chiers ouverts, etc. Cela est possible avec BIND 8 et 9.

Modier la limite de taille dun segment de donnes


Certains systmes dexploitation permettent de limiter la taille mmoire maximale utilisable par un processus. Si le systme utilis naccorde pas la mmoire demande au serveur de noms, le serveur peut ne pas fonctionner correctement (panic) et ventuellement sarrter. Ce type de problme napparat quavec les serveurs qui grent une trs grande quantit de donnes ou dont les limites sont trs basses. Des options de conguration de BIND 8, ainsi que de BIND 9 depuis la version 9.1.0, permettent de modier la limite par dfaut du systme sur la taille dun segment de donnes. Pour xer une limite suprieure celle impose par le systme named, il faut utiliser loption suivante :
options { datasize taille };

taille est une valeur entire exprime, en standard, en octets. On peut indiquer une autre unit en ajoutant un caractre la valeur : k (kilo-octet), m (mga-octet) ou g (gigaoctet). Par exemple, 64m reprsente 64 mga-octets.
Tous les systmes dexploitation ne permettent pas cette augmentation pour des processus spciques. Dans ce cas, si on tente malgr tout une telle augmentation, le serveur de noms envoie un message vers syslog au niveau LOG_WARNING pour le signaler.

Modier la limite de taille de la pile


BIND 8, ainsi que BIND 9 depuis la version 9.1.0, permettent dajuster la limite de taille de pile utilisable par named :
options { stacksize taille; };

taille a la mme forme que pour datasize. Cela ne fonctionne quavec les systmes dexploitation acceptant la modication de limite de taille de pile par un processus.

Modier la limite de taille dun chier core


Si on souhaite que named ne laisse pas traner de chiers core volumineux dans les systmes de chiers, on peut au moins limiter leur taille en utilisant coresize. Inverse-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Paramtrer le systme

247

ment, si named na pas la possibilit de gnrer un chier core complet en raison dune limitation impose par le systme dexploitation, on peut ventuellement augmenter la limite. La syntaxe de coresize est :
options { coresize taille; };

Cela ne fonctionne quavec les systmes dexploitation acceptant la modication de limite de taille de chier core gnr par un processus et ne fonctionne pas avant la version 9.1.0 de BIND 9.

Modier la limite du nombre de chiers ouverts


Sur les serveurs faisant autorit sur un grand nombre de zones, le processus named ouvre une grande quantit de chiers ds son dmarrage : un par zone, en supposant que lon utilise un chier de sauvegarde sur chaque zone pour laquelle le serveur est esclave. De mme, si lhte utilise des interfaces rseaux virtuelles13, named a besoin dun descripteur de chiers par interface. La plupart des systmes Unix xent une limite sur le nombre de chiers quun processus peut ouvrir simultanment. Si le serveur de noms tente douvrir plus de chiers que ne le permet la limite, le message syslog suivant apparat :
named[pid]: socket(SOCK_RAW): Too many open files

Si le systme dexploitation permet de modier la limite processus par processus, on peut augmenter la limite en utilisant la sous-structure les de BIND :
options { files nombre; };

La valeur par dfaut nest pas limite (unlimited), ce qui signie que le serveur ne xe aucune limite sur le nombre de chiers ouverts simultanment ; dans ce cas, cest la limite impose par le systme dexploitation qui agira. Cette limitation fonctionne pas partir de la version 9.1.0 de BIND 9.

Limiter le nombre de clients


BIND 9 permet de limiter le nombre de clients servis simultanment. On peut xer une limite sur le nombre de clients rcursifs (cest--dire le nombre de resolvers et de serveurs utilisant un serveur comme forwarder) grce la sous-structure recursive-clients :
options { recursive-clients 5000; };

La valeur standard est xe 1000. Le message :


Sep 22 02:26:11 toystory named[13979]: client 192.249.249.151#1677: no more recursive clients: quota reached

13. Le Chapitre 14 dcrit de meilleures solutions au problme du dpassement de la limite sur le nombre de chiers ouverts.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

248

Chapitre 10 Fonctionnalits avances

indique que le serveur refuse des requtes rcursives ; dans ce cas, on peut augmenter la limite. Inversement, si le serveur a du mal suivre le rythme des requtes rcursives, la limite peut tre diminue. On peut aussi limiter le nombre de connexions TCP concurrentes que peut traiter le serveur (pour les transferts de zone et les requtes achemines par TCP) avec la sousstructure tcp-clients. Les connexions TCP consomment beaucoup plus de ressources que le fonctionnement en UDP en raison de la conservation dtat en TCP La valeur stan, . dard est xe 100.

Limiter les requtes de SOA


Depuis BIND 8.2.2, on peut limiter le nombre de requtes de SOA sortantes. Si un serveur est esclave de plusieurs milliers de zones, il gnre de nombreuses requtes de SOA tout moment. Le suivi de chaque requte consomme de la mmoire. BIND 8 limite le nombre de requtes de SOA en cours quatre. Si cela est insufsant pour que lesclave remplisse pleinement son rle, on peut augmenter la limite laide de la sousstructure serial-queries :
options { serial-queries 1000; };

serial-queries est obsolte en BIND 9. BIND 9 limite le rythme de requtes de numro de srie sortantes (20 par seconde) et non pas le nombre de requtes simultanes. Cette limite peut tre ajuste laide de la directive serial-query-rate, dont largument est un nombre entier (nombre de requtes par seconde).

Oprations priodiques
Les serveurs de noms BIND effectuent priodiquement des oprations automatiques dentretien, telles que le rafrachissement des zones sur un esclave. BIND 8 et 9 permettent de contrler lactivit et la priodicit de ces oprations.

Priodicit de purge
Tous les serveurs suppriment passivement les donnes primes de leur mmoire cache. Avant quun serveur ne renvoie un enregistrement un demandeur, il vrie le TTL de lenregistrement pour voir si ce dernier est encore valable. Si ce nest pas le cas, le serveur lance un processus de rsolution pour rechercher une information plus jour. Toutefois, le fait de sappuyer entirement sur ce mcanisme peut conduire une mmoire cache inutilement grande. En effet, un serveur peut conserver de trs nombreux enregistrements prims dans sa mmoire cache. Pour rgler ce problme, BIND parcourt priodiquement la mmoire cache et supprime les enregistrements prims, ce qui permet de minimiser la taille de mmoire utilise par le cache. Par contre, le processus de purge utilise du temps-machine, ce qui peut tre gnant sur les serveurs trs lents ou trs chargs. Par dfaut, la priodicit de purge est xe 60 minutes. On peut la modier laide de la directive cleaning-interval de la structure options. Par exemple :
options { cleaning-interval 120; };
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Paramtrer le systme

249

Cette option xe la priodicit de purge 120 minutes. Pour dsactiver le processus de purge, il suft de xer une priodicit 0.

Frquence de surveillance des interfaces


Nous avons signal que BIND, par dfaut, est lcoute de toutes les interfaces dun hte multi-domicili. BIND 8 ou 9 surveille priodiquement ltat des interfaces pour dterminer celles qui ont dmarr ou se sont arrtes. Par dfaut, lintervalle de surveillance des interfaces est x 60 minutes. Si un serveur de noms na pas dinterface dynamique, on peut dsactiver la surveillance des nouvelles interfaces en ramenant lintervalle 0, an dviter une surveillance horaire inutile :
options { interface-interval 0; };

Par contre, si un hte dmarre ou arrte des interfaces plus souvent quune fois par heure, on peut rduire lintervalle de surveillance.

Intervalle de gnration des statistiques


Le rglage de lintervalle de gnration des statistiques par BIND 8 ou 9 na pas une grande inuence sur les performances, mais cest malgr tout le meilleur endroit pour en parler. La syntaxe de la directive statistics-interval est analogue celle des autres intervalles :
options { statistics-interval 60; };

La valeur par dfaut est de 60 minutes et une valeur 0 dsactive la gnration des statistiques. BIND 9 ne gnrant pas de statistiques vers syslog, il ne dispose pas doptions de rglage concernant les statistiques.

TTL
En interne, BIND limite le TTL des enregistrements en mmoire cache des valeurs raisonnables. BIND 8 et 9 permettent de rgler ces limites. Depuis BIND 8.2, et avec toutes les versions de BIND 9, on peut limiter le TTL dune rponse ngative avec la sous-structure max-ncache-ttl de options. Pour ceux qui passent BIND 8.2, il sagit dun garde-fou qui met en uvre le nouveau mcanisme de mmoire cache ngative (RFC 2308, dcrit au Chapitre 4). Cette version de BIND gre en mmoire cache les rponses ngatives en utilisant le dernier champ de lenregistrement SOA. Or, de nombreux administrateurs utilisent encore ce champ pour xer la valeur par dfaut du TTL de leur zone, valeur en gnral trop grande pour grer lexpiration dune rponse ngative. Aussi, un administrateur prudent peut-il utiliser la sousstructure :
options { max-ncache-ttl 3600; // 1 heure };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

250

Chapitre 10 Fonctionnalits avances

pour limiter une heure le TTL dune rponse ngative. La valeur standard est de 10800 secondes (3 heures). Sans cette prcaution, il est possible que quelquun qui recherche un nouvel enregistrement, obtienne une rponse ngative (peut-tre parce que ce nouvel enregistrement nest pas encore parvenu tous les esclaves) et que son serveur place trop longtemps cette rponse ngative dans sa mmoire cache, empchant ainsi la rsolution de nom correspondante. BIND 9 ajoute la possibilit de limiter le TTL sur les enregistrements placs en mmoire cache avec la sous-structure max-cache-ttl. La valeur standard est dune semaine. BIND 8 offre la mme limitation, mais elle nest pas rglable. Enn, il reste le lame TTL, qui nest pas proprement parler un TTL. Cette valeur reprsente la dure pendant laquelle un serveur se souvient quun serveur distant ne fait pas autorit sur une zone qui lui est dlgue. Cela vite au serveur de perdre du temps et des ressources en interrogeant un serveur sur des donnes dont il ignore tout. BIND 8 depuis la version 8.2 et BIND 9 depuis la version 9.1.0 permettent dajuster cette valeur avec la sous-structure lame-ttl de options. La valeur Sil est possible dannuler cette mmorisation avec une valeur nulle, cela nest pas trs conseill.

Compatibilit
Cette section traite des rglages relatifs la compatibilit dun serveur de noms avec des resolvers ou dautres serveurs de noms. La sous-structure rfc2308-type1 xe le format des rponses ngatives envoyes par un serveur. En standard, BIND 8 et 9 placent uniquement lenregistrement SOA dans une rponse ngative. Il est aussi possible dinclure les enregistrements NS de la zone, mais certains anciens serveurs interprtent cette rponse comme une rfrence dautres serveurs. Si malgr tout on souhaite envoyer ces enregistrements NS (mais nous nen voyons vraiment pas lintrt), on peut utiliser la dclaration :
options { rfc2308-type1 yes; };

rfc2308-type1 a t introduit avec BIND 8.2 mais nest pas gr par BIND 9. Certains anciens serveurs peuvent avoir des problmes lors de la rception de rponses ngatives. Avant linvention de la mise en mmoire cache des rponses ngatives, toutes les rponses ngatives taient considres comme faisant autorit. Aussi certains dveloppeurs avaient-ils ajout un test aux serveurs, pour naccepter que les rponses ngatives faisant autorit. Depuis linstitution de la mmoire cache ngative, des rponses ngatives peuvent ne pas faire autorit, ce qui pose problme avec le test effectu sur certains anciens serveurs. La sous-structure auth-nxdomain de options permet un serveur de dclarer quune rponse ngative issue de sa mmoire cache fait en ralit autorit, cest--dire exactement ce quattend un ancien serveur modi. En standard, auth-nxdomain est actif (initialis yes) dans BIND 8 ; cest linverse avec BIND 9. Lorsque des dveloppeurs ont port BIND 8.2.2 sur Windows NT, ils ont dcouvert que le serveur devait traiter un retour-chariot (carriage return) suivi dun saut de ligne (newline) (la squence Windows indiquant une n de ligne) de la mme manire quun

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Les bases de ladressage IPv6

251

simple saut de ligne (une n de ligne en Unix). Pour obtenir ce comportement, il faut utiliser :
options { treat-cr-as-space yes; };

BIND 9 na pas besoin de cette option, car il traite ces deux cas de la mme manire, cest--dire comme un simple saut de ligne. Enn, si lun des serveurs BIND est esclave de Microsoft DNS Servers avec des zones intgres dans Active Directory, on peut ventuellement voir un message syslog informant que le numro de srie des zones a diminu. Cest un effet de bord du mcanisme de rplication utilis par Active Directory et il ne faut pas sen inquiter. Si on veut viter ce message, on peut utiliser la sous-structure multi-master de zone de BIND 9.3.0 pour indiquer lesclave que les adresses IP de la directive masters correspondent en ralit plusieurs serveurs, et non plusieurs interfaces dun mme serveur :
zone "_msdcs.domain.com" { type slave; masters { 10.0.0.2; 10.0.0.3; }; file "bak._msdcs.domain.com"; multi-master yes; };

Les bases de ladressage IPv6


Avant daborder les deux prochains sujets (Adresses et ports et Correspondance directe et inverse en IPv6), nous dcrivons la reprsentation et la structure des adresses IPv6. Les adresses IPv6 ont une longueur de 128 bits. La reprsentation la plus courante est celle qui groupe les nombres en huit lments de quatre chiffres hexadcimaux, spars par des deux-points :
2001:db80:0123:4567:89ab:cdef:0123:4567

Le premier groupe (2001 ici) est llment le plus signicatif de ladresse. Il reprsente les 16 bits de poids forts de ladresse. Dans la reprsentation, les groupes de nombres qui commencent par un ou plusieurs zros nont pas besoin dtre cals sur quatre chiffres. On peut donc donner une nouvelle reprsentation de ladresse prcdente :
2001:db80:123:4567:89ab:cdef:123:4567

Chaque groupe doit contenir au moins un nombre, sauf si on utilise la notation :: . Elle permet de condenser la reprsentation dune suite de zros, ce qui est pratique, par exemple, pour dnir un prxe IPv6 :
2001:db80:dead:beef::

Cette adresse xe les 64 premiers bits dune adresse IPv6 2001:db80:dead:beef et les 64 bits restants zro. :: peut aussi tre utilis au dbut dune adresse IPv6 pour dnir un sufxe. Ainsi, ladresse de bouclage (loopback) IPv6 scrit habituellement :
::1

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

252

Chapitre 10 Fonctionnalits avances

cela signie une suite de 127 zros suivis dun unique 1. :: peut aussi servir au milieu dune adresse pour condenser la reprsentation dune suite de zros :
2001:db80:dead:beef::1

:: ne peut tre utilis quune seule fois dans une adresse, car une utilisation multiple conduirait des ambiguts. Les prxes IPv6 sont dnis dans un format similaire la notation CIDR dIPv4. Les bits signicatifs du prxe sont reprsents selon la notation standard en IPv6 et sont suivis dun slash puis du nombre exact (en dcimal) de bits signicatifs. Ainsi, les trois dnitions de prxes suivantes sont quivalentes :
2001:db80:dead:beef:0000:00f1:0000:0000/96 2001:db80:dead:beef:0:f1:0:0/96 2001:db80:dead:beef:0:f1::/96

Lquivalent IPv6 dune adresse de rseau IPv4 sappelle un prxe de routage global (global routing prex). Il sagit dun nombre variable de bits de poids fort dune adresse IPv6, utilis pour identier un rseau particulier. Toutes les adresses unicast globales ont un prxe de routage global commenant par la valeur binaire 001. Ces adresses sont attribues par un registry dadresses ou par un fournisseur daccs Internet. Le prxe de routage global peut lui-mme tre hirarchique, un registry dadresse tant alors charg dattribuer des bits de poids plus faible diffrents FAI, eux-mmes responsables de lattribution de ces bits de poids faible du prxe leurs clients. la suite du prxe de routage global, une adresse IPv6 peut contenir un autre nombre variable de bits pour dsigner un sous-rseau particulier lintrieur dun rseau ; il sagit alors dun identiant de sous-rseau (subnet ID). Les bits restants de ladresse dnissent une interface particulire et sont appels identiant dinterface (interface ID). Le diagramme de la RFC 3513 dcrit cette structure :
| n bits | m bits | 128-n-m bits | +---------------------------+-------------------+----------------+ | prfixe de routage global | ID de sous-rseau | ID dinterface | +---------------------------+-------------------+----------------+

Conformment la RFC 3177, qui dcrit lattribution des adresses IPv6 aux sites :

les particuliers devraient recevoir un prxe /48 ; les petites et grandes entreprises devraient recevoir un prxe /48 ; les trs grandes entreprises devraient recevoir un prxe /47 ou lgrement plus
court.

Adresses et ports
Comme IPv4 est relativement simple compar IPv6, nous allons dcrire simultanment la conguration dun serveur IPv4 et dun serveur IPv6. Depuis la version 8.4.0 de BIND et avec BIND 9, un serveur peut aussi bien utiliser un transport IPv4 quun transport IPv6, cest--dire quil peut envoyer des requtes et recevoir des rponses via IPv4 ou IPv6. BIND 8 ne fonctionne quen IPv4. Les deux types disposent de sous-structures similaires pour congurer les interfaces et les ports utiliser pour les requtes reues et envoyes.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Adresses et ports

253

Congurer le transport IPv4


On peut xer les interfaces sur lesquelles un serveur BIND 8 ou 9 coute les requtes laide de la sous-structure listen-on, suivie au minimum dune liste dadresses :
options { listen-on { 192.249.249/24; }; };

Le serveur est lcoute de toutes les interfaces correspondant la liste dadresses. Pour dnir un port autre que le port 53, on peut ajouter le paramtre port :
options { listen-on port 5353 { 192.249.249/24; }; };

En BIND 9, on peut mme dnir un port diffrent pour chaque interface :


options { listen-on { 192.249.249.1 port 5353; 192.253.253.1 port 1053; }; };

Notons qutant donn que la plupart des resolvers ne sont pas congurables pour interroger un autre port que le 53, le serveur dni ci-dessus nest pas trs utile. Il peut toutefois servir aux transferts de zone, puisque quon peut prciser un autre port dans une sous-structure masters :
zone "movie.edu" { type slave; masters port 5353 { 192.249.249.1; }; file "bak.movie.edu"; };

Si un serveur BIND 9 a plusieurs serveurs-matres (chacun lcoute dun port diffrent), on peut utiliser une sous-structure masters semblable ce qui suit :
zone "movie.edu" { type slave; masters { 192.249.249.1 port 5353; 192.253.253.1 port 1053; }; file "bak.movie.edu"; };

BIND 9 permet mme denvoyer les messages NOTIFY vers des ports alternatifs. Si le port alternatif est le mme sur tous les esclaves, on peut utiliser :
also-notify port 5353 { 192.249.249.9; 192.253.253.9; }; // les 2 adresses de // zardoz

Si chaque esclave a un port de remplacement propre, on peut utiliser :


also-notify { 192.249.249.9 port 5353; 192.249.249.1 port 1053; };

Si un esclave multi-domicili a besoin dutiliser une interface spcique pour envoyer ses requtes, par exemple si lun de ses matres ne le reconnat que par une seule de ses adresses, on peut utiliser la sous-structure query-source :
options { query-source address 192.249.249.1; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

254

Chapitre 10 Fonctionnalits avances

Notons que largument nest pas une liste dadresses, mais une adresse IP unicast. On peut aussi dnir un port dorigine spcique pour gnrer les requtes :
options { query-source address 192.249.249.1 port 53; };

Le comportement par dfaut de BIND consiste utiliser toute interface dsigne par la route jusqu la destination, ainsi quun port non privilgi, choisi alatoirement :
options { query-source address * port *; };

Notons que query-source ne concerne que les requtes vhicules par UDP ; les requtes achemines par TCP choisissent ladresse dorigine en fonction de la table de routage et un port au hasard. La sous-structure transfer-source fonctionne de manire analogue et permet de xer ladresse dorigine utilise pour un transfert de zone. En BIND 9, elle sapplique aussi aux demandes de SOA faites par un serveur-esclave, ainsi qu la retransmission des mises jour dynamiques :
options { transfer-source 192.249.249.1; };

Comme avec query-source, largument est une simple adresse IP mais sans le mot-cl , address. Avec BIND 8, il ny a pas doption port. Avec BIND 9, on peut dnir le port dorigine :
options { transfer-source 192.249.249.1 port 1053; };

Toutefois, ce port dorigine ne sapplique quau trac UDP (requte de SOA et retransmission de mise jour dynamique). transfer-source peut aussi apparatre dans une sous-structure zone. Dans ce cas, elle naffecte que les transferts de cette zone en BIND 8, mais aussi les requtes de SOA et les mises jour dynamiques en BIND 9 :
zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; transfer-source 192.249.249.1; // utiliser toujours des adresses IP du mme // rseau pour les transferts de movie.edu };

Enn, la sous-structure notify-source de BIND 9.1.0 permet de dnir ladresse partir de laquelle on envoie les messages NOTIFY. Cela est utile avec des serveurs multi-domicilis car, par dfaut, les serveurs-esclaves nacceptent les messages NOTIFY pour une zone que lorsquils proviennent dune adresse IP qui apparat dans la sous-structure masters pour cette zone. La syntaxe de notify-source est semblable celle de toutes les sous-structures -source :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Adresses et ports
options { notify-source 192.249.249.1; };

255

Comme avec transfer-source, notify-source peut comporter un numro de port dorigine et peut tre utilise dans une structure zone lorsquelle ne concerne quune zone spcique :
zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; notify-source 192.249.249.1 port 5353; };

Si on ne peut pas contrler ladresse IP de laquelle proviennent les messages NOTIFY (parce que lon nest pas ladministrateur du serveur-matre, par exemple), on peut soit inclure les adresses IP de tous les matres dans la sous-structure masters, soit utiliser allow-notify pour permettre explicitement les messages NOTIFY pour des adresses non dnies dans masters.

Congurer le transport en IPv6


En standard, un serveur BIND 9 nest pas lcoute des requtes IPv6. La sous-structure listen-on-v6 lui indique dtre lcoute des interfaces locales en IPv6 :
options { listen-on-v6 { any; }; };

Avant BIND 9.3.0, la structure listen-on-v6 nacceptait que les arguments any et none. On peut aussi congurer un serveur BIND pour quil soit lcoute dun port alternatif ou mme de plusieurs ports, avec loption port :
options { listen-on-v6 port 1053 { any; }; };

Pour couter sur plus dune interface ou dun port IPv6, il suft de dclarer plusieurs directives listen-on-v6. Bien sr, le port standard est le port 53. La sous-structure transfer-source-v6 xe ladresse dorigine IPv6 utilise par le serveur pour envoyer des requtes :
options { transfer-source-v6 222:10:2521:1:210:4bff:fe10:d24; };

Elle dnit un port dorigine :


options { transfer-source-v6 222:10:2521:1:210:4bff:fe10:d24 port 53; };

Seul BIND 9 permet de dnir le port dorigine. En standard, ladresse dorigine utilise correspond linterface rseau dsigne par la route vers la destination et le port non privilgi est choisi alatoirement. Comme pour transfer-source, on peut utiliser transfer-

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

256

Chapitre 10 Fonctionnalits avances

source-v6 comme sous-structure de zone. Le port dorigine concerne aussi les requtes de SOA et la retransmission de mises jour dynamiques. Enn, depuis BIND 9.1.0, on peut xer ladresse IPv6 utilise dans les messages NOTIFY avec la sous-structure notify-source-v6, de la mme manire quavec la sous-structure notify-source :
options { notify-source-v6 222:10:2521:1:210:4bff:fe10:d24; };

Comme avec transfer-source-v6, il est possible de prciser un autre port dorigine et de recourir la sous-structure dans une structure zone.

EDNS0
Les messages DNS bass sur UDP sont traditionnellement limits 512 octets. Cette limite a t institue pour viter la fragmentation, qui tait coteuse et peu able aux dbuts dInternet. Les temps ont chang et la plupart des chemins sur Internet peuvent vhiculer des datagrammes UDP plus grands. En raison des nouvelles caractristiques du DNS, telles que DNSSEC ou la prise en compte de IPv6, la taille moyenne des rponses est bien plus importante. En particulier, les rponses provenant des zones signes peuvent facilement dpasser la limite des 512 octets, ce qui peut provoquer des redirections coteuses en TCP . Le mcanisme dextension du DNS version 0 (Extension Mechanisms for DNS, version 0, ou EDNS0) dnit un systme de signalisation simple dans le DNS. Avec EDNS0, un resolver ou un serveur de noms informe un autre serveur quil peut grer des messages DNS plus longs que 512 octets (il peut aussi signaler dautres caractristiques, comme nous le verrons au prochain chapitre). Les serveurs de noms BIND grent EDNS0 depuis les versions 9.0.0 et 8.3.0. Par dfaut, ces serveurs envoient des informations de signalisation EDNS0 et tentent de ngocier une taille de message DNS bas sur UDP de 4096 octets. Sils reoivent une rponse indiquant que le serveur distant ne comprend pas EDNS0, ils utilisent des messages de longueur classique de 512 octets. Cette technique fonctionne gnralement bien mais, parfois, certains serveurs ragissent mal aux sondages EDNS0. Pour faire face ce problme, la directive edns de server permet dinvalider EDNS0 pour ce serveur de noms :
server 10.0.0.1 { edns no; };

Cette directive est disponible depuis BIND 9.2.0 et BIND 8.3.2. Avec BIND 9 depuis sa version 9.3.0 et avec BIND 8 depuis sa version 8.4.0, on peut aussi dnir la taille des messages DNS bass sur UDP que le serveur ngociera, laide de la directive edns-udp-size de options :
options { directory "/var/named"; edns-udp-size 512; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Adresses et ports

257

Cette conguration peut tre utile si un pare-feu ne comprend pas que les messages DNS peuvent dpasser 512 octets et quil continue abandonner ces messages pourtant lgitimes (le mieux serait bien sr de faire voluer le pare-feu, mais cette option peut permettre de patienter). La valeur maximale de edns-udp-size est de 4096 et son minimum est de 512.

Correspondance directe et inverse en IPv6


Lenregistrement A ne peut pas convenir pour les adresses IPv6 sur 128 bits ; en effet, la donne spcique dun enregistrement A doit tre une adresse sur 32 bits, en notation dcimale pointe. Dans la RFC 1886, lIETF a propos une solution trs simple ce problme. Un nouvel enregistrement, AAAA, est utilis pour stocker une adresse IPv6 sur 128 bits, ainsi quun nouveau domaine pour la correspondance inverse, ip6.int. Cette solution est sufsamment simple pour tre intgre mme dans BIND 4. Malheureusement cette solution prsentent quelques inconvnients et une autre solution, plus complexe, a vu le jour. Elle propose de nouveaux enregistrements, A6 et DNAME, et requiert une refonte complte des serveurs de noms BIND. Puis, la suite de nombreux et vifs dbats, lIETF a dcid que le nouveau schma A6/DNAME tait trop coteux, trop instable et que son utilit ntait pas prouve. Au moins temporairement, la RFC dcrivant les enregistrements A6 est repasse du statut de standard celui de norme exprimentale, rendant ainsi inutile lutilisation des enregistrements DNAME et restaurant lancienne RFC 1886. Ce qui tait prim est nouveau au got du jour. Pour le moment, lenregistrement AAAA est la mthode utiliser pour grer la correspondance directe en IPv6. Par contre, ip6.int reste obsolte, au moins pour des raisons politiques, et il a t remplac par ip6.arpa. Dans le but de vous prparer tout changement dans le futur, y compris la rapparition de A6 et DNAME, nous dcrirons les deux mthodes.

AAAA et ip6.arpa
Cette manire daborder le problme de la correspondance directe, dcrite dans la RFC 1886, consiste mettre en place un enregistrement dadresse quatre fois plus long quun enregistrement A, lenregistrement AAAA. Lenregistrement AAAA contient la forme textuelle dune adresse IPv6 :
ipv6-host IN AAAA 2001:db80:1:2:3:4:567:89ab

La RFC 1886 dnit galement ip6.int, maintenant remplac par ip6.arpa, un nouvel espace de noms pour la correspondance inverse des adresses IPv6. Chaque niveau de sous-domaine de ip6.arpa correspond quatre bits de ladresse sur 128 bits, reprsents sous la forme de nombres hexadcimaux. Les bits les moins signicatifs (les bits de poids faible de ladresse) sont positionns gauche dans le nom. la diffrence de la reprsentation des adresses dans lenregistrement AAAA, il est impossible domettre les suites de zros : il faut quil y ait bien 32 nombres hexadcimaux et donc 32 niveaux de sousdomaines correspondant ladresse IPv6 complte. Le nom correspondant ladresse prcdente est alors :
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.8.b.d.1.0.0.2.ip6.arpa.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

258

Chapitre 10 Fonctionnalits avances

Ces noms sont attachs des enregistrements PTR, de la mme manire que ceux du domaine in-addr.arpa :
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.8.b.d.1.0.0.2.ip6.arpa. IN PTR mash.ip6.movie.edu.

A6, DNAME, chanes de bits et ip6.arpa


Pour grer la correspondance directe et inverse en IPv6, une autre mthode, plus complexe et maintenant seulement exprimentale, dnit deux nouveaux types denregistrement, A6 et DNAME. Ils sont respectivement dcrits dans les RFC 2874 et 2672. BIND 9.0.0 tait la premire version de BIND pouvoir les grer.
Il ny a aucune garantie que cette mthode de gestion de la correspondance directe et inverse en IPv6 nisse par merger et les dernires versions de BIND ne la mettent pas totalement en uvre.Vous perdez peut-tre votre temps en lisant cette section, tout comme nous avons peut-tre perdu le ntre en lcrivant. Nous la conservons toutefois ici parce que les mthodes sont cycliques et A6 et ses copains pourraient revenir sur le devant de la scne. Si vous voulez exprimenter A6 et les chanes de bits, rcuprez un serveur BIND 9.2.x. LISC a retir la gestion des chanes de bits partir de BIND 9.3.0 et annonce que A6 nest dj plus totalement pris en charge. Notez aussi que les chanes de bits peuvent poser des problmes dinteroprabilit avec certains logiciels de DNS.

La raison principale du remplacement de lenregistrement AAAA et du schma de correspondance inverse ip6.int tait quils rendaient difciles les re-numrotations. Ainsi, si une entreprise dcide de changer de FAI, elle doit changer tous les enregistrements AAAA dans ses chiers de zone, puisque certains des bits dune adresse IPv6 identient un le FAI14. On peut imaginer limpact dun changement de registry dadresse par le FAI : cela bouleverserait toutes les donnes de zone de ses clients.

Enregistrement A6 et correspondance directe


Pour faciliter la re-numrotation, un enregistrement A6 peut ne dnir quune partie dadresse IPv6, comme par exemple les 64 derniers bits (peut-tre lID dinterface) attribus linterface rseau dun hte, le reste de ladresse tant dni par un nom symbolique. Cela permet aux administrateurs de zone de ne dnir que la partie de ladresse qui est sous leur contrle. Pour construire une adresse complte, un resolver ou un serveur de noms doit suivre la chane denregistrements A6 dun nom dhte, jusqu lID du registry. Cette chane peut comporter des branches si un rseau de site est connect plusieurs FAI ou si un FAI est connect plusieurs registries dadresse. Ainsi, lenregistrement A6 :
$ORIGIN movie.edu. drunkenmaster IN A6 64 ::0210:4bff:fe10:0d24 subnet1.v6.movie.edu.

14. De plus, le nouveau FAI peut utiliser un registry diffrent, ce qui implique de modier encore plus de bits.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Adresses et ports

259

dnit les 64 derniers bits de ladresse IPv6 de drunkenmaster.movie.edu, cest--dire lID dinterface. Le nombre 64 qui apparat dans lenregistrement indique que les 64 premiers bits ne sont pas dnis dans cet enregistrement A6, mais quils le sont dans lenregistrement A6 de subnet1.v6.movie.edu. subnet1.v6.movie.edu dnit les 16 derniers bits du prxe de 64 bits, cest--dire lID de sous-rseau qui nest pas dni dans ladresse de lenregistrement A6 de drunkenmaster.movie.edu, mais galement le nom de lenregistrement A6 quil faut chercher pour connatre les premiers bits
$ORIGIN v6.movie.edu. subnet1 IN A6 48 0:0:0:1:: movie-u.isp-a.net. subnet1 IN A6 48 0:0:0:1:: movie.isp-b.net.

Les 48 premiers bits du prxe dans lenregistrement A6 de subnet1.v6.movie.edu sont initialiss 0 car ils nont pas de signication ici. Ces deux derniers enregistrements indiquent de chercher deux autres enregistrements A6, lun de nom movie-u.isp-a.net et lautre de nom movie.isp-b.net pour dcouvrir le dbut du prxe. Lexistence de deux enregistrements vient du fait que lUniversit du Cinma est connecte deux FAI, FAI A et FAI B. Dans la zone du FAI A, on trouve :
$ORIGIN isp-a.net. movie-u IN A6 40 0:0:21:: isp-a.rir-1.net.

qui dnit 8 bits du prxe de routage global dni par le FAI A pour lUniversit du Cinma (le prxe de routage global peut tre lui-mme hirarchique : il comprend la fois une identication du FAI, attribue par son registry dadresse, et une identication du site de lUniversit du Cinma). Puisque le FAI attribue une partie des bits du prxe de routage global mais que le reste du prxe est attribu par son registry dadresse, seuls les bits attribus par le FAI apparaissent dans les donnes de zone du FAI. Le reste du prxe est dni dans un enregistrement A6 dans les donnes de zone du registry dadresse. Dans la zone du FAI B, lenregistrement suivant dnit lidentiant de site du rseau de lUniversit du Cinma :
$ORIGIN isp-b.net. movie IN A6 40 0:0:42:: isp-b.rir-2.net.

Dans les zones des registries dadresse, on trouve les quatre bits suivants de ladresse IPv6 :
$ORIGIN rir-1.net. isp-a IN A6 36 0:0:0500:: rir-2.top-level-v6.net.

et :
$ORIGIN rir-2.net. isp-b IN A6 36 0:0:0600:: rir-1.top-level-v6.net.

Enn, dans la zone de lorganisme denregistrement des adresses de plus haut niveau, on trouve les enregistrements dnissant les bits des prxes attribus au RIR 1 et au RIR 2 :
$ORIGIN top-level-v6.net. rir-1 IN A6 0 2001:db80::2 rir-2 IN A6 0 2001:db80::6

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

260

Chapitre 10 Fonctionnalits avances

En suivant cet enchanement denregistrements A6, un serveur de noms peut reconstituer lensemble des 128 bits des deux adresses IPv6 de drunkenmaster.movie.edu :
2001:db80:2521:1:210:4bff:fe10:d24 2001:db80:6642:1:210:4bff:fe10:d24

Pour atteindre le rseau de lUniversit, la premire de ces deux adresses donne une route via le RIR 1 et le FAI A, et la seconde une route via le RIR 2 et le FAI B (luniversit est connecte deux FAI pour la redondance). Notons que si le RIR 1 modie le prxe attribu au FAI A, il lui suft de modier lenregistrement A6 de isp-a.rir-1.net dans sa zone ; les modications seront vues en cascade dans tous les enchanements denregistrements A6 mettant en jeu le FAI A. Cela facilite la gestion de ladressage dans les rseaux IPv6 et permet aussi de changer facilement de FAI. Vous voyez peut-tre dj certains des problmes lis aux enregistrements A6. La rsolution de noms vers une simple adresse IPv6 peut ncessiter plusieurs requtes indpendantes (recherche des enregistrements A6 du RIR, du FAI, etc). La rsolution complte peut prendre plusieurs fois le temps dune recherche denregistrement AAAA, et si lune des rsolutions lmentaires choue, la totalit du processus de rsolution choue aussi.
Si un serveur apparat dans un enregistrement NS, associ un ou plusieurs enregistrements A6, ces derniers doivent dnir la totalit des 128 bits de ladresse IPv6. Cela vite les problmes dinterblocage qui apparatraient lors du contact dun serveur distant par un resolver ou un serveur pour rsoudre une partie de ladresse IPv6 du serveur.

Enregistrement DNAME et correspondance inverse


Maintenant que nous connaissons le principe de la correspondance directe avec les enregistrements A6, tudions celui de la correspondance inverse entre une adresse IPv6 et un nom. Comme cela est dj le cas pour les enregistrements A6, la correspondance inverse nest pas aussi simple quavec ip6.arpa. Cette correspondance inverse met en jeu les enregistrements DNAME, dcrits dans la RFC 2672, ainsi que les chanes de bits (bitstring labels), introduites par la RFC 2673. Les enregistrements DNAME ressemblent des enregistrements CNAME gnriques. Ils servent substituer un sufxe par un autre. Par exemple, si nous avions utilis le nom movieu.edu pour lUniversit du Cinma par le pass, et que nous lavions remplac par le nom movie.edu, nous pouvons remplacer les donnes de lancienne zone movieu.edu par :
$TTL 1d @ IN SOA toystory.movie.edu. root.movie.edu. ( 2000102300 3h 30m 30d 1h ) IN NS toystory.movie.edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Adresses et ports
IN IN IN NS MX wormhole.movie.edu. 10 postmanrings2x.movie.edu.

261

DNAME movie.edu.

Lenregistrement DNAME dans la zone movieu.edu sapplique tous les noms qui se terminent par movieu.edu sauf movieu.edu lui-mme. la diffrence dun enregistrement CNAME, un enregistrement DNAME peut coexister avec dautres types denregistrements associs au mme nom, condition quils ne soient ni un CNAME ni un autre DNAME. Cependant, le nom associ lenregistrement DNAME ne peut pas avoir de sous-domaine. Lorsquun serveur de movieu.edu reoit une requte de nom se terminant par movieu.edu, par exemple cuckoosnest.movieu.edu, lenregistrement DNAME lui indique de construire un alias de cuckoosnest.movieu.edu vers cuckoosnest.movie.edu, en remplaant, en quelque sorte, le nom movieu.edu par movie.edu :
cuckoosnest.movieu.edu. IN CNAME cuckoosnest.movie.edu.

Cela ressemble la commande s (substitute) de sed. Le serveur de noms de movieu.edu rpond par cet enregistrement CNAME. Sil rpond un serveur rcent, il joint lenregistrement DNAME la rponse, ce qui permet au serveur qui interroge de construire lui-mme ses propres enregistrements CNAME partir de lenregistrement DNAME quil aura plac dans sa mmoire cache. Les chanes de bits (Bitstring labels) constituent la seconde moiti du mcanisme mis en jeu dans la correspondance inverse en IPv6. Les chanes de bits sont simplement un moyen de condenser une longue squence de noms reprsentant chacun un nombre binaire (cest--dire un bit) dans un nom complet. En effet, on veut construire une dlgation correspondant chaque bit dune adresse IP ce qui implique de reprsenter , chaque bit de ladresse par un nom dans un nom complet. Mais cela ncessiterait de dnir 128 noms pour reprsenter une adresse IPv6. Du pain sur la planche ! Et cela dpasse la limite sur le nombre de termes dans un nom totalement quali ! Les chanes de bits concatnent les bits en un raccourci hexadcimal, octal, binaire ou une chane doctets en notation pointe. La chane est encadre par \[ et ] pour la diffrencier dun nom traditionnel et commence par une lettre qui indique la base utilise dans la chane : b pour le binaire, o pour loctal et x pour lhexadcimal. Voici les chanes qui correspondent aux deux adresses IPv6 de drunkenmaster.movie.edu :
\[x2001db802521000102104bfffe100d24] \[x2001db806642000102104bfffe100d24]

Notons que le bit le plus signicatif est au dbut de la chane, comme dans la reprsentation de ladresse IPv6, mais dans le sens oppos de lordre des tiquettes dans le domaine in-addr.arpa. Il ne sagit que de reprsentations diffrentes dun mme nom standard codant ladresse, en commenant par les poids faibles :
0.0.1.0.0.1.0.0.1.0.1.1.0.0.0.0.0.0.0.0.1.0.0.0.0.1.1.1.1.1.1.1...

Notons galement que les 32 nombres hexadcimaux de ladresse sont prsents dans cette reprsentation : il nest pas possible de condenser les zros, car il ny a pas de : pour sparer les groupes de quatre nombres.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

262

Chapitre 10 Fonctionnalits avances

Les chanes de bits peuvent aussi permettre de dnir des parties dadresse IPv6, ce qui ncessite de dnir le nombre de bits signicatifs dans la chane, spar de la chane par un slash. Ainsi la portion de prxe de routage global attribue au RIR est \[x2001db802/ 36]. Associs, les DNAME et les chanes de bits sont utiliss pour mettre en correspondance des parties dun nom long qui reprsentent une adresse IPv6 et pour modier chaque itration le nom recherch vers un nom situ dans la zone sous contrle de lorganisme qui gre lhte avec cette adresse IPv6. Supposons que nous fassions une recherche inverse du nom \[x2001db806642000102104bfffe100d24].ip6.arpa, qui correspond linterface rseau de lhte drunkenmaster.movie.edu lorsquil est atteint via le RIR 2 et le FAI B. Les serveurs de la racine indiqueront probablement de sadresser aux serveurs de ip6.arpa, qui contiennent ces enregistrements :
$ORIGIN ip6.arpa. \[x2001db802/36] \[x2001db806/36] IN IN DNAME DNAME ip6.rir-1.net. ip6.rir-2.net.

Le second de ces deux enregistrements correspond au dbut du nom que nous cherchons, aussi les serveurs de ip6.arpa rpondent-ils par lalias suivant :
\[x2001db806642000102104bfffe100d24].ip6.arpa. IN CNAME \[x642000102104bfffe100d24].ip6.rir-2.net.

Notons que les neuf premiers nombres hexadcimaux (les 36 bits les plus signicatifs) de ladresse ont t limins et que la n de la cible de lalias est maintenant ip6.rir-2.net, cette adresse appartenant au RIR 2. Dans ip6.rir-2.net, nous trouvons :
$ORIGIN ip6.rir-2.net. \[x6/4] IN DNAME ip6.isp-b.net.

Cela remplace le nom recherch :


\[x642000102104bfffe100d24].ip6.rir-2.net

par :
\[x42000102104bfffe100d24].ip6.isp-b.net

Ensuite, le serveur de noms interroge un serveur de ip6.isp-b.net au sujet de ce nouveau nom. Lenregistrement suivant de la zone ip6.isp-b.net :
$ORIGIN ip6.isp-b.net. \[x42/8] IN DNAME ip6.movie.edu.

remplace le nom que nous cherchions par :


\[x000102104bfffe100d24].ip6.movie.edu

Enn, la zone ip6.movie.edu contient lenregistrement PTR qui renvoie vers le nom dhte recherch :
$ORIGIN ip6.movie.edu. \[x000102104bfffe100d24/80] IN PTR drunkenmaster.ip6.movie.edu.

Notons que nous aurions pu utiliser un autre DNAME pour le sous-rseau 1.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Adresses et ports

263

Heureusement, en temps quadministrateur de zone, on ne sera probablement responsable que de lenregistrement PTR tel que ceux dans ip6.movie.edu. Mme si on travaille pour un RIR ou un FAI, la cration denregistrements DNAME permettant dextraire les bits adquats du prxe de routage global pour les adresses des clients nest pas aussi lourde que cela. De plus, mme si un hte a plusieurs adresses ou si on est connect plusieurs FAI, on gagne en souplesse navoir quun seul chier de correspondance inverse grer.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

11
Scurit
Jespre que vos cheveux tiennent bien ? poursuivit-il, tandis quils se remettaient en route. Comme ceux de tout le monde, rpondit Alice en souriant. Ce nest gure suffisant, dit-il dune voix angoisse. Le vent est tellement fort ici, vous voyez. Il est fort comme la soupe. Avez-vous invent un systme pour empcher les cheveux dtre souffls par le vent ? senquit Alice. Pas encore, dit le Cavalier, mais jai dj un systme pour les empcher de tomber.

Pourquoi faut-il se proccuper de scurit avec le DNS ? Pourquoi perdre du temps scuriser un service dont le rle essentiel est de mettre en correspondance des noms et des adresses ? Et bien, lisez la petite histoire qui suit. En juillet 1997, durant deux priodes de quelques jours, des utilisateurs pensant se connecter sur le site web dInterNIC (www.internic.net) aboutissent en fait sur celui dAlterNIC. Ce dernier gre un autre ensemble de serveurs de la racine, qui cre des dlgations vers des domaines supplmentaires tels que med et porn. Eugene Kashpureff, alors membre dAlterNIC, vient dexcuter un programme pour empoisonner la mmoire cache de plusieurs serveurs de noms principaux travers le monde, an de leur faire croire que ladresse de www.internic.net est en ralit celle du serveur web dAlterNIC. Kashpureff na fait aucune tentative de mystication ; le site web atteint par les utilisateurs est effectivement celui dAlterNIC et non une imitation de celui dInterNIC. Mais imaginons une opration similaire pour rediriger www.amazon.com ou www.wellsfargo.com vers un serveur priv, install hors de porte des lois locales. Imaginons quun utilisateur lui fournisse son numro de carte de crdit et la date dexpiration. Il ny a pas grand chose de plus dire ! La protection des utilisateurs contre ce type dattaque sappuie sur la scurit au niveau du DNS. Plusieurs axes sont envisageables. On peut scuriser les transactions : les requtes, les rponses et tous les messages reus ou envoys par un serveur de noms. On

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

266

Chapitre 11 Scurit

peut scuriser le serveur de noms en refusant de rpondre, de transfrer une zone ou de la mettre jour dynamiquement selon ladresse dorigine de la requte. On peut mme scuriser les informations dune zone en leur appliquant une signature. Puisque la scurit est le sujet le plus complexe du DNS, nous commencerons par le plus simple et terminerons par le plus ardu.

TSIG
BIND 8.2 introduit un nouveau mcanisme de scurisation des messages DNS, la signature de transaction (Transaction SIGnature ou TSIG). TSIG est bas sur un secret partag (des cls) et utilise une fonction de hachage non inversible pour authentier les messages DNS, particulirement les rponses et les mises jour. TSIG, dni dans la RFC 2845, est relativement simple congurer, lger pour les resolvers et les serveurs de noms, et sufsamment exible pour scuriser les messages DNS (y compris les transferts de zone) et les mises jour dynamiques (en cela, il contraste avec les extensions de scurit du DNS, qui seront prsentes la n de ce chapitre). Lorsque TSIG est congur, un serveur de noms, ou un updater, place un enregistrement TSIG dans la section des enregistrements complmentaires dun message DNS. Lenregistrement TSIG signe le message, ce qui permet de prouver que lexpditeur et le destinataire partagent la mme cl et que le message na pas t modi depuis son envoi1.

Fonction de hachage non inversible


TSIG fournit authentication et intgrit grce une fonction de hachage non inversible (one-way hash function). Une telle fonction, aussi appele somme de contrle (cryptographic checksum) ou condensat (message digest), calcule une valeur de hachage dune taille prdnie partir dun message de taille arbitraire. Chaque bit de la valeur de hachage dpend la fois de chacun des autres bits et de chaque bit du message. Si on modie un bit du message, la valeur de hachage change totalement et de manire non prvisible, ce qui fait quil est techniquement infaisable , connaissant une valeur de hachage, dinverser la fonction et de trouver un message qui aurait produit la valeur de hachage de dpart. TSIG utilise la fonction de hachage MD5, et plus spciquement la variante HMACMD5, dont la valeur de hachage de 128 bits dpend non seulement du message mais aussi dune cl.

Lenregistrement TSIG
Nous ne dcrirons pas lenregistrement TSIG en dtail car cela est inutile : il napparat jamais, ni dans les informations dune zone, ni en mmoire cache de resolver ou de

1.

Les spcialistes de la cryptographie argueront que les signatures TSIG ne sont pas rellement des signatures au sens du chiffrement, car elles ne fournissent pas le service de non rpudiation. Comme tous les dtenteurs de la cl partage peuvent crer un message sign, le destinataire dun message sign ne peut pas prtendre que seul lexpditeur peut avoir envoy le message (le destinataire peut lavoir lui-mme forg).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

TSIG

267

serveur de noms. Un expditeur ajoute lenregistrement TSIG au message DNS, le destinataire le supprime et vrie lenregistrement avant de le traiter. Par contre, il est utile de savoir que lenregistrement TSIG contient une valeur de hachage calcule sur lensemble du message DNS et sur certains champs complmentaires (ces informations sont fournies lalgorithme HMAC-MD5 pour gnrer la valeur de hachage). La valeur de hachage est ensuite chiffre laide dune cl prive partage entre le signataire et le vricateur. La vrication de la valeur de hachage prouve que le message DNS a t sign par un dtenteur de la cl partage et quil na pas t modi aprs signature. Les champs complmentaires signs par TSIG comprennent la date et lheure de signature du message DNS, an dviter quun pirate ne rejoue ultrieurement une transaction signe et autorise suite une capture (par exemple une mise jour dynamique supprimant un enregistrement de ressources important). Le destinataire vrie que lheure de signature est sufsamment rcente.

Congurer TSIG
Avant dutiliser TSIG pour lauthentication, il faut congurer une ou plusieurs cls TSIG chaque extrmit de la transaction. Ainsi, si on veut utiliser TSIG pour scuriser les transferts de zone entre le serveur-matre et les serveurs-esclaves de movie.edu, il faut congurer tous les serveurs avec une cl commune :
key toystory-wormhole.movie.edu. { algorithm hmac-md5; secret "skrKc4Twy/cIgIykQu7JZA=="; };

Largument de la structure key de cet exemple, toystory-wormhole.movie.edu., est en ralit le nom de la cl, bien quil ressemble un nom de domaine (il est cod dans un message DNS au mme format que les noms de domaine). La RFC dcrivant TSIG recommande de nommer les cls daprs le nom des deux htes qui lutilisent. La RFC conseille aussi dutiliser une cl spcique par paire dhtes. Cette disposition permet de se prmunir contre la divulgation dune cl unique, ce qui compromettrait toutes les communications, grce la limitation de lutilisation de chaque cl. Il est important que le nom de la cl, et pas seulement la valeur quelle contient, soit exactement le mme aux deux extrmits de la transaction. Si ce nest pas le cas, le destinataire tente de vrier lenregistrement TSIG et dcouvre quil ne connat pas la cl annonce par cet enregistrement et utilise pour signer le message. Un message derreur apparat :
Jan 4 16:05:35 wormhole named[86705]: client 192.249.249.1#4666: request has invalid signature: TSIG tsig-key.movie.edu: tsig verify failure (BADKEY)

Pour le moment, le seul algorithme est hmac-md5. La sous-structure secret mmorise la cl, code en base 64. Le programme dnssec-keygen de BIND 9 ou dnskeygen de BIND 8 permet de gnrer de telles cls. dnssec-keygen est le plus facile utiliser :
# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST toystory-wormhole.movie.edu. Ktoystory-wormhole.movie.edu.+157+28446

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

268

Chapitre 11 Scurit

Loption a permet de dnir lalgorithme avec lequel la cl sera utilise (dnssec-keygen peut gnrer dautres types de cl ; voir la section Extensions de scurit du DNS). Loption b dnit la longueur de la cl ; la RFC recommande des signatures avec des cls de 128 bits. Loption n dnit le type de cl gnrer, ici HOST (DNSSEC utilise des cls de type ZONE). La dernire valeur est le nom de la cl. dnssec-keygen et dnskeygen crent tous deux des chiers situs dans leur rpertoire de travail, et contenant les cls gnres. dnssec-keygen afche le prxe des noms de ces chiers. Ici, dnssec-keygen cre les chiers Ktoystory-wormhole.movie.edu.+157+28446.key et Ktoystory-wormhole.movie.edu.+157+28446.private. Les nombres 157 et 28446 reprsentent, respectivement, la rfrence dalgorithme de cl de DNSSEC (157 pour HMACMD5) et un identiant pour la cl gnre (une valeur de hachage calcule partir de la cl). Cet identiant ne sert pas TSIG, mais il est utile pour DNSSEC, qui accepte plusieurs cls par zone. Le chier Ktoystory-wormhole.movie.edu.+157+28446.key contient :
toystory-wormhole.movie.edu. IN KEY 512 3 157 skrKc4Twy/cIgIykQu7JZA==

et le chier Ktoystory-wormhole.movie.edu.+157+28446.private contient :


Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: skrKc4Twy/cIgIykQu7JZA==

On peut aussi choisir soi-mme sa propre cl et la coder en base 64 laide de mmencode :


% mmencode foobarbaz Zm9vYmFyYmF6

Comme la valeur de la cl est condentielle, son transfert vers tous les serveurs doit tre entour de prcautions (par exemple en utilisant ssh) et on doit sassurer que personne ne peut y accder en lecture. En particulier, le chier named.conf ne doit pas tre en lecture publique ; on peut aussi placer les structures key dans un chier annexe non accessible en lecture publique, puis charger ce chier par une structure include :
include "/etc/dns.keys.conf";

Reste enn le problme crucial de la synchronisation temporelle. Lestampille temporelle place dans lenregistrement TSIG sert empcher quune transaction ne soit rejoue. En cas de dsynchronisation, les messages sont rejets (les horloges des serveurs de noms ne doivent pas tre dcales de plus de cinq minutes) :
wormhole named[86705]: client 192.249.249.1#54331: request has invalid signature: TSIG toystory-wormhole.movie.edu.: tsig verify failure (BADTIME)

La solution la plus simple et la plus rapide est de mettre en uvre NTP (Network Time Protocol)2, un protocole de synchronisation temporelle.

2.

Voir le site http://www.eecis.udel.edu/~ntp pour des informations sur NTP .

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

TSIG

269

Utiliser TSIG
Maintenant que les cls TSIG sont congures, on peut les utiliser. Depuis BIND 8.2 et avec toutes les versions de BIND 9, TSIG permet de scuriser les requtes, les rponses, les transferts de zone et les mises jour dynamique. Cest le rle de la sous-structure keys de la structure server. La structure server suivante indique au serveur, ici wormhole.movie.edu, de signer les requtes vers 192.249.249.1 (toystory.movie.edu) avec la cl toystory-wormhole.movie.edu :
server 192.249.249.1 { keys { toystory-wormhole.movie.edu.; }; };

Si on est uniquement concern par les transferts de zone (et non par lensemble du trac de requtes), on peut dnir la cl dans la directive masters pour toutes les zones esclave :
zone "movie.edu" { type slave; masters { 192.249.249.1 key toystory-wormhole.movie.edu.; }; file "bak.movie.edu"; };

Sur toystory.movie.edu, les transferts de zone peuvent tre restreints aux requtes signes avec la cl toystory-wormhole.movie.edu :
zone "movie.edu" { type master; file "db.movie.edu"; allow-transfer { key toystory-wormhole.movie.edu.; }; };

toystory.movie.edu signe aussi les donnes transfres, ce qui permet wormhole.movie.edu de les vrier. On peut aussi restreindre les mises jour dynamiques laide de TSIG, en utilisant les sous-structures allow-update et update-policy (voir le Chapitre 17). Le programme nsupdate, fourni avec BIND 8 depuis la version 8.2 et toutes les versions de BIND 9, est compatible avec TSIG. Si les cls ont t cres par dnssec-keygen, on peut utiliser nimporte lequel des deux noms de chiers crs avec loption k de nsupdate. Voici comment utiliser la version de nsupdate livre avec BIND 9 :
% nsupdate -k Ktoystory-wormhole.movie.edu.+157+28446.key

ou :
% nsupdate -k Ktoystory-wormhole.movie.edu.+157+28446.private

La syntaxe de nsupdate en BIND 8 est lgrement diffrente : k dnit un rpertoire et un nom de cl, spars par un : :
% nsupdate -k /var/named:toystory-wormhole.movie.edu.

Si les chiers ne sont pas disponibles en local (par exemple si on utilise nsupdate sur un autre hte), on peut encore dnir le nom de cl et la cl secrte en ligne de commande, avec la version BIND 9 de nsupdate :
% nsupdate -y toystory-wormhole.movie.edu.:skrKc4Twy/cIgIykQu7JZA==
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

270

Chapitre 11 Scurit

Le nom de la cl est le premier argument de loption y ; il est suivi dun caractre : , puis de la valeur secrte code en base 64. Il nest pas ncessaire de placer cette dernire entre guillemets pour la protger dune interprtation par le Shell, car les valeurs codes en base 64 ne peuvent contenir aucun mta-caractre de Shell. Le module Perl Net::DNS de Michael Fuhr permet aussi de gnrer des mises jour dynamiques et des requtes de transfert de zone signes par TSIG. Pour plus dinformation sur Net::DNS, voyez le Chapitre 15. Maintenant que nous avons prsent un mcanisme pratique pour scuriser les transactions du DNS, nous allons tudier la scurisation dun serveur de noms.

Scuriser un serveur
BIND 8 et 9 disposent de plusieurs fonctions de scurit, particulirement importantes pour les serveurs connects lInternet, mais aussi utiles en interne. Nous prsenterons tout dabord des mesures qui devraient tre prises sur tous les serveurs pour lesquels la scurit est importante. Nous aborderons ensuite un modle o les serveurs sont rpartis en deux classes, lune uniquement pour rpondre aux requtes des resolvers, lautre pour rpondre celles des autres serveurs.

Version de BIND
Lun des meilleurs moyens pour augmenter la scurit est dinstaller une version rcente de BIND. Toutes les versions antrieures BIND 8.4.7 ou BIND 9.2.3 sont vulnrables au moins quelques attaques connues. LISC gre une liste des vulnrabilits en fonction des versions de BIND : http://www.isc.org/sw/bind/bind-security.php. Mais ne vous contentez pas de cela : de nouvelles attaques apparaissent quotidiennement. Il faut donc tenir jour son exemplaire de BIND. Il est conseill de lire rgulirement le forum comp.protocols.dns.bind ou de sabonner la liste quivalente, bindusers. On peut aussi se contenter de la liste bind-announce qui annonce les nouveaux correctifs ou les nouvelles versions3. La version de BIND elle-mme est un lment de scurit : si un pirate peut facilement dcouvrir la version de BIND utilise sur un serveur, il peut orienter des attaques en fonction des failles connues pour cette version. Or depuis BIND 4.9, si on cherche sur un serveur lenregistrement TXT associ au nom version.bind dans la classe CHAOSNET, BIND rpond par son numro de version :
% dig txt chaos version.bind. ; <<>> DiG 9.3.2 <<>> txt chaos version.bind. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14286 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION:
3. Nous avons dcrit labonnement la liste bind-users au Chapitre 3. Les instructions pour labonnement bind-announce sont les mmes.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Scuriser un serveur
;version.bind. ;; ANSWER SECTION: version.bind. ;; AUTHORITY SECTION: version.bind. ;; ;; ;; ;; 0 0 CH CH CH TXT TXT NS "9.3.2" version.bind.

271

Query time: 17 msec SERVER: 192.168.0.1#53(192.168.0.1) WHEN: Sat Jan 7 16:14:39 2006 MSG SIZE rcvd: 62

Pour contourner ce problme, on peut xer la rponse cette question depuis BIND 8.2 :
options { version "Mlez-vous de ce qui vous regarde !"; };

videmment, avec une telle rponse, un pirate aura lindication que le serveur est postrieur BIND 8.2, mais cela lui mettra tout de mme des btons dans les roues. Cest pour cela que loption version none a t introduite depuis BIND 9.3.0 :
options { directory "/var/named"; version none; };

ce qui produit la rponse suivante :


; <<>> DiG 9.3.2 <<>> txt chaos version.bind. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21957 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;version.bind.

CH

TXT

;; AUTHORITY SECTION: version.bind. 86400 CH sion.bind. 0 28800 7200 604800 86400 ;; ;; ;; ;; Query time: 2 msec SERVER: 192.168.0.1#53(192.168.0.1) WHEN: Sat Jan 7 16:16:43 2006 MSG SIZE rcvd: 77

SOA

version.bind. hostmaster.ver-

Restreindre les requtes


lpoque de BIND 4, un administrateur ne pouvait pas contrler laccs son serveur, ce qui correspondait bien lapproche de base : rendre facilement accessible linformation dans tout lInternet.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

272

Chapitre 11 Scurit

Le comportement des utilisateurs ayant volu, les administrateurs de pare-feu ont lgitimement besoin de masquer certaines portions de leur espace de noms une partie du monde, tout en les rendant disponibles dautres utilisateurs. La structure allow-query de BIND 8 et 9 permet de congurer un contrle daccs bas sur les adresses IP de lorigine des requtes, en acceptant ou non les requtes correspondantes. LACL peut sappliquer soit aux requtes concernant une zone particulire, soit lensemble des requtes reues par le serveur. Autrement dit, lACL dnit les adresses IP qui peuvent lgitimement poser des questions un serveur.

Restreindre la totalit des requtes


La forme globale de la structure allow-query est la suivante :
options { allow-query { address_match_list; }; };

Pour indiquer un serveur de ne rpondre quaux requtes provenant des trois rseaux principaux de lUniversit du Cinma, il faut utiliser :
options { allow-query { 192.249.249/24; 192.253.253/24; 192.253.254/24; }; };

Restreindre sur les requtes concernant une zone


BIND 8 et 9 permettent aussi dappliquer une ACL une zone particulire. Dans ce cas, il suft dutiliser allow-query dans la structure zone protger :
acl "HP-NET" { 15/8; }; zone "hp.com" { type slave; file "bak.hp.com"; masters { 15.255.152.2; }; allow-query { "HP-NET"; }; };

Tout type de serveur, matre ou esclave, faisant autorit peut appliquer une ACL la zone4. Les ACL spciques une zone sont prpondrantes sur les ACL globales. LACL propre une zone peut mme tre plus souple que lACL globale. En labsence dACL spcique, toute ACL globale sapplique.

Contrler les transferts de zone


Il est encore plus important de sassurer que seuls les serveurs-esclaves rels dune zone peuvent demander un transfert de zone. Les utilisateurs des htes distants qui peuvent interroger un serveur ne peuvent rechercher que des enregistrements concernant des noms dj connus, et un seul la fois. Les utilisateurs qui peuvent demander un transfert de zone peuvent obtenir la liste complte des htes dun domaine. Cest la mme diffrence quentre, dune part, pouvoir appeler le standard dune entreprise et
4. En ralit, allow-query est mme utilisable dans une zone stub.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Scuriser un serveur

273

demander le numro de Jean Dupont et, dautre part, se procurer lannuaire de cette entreprise. La sous-structure allow-transfer de BIND 8 et 9 permet dappliquer une ACL aux transferts de zone. allow-transfer limite les transferts dune zone spcique, en tant que sousstructure dune structure zone, ou de toutes les zones, en tant que sous-structure dune structure options. Le paramtre de allow-transfer est une liste dadresses. Les serveurs-esclaves de la zone movie.edu ont pour adresses IP 192.249.249.1 et 192.253.253.1 (wormhole.movie.edu), et 192.249.249.9 et 192.253.253.9 (zardoz.movie.edu). La structure zone :
zone "movie.edu" { type master; file "db.movie.edu"; allow-transfer { 192.249.249.1; 192.253.253.1; 192.249.249.9; 192.253.253.9; }; };

autorise ces seuls serveurs transfrer la zone movie.edu partir du serveur-matre primaire. Comme par dfaut BIND 8 et 9 permettent nimporte quelle adresse IP de demander un transfert de zone, il ne faut pas se contenter de protger le matre primaire ; il faut galement protger les esclaves, qui ne le sont pas en standard :
zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; allow-transfer { none; }; };

BIND 8 et 9 permettent aussi dappliquer une ACL globale pour les transferts de zone. Il sapplique toutes les zones qui nont pas dACL propre dnie dans leur structure zone. Par exemple, on peut vouloir rserver tous les transferts de zone aux htes du rseau local :
options { allow-transfer { 192.249.249/24; 192.253.253/24; 192.253.254/24; }; };

Enn, comme nous lavons dj mentionn dans ce chapitre, depuis BIND 8.2 et toutes les versions de BIND 9, on peut rserver les transferts de zone aux esclaves qui fournissent une signature de transaction correcte lorsquils requirent un transfert. Sur le serveur-matre, il faut dnir la cl dans une structure key, puis invoquer cette cl dans la liste daccs :
key toystory-wormhole. { algorithm hmac-md5; secret "UNd5xYLjz0FPkoqWRymtgI+paxW927LU/gTrDyulJRI="; }; zone "movie.edu" { type master; file "db.movie.edu"; allow-transfer { key toystory-wormhole.; }; };
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

274

Chapitre 11 Scurit

Il faut congurer lesclave pour quil signe les requtes de transfert de zone, avec la mme cl :
key toystory-wormhole. { algorithm hmac-md5; secret "UNd5xYLjz0FPkoqWRymtgI+paxW927LU/gTrDyulJRI="; }; server 192.249.249.3 { keys { toystory-wormhole.; }; // signature des requtes vers // 192.249.249.3 avec cette cl }; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; };

Si un serveur primaire est accessible de lInternet, il peut tre intressant de ne permettre les transferts de zone qu ses serveurs-esclaves. La scurisation des transferts dans le cas de serveurs internes placs derrire un pare-feu est moins utile, moins que lon ne craigne les attaques internes.

Excuter BIND avec moins de privilges


Lexcution dun serveur tel que BIND par un utilisateur privilgi comme root peut tre risque, et cest pourtant ce qui se passe en standard. Si un pirate trouve une faille dans le serveur lui permettant de lire ou dcrire des chiers, il peut obtenir un accs privilgi au systme de chiers. Sil peut exploiter une imperfection lui permettant dexcuter des commandes, il le fera sous lidentit de lutilisateur privilgi. Depuis BIND 8.1.2 et avec toutes les versions de BIND 9, on peut changer lidentit de lutilisateur et du groupe qui excutent BIND, an de restreindre ses privilges : on lui donne alors les seules possibilits dont il a rellement besoin. De cette manire, si un pirate lutilise pour sintroduire dans le systme, il nobtiendra pas les droits de root. Avec un tel serveur, une option permet dutiliser chroot( ) an que la racine de son systme de chiers soit un sous-rpertoire particulier du systme de chiers de lhte. Cela restreint le serveur de noms son rpertoire et, par voie de consquence, restreint galement le pirate ventuel. Pour BIND, les paramtres en ligne de commande sont : u Dnit lidentit de lutilisateur qui excute BIND lissue de son dmarrage. Exemple : named u bind. g Dnit lidentit du groupe qui excute BIND lissue de son dmarrage. Exemple : named g autre. Si -u est indiqu sans -g, le serveur utilise le groupe primaire de lutilisateur. En BIND 9, cette option nest pas applicable, car le groupe dexcution de BIND est toujours le groupe primaire de lutilisateur.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Scuriser un serveur
t

275

Dnit la racine du systme de chiers vu par BIND aprs utilisation de chroot( ). Si on utilise les options -u et -g, il faut choisir lutilisateur et le groupe qui excutent BIND. Lidal est de crer un nouvel utilisateur et un nouveau groupe, tels que bind ou named. Puisque le serveur de noms lit le chier named.conf avant dabandonner les privilges de root, il nest pas ncessaire de modier les permissions de ce chier. Par contre, il faudra peut-tre modier les permissions et la proprit des chiers de zone, an que le nouvel utilisateur excutant le serveur puisse les lire. Si on utilise la mise jour dynamique, il faut aussi donner cet utilisateur un droit dcriture sur ces chiers. Si le serveur est congur pour enregistrer les vnements dans des chiers (et non pas via syslog), ces chiers doivent exister et tre accessibles en criture par le serveur. Loption t ncessite plus de prparation. En particulier, il est ncessaire que tous les chiers que named utilise soient prsents dans larborescence dans laquelle le serveur est restreint. Voici la procdure de mise en uvre via chroot pour une restriction daccs la seule arborescence /var/named5. 1. Crez ventuellement le rpertoire /var/named. Crez les sous-rpertoires dev, etc, lib, usr et var. Dans usr, crez le sous-rpertoire sbin. Dans var, crez les sous-rpertoires named et run :
# mkdir /var/named # cd /var/named # mkdir -p dev etc lib usr/sbin var/named var/run

2. Copiez named.conf vers /var/named/etc/named.conf :


# cp /etc/named.conf etc

3. En BIND 9, qui nutilise pas named-xfer, passez directement au point 4. En BIND 8, copiez le programme named-xfer vers le sous-rpertoire usr/sbin/ ou etc (selon que loriginal se trouve dans /usr/sbin ou dans /etc) :
# cp /usr/sbin/named-xfer usr/sbin

Vous pouvez aussi le placer o vous le souhaitez sous /var/named, puis utiliser la sous-structure named-xfer pour en informer named. Noubliez pas dexclure le rpertoire /var/named des noms de chemin car, lors de la lecture de named.conf par named, /var/named reprsentera en fait la racine. 4. Crez dev/null dans le nouvel environnement chroot6 :
# mknod dev/null c 2 2

5. En BIND 8, copiez la bibliothque C standard et le chargeur vers le rpertoire lib :


# cp /lib/libc.so.6 /lib/ld-2.1.3.so lib

Selon le systme dexploitation, les chemins peuvent varier. BIND 9 est autosufsant ; la copie des bibliothques nest donc pas ncessaire. 6. Modiez les chiers de dmarrage pour lancer syslogd avec loption a /var/named/ dev/log. Dans la plupart des Unix rcents, syslogd est dmarr par le script /etc/rc ou

5. 6.

Cette procdure est base sur FreeBSD. Elle peut donc demander des adaptations. Les paramtres de mknod pour crer dev/null peuvent varier dun systmes dexploitation lautre.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

276

Chapitre 11 Scurit

/etc/rc.d/init.d/syslog. Au redmarrage suivant, syslogd crera /var/named/dev/log, et named lutilisera pour enregistrer ses messages. Si le syslogd utilis ne connat pas loption a, utilisez la structure logging dcrite dans le Chapitre 7 pour enregistrer les messages dans le rpertoire sous contrle de chroot( ). 7. Si vous utilisez BIND 8 et ses options u ou g, crez les chiers passwd et group dans le sous-rpertoire etc pour associer les arguments de u et g leur valeur numrique (ou utilisez directement des valeurs numriques) :
# echo "named:x:42:42:named:/:" > etc/passwd # echo "named::42" > etc/group

puis ajoutez les lignes aux chiers /etc/passwd et /etc/group du systme. En BIND 9, il suft de complter /etc/passwd et /etc/group, puisque les serveurs BIND 9 lisent les informations requises avant dappeler chroot( ). 8. Enn, modiez les chiers de dmarrage pour lancer named avec loption t /var/ named. De mme que pour syslogd, la plupart des Unix rcents lancent named via le script /etc/rc ou /etc/rc.d/init.d/named. Si on est habitu au pilotage de BIND 8 par ndc, on peut continuer lutiliser condition de dnir le chemin de la socket de domaine Unix laide de loption c de ndc :
# ndc -c /var/named/var/run/ndc reload

En BIND 9, rndc fonctionne de la mme manire quauparavant puisquil sadresse au serveur uniquement par le port 953.

Sparer les fonctions


Les serveurs de noms ont deux fonctions majeures : rpondre des requtes itratives provenant de serveurs distants et rpondre des requtes rcursives provenant de resolvers locaux. La sparation de ces deux fonctions et leur rpartition sur deux ensembles de serveurs permet damliorer grandement la scurit.

Congurer un serveur de publication


Les serveurs interrogs par dautres serveurs de lInternet rpondent essentiellement des requtes itratives. Ces serveurs sont publiquement connus grce aux enregistrements NS de dlgation. Nous les appelons serveurs de publication car leur rle est de publier des zones dans lInternet. On peut prendre plusieurs mesures pour scuriser des serveurs de publication. Tout dabord, il faut sassurer quils ne reoivent pas de requtes rcursives (dans la mesure o aucun resolver local nest congur pour les interroger et quaucun serveur local ne les utilise comme forwarder). Certaines des prcautions prconises, comme amener un serveur rpondre itrativement une requte rcursive, excluent toute possibilit pour un resolver de les utiliser. Par consquent, si un resolver doit les interroger, il faut envisager de crer une autre catgorie de serveurs pour rpondre uniquement ce resolver ou dutiliser la conguration Deux serveurs en un (voir page 277). Aprs stre assur quun serveur rpond des requtes provenant uniquement dautres serveurs, on peut dsactiver la rcursivit. Cela limine une importante faille de scurit : la principale mascarade consiste faire en sorte que le serveur attaqu envoie

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Scuriser un serveur

277

une requte vers un serveur sous contrle du pirate. Cela se fait laide dune requte rcursive concernant un domaine servi par le serveur sous contrle du pirate. Pour dsactiver la rcursivit, il faut utiliser la structure suivante, en BIND 8 et 9 :
options { recursion no; };

Il faudrait aussi rserver le transfert de zones des serveurs-esclaves bien connus (voir prcdemment dans ce chapitre la section Contrler les transferts de zone, page 272). Enn, on pourrait dsactiver la construction de mmoire cache. En effet, un serveur tente de rsoudre les noms de chaque serveur apparaissant dans les enregistrements NS. Pour len empcher tout en lui permettant de gnrer des requtes sa propre initiative, il faut utiliser, avec BIND 8 (cette option nest pas disponible avec BIND 9) :
options { fetch-glue no; };

Congurer un serveur de rsolution


Nous appelons serveur de rsolution un serveur qui rpond un ou plusieurs resolvers ou qui est congur comme redirecteur. Contrairement un serveur dlgu, il ne peut pas refuser les requtes rcursives. Par consquent, il faut adopter dautres mesures de scurit. Comme a priori, un tel serveur ne reoit de requtes quen provenance de ses propres resolvers, on peut lui demander de rejeter toutes les autres requtes. La structure allow-query ci-dessous ne valide que les requtes internes au rseau :
options { allow-query { 192.249.249/24; 192.253.253/24; 192.253.254/24; }; };

Dans ce cas, les seuls resolvers capables denvoyer des requtes rcursives vers un serveur et de provoquer linterrogation dautres serveurs par ce serveur, sont les resolvers internes, qui sont normalement plutt gentils. Loption use-id-pool permet de scuriser un peu plus le serveur de rsolution :
options { use-id-pool yes; };

Loption use-id-pool est apparue avec BIND 8.2. Elle indique au serveur dutiliser des ID alatoires pour les messages. En effet, les ID de messages ne sont pas sufsamment alatoires pour viter des attaques par force brute qui essaieraient de dcouvrir les ID en cours dutilisation an de simuler des rponses. Lactivation de cette option est inutile en BIND 9 car cette fonction est devenue standard.

Deux serveurs en un
Si on ne dispose que dune seule machine pour la fois annoncer une zone sur lInternet et rpondre aux requtes des resolvers locaux, il y a plusieurs solutions. Deux dentre elles sont bases sur un serveur unique en tirant parti de la exibilit de BIND

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

278

Chapitre 11 Scurit

8 et 9. Lune de ces congurations permet nimporte qui dinterroger le serveur, mais seuls les resolvers internes peuvent linterroger pour rechercher des informations sur lesquelles il ne fait pas autorit. Bien que cela nempche pas des resolvers distants denvoyer des requtes rcursives, ces requtes doivent concerner des informations sur lesquelles le serveur fait autorit, an que ce dernier nait pas gnrer de recherches complmentaires. Voici le chier named.conf correspondant :
acl "interne" { 192.249.249/24; 192.253.253/24; 192.253.254/24; localhost; }; acl "esclaves" { 192.249.249.1; 192.253.253.1; 192.249.249.9; 192.253.253.9; }; options { directory "/var/named"; allow-query { "interne"; }; use-id-pool yes; }; zone "movie.edu" { type master; file "db.movie.edu"; allow-query { any; }; allow-transfer { "esclaves"; }; }; zone "249.249.192.in-addr.arpa" { type master; file "db.192.249.249"; allow-query { any; }; allow-transfer { "esclaves"; }; }; zone "." { type hint; file "db.cache"; };

Ici, lACL, plus permissive et spcique une zone, sapplique des requtes provenant de la zone sur laquelle le serveur fait autorit, alors que lACL globale, plus restrictive, sapplique toutes les requtes. Depuis BIND 8.2.1 ou avec toutes les versions de BIND 9, on peut simplier cette conguration laide de la sous-structure allow-recursion :
acl "interne" { 192.249.249/24; 192.253.253/24; 192.253.254/24; localhost; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Scuriser un serveur
acl "esclaves" { 192.249.249.1; 192.253.253.1; 192.249.249.9; 192.253.253.9; }; options { directory "/var/named"; allow-recursion { "interne"; }; use-id-pool yes; }; zone "movie.edu" { type master; file "db.movie.edu"; allow-transfer { "esclaves"; }; }; zone "249.249.192.in-addr.arpa" { type master; file "db.192.249.249"; allow-transfer { "esclaves"; }; }; zone "." { type hint; file "db.cache"; };

279

La sous-structure allow-query nest plus ncessaire : le serveur peut recevoir des requtes de lextrieur, mais il les traite comme des requtes itratives. Ces requtes ne peuvent donc pas induire de recherches complmentaires par le serveur de noms. Cette conguration a aussi lavantage de ne pas souffrir dun ala qui existe dans la prcdente conguration : si le serveur fait autorit sur une zone-parente, il peut recevoir des requtes provenant de serveurs distants concernant des noms situs dans un sousdomaine dlgu de cette zone-parente. La solution base sur allow-query rejette ces requtes, pourtant lgitimes, alors que celle base sur allow-recursion les accepte. Une autre solution consiste utiliser deux processus named sur la mme machine. Lun est congur comme serveur de publication, lautre comme serveur de rsolution. Comme il nexiste aucun moyen dindiquer des serveurs distants ou des resolvers dinterroger lun des serveurs sur un port autre que le 53 (le port par dfaut du DNS), il faut excuter ces serveurs sur des adresses IP diffrentes. Bien sr, si lhte a dj plusieurs interfaces de rseau, il ny a aucune difcult. Mme sil nen a quune, le systme dexploitation accepte peut-tre les alias dadresses IP Cela . permettrait dattribuer plus dune adresse IP une mme interface. Un processus named peut tre lcoute sur chaque adresse. Si le systme dexploitation naccepte pas les alias dadresses IP, il est encore possible dattribuer lun des named ladresse du rseau local, et lautre ladresse de bouclage. Seul lhte local pourra envoyer des requtes au named lcoute sur ladresse de bouclage ; cela ne fonctionne donc que si le resolver de lhte local est le seul client.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

280

Chapitre 11 Scurit

Tout dabord, voici le chier named.conf du serveur de publication, lcoute sur ladresse IP de linterface rseau :
acl "esclaves" { 192.249.249.1; 192.253.253.1; 192.249.249.9; 192;253.253.9; }; options { directory "/var/named-advertising"; recursion no; fetch-glue no; listen-on { 192.249.249.3; }; pid-file "/var/run/named.advertising.pid"; }; zone "movie.edu" { type master; file "db.movie.edu"; allow-transfer { "esclaves"; }; }; zone "249.249.192.in-addr.arpa" { type master; file "db.192.249.249"; allow-transfer { "esclaves"; }; };

Voici maintenant le chier named.conf du serveur de rsolution, lcoute sur ladresse de bouclage :
options { directory "/var/named-resolving"; listen-on { 127.0.0.1; }; pid-file "/var/run/named.resolving.pid"; use-id-pool yes; }; zone "." { type hint; file "db.cache"; };

Une ACL est inutile pour le serveur de rsolution, puisquil ncoute que linterface de bouclage et quil ne peut recevoir aucune requte en provenance dun autre hte (si le serveur de rsolution est lcoute sur un alias dadresse IP ou sur une autre interface, , on peut utiliser allow-query pour viter que dautres htes nutilisent le serveur). Nous avons dsactiv la rcursivit sur le serveur de publication, mais nous lavons laisse sur le serveur de rsolution. Chaque serveur dispose de son propre chier PID an dviter toute collision entre chiers PID, ainsi que de son propre rpertoire de travail de manire ce que les chiers de dbogage et les chiers de statistiques soient sauvegards dans des endroits diffrents.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Scuriser un serveur

281

Pour utiliser le serveur de rsolution lcoute sur ladresse de bouclage, le chier resolv.conf de lhte local doit contenir comme premire directive nameserver :
nameserver 127.0.0.1

En BIND 9, on peut mme runir la conguration des deux serveurs en une seule laide des vues :
options { directory "/var/named"; }; acl "interne" { 192.249.249/24; 192.253.253/24; 192.253.254/24; localhost; }; view "interne" { match-clients { "interne"; }; recursion yes; zone "movie.edu" { type master; file "db.movie.edu"; }; zone "249.249.192.in-addr.arpa" { type master; file "db.192.249.249"; }; zone "." { type hint; file "db.cache"; }; }; view "externe" { match-clients { any; }; recursion no; zone "movie.edu" { type master; file "db.movie.edu"; }; zone "249.249.192.in-addr.arpa" { type master; file "db.192.249.249"; }; zone "." { type hint;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

282
file "db.cache"; }; };

Chapitre 11 Scurit

Cette conguration deux vues est simple : lintrieur et lextrieur. La rcursivit est valide dans la vue interne, qui ne concerne que le rseau local. Elle est inhibe dans la vue externe, qui concerne tout le reste. Les zones movie.edu et 249.249.192.in-addr.arpa sont dnies de la mme manire dans les deux vues. On pourrait afner cette conguration, par exemple en dnissant deux zones diffrentes, lune pour la vue interne et lautre pour la vue externe, ce que nous rservons pour la prochaine section.

DNS et pare-feu
Le systme de noms de domaine na pas t conu pour travailler avec un pare-feu de lInternet. Toutefois, la exibilit du DNS et de sa mise en uvre par BIND permettent de congurer le DNS pour quil puisse travailler avec un pare-feu de lInternet. La conguration de BIND pour fonctionner dans un environnement protg par un pare-feu, bien que facile, ncessite toutefois une comprhension complte du DNS et de quelques caractristiques complexes de BIND. Leur description occupe une part importante de ce chapitre. La premire partie dcrit les deux principales familles de pare-feu : le ltrage de paquets et les proxies (passerelles applicatives). Les caractristiques de chaque famille dtermineront une partie de la conguration de BIND. La partie suivante dtaille les deux principales architectures DNS utilises avec un pare-feu, les redirecteurs et les racines internes ; elle dcrit les avantages et inconvnients de chaque mthode. Il sera ensuite question des zones rediriges, nouvelle possibilit qui combine le meilleur des racines internes et des redirecteurs. Enn, on trouvera des dtails sur les espaces de noms spars et la conguration dune machine bastion, hte au cur dun systme bas sur un pare-feu.

Familles de pare-feu
Avant de congurer BIND associ un pare-feu, il est ncessaire de comprendre les fonctions du pare-feu utilis. Ces fonctions inuenceront les choix darchitecture DNS ainsi que leur mise en uvre. Si vous ne connaissez pas les rponses ces questions, partez la recherche dun collgue qui saurait y rpondre ou, encore mieux, travaillez avec ladministrateur du pare-feu lors de la conception darchitecture DNS, an dtre certain que le DNS et le pare-feu coexisteront parfaitement. Cette section dcrit les deux principales familles de pare-feux, dans loptique de leur utilisation avec des serveurs de noms. Pour une tude exhaustive des pare-feu, il faudra consulter louvrage Building Internet Firewalls dElizabeth D. Zwicky, Simon Cooper et D. Brent Chapman (OReilly Media).

Filtrage de paquets
Le pare-feu par ltrage de paquets travaille essentiellement aux niveaux rseau et transport de la pile TCP/IP (couches trois et quatre du modle de rfrence OSI). Il dcide de router un paquet selon des critres tels que le protocole de transport (TCP ou UDP), les adresses dorigine et de destination, et les ports dorigine et de destination (voir la gure 11-1).
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu

283

couche application couche prsentation couche session couche transport (port origine et destination) couche rseau (adresse IP origine et destination) couche liaison de donnes couche physique

Figure 11-1. Le filtrage de paquets intervient aux niveaux rseau et transport


Laspect important dun pare-feu par ltrage de paquets, est quon peut les congurer pour autoriser explicitement le trac DNS entre des htes de lInternet et les htes internes. On peut donc autoriser un ensemble arbitraire dhtes communiquer avec des serveurs de noms de lInternet. Certains pare-feu par ltrage de paquets permettent mme des serveurs internes dinterroger des serveurs de lInternet, tout en interdisant la rciproque. Tout pare-feu bas sur un routeur est pare-feu ltrage de paquets. Les produits commerciaux FireWall-1 de Checkpoint, PIX de Cisco et NetScreen de Juniper entrent dans cette catgorie.

Proxies
Les proxies (passerelles applicatives) travaillent au niveau application (couche sept du modle de rfrence OSI), donc plusieurs couches au-dessus dun pare-feu par ltrage de paquets (voir la gure 11-2). En quelque sorte, une passerelle comprend le protocole de lapplication, de la mme manire quun serveur spcique cette application. Un proxy FTP par exemple, peut dcider dautoriser ou dinterdire une opration FTP , particulire, telle que RETR (get) ou STOR (put).

couche application (opration de niveau application : STOR, RETR) couche prsentation couche session couche transport couche rseau couche liaison de donnes couche physique

Figure 11-2. Les passerelles applicatives travaillent au niveau application de la pile

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

284

Chapitre 11 Scurit

BIND 8 ou 9 et les pare-feu par ltrage de paquets


Les serveurs BIND 4 envoient toujours leurs requtes partir du port 53, port rserv au DNS, destination dun port 53. Les resolvers, quant eux, envoient leurs requtes partir de ports plus levs, mais infrieurs 1023, galement destination dun port 53. Toutefois, rien noblige un serveur DNS expdier ses requtes partir du port du DNS. Dailleurs, les serveurs BIND 8 et 9 fonctionnent par dfaut comme les resolvers et expdient leurs requtes partir de ports dont le numro est plus lev. Cela peut tre une source de problme avec les pare-feu par ltrage de paquets congurs pour permettre le trac de serveur de noms serveur de noms, et non de resolver serveur de noms. En effet, ces pare-feu sattendent ce que le trac de serveur de noms serveur de noms provienne dun port 53 et aboutisse un port 53. Voici deux solutions ce problme : recongurer le pare-feu pour autoriser les envois et rceptions de requtes de serveur de noms via un port autre que le 53, en supposant que le fait dautoriser les paquets en provenance dhtes de lInternet et de ports numro lev destination des serveurs internes, ne compromet pas la scurit du pare-feu ; congurer BIND, laide de la sous-structure query-source, pour quil se comporte la manire ancienne. Les paramtres de query-source sont une adresse et, ventuellement, un numro de port. La structure :
options { query-source address * port 53; };

demande BIND dutiliser le port 53 comme origine des requtes envoyes via toutes les interfaces locales. On peut indiquer une adresse explicite pour limiter les adresses partir desquelles BIND enverra des requtes. Ainsi, sur wormhole.movie.edu, la structure :
options { query-source address 192.249.249.1 port *; };

demande BIND denvoyer toutes ses requtes via linterface 192.249.249.1, et non par 192.253.253.1, et dutiliser dynamiquement les ports numro lev. Lutilisation de query-source avec une adresse gnrique est dfectueuse en BIND 9 avant la version 9.1.0, mais on peut nanmoins demander tout serveur BIND 9 denvoyer toutes ses requtes depuis le port 53 de nimporte quelle adresse.

Le problme est que la plupart des pare-feu de type proxy ne comprennent que les protocoles applicatifs bass sur TCP Le DNS utilise intensivement UDP Par consquent, si on . . utilise un pare-feu de type proxy, les htes internes ne pourront pas facilement communiquer avec les serveurs de noms sur lInternet. Firewall Toolkit, dit par Trusted Information Systems (TIS, maintenant liale de MCAfee), tait un ensemble de proxies pour les protocoles de lInternet tels que Telnet, FTP et HTTP Les produits pare-feu Sidewinder de Secure Computing ou ceux de Symantec . sont eux aussi bass sur des proxies.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu

285

Ces deux catgories de pare-feu sont thoriques. La technologie volue trs rapidement : les nouveaux pare-feu ltrage de paquets peuvent inspecter les donnes de niveau applicatif et les pare-feu bass sur les proxies prennent dsormais en charge le DNS. La classication en deux grandes familles de pare-feu doit surtout servir cerner les possibilits thoriques dun pare-feu ; il faut ensuite regarder les caractristiques particulires de chacun deux.

Conguration viter
Dans la conguration la plus simple, celle dun pare-feu laissant passer la totalit du trac DNS, tout serveur de noms interne peut interroger tout serveur de lInternet, et tout serveur de noms de lInternet peut interroger tout serveur interne. Cest une mauvaise conguration pour au moins deux raisons : Suivi de versions Les auteurs de BIND dcouvrent et corrigent en permanence des bogues de scurit dans BIND. Par consquent, il est important de toujours utiliser une version rcente, et plus particulirement sur les serveurs directement exposs lInternet. Si un unique serveur interne peut communiquer directement avec des serveurs de lInternet, seul ce serveur a besoin dtre mis jour de manire suivie, ce qui est relativement facile. Si tous les serveurs sont exposs, il faut tous les mettre jour rapidement, ce qui est plus contraignant et plus difcile. Vecteur de pntration Mme si on nexcute pas un serveur de noms sur un hte, si le trac DNS est libre travers le pare-feu, un pirate peut utiliser le vecteur du DNS pour attaquer cet hte. Un complice situ lintrieur de la zone peut, par exemple, installer un serveur Telnet lcoute du port du DNS, permettant ainsi au pirate dutiliser telnet, mme si le protocole Telnet est interdit travers le pare-feu. Dans le reste de ce chapitre, nous tenterons de construire un bon exemple.

Redirecteurs pour lInternet


tant donn le danger dune autorisation bidirectionnelle de trac DNS travers un pare-feu non restreint, la plupart des organismes choisissent de restreindre la liste des htes internes qui peuvent dialoguer en DNS avec lInternet. Avec un pare-feu de type proxy, ou avec tout pare-feu capable de bloquer le trac DNS, les seuls htes capables de communiquer avec les serveurs de noms de lInternet sont les machines bastion ( gure 11-3). Avec un pare-feu par ltrage de paquets, ladministrateur peut congurer son pare-feu pour permettre tout ensemble de serveurs de noms internes de communiquer avec les serveurs de noms de lInternet. Il sagit souvent dun petit ensemble dhtes qui hbergent des serveurs de noms placs directement sous le contrle de ladministrateur du domaine ( gure 11-4).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

286

Chapitre 11 Scurit

Internet

routeur machine bastion requtes et rponses DNS

routeur

Rseau interne

Figure 11-3. Schma dun petit rseau, montrant la machine bastion


requtes et rponses DNS serveur de noms serveur de noms

Internet

routeur machine bastion

routeur

Rseau interne

requtes et rponses DNS

serveur de noms

Figure 11-4. Schma dun petit rseau, montrant les serveurs privilgis internes
Les serveurs internes qui peuvent directement interroger des serveurs de lInternet ne requirent aucune conguration spciale. Leur chier dindications initiales contient la liste des serveurs de la racine, ce qui leur permet de rsoudre les noms de lInternet. Par contre, les serveurs de noms internes qui ne peuvent pas interroger directement les serveurs de lInternet ont besoin de retransmettre leurs requtes un intermdiaire. Pour cela, ils utilisent la directive forwarders, prsente au Chapitre 10. La gure 11-5 reprsente une architecture courante : les serveurs de noms internes redirigent leurs requtes un serveur de noms situ sur une machine bastion. Dans le cas de lUniversit du Cinma, un pare-feu protge le rseau des assauts de lInternet. Il sagit dun pare-feu par ltrage de paquets qui autorise le trac DNS entre les serveurs de noms de lInternet et deux des serveurs de noms internes, toystory.movie.edu et wormhole.movie.edu. Voici la conguration mise en place sur les autres serveurs, pour ceux utilisant BIND 8 ou 9 :
options { forwarders { 192.249.249.1; 192.249.249.3; }; forward only; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu

287

Serveur DNS

Internet
Machine bastion

routeur dentre
3 4

Rseau ouvert routeur interne Rseau interne


5 1 2

1 2 3 4

Les clients interrogent le serveur interne. Ce serveur interroge le forwarder sur la machine bastion. La machine bastion interroge lInternet et reoit les rponses. La machine bastion rpond au serveur interne. Le serveur interne rpond au client.

Client DNS

Serveur DNS

Client interne

Serveur interne

Figure 11-5. Utilisation de redirecteurs


Nous varions lordre dans lequel les redirecteurs apparaissent an de favoriser une rpartition de charge entre eux. Cest inutile depuis les serveurs BIND 8.2.3 ou BIND 9.3.0, qui choisissent un redirecteur en fonction du temps daller-retour. Lorsquun serveur de noms interne reoit une requte quil ne peut rsoudre localement, par exemple un nom de lInternet, il redirige la requte lun des redirecteurs qui, lui, est autoris contacter les serveurs de noms de lInternet.

Problme li la redirection
Malheureusement, la redirection ne fonctionne pas comme escompt lors de la mise en place de sous-rseaux ou lors de la construction dun grand rseau volutif. Pour expliquer le problme, regardons le chier de conguration de zardoz.movie.edu :
options { directory "/var/named"; forwarders { 192.249.249.1; 192.253.253.3; }; }; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; };

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

288

Chapitre 11 Scurit

zardoz.movie.edu est un esclave pour movie.edu et utilise les deux forwarders. Supposons que zardoz.movie.edu reoive une requte concernant fx.movie.edu. En tant que serveur faisant autorit sur movie.edu, zardoz.movie.edu possde les enregistrements NS qui dlguent fx.movie.edu vers les serveurs de noms du sous-rseau. Mais zardoz.movie.edu est aussi congur pour rediriger les requtes auxquelles il ne sait pas rpondre lui-mme vers les forwarders toystory.movie.edu et wormhole.movie.edu. Que se passe-t-il alors ? Il savre que zardoz.movie.edu ne tient pas compte de linformation de dlgation et redirige la requte, par exemple, toystory.movie.edu. toystory.movie.edu reoit donc la requte rcursive et recherche les enregistrements NS de fx.movie.edu pour le compte de zardoz.movie.edu. Ce schma fonctionne mais nest pas efcace, puisque zardoz.movie.edu aurait pu rechercher linformation lui-mme. Imaginons maintenant le cas dun rseau grande chelle, celui dune multinationale, contenant des dizaines de milliers de machines et une centaine de serveurs de noms. Tous les serveurs internes qui ne possdent pas la connectivit directe lInternet, utilisent un ensemble rduit de redirecteurs. Plusieurs problmes peuvent apparatre : Vulnrabilit Si les redirecteurs tombent en panne, les serveurs internes perdent la capacit de rsoudre la fois les noms de lInternet et les noms internes quils nauraient pas dj en mmoire cache, ou sur lesquels il ne feraient pas autorit. Concentration de la charge Les redirecteurs reoivent une norme charge de requtes, en raison du grand nombre de serveurs internes qui les sollicitent, et des requtes rcursives qui induisent un travail important avant de pouvoir rpondre. Rsolution inefficace Imaginons deux serveurs de noms internes faisant respectivement autorit sur west.acmebw.com et east.acmebw.com, situs tous deux sur le mme segment de rseau Boulder, au Colorado. Ils sont tous deux congurs pour utiliser le forwarder de lentreprise Bethesda dans le Maryland7. Si west.acmebw.com doit rsoudre un nom situ dans east.acmebw.com, il redirige la requte au redirecteur de Bethesda. Ce dernier envoie ensuite la requte Boulder au serveur de east.acmebw.com, le voisin du demandeur dorigine. Le serveur east.acmebw.com rpond au forwarder Bethesda, qui renvoie la rponse Boulder. Dans une conguration traditionnelle, le serveur de west.acmebw.com aurait rapidement appris que le serveur east.acmebw.com se trouve juste proximit, en raison du faible temps daller-retour, et il laurait privilgi. Lutilisation de redirecteurs court-circuite lefcacit normale du processus de rsolution. En bref, la redirection fonctionne bien pour des petits rseaux et des espaces de noms simples, mais est totalement inadapte pour les grands rseaux et espaces de noms complexes. Il est donc ncessaire de trouver une alternative.

7.

NdT : Boulder et Bethesda sont respectivement situs au centre ouest et au nord est des tats-Unis, et sont distants de 2700 km (1680 miles).

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu

289

Utiliser des zones rediriges


On peut rsoudre le problme dinefcacit de la rsolution laide des zones rediriges introduites par BIND 8.2 et 9.1.08. Voici la nouvelle conguration de zardoz.movie.edu :
options { directory "/var/named"; forwarders { 192.249.249.1; 192.253.253.3; }; }; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; forwarders {}; };

Remarquons bien la directive forwarders qui est vide. Dsormais, si zardoz.movie.edu reoit une requte dont le nom se termine par movie.edu mais est hors de la zone movie.edu (le nom est, par exemple, dans fx.movie.edu), il ne tient pas compte des forwarders dnis dans options et envoie des requtes itratives. Avec cette conguration, zardoz.movie.edu continue toutefois solliciter les redirecteurs pour la correspondance inverse. Pour lviter, il suft dajouter quelques structures zone au chier named.conf :
zone "249.249.192.in-addr.arpa" { type stub; masters { 192.249.249.3; }; file "stub.192.249.249"; forwarders {}; }; zone "253.253.192.in-addr.arpa" { type stub; masters { 192.249.249.3; }; file "stub.192.253.253"; forwarders {}; }; zone "254.253.192.in-addr.arpa" { type stub; masters { 192.253.254.2; }; file "stub.192.253.254"; forwarders {}; }; zone "20.254.192.in-addr.arpa" { type stub;

8.

La redirection conditionnelle ne fonctionne toutefois en BIND 9 qu partir de la version 9.2.0, en raison dun bogue.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

290
masters { 192.253.254.2; }; file "stub.192.254.20"; forwarders {}; };

Chapitre 11 Scurit

Ces nouvelles structures zone mritent quelques explications. Tout dabord, les zones pour la correspondance inverse sont congures comme des souches (stubs). De cette manire, le serveur de noms recherche les enregistrements NS de ces zones en demandant priodiquement les serveurs-matres de ces zones. Ensuite, la sous-structure vide forwarders dsactive la redirection pour les noms contenus dans le domaine inverse correspondant. Dsormais, au lieu dinterroger les redirecteurs lors de la recherche de lenregistrement PTR 2.254.253.192.in-addr.arpa, par exemple, zardoz.movie.edu interroge directement lun des serveurs de 254.253.192.in-addr.arpa. De telles structures zone sont ncessaires sur la totalit des serveurs internes, ce qui implique aussi dutiliser une version de BIND postrieure 8.2 ou 9.2.0. Cette conguration est robuste et minimise lexposition des serveurs lInternet : elle utilise une rsolution de noms itrative, robuste et efcace pour la recherche de noms internes, ainsi que des redirecteurs lorsque cela est ncessaire pour rsoudre des noms de lInternet. Si les redirecteurs sont dfaillants ou si la connectivit lInternet est rompue, seule la capacit de rsoudre des noms de lInternet est perdue.

Racine interne
Pour annuler les problmes dchelle avec la redirection, on peut mettre en uvre sa propre racine interne, qui ne servira quaux serveurs internes de lentreprise. La racine interne na dinformations que sur la partie de lespace de noms qui correspond lentreprise. En utilisant une architecture base sur des serveurs de la racine, on bncie dune facilit de croissance de lespace de noms, dune redondance, dune distribution de charge et dune rsolution efcace. On peut avoir autant de racines internes que lInternet (environ 13) alors que cela compromettrait la scurit davoir autant de redirecteurs. De plus, les serveurs de la racine ne sont que rarement contacts : les serveurs de noms nen ont besoin que pour la recherche des zones de plus haut niveau. Avec lutilisation de forwarders, les serveurs pourraient avoir appeler un redirecteur chaque requte. En conclusion, si on envisage davoir un grand espace de noms et de nombreux serveurs internes (ou si on les possde dj), la meilleure solution est celle des serveurs internes de la racine.

Localiser les serveurs internes de la racine


Puisque les serveurs de noms privilgient les serveurs de la racine les plus proches, en analysant les temps daller-retour, il est intressant de dissminer les serveurs internes de la racine dans tout le rseau. Si une multinationale est implante aux tats-Unis dAmrique, en Europe et au bord du Pacique, il faut envisager dinstaller une racine interne sur chaque continent. Si on a trois sites majeurs en Europe, il faut installer une racine interne sur chacun deux.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu

291

Dlguer partir de la racine


Une racine interne dlgue directement lautorit chaque zone du rseau interne. Dans movie.edu, par exemple, les chiers de la racine contiennent :
movie.edu. 86400 IN 86400 IN 86400 IN toystory.movie.edu. wormhole.movie.edu. zardoz.movie.edu. NS toystory.movie.edu. NS wormhole.movie.edu. NS zardoz.movie.edu. 86400 IN A 192.249.249.3 86400 IN A 192.249.249.1 86400 IN A 192.253.253.1 86400 IN A 192.249.249.9 86400 IN A 192.253.253.9

Sur lInternet, ces informations apparaissent dans les chiers de zone des serveurs de edu. Dans le rseau movie.edu, videmment, il ny a pas de serveur de edu ; par consquent, la dlgation vers movie.edu est faite directement partir de la racine. On peut constater quil napparat pas de dlgation vers fx.movie.edu ou dautres sousdomaines de movie.edu. En effet, les serveurs de movie.edu savent quels serveurs font autorit pour chaque sous-rseau, et toute requte concernant un sous-domaine fait obligatoirement entrer en jeu les serveurs de movie.edu ; la dlgation partir de la racine est donc inutile.

Dlguer in-addr.arpa
partir de la racine interne, il faut aussi dlguer lautorit vers les zones in-addr.arpa, correspondant aux rseaux de lUniversit du Cinma :
249.249.192.in-addr.arpa. 86400 86400 86400 253.253.192.in-addr.arpa. 86400 86400 86400 254.253.192.in-addr.arpa. 86400 86400 86400 20.254.192.in-addr.arpa. 86400 86400 86400 IN IN IN IN IN IN IN IN IN IN IN IN NS NS NS NS NS NS NS NS NS NS NS NS toystory.movie.edu. wormhole.movie.edu. zardoz.movie.edu. toystory.movie.edu. wormhole.movie.edu. zardoz.movie.edu. bladerunner.fx.movie.edu. outland.fx.movie.edu. alien.fx.movie.edu. bladerunner.fx.movie.edu. outland.fx.movie.edu. alien.fx.movie.edu.

On constate quil ny a pas de dlgation pour les zones 254.253.192.in-addr.arpa et 20.254.192.in-addr.arpa, bien quelles correspondent la zone fx.movie.edu. Cette dlgation nest pas ncessaire car elle est dj effective vers la zone-parente movie.edu. Les serveurs de movie.edu dlguent fx.movie.edu et donc, par transitivit, la racine dlgue fx.movie.edu. Par contre, comme aucune autre zone de in-addr.arpa nest parente de 254.253.192.in-addr.arpa ou de 20.254.192.in-addr.arpa, il faut dlguer ces deux zones partir de la racine. Il est inutile dajouter des enregistrements de ressource pour les trois serveurs bladerunner.movie.edu, outland.movie.edu et alien.movie.edu, car un serveur de noms distant peut trouver leur adresse en suivant la dlgation partir de movie.edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

292

Chapitre 11 Scurit

Le chier db.root
Il ne reste maintenant qu ajouter un enregistrement SOA pour la zone racine, ainsi que des enregistrements NS pour les serveurs de la racine interne :
$TTL 1d . IN SOA rainman.movie.edu. hostmaster.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure IN NS rainman.movie.edu. IN NS awakenings.movie.edu. rainman.movie.edu. IN A 192.249.249.254 awakenings.movie.edu. IN A 192.253.253.254

rainman.movie.edu et awakenings.movie.edu sont les htes qui hbergent la racine interne. On nutilise pas la machine bastion comme racine interne, en raison du risque de corruption de cette racine par pollution du cache par des donnes externes. Pour nir, voici le chier db.root complet (par convention, nous appelons db.root le chier de la zone racine) :
$TTL 1d . IN SOA rainman.movie.edu. hostmaster.movie.edu. ( 1 ; numro de srie 3h ; rafrachissement aprs 3 heures 1h ; nouvel essai aprs 1 heure 1w ; expiration aprs 1 semaine 1h ) ; TTL rponse ngative d1 heure IN NS rainman.movie.edu. IN NS awakenings.movie.edu. rainman.movie.edu. IN A 192.249.249.254 awakenings.movie.edu. IN A 192.253.253.254 movie.edu. IN NS toystory.movie.edu. IN NS wormhole.movie.edu. IN NS zardoz.movie.edu. toystory.movie.edu. wormhole.movie.edu. zardoz.movie.edu. IN IN IN IN IN A A A A A 192.249.249.3 192.249.249.1 192.253.253.1 192.249.249.9 192.253.253.9

249.249.192.in-addr.arpa. IN NS toystory.movie.edu. IN NS wormhole.movie.edu. IN NS zardoz.movie.edu.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu
253.253.192.in-addr.arpa. IN IN IN 254.253.192.in-addr.arpa. IN IN IN 20.254.192.in-addr.arpa. IN IN IN NS NS NS NS NS NS NS NS NS toystory.movie.edu. wormhole.movie.edu. zardoz.movie.edu. bladerunner.fx.movie.edu. outland.fx.movie.edu. alien.fx.movie.edu. bladerunner.fx.movie.edu. outland.fx.movie.edu. alien.fx.movie.edu.

293

Voici le chier named.conf des serveurs de la racine, rainman.movie.edu et awakenings.movie.edu :


zone "." { type master; file "db.root"; };

Cela remplace une structure zone de type hint, car un serveur de la racine na pas besoin de chier dindications initiales lui permettant dapprendre o sont les autres serveurs de la racine ; il peut trouver cette information dans le chier db.root. Cela veut-il dire que chaque serveur de la racine est un serveur primaire de la zone racine ? La rponse est non, car la zone racine est similaire toutes les zones, ce qui fait quon aura probablement un serveur primaire, tous les autres tant des esclaves. Si on na pas sufsamment de machines inoccupes pour y installer un serveur de la racine interne, on peut le faire sur tout serveur interne existant, cest--dire autre que la machine bastion et non situ lextrieur par rapport au pare-feu. En effet, un serveur unique peut servir de racine interne et de serveur faisant autorit sur toute zone quon lui ferait charger. Souvenons-nous quun serveur unique peut faire autorit sur de trs trs nombreuses zones, dont la zone racine.

Congurer les autres serveurs internes


Une fois que les serveurs de la racine interne sont prts, il faut congurer tous les serveurs internes du rseau, an quils utilisent les nouveaux serveurs de la racine. Les serveurs internes qui nont pas de connectivit directe lInternet (cest--dire qui sont protgs par le pare-feu) doivent avoir la liste des serveurs de la racine dans leur chier dindications initiales :
; Fichier dindications initiales pour la racine interne, pour les ; htes de lUniversit du Cinma sans connexion directe lInternet ; ; Ne pas lutiliser sur un hte connectivit directe lInternet ! ; . 99999999 IN NS rainman.movie.edu. 99999999 IN NS awakenings.movie.edu. rainman.movie.edu. 99999999 IN A 192.249.249.254 awakenings.movie.edu. 99999999 IN A 192.253.253.254

Les serveurs utilisant ce chier pourront rsoudre eux-mmes les noms de movie.edu et des domaines de in-addr.arpa correspondants, mais pas ceux hors de ces domaines.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

294

Chapitre 11 Scurit

Utilisation des serveurs internes de la racine par les serveurs internes


Pour bien comprendre comment tout cela fonctionne, tudions un exemple de rsolution sur un serveur cache interne qui utilise les serveurs de la racine interne. Le serveur cache reoit tout dabord une requte sur un nom de movie.edu, ladresse de gump.fx.movie.edu. Si ce serveur na pas dj linformation ou une aide en mmoire, il interroge un serveur de la racine interne. Sil a dj eu loccasion de communiquer avec les serveurs de la racine interne, il a connaissance des temps daller-retour pour chacun deux, ce qui lui permet de choisir celui qui lui rpondra le plus rapidement. Il envoie une requte itrative ce dernier, en demandant ladresse de gump.fx.movie.edu. La rponse de la racine interne fait rfrence aux serveurs de movie.edu, situs sur toystory.movie.edu, wormhole.movie.edu et zardoz.movie.edu. Le serveur cache envoie une nouvelle requte itrative lun de ces serveurs, en demandant ladresse de gump.fx.movie.edu. Le serveur contact envoie une rfrence concernant les serveurs de fx.movie.edu. Le serveur cache envoie alors une requte itrative pour chercher ladresse de gump.fx.movie.edu lun des serveurs de fx.movie.edu et reoit enn la rponse. Comparons cela ce qui ce passe avec des redirecteurs. Avec cette autre architecture, le serveur cache est congur pour retransmettre les requtes toystory.movie.edu puis wormhole.movie.edu. Le serveur cache recherche ladresse de gump.fx.movie.edu dans sa mmoire cache puis, sil ne la trouve pas, fait suivre la requte toystory.movie.edu. toystory.movie.edu interroge un serveur de fx.movie.edu de la part du serveur cache, puis renvoie la rponse. Si le serveur cache a besoin de rsoudre un autre nom de fx.movie.edu, il ne peut quinterroger nouveau un des redirecteurs, mme si la rponse prcdente contenait les noms et adresses des serveurs de fx.movie.edu.

Courrier provenant des htes internes et destination de lInternet


La topologie avec racine interne concerne aussi les mcanismes de messagerie. Nous avons dj parl de la rception du courrier en provenance de lInternet sans ncessit dadapter la conguration de chaque sendmail du rseau interne. Les mta-enregistrements, et particulirement les MX, sont la cl du fonctionnement de la messagerie. Dautre part, il serait souhaitable que les courriers destination de lInternet transitent par la machine bastion de lUniversit, postmanrings2x.movie.edu, qui a une connectivit directe lInternet. Cela peut se faire en ajoutant les enregistrements suivants au chier db.root des serveurs de la racine interne :
* *.edu. IN IN MX MX 5 postmanrings2x.movie.edu. 10 postmanrings2x.movie.edu.

Lenregistrement MX *.edu est ncessaire, en plus de lenregistrement *, en raison des restrictions sur les mta-enregistrements exposes la section Mta-caractres du Chapitre 17 (page 461). Puisquil y a, dans la zone, des informations explicites concernant movie.edu, le premier enregistrement MX ninclura, ni movie.edu, ni aucun autre sous-domaine de edu. Il faut donc un autre mta-enregistrement explicite pour edu an de trouver une correspondance pour tous les sous-domaines de edu. Les htes internes de movie.edu enverront les courriers destination de lInternet via postmanrings2x.movie.edu. Le premier mta-enregistrement MX sapplique au courrier envoy nic.ddn.mil :
% nslookup -type=mx nic.ddn.mil. Correspond lenregistrement MX *

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu
Server: rainman.movie.edu Address: 192.249.249.19 nic.ddn.mil preference = 5, mail exchanger = postmanrings2x.movie.edu postmanrings2x.movie.edu internet address = 192.249.249.20

295

alors que cest le second qui sapplique au courrier vers vangogh.cs.berkeley.edu :


% nslookup -type=mx vangogh.cs.berkeley.edu. Server: rainman.movie.edu Address: 192.249.249.19 Correspond lenregistrement MX *.edu

vangogh.cs.berkeley.edu preference = 10, mail exchanger = postmanrings2x.movie.edu postmanrings2x.movie.edu internet address = 192.249.249.20

Une fois que le courrier atteint la machine bastion postmanrings2x.movie.edu, le routeur de messagerie de postmanrings2x.movie.edu recherche lui-mme les enregistrements MX des adresses de destination. Puisque postmanrings2x.movie.edu rsout le nom de destination en utilisant lespace des noms de lInternet et non pas lespace des noms internes, il trouve les vrais enregistrements MX et peut livrer le courrier. Aucune reconguration de sendmail nest ncessaire.

Courrier destination de noms spciques de lInternet


Larchitecture racine interne permet aussi de retransmettre les courriers adresss des domaines spciques de lInternet via des machines bastion particulires, si on en a plusieurs. On peut choisir par exemple, denvoyer le courrier adress des destinataires du domaine uk de prfrence via la machine bastion situe Londres. Cela peut tre trs utile si on souhaite que le courrier transite au maximum par le rseau interne pour des raisons conomiques. LUniversit du Cinma dispose dune connexion de rseau priv vers son homologue situe aux Studios Pinewood prs de Londres. Pour des raisons de scurit, le courrier destination de correspondants situs dans le domaine uk doit transiter via le lien priv puis via lhte situ Pinewood. Pour cela, il faut ajouter les mta-enregistrements suivants au chier db.root :
; holygrail.movie.ac.uk est lextrmit britannique du lien *.uk. IN MX 10 holygrail.movie.ac.uk. holygrail.movie.ac.uk. IN A 192.168.76.4

Dsormais, tous les courriers adresss aux sous-domaines de uk seront retransmis la machine bastion holygrail.movie.ac.uk, qui est cense tre plus habile pour faire suivre le courrier vers les diffrentes destinations du Royaume Uni.

Problme avec les racines internes


Malheureusement, les architectures racine interne ont aussi des limites. Le plus gros problme est que les htes internes ne savent rien de lespace des noms de lInternet. Dans certains rseaux, ce nest pas un problme car la plupart des htes internes nont pas eux-mmes de connectivit directe lInternet. Leur resolver peut tre congur au minimum pour utiliser le serveur de noms situ sur une machine bastion. Certains de

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

296

Chapitre 11 Scurit

ces htes auront sans doute besoin dhberger des serveurs proxy pour permettre aux autres htes internes daccder des services situs sur lInternet. Dans les autres rseaux, toutefois, le pare-feu Internet ou les logiciels de ce type peuvent exiger que tous les htes internes soient capables de rsoudre les noms de lespace des noms Internet. Pour ces rseaux, une architecture racine interne ne fonctionnera pas.

Espace de noms fractionn


De nombreuses entreprises voudraient prsenter lInternet une image de leur rseau interne diffrente de la ralit. Souvent, de nombreuses informations internes la zone sont sans intrt pour lextrieur, en raison du pare-feu. Celui-ci peut parfois permettre daccder directement certains htes internes et deffectuer des traductions dadresses IP internes vers une plage dadresses IP ofciellement attribue lorganisme. Par consquent, lorganisme peut avoir besoin dliminer les informations internes dans la vue externe de la zone ou de modier les adresses internes en leur quivalent externe. Malheureusement, BIND ne propose ni ltrage ni traduction automatique des donnes de zone. Par consquent, de nombreuses entreprises crent manuellement des espaces de noms fractionns (split namespaces), dans lesquels lespace de noms rel nest disponible quen interne, alors quune version allge et traduite, appele espace de noms fantme, est visible depuis lInternet. Lespace de noms fantme contient les correspondances nom-adresse et adresse-nom des seuls htes du rseau priphrique (cest--dire situs lextrieur du pare-feu) ou accessibles partir de lInternet travers le pare-feu. Les adresses annonces peuvent tre des adresses traduites par rapport des adresses internes. Lespace de noms fantme peut aussi contenir un ou plusieurs enregistrements MX pour diriger le courrier venant de lInternet travers le pare-feu vers un serveur de courrier. Puisque lUniversit du Cinma a un pare-feu qui limite grandement laccs au rseau interne partir de lInternet, un espace de noms fantme a t cr. Pour la zone movie.edu, les seules informations annoncer concernent le nom movie.edu (un enregistrement SOA et quelques enregistrements NS), la machine bastion (postmanrings2x.movie.edu), le nom du nouveau serveur externe (ns.movie.edu) et le serveur web externe (www.movie.edu). Ladresse de linterface externe de la machine bastion est 200.1.4.2, celle du serveur de noms est 200.1.4.3 et celle du serveur web est 200.1.4.4. Le chier fantme de la zone movie.edu contient alors :
$TTL 1d @ IN SOA ns.movie.edu. 1 3h 1h 1w 1h ) ns.movie.edu. ns1.isp.net. hostmaster.movie.edu. ( numro de srie rafrachissement aprs 3 heures nouvel essai aprs 1 heure expiration aprs 1 semaine TTL rponse ngative d1 heure

; ; ; ; ;

IN IN IN IN IN

NS NS A MX MX

; le serveur de nom du FAI ; est un esclave de movie.edu 200.1.4.4 ; pour ceux qui tentent daccder http://movie.edu 10 postmanrings2x.movie.edu. 100 mail.isp.net.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu

297

www

IN

A A MX MX

200.1.4.4 200.1.4.2 10 postmanrings2x.movie.edu. 100 mail.isp.net. traite le courrier adress ns.movie.edu 200.1.4.3 10 postmanrings2x.movie.edu. 100 mail.isp.net. 10 postmanrings2x.movie.edu. 100 mail.isp.net.

postmanrings2x IN IN IN

; postmanrings2x.movie.edu ns IN A IN MX IN MX * IN IN MX MX

Aucun sous-rseau de movie.edu, ni aucune information de dlgation vers les serveurs de noms de ces sous-domaines ne sont mentionns. Ces informations ne sont pas ncessaires, puisquil ny a rien dans ces sous-domaines qui puisse intresser lInternet et le courrier entrant adress aux htes du sous-domaine est intercept grce au mta-caractre. Le chier db.200.1.4, dont on a besoin sur lInternet pour la rsolution inverse des adresses de movie.edu, contient :
$TTL 1d @ IN SOA ns.movie.edu. 1 3h 1h 1w 1h ) ns.movie.edu. ns1.isp.net. hostmaster.movie.edu. ( numro de srie rafrachissement aprs 3 heures nouvel essai aprs 1 heure expiration aprs 1 semaine TTL rponse ngative d1 heure

; ; ; ; ;

IN IN 2 3 4 IN IN IN

NS NS PTR PTR PTR

postmanrings2x.movie.edu. ns.movie.edu. www.movie.edu.

Il faut sassurer que les resolvers de la machine bastion, du serveur de messagerie et du serveur web ne sont pas congurs pour utiliser ns.movie.edu. Puisque ce dernier ne peut pas voir la zone interne relle movie.edu, son utilisation rendrait les trois machines cites incapables de faire correspondre les noms internes aux adresses et les adresses internes aux noms.

Congurer la machine bastion


La machine bastion est un cas particulier de lespace de noms fractionn. En effet, elle a un pied dans chaque environnement puisquune interface la connecte lInternet et lautre la connecte au rseau interne. Maintenant que lespace de noms est fractionn, comment la machine bastion peut-elle voir simultanment lespace de noms de lInternet et lespace de noms interne ? Si on place la liste des serveurs de la racine de lInternet dans ses chiers dindications initiales, elle suit la dlgation partir des serveurs de edu vers un serveur externe de movie.edu ayant des donnes de zone fantmes. Elle ne devrait pas voir lespace de noms interne dont elle a besoin pour voir

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

298

Chapitre 11 Scurit

les traces de connexion, pour livrer le courrier entrant, etc. Par contre, en congurant la machine bastion pour quelle utilise la racine interne, elle ne verra pas lespace de noms de lInternet, dont elle a pourtant besoin pour agir comme un pare-feu. Quelle option choisir ? Si on a des serveurs internes qui peuvent rsoudre la fois des noms internes et des noms de lInternet, en utilisant des zones rediriges, on peut simplement congurer le resolver de la machine bastion pour quil les interroge. Mais si on utilise la redirection en interne, et selon le type de pare-feu utilis, on peut aussi avoir besoin dinstaller un redirecteur sur la machine bastion elle-mme. Si le pare-feu ne laisse pas passer le trac DNS, il faut au moins, sur la machine bastion, un serveur cache congur avec les serveurs de la racine de lInternet, an que les serveurs internes aient un serveur vers lequel rediriger les requtes non rsolues. Si les serveurs internes ne grent pas les zones rediriges, le serveur sur la machine bastion doit tre congur comme un esclave ou une source (stub) pour movie.edu et toutes les zones in-addr.arpa pour lesquelles il doit rsoudre des adresses. Ainsi, sil reoit une requte pour un nom de movie.edu, il utilise les donnes locales sur lesquelles il fait autorit pour rsoudre le nom (cas dune zone-esclave) ou suivre les enregistrements NS internes jusquaux serveurs de noms faisant autorit (cas dune zone source) (si les serveurs internes acceptent les zones rediriges et sont correctement congurs, le serveur de noms sur la machine bastion ne recevra jamais de requte de noms situs dans movie.edu). Si le nom est dans un sous-domaine dlgu de movie.edu, le serveur sur la machine bastion suit les enregistrements NS situs dans les donnes de la zone movie.edu ou reus dun serveur de movie.edu pour interroger un serveur interne au sujet du nom. Par consquent, il na pas besoin dtre congur en esclave de chacun des sous-domaines de movie.edu, tel que fx.movie.edu, mais uniquement pour le domaine de plus haut niveau (voir la gure 11-6).

serveur primaire de movie.edu

serveur esclave de movie.edu client DNS

Pare-feu

Internet
machine bastion serveur primaire cach de movie.edu machine externe esclave cach de movie.edu

machine interne

Lgende

routeur requtes de transfert de zone requtes


(rponses utilisant le chemin de retour)

Rseau ouvert

machine de FAI

Figure 11-6. Solution avec un espace de noms fractionn

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu
Le chier named.conf de la machine bastion contient :
options { directory "/var/named"; }; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; }; zone "249.249.192.in-addr.arpa" { type slave; masters { 192.249.249.3; }; file "bak.192.249.249"; }; zone "253.253.192.in-addr.arpa" { type slave; masters { 192.249.249.3; }; file "bak.192.253.253"; }; zone "254.253.192.in-addr.arpa" { type slave; masters { 192.253.254.2; }; file "bak.192.253.254"; }; zone "20.254.192.in-addr.arpa" { type slave; masters { 192.253.254.2; }; file "bak.192.254.20"; }; zone "." { type hint; file "db.cache"; };

299

Protger les donnes de zone sur une machine bastion


Malheureusement, le chargement de ces zones sur la machine bastion les expose la divulgation sur lInternet, ce que lon tentait justement dempcher en fractionnant lespace de noms. Mais on peut protger les donnes de la zone laide de la sous-structure allow-query. Avec allow-query, on peut crer une liste globale daccs aux donnes. Voici la structure options du chier named.conf :
options { directory "/var/named"; allow-query { 127/8; 192.249.249/24; 192.253.253/24; 192.253.254/24; 192.254.20/24; }; };
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

300

Chapitre 11 Scurit

Il ne faut pas oublier dincorporer ladresse de bouclage dans la liste, sinon le propre resolver de la machine bastion ne peut pas obtenir de rponse du serveur local !

Conguration complte
Enn, il est ncessaire dappliquer les prcautions, dont nous avons parl, la machine bastion, et en particulier :

restriction sur les transferts de zone ; utilisation des ID alatoires de message (depuis BIND 8.2 mais pas en BIND 9) ; excution ventuelle de BIND par un utilisateur sans privilge et via chroot.
Le chier named.conf complet devrait ressembler ceci :
acl "interne" { 127/8; 192.249.249/24; 192.253.253/24; 192.253.254/24; 192.254.20/24; }; options { directory "/var/named"; allow-query { "interne"; }; allow-transfer { none; }; }; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; }; zone "249.249.192.in-addr.arpa" { type slave; masters { 192.249.249.3; }; file "bak.192.249.249"; }; zone "253.253.192.in-addr.arpa" { type slave; masters { 192.249.249.3; }; file "bak.192.253.253"; }; zone "254.253.192.in-addr.arpa" { type slave; masters { 192.253.254.2; }; file "bak.192.253.254"; }; zone "20.254.192.in-addr.arpa" { type slave; masters { 192.253.254.2; }; file "bak.192.254.20"; };
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

DNS et pare-feu
zone "." { type hint; file "db.cache"; };

301

Utiliser des vues sur la machine bastion


Sur une machine bastion fonctionnant en BIND 9, on peut utiliser les vues pour prsenter la zone fantme movie.edu au reste du monde, tout en rsolvant les noms de lInternet pour les machines internes. Cela permet de ne pas avoir besoin dinstaller un serveur de noms externe sur ns.movie.edu. Sinon, il faudra un serveur de noms supplmentaire pour prsenter la zone movie.edu externe. Cette conguration est trs proche de lune des congurations tudies dans la section Vues au Chapitre 10 (page 232) :
options { directory "/var/named"; }; acl "interne" { 127/8; 192.249.249/24; 192.253.253/24; 192.253.254/24; 192.254.20/24; }; view "interne" { match-clients { "interne"; }; recursion yes; zone "movie.edu" { type slave; masters { 192.249.249.3; }; file "bak.movie.edu"; }; zone "249.249.192.in-addr.arpa" { type slave; masters { 192.249.249.3; }; file "bak.192.249.249"; }; zone "253.253.192.in-addr.arpa" { type slave; masters { 192.249.249.3; }; file "bak.192.253.253"; }; zone "254.253.192.in-addr.arpa" { type slave; masters { 192.253.254.2; }; file "bak.192.253.254"; }; zone "20.254.192.in-addr.arpa" { type slave;

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

302
masters { 192.253.254.2; }; file "bak.192.254.20"; }; zone "." { type hint; file "db.cache"; }; }; acl "ns1.isp.net" { 199.11.28.12; }; view "externe" { match-clients { any; }; recursion no; zone "movie.edu" { type master; file "db.movie.edu.external"; allow-transfer { "ns1.isp.net"; }; }; zone "4.1.200.in-addr.arpa" { type master; file "db.200.1.4"; allow-transfer { "ns1.isp.net"; }; }; zone "." { type hint; file "db.cache"; }; };

Chapitre 11 Scurit

Les vues interne et externe prsentent deux aspects diffrents de movie.edu : lune est charge partir du serveur primaire de movie.edu interne et lautre partir des chiers de zone db.movie.edu.external. Sil y avait plus de zones dans la vue externe, on aurait probablement cr un sous-rpertoire diffrent pour les chiers des zones externes de celui des chiers de la zone interne.

Extensions de scurit du DNS


TSIG, dcrit au dbut de ce chapitre, est parfait pour scuriser les communications entre deux serveurs de noms ou entre un updater et un serveur. Toutefois, il ne protge pas contre la corruption dun serveur de noms : si un intrus prend possession dun hte hbergeant un serveur de noms, il peut accder aux cls TSIG. De plus, comme TSIG est bas sur le partage dun secret, il est difcile mettre en uvre sur de nombreux serveurs. On ne peut pas utiliser TSIG pour scuriser les communications entre serveurs, pour des serveurs situs sur lInternet en raison de la difcult de la propagation et de la gestion des cls. La meilleure solution pour rgler de tels problmes de gestion de cls est dutiliser un chiffrement cl publique. Les extensions de scurit du DNS, DNSSEC, dcrites dans les
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Extensions de scurit du DNS

303

RFC 4033, 4034 et 4035, utilisent un chiffrement cl publique pour permettre aux administrateurs de zone de signer lectroniquement leurs donnes, prouvant ainsi leur authenticit.
Nous allons dcrire les extensions de scurit du DNS dans leur forme actuelle, telles quelles sont dnies dans les RFC 4033 4035. Ces RFC mettent en vidence de profondes volutions dans DNSSEC depuis sa version initiale, dcrite dans la RFC 2065 (ainsi que dans la prcdente version de cet ouvrage). Toutefois, le groupe de travail DNSEXT de lIETF travaille encore sur DNSSEC et peut le faire voluer avant quil ne devienne un standard. BIND 8.2 fournit un dbut de mise en uvre de DNSSEC9, mais DNSSEC nest pas rellement utilisable avant BIND 9 ; de plus, il faut attendre la version 9.3.0 pour pouvoir lutiliser tel quil est dcrit dans cette section (et dans les RFC les plus rcents). Par consquent, nous utiliserons BIND 9.3.2 dans les exemples. Si on envisage dutiliser DNSSEC, il ne faudrait pas utiliser de version antrieure cette dernire.

Chiffrement cl publique et signature lectronique


Le chiffrement cl publique rsout le problme de distribution de cls en utilisant des algorithmes de chiffrement asymtriques. Dans un tel algorithme, une cl est utilise pour dchiffrer un message chiffr par une autre cl. Les deux cls forment une paire et sont gnres simultanment laide dune formule mathmatique. Cest le seul moyen simple pour gnrer deux cls ayant cette asymtrie spciale (lune dchiffre ce que lautre a chiffr) : il est en effet difcile de dterminer une cl a posteriori partir de lautre (lalgorithme de chiffrement asymtrique le plus utilis, RSA, met en jeu la factorisation de grands nombres, un problme notoirement complexe). Avec un chiffrement cl publique, on commence par gnrer une paire de cls. Lune des cls devient la cl publique (publie dans un annuaire, par exemple) et lautre la cl prive (maintenue secrte). Pour communiquer de manire scurise, lexpditeur chiffre son message avec la cl publique du destinataire avant de le lui envoyer (ou de le publier dans un forum ou sur un serveur web). Si le destinataire a bien conserv secrte sa cl prive, il est le seul pouvoir dchiffrer le message. Inversement, lexpditeur peut chiffrer le message laide de sa propre cl prive avant de lexpdier. Le destinataire peut ainsi vrier que le message vient bien de cet expditeur en tentant de le dchiffrer avec la cl publique de lexpditeur. Si le message dchiffr est lisible et que lexpditeur a bien conserv secrte sa cl prive, le destinataire peut tre certain que cest bien cet expditeur qui a chiffr le message. Le dchiffrement prouve aussi que le message na pas t altr durant son transit (par exemple lors de son passage dans un serveur de messagerie). De cette manire, le destinataire peut authentier le message. Malheureusement, le chiffrement dune grande quantit de donnes avec un algorithme asymtrique est relativement lent (il est plus lent quavec un algorithme symtrique). Toutefois, lutilisation dun chiffrement par cl publique pour
9. En particulier, BIND 8 ne peut pas suivre une chane de conance. Il ne peut vrier des enregistrements SIG que pour les zones pour lesquelles il dispose de structures trusted-keys.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

304

Chapitre 11 Scurit

lauthentication (et non pas pour la condentialit) ne ncessite pas le chiffrement de la totalit du message. On commence donc par passer le message dans une fonction de hachage non inversible, puis on chiffre la valeur obtenue. On attache ensuite la valeur de hachage chiffre, quon appelle signature lectronique, au message quon veut authentier. Le destinataire authentie le message en dchiffrant la signature lectronique puis en passant le message dans la fonction de hachage non inversible. Si la valeur obtenue est gale la signature lectronique dchiffre, le message est authentique. Nous appelons signature le processus de calcul de la valeur de hachage, et vrication le processus de validation de la signature lectronique. Ils sont tous deux dcrits dans la gure 11-7.

Signature
message

fonction de hachage

valeur de hachage chiffrement avec cl prive

signature numrique

message sign

Vrification

message sign

message

signature numrique
dchiffrement avec cl publique

valeur de hachage 1

fonction de hachage

valeur de hachage 2 comparaison valeur de hachage 1 valeur de hachage 2

Figure 11-7. Signature et vrification dun message


[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Extensions de scurit du DNS

305

Enregistrement DNSKEY
Avec les extensions de scurit du DNS, chaque zone signe dispose dune paire de cls. La cl prive est stocke dans un endroit sr, en gnral dans un chier sur le serveur de noms primaire. La cl publique de la zone est annonce sous la forme dun enregistrement de ressource, lenregistrement DNSKEY, li au nom de la zone. La version prcdente de DNSSEC comportait un enregistrement KEY usage gnral : on pouvait lutiliser pour mmoriser diffrents types de cl de chiffrement, et pas seulement les cls publiques utilises par DNSSEC. Toutefois, la nouvelle version de DNSSEC nutilise que lenregistrement DNSKEY pour stocker la cl publique dune zone. Lenregistrement DNSKEY se prsente sous la forme suivante :
movie.edu. IN DNSKEY 257 3 5 AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9CciAxJfMcS1vEuwz9c +QG7s EJnQuH5B9i5o/ja+DVitY3jpXNa12mEn

Le nom de lenregistrement est celui de la zone laquelle est rattache la cl. Le premier champ suivant le type denregistrement, 257 ici, est un ensemble, sur deux octets, de deux drapeaux de un bit chacun :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | |ZK | |SEP| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Les bits 0 6 et les bits 8 14 sont rservs et doivent tre zro. Le bit 7 dcrit le type de la cl : 0 Ce nest pas une cl de zone. Elle ne peut pas tre utilise pour vrier des donnes de zone signes. 1 Cest une cl de zone. Le nom associ lenregistrement DNSKEY est le nom de la zone signe. Le dernier bit (15) est le drapeau du point dentre de scurit (Secure Entry Point ou SEP), dont lutilisation exprimentale est dcrite dans la RFC 3757. Nous le dtaillerons plus loin dans ce chapitre. Dans lenregistrement DNSKEY dcrit plus haut, le champ des drapeaux (le premier champ aprs le type) indique que cette cl est celle de la zone movie.edu. Le champ suivant, de valeur 3, est le champ protocole. Cest un hritage de la prcdente version de DNSSEC, dans laquelle lenregistrement KEY pouvait servir diffrentes fonctions. Dans la version actuelle de DNSSEC, toutefois, lenregistrement DNSKEY ne sert qu DNSSEC, aussi ce champ est-il toujours gal 3, une valeur qui, historiquement, dsigne une cl DNSSEC. Le champ suivant, de valeur 5 ici, est le champ algorithme. DNSSEC peut fonctionner avec plusieurs algorithmes de chiffrement cl publique, ce qui ncessite de signaler lalgorithme utilis pour signer la zone :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

306
0 Valeur rserve. 1

Chapitre 11 Scurit

RSA/MD5. Lutilisation de RSA/MD5 est dconseille, essentiellement en raison de la dcouverte rcente dimperfections dans lalgorithme de hachage. 2 Dife-Hellman. Dife-Hellman ne peut pas servir la signature de zones, mais il peut servir dautres objets de DNSSEC. 3 DSA/SHA-1. Lutilisation de DSA/SHA-1 (en plus de tout algorithme obligatoire) est optionnelle. 4 Valeur rserve pour un algorithme cl publique bas sur les courbes elliptiques. 5 RSA/SHA-1. Lutilisation de RSA/SHA-1 est obligatoire. 253254 Valeurs rserves une utilisation prive par la RFC 4034. 255 Valeur rserve. Dans nos exemples, nous utiliserons des cls RSA/SHA-1. Le dernier champ est la cl publique elle-mme, code en base 64. DNSKEY accepte des cls de diffrentes tailles, comme nous lavons vu rapidement lorsque nous avons gnr la cl publique de movie.edu. Plus la cl publique est longue, plus elle est sre (il est plus difcile de dcouvrir la cl prive associe), mais plus il est long de signer les donnes dune zone avec la cl prive et de les vrier avec la cl publique, et plus lenregistrement DNSKEY et la signature rsultante sont longs.

Enregistrement RRSIG
Lenregistrement DNSKEY stocke la cl publique. Il faut aussi un enregistrement pour mmoriser la signature lie la cl prive, lenregistrement RRSIG. Cet enregistrement mmorise la signature numrique dans un RRset. Un RRset (Resource Record set) est un ensemble denregistrements de ressource de mme nom, classe et type. Lensemble des enregistrements dadresse de wormhole.movie.edu, par exemple, forment un RRset. De mme, lensemble des enregistrements MX de movie.edu forment un RRset. An de gagner du temps, on signe un RRset plutt que des enregistrements individuels. En effet, il ny a aucun moyen de rechercher un seul des enregistrements dadresse de wormhole.movie.edu : un serveur renvoie toujours lensemble. Il ny a donc aucun intrt signer chaque enregistrement sparment. Voici lenregistrement RRSIG qui couvre les enregistrements dadresses de wormhole.movie.edu :

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Extensions de scurit du DNS


wormhole.movie.edu. 86400 RRSIG A 5 3 86400 20060219233605 ( 20060120233605 3674 movie.edu. ZZP9AV28r824SZJqyIT+3WKkMQgcu1YTuFzp LgU3EN4USgpJhLZbYBqTHL77mipET5aJr8Od RxZvfFHHYV6UGw== )

307

Le nom de lenregistrement est wormhole.movie.edu, le mme nom que celui des enregistrements signs. Le premier champ aprs le champ type, ici de valeur A, est le type couvert. Il indique quels enregistrements de wormhole.movie.edu sont signs (ici les enregistrements dadresse). Il devrait y avoir un enregistrement SIG spcique pour chaque type denregistrement associ wormhole.movie.edu. Le second champ aprs le champ type, ici de valeur 5, est la rfrence de lalgorithme. Les valeurs sont les mmes que celles utilises dans lenregistrement DNSKEY ; 5 signie donc RSA/SHA-1. Si on gnre une cl RSA/SHA-1 et quon lutilise pour signer une zone, on obtient naturellement des signatures RSA/SHA-1. Si on signe une zone avec plusieurs types de cl, par exemple RSA/SHA-1 et DSA, on obtient deux enregistrements RRSIG pour chaque RRset couvrir, un avec un numro dalgorithme 5 (RSA/SHA1) et un avec un numro dalgorithme 3 (DSA)10. Le troisime champ indique le nombre de termes dans le nom de lenregistrement. wormhole.movie.edu contient trois termes, le champ est donc ici 3. Le nombre de termes et la valeur du champ peuvent diffrer lorsque lenregistrement RRSIG couvre un enregistrement gnrique. Nous ne dcrirons pas les nuances des enregistrements gnriques dans les zones signes. Le quatrime champ contient le TTL dorigine des enregistrements de lensemble couvert (tous les enregistrements dun RRset sont censs avoir le mme TTL). Le TTL doit tre mmoris ici car un serveur mettant en mmoire cache le RRset couvert par cet enregistrement RRSIG dcrmentera le TTL des enregistrements mmoriss. Or, si on ne connat pas le TTL dorigine dun enregistrement, il nest pas possible de reconstruire lenregistrement dadresse dorigine et de le fournir la fonction de hachage pour vrier la signature numrique. Les deux champs suivants contiennent, respectivement, la date dchance de la signature et sa date dorigine. Ils sont stocks sous la forme dun entier non sign et reprsentent la dure coule, en secondes, depuis lorigine dUnix (Epoch), cest--dire depuis le 1er janvier 1970. Dans un enregistrement RRSIG, ils sont prsents sous la forme AAAAMMJJHHMMSS (dans lexemple, la date dchance est le 19 fvrier 2006 peu aprs 23h36). La date dorigine de la signature est habituellement celle de lexcution du programme de signature de la zone. La date dchance est choisie ce moment-l. Aprs lchance de la signature, lenregistrement RRSIG nest plus utilisable pour vrier le RRset. Cela signie quil est ncessaire de re-signer priodiquement une zone. Cette opration est heureusement plus rapide que la mise en place initiale. Lenregistrement suivant, ici de valeur 3674, est lidentiant de cl. Sa valeur est drive de la cl publique associe la cl prive qui a servi signer la zone. Si la zone possde

10. On peut signer une zone avec deux cls dalgorithmes diffrents de manire ce que ceux dont les logiciels prfrent DSA puissent lutiliser pour vrier les donnes et que ceux qui ne fonctionnent quavec RSA-SHA-1 puissent aussi fonctionner.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

308

Chapitre 11 Scurit

plus dune cl publique (ce qui sera probablement le cas), le logiciel de vrication DNSSEC utilise lidentiant pour dterminer la cl utiliser durant la vrication. Le huitime champ, ici de valeur movie.edu., contient le nom du signataire. Cest le nom de la cl publique que doit utiliser le vricateur pour tester la signature. Associ lidentiant de cl, il dsigne lenregistrement DNSKEY utiliser. Le nom du signataire est le nom de la zone dans laquelle se trouvent les enregistrements signs. Le dernier champ est celui de la signature. Il contient la signature lectronique, par la cl prive de la zone, sur les enregistrements signs ainsi que sur la partie droite de lenregistrement RRSIG lui-mme (le champ signature exclu). Cette signature est code en base 64.

Enregistrement NSEC
DNSSEC dnit un nouvel enregistrement de ressource, lenregistrement NSEC. Que se passe-t-il si on recherche un nom qui nexiste pas, dans une zone scurise ? Si la zone nest pas signe, le serveur renvoie simplement le code no such domain name qui indique que ce nom nexiste pas. Mais comment peut-on signer un code de rponse ? Si on signe la totalit du message de rponse, il sera difcile mettre en mmoire cache. Il faut donc disposer dun lment supplmentaire qui permette de prouver quun nom nexiste pas. Lenregistrement NSEC rsout ce problme de signature de rponse ngative, en annonant le nom qui suit un autre nom dans une zone. Ce systme est bas sur un classement pralable des noms, do le nom du type denregistrement NSEC pour Next SECure (nom scuris suivant). Mais la notion de noms conscutifs sous entend un ordre canonique des noms dans la zone. Pour classer les noms dune zone, on commence par traiter les termes de droite des noms, puis viennent ensuite les termes immdiatement gauche et ainsi de suite. Lordre, qui ne tient pas compte de la casse des caractres, est celui du dictionnaire : les chiffres prcdent les lettres et les termes inexistants prcdent les chiffres. Ainsi, movie.edu prcde 0.movie.edu. Pour movie.edu, on obtient le classement suivant :
movie.edu carrie.movie.edu cujo.movie.edu fx.movie.edu bladerunner.fx.movie.edu outland.fx.movie.edu horror.movie.edu localhost.movie.edu mi.movie.edu misery.movie.edu monsters-inc.movie.edu shining.movie.edu shrek.movie.edu toys.movie.edu toystory.movie.edu

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Extensions de scurit du DNS


wh.movie.edu wh249.movie.edu wh253.movie.edu wormhole.movie.edu

309

Notons que tout comme movie.edu prcde carrie.movie.edu, fx.movie.edu prcde bladerunner.fx.movie.edu. Une fois que la zone est classe, les enregistrements NSEC prennent tout leur sens. Voici le premier, celui de movie.edu :
movie.edu. DNSKEY NSEC carrie.movie.edu. NS SOA MX RRSIG NSEC

Cet enregistrement indique que le nom suivant movie.edu est carrie.movie.edu, ce qui est conforme la liste ordonne. Il indique aussi que movie.edu dispose denregistrements NS, dun enregistrement SOA, denregistrements MX, dun enregistrement RRSIG, dun enregistrement NSEC et dun enregistrement DNSKEY. Le dernier enregistrement NSEC dune zone est spcial ; il referme la boucle, en dsignant le premier enregistrement de la zone :
wormhole.movie.edu. NSEC movie.edu. A RRSIG NSEC

Ainsi, pour indiquer que wormhole.movie.edu est le dernier enregistrement de la zone, il suft dindiquer que le nom suivant est movie.edu, le premier de la zone. Nous dirons quil sagit dune logique circulaire. Revenons la question dorigine : comment un enregistrement NSEC fournit-il lauthentication dune rponse ngative ? Si on recherche www.movie.edu, on reoit en retour lenregistrement NSEC de wormhole.movie.edu, ce qui indique que www.movie.edu nexiste pas, car il ny a pas de nom aprs wormhole.movie.edu. De mme, si on recherche les enregistrements TXT de movie.edu, on reoit le premier enregistrement NSEC montr dans cette section, qui indique quil ny a pas denregistrement TXT pour movie.edu, mais uniquement des enregistrements NS, SOA, MX, RRSIG, NSEC et DNSKEY. Un enregistrement RRSIG couvrant lenregistrement NSEC accompagne la rponse, authentiant linexistence du nom ou du type recherch. Il est important quun enregistrement NSEC indique prcisment ce qui nexiste pas dans la zone. Un message qui dirait simplement nexiste pas pourrait tre intercept et rejou pour annoncer quun nom ou un type denregistrement nexiste pas alors quil existe en ralit. Rassurons ceux qui voudraient mettre en place un tel mcanisme : BIND fournit un outil pour ajouter automatiquement des enregistrements NSEC et RRSIG. On peut aussi sinquiter des informations fournies aux pirates par les enregistrements NSEC. Un pirate peut commencer par rechercher lenregistrement NSEC associ au nom de zone, an de dcouvrir la liste des types associs au domaine ainsi que le nom suivant. Puis il peut rechercher lenregistrement NSEC associ au suivant, et ainsi de suite, pour btir la liste de tous les noms dune zone. Cest malheureusement un effet de bord ngatif. Mais on peut toujours se dire que notre zone est sre, mais publique .

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

310

Chapitre 11 Scurit

Enregistrement DS et chane de conance


Chaque RRset de la zone a un enregistrement RRSIG associ. Pour permettre tout le monde de vrier ces enregistrements RRSIG, la zone annonce ses cls publiques dans un enregistrement DNSKEY. Mais imaginons que le serveur primaire soit pirat. Le pirate pourrait gnrer sa propre paire de cls, modier les donnes de la zone, puis la signer nouveau en annonant sa propre cl dans un enregistrement DNSKEY. Pour viter ce problme, la cl publique de la zone est certie par une autorit suprieure, qui atteste que la cl publique de movie.edu annonce dans lenregistrement DNSKEY appartient rellement lorganisme. Avant de donner cette certication, lautorit suprieure demande la preuve de lidentit et de la fonction dadministrateur dment autoris de movie.edu. Lautorit suprieure est la zone-parente, edu. Lors de la gnration de la paire de cls et de la signature de zone, la cl publique a t envoye aux administrateurs de edu, avec les preuves didentit et de fonction dadministrateur de movie.edu11. Les administrateurs de edu signalent quils ont vri cette identit et la cl publique en insrant un enregistrement DS dans la zone edu et en signant cet enregistrement avec leur propre cl prive.Voici les enregistrements rsultants :
movie.edu. 86400 DS 15480 5 1 ( F340F3A05DB4D081B6D3D749F300636DCE3D 6C17 ) DS 5 2 86400 20060219234934 ( 20060120234934 23912 edu. Nw4xLOhtFoP0cE6ECIC8GgpJKtGWstzk0uH6 nd2cz28/24j4kz1Ahznr/+g5oU3AADyv86EK CnWZtyOeqnfhMZ3UW0yyPcF3wy73tYLQ/KjN gPm1VPQA/Sl3smauJsFW7/YPaoQuxcnREPWf YWInWvWx12IiPKfkVU3F0EbosBA= )

86400

RRSIG

DS signie Delegation Signer (signature de dlgation). Lenregistrement DS annonce la cl publique autorise signer les donnes de la zone movie.edu. Le premier champ aprs le type est ltiquette de cl, comme dans un enregistrement RRSIG, qui aide identier lenregistrement DNSKEY autoris effectuer les signatures. Le second champ dsigne lalgorithme, comme dans les enregistrements DNSKEY et RRSIG, et il est aussi utilis pour identier lenregistrement DNSKEY appropri dans le cas de plusieurs algorithmes de chiffrement. Le troisime champ indique le type dempreinte (digest type) que le vricateur doit utiliser pour vrier cette empreinte (le dernier champ). La seule valeur actuellement admise est 1, ce qui dsigne SHA-1. Lempreinte est une valeur de hachage non inversible sur 20 octets, code en hexadcimal, de lenregistrements DNSKEY12. Un enregistrement RRSIG accompagne lenregistrement DS, montrant que ladministrateur de edu a sign lenregistrement DS de movie.edu, attestant ainsi sa valeur.

11. Actuellement, seule la zone suprieure sudoise, se, signe sa zone et peut signer des enregistrements DNSKEY. 12. Une source (daccord, lun de nos relecteurs, mais source sonne mieux) nous a signal quune version prochaine de BIND utilisera SHA-256, an de contourner une faiblesse de SHA-1.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Extensions de scurit du DNS

311

En suivant la rfrence partir des serveurs de edu jusquaux serveurs de movie.edu et en vriant lenregistrements DNSKEY de movie.edu, un serveur vrie tout dabord lenregistrement RRSIG couvrant lenregistrement DS. Aprs cette vrication, le serveur recherche les enregistrements DNSKEY associs movie.edu et en slectionne un correspondant lidentiant et lalgorithme indiqus dans lenregistrement DS. Une fois lenregistrement DNSKEY adquat trouv, le serveur parcourt lenregistrement jusqu lempreinte et vrie quelle est identique celle afche dans lenregistrement DS. Dans lafrmative, lenregistrement DNSKEY est authentique ; le serveur peut lutiliser pour vrier les enregistrements RRSIG couvrant le RRset DNSKEY ou tout autre RRset sign par la cl prive correspondante. Que se passe-t-il si le serveur primaire de la zone edu est pirat ? Lenregistrement DNSKEY de la zone edu est certi par signature via un enregistrement DS dans la zone racine ; il nest donc pas facile remplacer et il en est de mme pour les donnes signes par lui. Et la zone racine ? Sa cl publique est connue de tous et est congure sur chaque serveur de noms qui supporte DNSSEC. La cl publique de la zone racine sera enregistre sur chaque serveur de noms lorsque DNSSEC sera totalement dploy. Mais pour le moment, ni la zone racine ni la zone edu ne sont signes, et aucune na de paire de cls. En attendant le dploiement complet de DNSSEC, il est toutefois possible de lutiliser au coup par coup.

lots scuriss
On souhaite scuriser la zone de lUniversit du Cinma laide de DNSSEC. On commence donc par signer la zone movie.edu mais edu ne signe pas denregistrement DNSKEY, puisque edu na pas encore scuris sa zone et na pas de paire de cls. Comment les serveurs de noms de lInternet peuvent-ils alors vrier les informations ? Comment les serveurs de la zone peuvent-ils vrier leur propres donnes ? La structure trusted-keys de BIND 9 permet de dnir la cl publique dune zone particulire dans le chier named.conf. Voici la structure trusted-keys pour movie.edu :
trusted-keys { movie.edu. 257 3 5 "AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9CciAxJfMcS1vEuwz9c +QG7s EJnQuH5B9i5o/ja+DVitY3jpXNa12mEn"; };

Il sagit de lenregistrement DNSKEY, sans les champs classe et type ; la cl est entre guillemets. Le nom de la zone peut ventuellement tre plac entre guillemets. Si movie.edu dispose de plus dune cl publique (par exemple une cl DSA), on peut aussi la dclarer :
trusted-keys { movie.edu. 257 3 5 "AQPWA4BRyjB3eqYNy/oykeGcSXjl+HQK9CciAxJfMcS1vEuwz9c +QG7s EJnQuH5B9i5o/ja+DVitY3jpXNa12mEn"; movie.edu. 257 3 3 "AMnD8GXACuJ5GVnfCJWmRydg2A6JptSm6tjH7QoL81SfBY/kcz1Nbe Hh z4l9AT1GG2kAZjGLjH07BZHY+joz6iYMPRCDaPOIt9LO+SRfBNZg62P4 aSPT5zVQPahDIMZmTIvv O7FV6IaTV+cQiKQl6noro8uTk4asCADrAHw0 iVjzjaYpoFF5AsB0cJU18fzDiCNBUb0VqE1mKFuRA/K 1KyxM2vJ3U7IS to0IgACiCfHkYK5r3qFbMvF1GrjyVwfwCC4NcMsqEXIT8IEI/YYIgFt4 Ennh"; };
[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

312

Chapitre 11 Scurit

Cette structure trusted-keys permet un serveur BIND 9 de vrier tous les enregistrements de la zone movie.edu. Le serveur distant peut aussi vrier tous les enregistrements des zones-enfants, comme fx.movie.edu, condition que leur enregistrement DNSKEY soit certi par un enregistrement DS et accompagn dun enregistrement RRSIG dans movie.edu. Pour rsumer, movie.edu devient un refuge de conance, au dessous duquel un serveur de noms distant peut vrier toute donne de zone signe.

Dlgation vers une zone non signe


Un enregistrement DS met en vidence quun sous-domaine dlgu spcique est sign et ofcialise un enregistrement DNSKEY particulier pour la vrication des donnessignes. Mais que se passe-til si un sous-domaine nest pas sign ? Les sous-domaines non signs ne disposent pas denregistrement DS dans leur zoneparente. Bien sr, ils nont pas non plus denregistrement RRSIG pour couvrir leur enregistrement DS. Les enregistrements NS qui mettent en uvre la dlgation seront cependant associs un ou plusieurs enregistrements NSEC, qui seront eux-mme couverts par un enregistrement RRSIG. Sil existe un enregistrement dadresse de recolage, il ny aura ni enregistrement NSEC ni enregistrement RRSIG, car ces derniers seront alors situs dans le sous-domaine. La rsolution de nom lorsquun serveur suit la dlgation partir dune zone signe jusqu une zone non signe dpend alors de la politique de scurit de ce serveur. Ce dernier peut soit accepter les rponses provenant de la zone non signe, soit exiger que ces rponses soient signes.

DO, AD et CD
Nous avons vu un exemple pour chacun des quatre nouveaux enregistrements de DNSSEC et nous connaissons maintenant leur longueur. Mais la longueur classique dun message DNS bas sur UDP nest que de 512 octets. Lincorporation de tous ces RRSIG devrait conduire des rponses tronques. Pour faire face ce problme, DNSSEC requiert EDNS0, que nous avons prsent au Chapitre 10. EDNS0 permet lutilisation de messages DNS bass sur UDP de 4096 octets. EDNS0 utilise aussi un nouveau drapeau, DO (DNSSEC OK), pour signaler quun quipement lanant une requte supporte DNSSEC et souhaite obtenir les enregistrements relatifs DNSSEC dans la rponse. Grce au drapeau DO, un serveur nincorporera pas inutilement un ensemble denregistrements sans intrt pour des demandeurs ne mettant pas en uvre DNSSEC. DNSSEC utilise deux autres drapeaux dans les requtes : DO et CD. Ils sont intgrs dans len-tte standard des requtes DNS et ont t placs des emplacements prcdemment libres13. AD signie Authenticated Data (donnes authenties). Il est positionn par un serveur capable de grer DNSSEC, mais uniquement dans les rponses pour lesquelles la totalit des enregistrements DNSSEC inclus dans le message ont t vris.

13. Seuls trois emplacements restaient libres dans len-tte. AD et CD en occupent maintenant deux.

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

Extensions de scurit du DNS

313

Le bit AD est destin aux resolvers qui interrogent un serveur de noms prenant en charge DNSSEC. Comme ils ne peuvent eux-mmes vrier les enregistrements DNSSEC, ils peuvent ainsi savoir si une rponse a t valide. Toutefois, ces resolvers ne peuvent avoir conance dans le bit AD que si leur communication avec le serveur de noms est sre, par exemple grce lutilisation de IPSEC ou de TSIG. Le bit CD (Checking Disabled, ne pas vrier) sert aux resolvers qui savent vrier les enregistrements DNSSEC. laide de ce bit, le resolver informe le serveur de noms quil ne doit pas perdre de temps vrier les enregistrements DNSSEC pour le compte du resolver, ce dernier tant capable deffectuer lui-mme le travail.

Utiliser les enregistrements


Observons le fonctionnement dun serveur de noms supportant DNSSEC lors de la vrication dun enregistrement de movie.edu. En particulier, regardons ce qui se passe lors de la recherche de ladresse de wormhole.movie.edu. Nous utiliserons dig, car on ne peut manipuler le bit DO avec nslookup. Tout dabord, le serveur envoie une requte dadresse :
% dig +dnssec +norec wormhole.movie.edu. ; <<>> DiG 9.3.2 <<>> +dnssec +norec wormhole.movie.edu. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32579 ;; flags: qr aa ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;wormhole.movie.edu. IN A ;; ANSWER SECTION: wormhole.movie.edu. 86400 IN A 192.253.253.1 wormhole.movie.edu. 86400 IN A 192.249.249.1 wormhole.movie.edu. 86400 IN RRSIG A 5 3 86400 20060219233605 20060120233605 3674 movie.edu. ZZP9AV28r824SZJqyIT+3WKkMQgcu1YTuFzpLgU3EN4USgpJhLZbYBqT HL77mipET5aJr8OdRxZvfFHHYV6UGw== ;; AUTHORITY SECTION: movie.edu. 86400 IN NS outland.fx.movie.edu. movie.edu. 86400 IN NS wormhole.movie.edu. movie.edu. 86400 IN NS toystory.movie.edu. movie.edu. 86400 IN RRSIG NS 5 2 86400 20060219233605 20060120233605 3674 movie.edu. bwiM/R56VVV0pHrzIERVADLat7BoTR+eeFuCfgYc/ GMXecdTxnUahLig RKsbNSsY+Uz8RVkcewFSiExExFoqwA==

[12/01/08]

Laetitia MAISON <keshin@free.fr>

DNS et Bind

314

Chapitre 11 Scurit

;; ADDITIONAL SECTION: toystory.movie.edu. 86400 IN A 192.249.249.3 toystory.movie.edu. 86400 IN RRSIG A 5 3 86400 20060219233605 20060120233605 3674 movie.edu. hlz+W41UlcfIaCMdzoKVAuTPjnyqZhxY3TKOOm/ 2i7FPAkfnVyWMyTwG iBns7Z1ws6QVj7+ZedDFx7xs+V0Iyw== ;; ;; ;; ;; Query time: 13 msec SERVER: 127.0.0.1#53(127.0.0.1) WHEN: Fri Jan 20 16:52:54 2006 MSG SIZE rcvd: 474

Notons que nous avons d prciser +dnssec en ligne de commande. Cette option provoque le positionnement du drapeau DO que nous venons de dcrire, ce qui informe ainsi le serveur de noms quil doit incorporer des enregistrements DNSSEC dans la rponse. On peut voir dans lafchage de dig que ce drapeau est positionn dans la ligne commenant par ; EDNS:. Le champ des drapeaux montre bien le bit DO ainsi quun rglage de la taille maximale de message UDP ngoci 4096 octets. Notons aussi que la rponse contient trois enregistrements RRSIG : lun couvre les enregistrements de la section de la question, un autre couvre les enregistrements de la section des enregistrements faisant autorit et le dernier couvre les enregistrements dadresse de toystory.movie.edu, dans la section des enregistrements complmentaires. Pour vrier les enregistrements RRSIG, le serveur de noms doit regarder lenregistrement DNSKEY de movie.edu. Mais avant dutiliser la cl, il doit la vrier moins, bien sr, quil ne lait dj vrie ou quil ne connaisse dj la cl publique de movie.edu via une structure trusted-keys. La vrication de la cl peut ncessiter plusieurs nouvelles requtes : une vers un serveur de noms de edu pour chercher lenregistrement DS de movie.edu ainsi que les enregistrements RRSIG qui le couvrent, et ventuellement une autre vers un serveur de la racine pour rechercher lenregistrement DS de edu ain