5 Format des “ Resource Record ”
Comme pour toute base de donn´ees, le serveur de nom a un format pour ses champs, ou “ Resource Record ”, RR dans la suite de ce texte, d´efini `a l’origine dans la RFC 1035.
En pratique toutes les distributions (commerciales ou libres) du serveur de noms conservent ce format de base de donn´ees, la mise en œuvre du serveur seule change (fichier de configuration du daemon).
Un serveur de noms a autorit´e (responsabilit´e duSOA) sur une ou plusieurs zones, celles-ci sont rep´er´ees dans ses fichiers de configuration (named.conf ounamed.bootselon les versions). S’il est serveur primaire d’une ou plusieurs zones, le contenu de ces zones est inscrit dans des fichiers ASCII ; leur syntaxe est succintement d´ecrite dans le paragraphe suivant.
S’il est serveur secondaire, le fichier de configuration indique au server de quelle(s) zone(s) il est secondaire (il peut ˆetre secondaire d’un grand nombre de zones) et donc o`u (adresse IP) il devra aller chercher cette information.
Cette action se traduit par ce que l’on nomme un “ transfert de zone ”. Ce transfert est effectu´e automatiquement `a la fr´equence pr´evue par l’adminis-trateur du champ SOA et donc connue d`es le premier transfert. En cas de changement sur le serveur principal, celui-ci avertit (“ Notify ”) ses serveurs secondaires de la n´ecessit´e de recharger la zone pour ˆetre `a jour.
Le propos de ce qui suit n’est pas de se substituer `a une documenta-tion nombreuse et bien faite sur le sujet, mais d’apporter quelques ´el´ements fondamentaux pour en aider la lecture.
Le constituant de base d’un serveur de noms est une paire de fichiers ASCII contenant les enregistrements, les “ Resource Record ”.
Ceux-ci sont en g´en´eral ´ecrits sur une seule ligne de texte (sauf pour le champ SOA qui s’´etale sur plusieurs lignes. Le marqueur de fin de ligne (CR+LF) est aussi celui de la fin de l’enregistrement. Le contenu g´en´eral d’un tel enregistrement a la forme suivante (les accolades indique des donn´ees optionnelles) :
{name} {ttl} addr-class Record Type Record Specific data
Cinq enregistrements, ou “ Resource Record ”, ou en RR, sont absolument fondamentaux pour faire fonctionner un serveur de noms : SOA, NS,A, MX et PTR.
5.1 RR de type SOA
$(ORIGIN) sio.ecp.fr.
name {ttl} addr−class SOA Origin Person in charge
@ IN SOA sio.ecp.fr. hostmaster.sio.ecp.fr. ( 2003110301 ; Serial
10800 ; Refresh (3h) 3600 ; Retry (1H) 3600000 ; Expire (5w6d16h) 86400 ) ; Minimum ttl (1D)
SOA est l’acronyme de “ Start Of Authority ” et d´esigne le d´ebut oblig´e et unique d’une zone. Il doit figurer dans chaque fichierdb.domain et db.adresseLe nom de cette zone est ici rep´er´e par le caract`ere @ qui signifie la zone courante, rep´er´ee par la ligne au dessus “$(ORIGIN) sio.ecp.fr.”.
La ligne aurait ´egalement pu s’´ecrire :
sio.ecp.fr. IN SOA sio.ecp.fr. hostmaster.sio.ecp.fr. ( ...
Un probl`eme concernant cette zone devra ˆetre signal´e par e-mail `a hostmaster@sio.ecp.fr(notez le “.” qui s’est transform´e en “@”).
Les param`etres de ce SOA sont d´ecrits sur plusieurs lignes, regroup´ees entres parenth`eses. Le caract`ere “ ;” marque le d´ebut d’un commentaire, qui s’arrˆete `a la fin de ligne.
Les points en fin de noms sont n´ecessaires.
Le num´ero de s´erie doit changer `a chaque mise `a jour de la zone (sur le serveur principal). Le “ Refresh ” indique la fr´equence, en secondes, `a laquelle les serveurs secondaires doivent consulter le primaire pour ´eventuellement lancer un transfert de zone (si le num´ero de s´erie est plus grand). Le “ Retry ” indique combien de secondes un serveur secondaire doit attendre un transfert avant de le d´eclarer impossible. Le “ Expire ” indique le nombre de secondes maximum pendant lesquelles un serveur secondaire peut se servir des donn´ees du primaire en cas d’´echec du transfert. “ Minimum ttl ” est le nombre de secondes par d´efaut pour le champ TTLsi celui-ci est omis dans les RR.
5.2 RR de type NS
Il faut ajouter une ligne de ce type (“ Name Server ”) pour chaque serveur de noms pour le domaine. Notez bien que rien dans la syntaxe ne permet de distinguer le serveur principal de ses secondaires.
Dans le fichierdb.domaine :
{name} {ttl} addr−class NS Name servers name IN NS ns−master.sio.ecp.fr.
IN NS ns−slave1.sio.ecp.fr.
IN NS ns−slave2.sio.ecp.fr.
RR de type A 119 Dans le fichier qui renseigne la zone “ reverse ”, par exemple db.adresse, on trouvera :
52.195.138.in−addr.arpa. IN NS ns−master.sio.ecp.fr.
52.195.138.in−addr.arpa. IN NS ns−slave1.sio.ecp.fr.
52.195.138.in−addr.arpa. IN NS ns−slave2.sio.ecp.fr.
5.3 RR de type A
Le RR de typeA, ou encore“ Address record ”attribue une ou plusieurs adresses `a un nom, c’est donc celui qui est potentiellement le plus fr´equement utilis´e. Il doit y avoir un RR de type A pour chaque adresse d’une machine.
{name} {ttl} addr−class A address gw−sio IN A 138.195.52.2 IN A 138.195.52.33 IN A 138.195.52.65
5.4 RR de type PTR
Le RR de type PTR, ou encore “ PoinTeR record ” permet de sp´ecifier les adresses pour la r´esolution inverse, donc dans le domaine sp´ecial IN-ADDR.ARPA. Notez le “.” en fin de nom qui interdit la compl´etion (il s’agit bien du nom FQDN).
name {ttl} addr−class PTR real name
2 IN PTR gw−sio.sio.ecp.fr.
33 IN PTR gw−sio.sio.ecp.fr.
65 IN PTR gw−sio.sio.ecp.fr.
5.5 RR de type MX
Le RR de typeMX, ou encore“ Mail eXchanger ”concerne les relations entre le serveur de noms et le courrier ´electronique. Nous examinerons son fonctionnement ult´erieurement dans le chapitre sur le courrier ´electronique (cf page 137).
sio.ecp.fr. IN MX 10 smtp.ecp.fr.
sio.ecp.fr. IN MX 20 mailhost.laissus.fr.
5.6 RR de type CNAME
Le RR de typeCNAME, ou encore“ canonical name ”permet de distin-guer le nom officiel d’une machine de ses surnoms.
www.sio.ecp.fr. IN CNAME srv.laissus.fr.
Dans l’exemple ci-dessus, la machine www.sio.ecp.fr est un surnom de la machine srv.laissus.fr. On notera que les domaines n’ont rien `a voir mais que ¸ca fonctionne quand mˆeme parfaitement.
Cette possibilit´e est tr`es employ´ee pour constituer des machines virtuelles, comme nous le verrons au chapitre X.
5.7 Autres RR. . .
Il existe d’autres RR, entres autres HINFO , TXT, WKS et KEY, non trait´es dans cette pr´esentation parcequ’ils n’apportent rien `a la compr´ehension du fonctionnement du serveur de noms. Le lecteur est fortement incit´e `a se reporter au “ Name Server Operations Guide ” pour plus d’informations.