dhcpd.conf - fichier de configuration de dhcpd

Le fichier dhcpd.conf contient les paramètres de configuration pour dhcpd, le serveur DHCP de l'Internet Software Consortium.
Le fichier dhcpd.conf est un fichier texte ASCII texte de format libre. Il est analysé par l'analyseur récursif-descendant intégré à dhcpd(8). Le fichier peut comporter des caractères de tabulations et de retour à la ligne supplémentaires pour la mise à page. Les mots clés du fichier sont insensibles à la casse (i.e. à la différence majuscule/minuscule). Les commentaires peuvent être placés n'importe où dans le fichier (sauf au sein des apostrophes). Les commentaires débutent par le caractère # et se terminent avec la ligne.
Le fichier est essentiellement constitué d'une liste de paramètres et de déclarations.
Les paramètres déterminent les valeurs internes du serveur (par ex. la durée de concession à offrir), définissent son comportement (par ex. est ce que dhcpd doit attribuer des adresses aux clients inconnus) et spécifient les informations qu'il doit fournir aux clients (par ex. utiliser la passerelle d'adresse 220.177.244.7).
Les déclarations sont utilisées pour décrire la topologie du réseau, les clients et les adresses attribuables, ou pour appliquer un groupe de paramètres à un groupe de déclarations. Dans tout groupe de paramètres et de déclarations, les paramètres doivent être spécifiés avant les déclarations qui en dépendent.
Les déclarations en relation avec la topologie du réseau incluent les déclarations de réseau partagé (share-network) et de sous-réseau (subnet). Si les clients d'un sous-réseau doivent recevoir dynamiquement leurs adresses, une déclaration de plage (range) d'adresses doit apparaître au sein de la déclaration du sous-réseau. Pour les clients, qui reçoivent des adresses statiques, ou pour les installations où seuls les clients connus sont servis, chaque client doit avoir une déclaration d'hôte (host). Une déclaration de groupe (group) peut être utilisée pour appliquer des paramètres à un groupe de déclaration qui ne suit pas le partionnement en sous-réseau.
Il doit y avoir une déclaration de sous-réseau pour chaque sous-réseau servi par dhcpd, ainsi que pour tous ceux auxquels le serveur DHCP est connecté. Ces déclarations permettent à dhcpd de déterminer si une adresse appartient à l'un de ces sous-réseaux. La déclaration de sous-réseau est obligatoire même si aucune adresse ne sera allouée dynamiquement sur celui-ci.
Certaines installations possèdent des réseaux physiques sur lesquels fonctionnent plusieurs sous-réseau IP. Par exemple, imaginons un site qui utilise un masque sous-réseau de 8 bit pour l'ensemble de ses départements, mais qu'un d'eux s'étende à un tel point qu'il ait plus de 254 noeuds sur le même réseau ethernet. Il est alors nécessaire d'utiliser deux sous-réseaux IP sur le même réseau ethernet en attendant l'installation d'un nouveau réseau physique. Dans ce cas, les déclarations de ces deux réseaux peuvent comporter une clause de réseau partagé.
Certains sites peuvent avoir des départements qui ont des clients sur plusieurs sous-réseaux, et qui veulent offrir à leurs clients un ensemble uniforme de paramètres, mais différents de ceux proposés aux clients des autres départements, bien qu'étant situés sur les mêmes sous-réseaux. Pour les clients qui seront explicitement déclarés par une déclaration d'hôte, ces déclarations peuvent être regroupées dans une déclaration de groupe avec les paramètres communs au département. Pour des clients dont les adresses seront assignées dynamiquement, il n'y a actuellement aucun moyen de grouper les paramètres d'assignements autrement que suivant la topologie du réseau.
Lorsqu'un client doit être démarré, ses paramètres de démarrage sont déterminés en consultant en premier lieu la déclaration d'hôte du client (s'il y en a une), puis en deuxième lieu la déclaration de groupe (s'il y en a une) qui comprend une déclaration d'hôte pour le client, puis en troisième lieu la déclaration du sous-réseau sur lequel le client est en train de démarrer, puis en quatrième lieu la déclaration de réseau partagé (s'il y en a une) contenant ce sous-réseau, et finalement les paramètres du niveau principal qui peuvent être spécifiés en dehors de toute déclaration.
Lorsque dhcpd essaye de trouver une déclaration d'hôte pour un client, il recherche d'abord une déclaration d'hôte avec un paramètre fixed-address (adresse fixe) correspondant au sous-réseau ou au réseau partagé sur lequel le client est en train de démarrer. S'il ne trouve pas une telle entrée, alors il recommence sa recherche sans le paramètre fixed-address. S'il ne trouve toujours rien, alors dhcpd considère qu'il n'y a pas d'entrée dans le fichier dhcpd.conf pour ce client : il ignore une éventuelle une entrée pour ce client sur un sous-réseau ou un réseau partagé différent.

Un fichier dhcpd.conf typique ressemblera à quelque chose comme ceci :

paramètres globaux

shared-network ISC-BIGGIE {
  paramètres spécifiques au réseau partagé...
  subnet 204.254.239.0 netmask 255.255.255.224 {
    paramètres spécifiques au sous-réseau...
    range 204.254.239.10 204.254.239.30;
  }
  subnet 204.254.239.32 netmask 255.255.255.224 {
    paramètres spécifiques au sous-réseau...
    range 204.254.239.42 204.254.239.62;
  }
}

subnet 204.254.239.64 netmask 255.255.255.224 {
  paramètres spécifiques au sous-réseau...
  range 204.254.239.74 204.254.239.94;
}

group {
  paramètres spécifiques au groupe...
  host zappo.test.isc.org {
    paramètres spécifiques à l'hôte...
  }
  host beppo.test.isc.org {
    paramètres spécifiques à l'hôte...
  }
  host harpo.test.isc.org {
    paramètres spécifiques à l'hôte...
  }
}


Figure 1

Notez qu'au début du fichier se trouve un emplacement pour les paramètres globaux. Ce peut être des choses comme le nom de domaine de l'organisation, les adresses des serveurs de noms (s'ils sont commun à l'ensemble de l'organisation), et d'autres choses encore. Par exemple :

        option domain-name "isc.org";
        option domain-name-servers ns1.isc.org, ns2.isc.org;


Figure 2

Comme vous pouvez le voir dans la figure 2, il est possible de spécifier par nom les adresses des hôtes plutôt que par adresses IP numériques. Si un nom d'hôte donné se résout en plusieurs adresses IP (par exemple, si un hôte à deux interfaces ethernets), elles sont toutes fournies au client.
Dans la figure 1, vous pouvez voir que les deux déclaration de réseau partagé et sous-réseau (shared-network et subnet) peuvent avoir des paramètres. Imaginons que le réseau partagé ISC-BIGGIE supporte un département entier - par exemple le département comptable. Si la comptabilité à son propre domaine alors les paramètres spécifiques au réseau partagé peuvent être :

        option domain-name "comptabilite.isc.org";

Ainsi toutes les sous-réseaux déclarés dans la déclaration du réseau partagé ISC-BIGGIE auront l'option de nom de domaine (domain-name) mise à "comptabilite.isc.org", au lieu "isc.org" défini au niveau global.
La raison la plus évidente d'avoir des paramètres spécifiques à un sous-réseau est montré dans la Figure 1 : chaque sous-réseau, par nécessité, a son propre routeur. Aussi pour le premier sous-réseau, par exemple, on peut avoir quelque chose comme :

        option routers 204.254.239.1;

Notez qu'ici l'adresse est spécifiée numériquement. Ce n'est pas une obligation - si vous avez un nom de domaine différent pour chaque interface de votre routeur, il est parfaitement légitime d'utiliser le nom de domaine pour les interfaces plutôt que les adresses numériques. Cependant, dans la plupart des cas, vous n'aurez qu'un seul nom de domaine pour toutes les adresses IP d'un routeur, et il ne sera pas approprié d'utiliser ce nom ici.
Dans la Figure 1, il y a aussi une déclaration de groupe qui fournit les paramètres communs pour un ensemble de trois hôtes - « zappo », « beppo » et « harpo ». Comme vous pouvez le constater, ces hôtes sont tous dans le domaine test.isc.org, aussi on peut donc choisir d'avoir un paramètre spécifique au groupe qui remplacera le nom de domaine fourni à ces hôtes :

        option domain-name "test.isc.org";

Vu le nom de domaine dans lequel se trouvent ces machines, elles sont probablement destinés à des tests. Si nous voulons tester le mécanisme de concession de DHCP, nous pouvons mettre la durée de concession à une valeur inférieure à la valeur par défaut :

        max-lease-time 120;
        default-lease-time 120;

Vous avez peut être remarqué que certains paramètres débutent avec le mot-clé option et d'autres non. Les paramètres débutant avec le mot-clé option sont réellement optionnels pour DHCP tandis que les autres, soit contrôlent le comportement du serveur DHCP (par ex. la durée des concessions fournie par dhcpd), soit spécifient des paramètres obligatoires des clients DHCP (par ex. nom de serveur et nom de fichier).
Dans la Figure 1, chaque machine a des paramètres d'hôtes spécifiques. Parmi ces paramètres on trouve des choses telles que le nom d'hôte (hostname), le nom du fichier (filename) à lui envoyer ou l'adresse du serveur depuis lequel le fichier sera envoyé (paramètre next-server). En général, n'importe quel paramètre peut apparaître à n'importe quel endroit où les paramètres sont autorisés. Il sera appliqué en fonction de la portée du bloc dans lequel il apparaît.
Imaginons un site avec de nombreux Terminaux-X de marque NCD. Ces terminaux sont de différents modèles, et il vous faut spécifier un fichier de démarrage par type de modèle. Une méthode serait d'avoir une déclaration d'hôte par terminal et de les grouper par modèle :

group {
  filename "Xncd19r";
  next-server ncd-booter;

  host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
  host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
  host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
}

group {
  filename "Xncd19c";
  next-server ncd-booter;

  host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
  host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
}

group {
  filename "XncdHMX";
  next-server ncd-booter;

  host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
  host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
  host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
}

La déclaration shared-network (réseau partagé)

 shared-network name {
   [ paramètres ]
   [ déclarations ]
 }

La déclaration de réseau partagé est utilisée pour informer le serveur DHCP que certains sous-réseau IP partagent en réalité le même réseau physique. Tout sous-réseau d'un réseau partagé devrait être déclaré au sein d'une telle déclaration. Les paramètres spécifiés dans la déclaration de réseau partagé seront utilisés lorsque les clients démarreront sur ces sous-réseaux à moins que ces paramètres ne soient écrasés par ceux fournis au niveau du réseau ou de l'hôte. Dans un réseau partagé, les adresses disponibles dans chaque sous-réseau pour l'allocation dynamique sont mises en commun. Il n'y a aucun moyen de choisir le sous-réseau du réseau partagé sur lequel un client doit démarrer.
name devrait être le nom du réseau partagé. Ce nom est utilisé lors de l'impression de messages de debug, aussi il devrait être descriptif pour le réseau partagé. Le nom peut avoir la syntaxe d'un nom de domaine valide (bien qu'il ne sera jamais utilisé en tant que tel), ou bien n'importe quel nom entre guillemets.
La déclaration subnet (sous-réseau)

 subnet subnet-number netmask netmask {
   [ paramètres ]
   [ déclarations ]
 }

La déclaration de sous-réseau est utilisée pour que dhcpd puisse déterminer si une adresse IP appartient à un sous-réseau. Elle peut aussi être utilisée pour fournir des paramètres spécifiques au sous-réseau et pour spécifier quelles adresses peuvent être dynamiquement allouées aux clients démarrant sur ce sous-réseau. De telles adresses sont spécifiées en utilisant la déclaration range (plage ou intervalle [d'adresses]).
L'adresse de sous-réseau subnet-number doit être une adresse IP ou un nom de domaine qui se résout en cette adresse IP. Le masque de réseau netmask doit aussi être une adresse IP ou un nom de domaine qui se résout en cette adresse IP.
L'adresse du sous-réseau et le masque de réseau suffisent à déterminer si une adresse IP donnée appartient à ce sous-réseau.
Bien qu'un masque de réseau doit être donné avec chaque déclaration d'un sous-réseau, il est recommandé dans le cas où on utilise le même masque de réseau pour tout un site, d'utiliser la déclaration de paramètre option subnet-mask dans chaque déclaration de sous-réseau, puisqu'elle écrasera le masque de réseau indiqué à la déclaration du sous-réseau.
La déclaration range (plage [d'adresses])

 range [ dynamic-bootp ] low-address [ high-address];

Tout sous-réseau sur lequel des adresses seront assignés dynamiquement, doit comporter au moins une déclaration de plage d'adresse. Cette déclaration donne la plus petite (low-address) et la plus grande adresse IP (high-address) de la plage. Toutes les adresses IP de la plage doivent appartenir au sous-réseau dans lequel la plage est déclarée. L'option dynamic-bootp peut être spécifiée pour indiquer que les adresses de la plage peuvent être assignées dynamiquement aussi bien aux clients DHCP que BOOTP. Lorsque la plage se réduit à une seule adresse, l'adresse supérieure (high-address) peut être omise.
La déclaration host (hôte)

 host hostname {
   [ paramètres ]
   [ déclarations ]
 }

Il doit y avoir au moins une déclaration d'hôte pour chaque client BOOTP à servir. Cette déclaration peut aussi être spécifiée pour les clients DHCP, bien que ce ne soit pas nécessaire à moins que le démarrage ne soit activé que pour les hôtes connus.
Si on veut être capable de démarrer un client DHCP ou BOOTP sur plus d'un sous-réseau avec des adresses fixes, on peut spécifier plusieurs adresses dans le paramètre fixed-address (adresse fixe), ou bien utiliser plusieurs déclarations d'hôtes.
Si les paramètres de démarrage spécifiques à un client varient en fonction du réseau auquel il est rattaché, alors il faut utiliser plusieurs déclaration d'hôtes.
Si un client doit être démarré dans la mesure du possible en utilisant une adresse fixe, mais qu'en cas d'impossibilité il doit recevoir une adresse dynamique, alors il faut ajouter une deuxième déclaration d'hôte sans le paramètre fixed-address. hostname est le nom identifiant l'hôte. Si aucune autre option hostname n'est spécifiée pour l'hôte, alors hostname est utilisé.
Les déclarations d'hôtes sont comparées aux clients DHCP et BOOTP réels en mettant en correspondance l'option dhcp-client-identifier spécifiée dans la déclaration d'hôte avec celle fournie par le client, ou, si cette option est absente de la déclaration d'hôte ou si le client ne fournit pas d'option dhcp-client-identifier, en comparant l'adresse matérielle du client avec le paramètre hardware de la déclaration d'hôte. Normalement, les clients BOOTP ne fournissent pas d'option dhcp-client-identifier, aussi l'adresse matérielle doit être utilisée pour tous les clients utilisant le protocole BOOTP.
La déclaration group (group)

 group {
   [ paramètres ]
   [ déclarations ]
 }

La déclaration group est utilisée tout simplement pour appliquer un ou plusieurs paramètres à un groupe de déclaration. Elle peut être utilisée pour grouper hôtes, réseaux partagés, sous-réseaux, ou même d'autres groupes.

Les déclarations allow (autoriser) et deny (interdire) peuvent être utilisées pour contrôler le comportement de dhcpd en fonction de la nature des requêtes.

Le mot-clé unknown-clients (clients inconnus)

 allow unknown-clients;
 deny unknown-clients;
Le mot clé unknown-clients est utilisé pour indiquer à dhcpd s'il doit oui ou non attribuer dynamiquement des adresses aux clients inconnus. Par défaut, l'attribution dynamique des adresses est autorisée pour les clients inconnus.
Le mot-clé bootp

 allow bootp;
 deny bootp;
Le mot-clé bootp est utilisé pour indiquer à dhcpd s'il doit oui ou non répondre aux requêtes bootp. Par défaut, les requêtes bootp sont autorisées.
Le mot-clé booting

 allow booting;
 deny booting;
Le mot-clé booting est utilisé pour dire à dhcpd si oui ou non il doit répondre aux demandes d'un client particulier Ce mot-clé n'a de signification uniquement dans une déclaration d'hôte. Par défaut booting est autorisé, mais si il est désactivé pour un client particulier, alors ce client sera incapable d'obtenir une adresse depuis le serveur DHCP.

Le paramètre default-lease-time

 default-lease-time time;
time spécifie la durée en secondes de la concession attribuée à un client qui n'a pas demandé une durée spécifique.
Le paramètre max-lease-time

 max-lease-time time;
time spécifie la durée maximale en secondes de la concession attribuée à un client qui a demandé une durée spécifique.
Le paramètre hardware

 hardware hardware-type hardware-address;
Dans le but de reconnaître un client BOOTP, son adresse matérielle doit être déclarée en utilisant la clause hardware dans la déclaration d'hôte. hardware-type doit être le nom d'un type d'interface matérielle. Actuellement seuls les types, ethernet et token-ring sont reconnus, bien que le support pour d'autres types d'interfaces matérielles telles que fddi soit souhaitable. L'adresse matérielle (hardware-address) doit être spécifiée en utilisant la notation hexadécimale et en séparant les octets par des deux-points (par ex: 5A:54:05:F6:5D:B6). Le paramètre hardware peut aussi être utilisé pour les clients DHCP.
Le paramètre filename (nom de fichier)

 filename "filename";
Le paramètre filename peut être utilisé pour spécifier le nom du fichier de démarrage initial qui doit être utilisé par un client. Le nom de fichier doit être un nom de fichier reconnaissable par tous les protocoles de transport de fichier que le client utilisera pour charger le fichier.
Le paramètre server-name (nom de serveur)

 server-name "name";
Le paramètre server-name est utilisé pour indiquer aux clients le nom du serveur depuis lequel ils sont en train de démarrer. name sera le nom fourni au client.
Le paramètre next-server (prochain serveur)

 next-server server-name;
Le paramètre next-server est utilisé pour spécifier l'adresse hôte du serveur depuis lequel le fichier de démarrage initial (spécifié par le paramètre filename) sera chargé. server-name doit être une adresse IP numérique ou un nom de domaine. Si aucun paramètre next-server ne s'applique à un client donné, l'adresse du serveur DHCP est utilisée.
Le paramètre fixed-address (adresse fixe)

 fixed-address address [, address ... ];
Le paramètre fixed-address est utilisée pour assigner une ou plusieurs adresse IP fixes à un client. Elle devrait apparaître uniquement dans une déclaration d'hôte. Si plus d'une adresse est fournie, alors lorsque le client démarre, il reçoit l'adresse correspondant au réseau sur lequel il démarre. Si aucune adresse spécifiée dans la clause fixed-address ne correspond au réseau sur lequel le client est en train de démarrer, alors le client ne correspondra pas à la déclaration d'hôte qui contient cette clause. address est une adresse IP numérique ou un nom de domaine qui se résout en une ou plusieurs adresses IP.
Le paramètre dynamic-bootp-lease-cutoff (coupure des concessions bootp dynamiques)

 dynamic-bootp-lease-cutoff date;
Le paramètre dynamic-bootp-lease-cutoff définit une date de fin pour toutes les concessions attribuées dynamiquement aux clients BOOTP. Comme les clients BOOTP n'ont aucun moyen pour renouveler les concessions et qu'ils ne savent pas quand leurs concessions expirent, par défaut dhcpd attribue des concessions à perpétuité aux clients BOOTP. Cependant, dans certaines situations on veut fixer une date de clôture pour toutes les concessions BOOTP - par exemple, pendant la nuit quand un bâtiment est fermé et que toutes les machines doivent être éteintes.
date devrait être la date à laquelle toutes les concessions BOOTP attribuées devront être interrompues. La date est spécifiée dans le format suivant
W AAAA/MM/JJ HH:MM:SS

W est le jour de la semaine exprimé sous forme de nombre depuis 0 (Dimanche) jusqu'à 6 (Samedi). AAAA est l'année, avec les 4 chiffres. MM est le mois exprimé sous forme numérique de 1 à 12. JJ est le jour du mois, qui commence à 1. HH est l'heure de 0 à 23. MM pour les minutes et SS les secondes. L'heure est toujours donnée en heure universelle (UTC=Universal Time Coordinated ), et non en heure locale.
Le paramètre dynamic-bootp-lease-length (durée des concessions BOOTP dynamiques)

 dynamic-bootp-lease-length length;
Le paramètre dynamic-bootp-lease-length est utilisé pour fixer la durée des concessions attribuées aux clients BOOTP. Sur certains sites, il est possible de supposer qu'une concession n'est plus utilisée si son propriétaire n'a pas utilisé BOOTP ou DHCP pour récupérer son adresse depuis un certain temps. Cette durée est spécifiée par le paramètre length en secondes. Si un client redémarre en utilisant BOOTP, avant l'expiration de cette durée, la durée de sa concession est réinitialisée à length, aussi un client BOOTP qui redémarre suffisamment fréquemment ne perdra jamais sa concession. Il est inutile de préciser que ce paramètre doit être ajusté avec une extrême prudence.
Le paramètre get-lease-hostnames

 get-lease-hostnames flag; (trouver le nom des concessionnaires)
Le paramètre get-lease-hostnames est utilisé pour indiquer à dhcpd s'il doit oui ou non rechercher les nom de domaines qui correspondent aux adresses IP disponibles pour l'allocation dynamique et utiliser cette adresse l'option hostname de DHCP. Si flag est positionné à true (vrai), alors cette recherche sera faite pour toutes les adresses dans le contexte actuel. Par défaut, la valeur est positionnée à false (faux), et aucune recherche n'est faite.
Le paramètre use-host-decl-names (utiliser le nom de la déclaration d'hôte comme nom d'hôte)

 use-host-decl-names flag;
Si le paramètre use-host-decl-names est vrai dans la portée d'un bloc, alors pour chaque déclaration d'hôtes à l'intérieur de ce bloc, le nom fourni pour la déclaration sera fourni au client pour devenir son nom d'hôte. Par exemple

    group {
      use-host-decl-names on;

      host toto {
        hardware ethernet 08:00:2b:4c:29:32;
        fixed-address toto.fugue.com;
      }
    }

est équivalent à

      host toto {
        hardware ethernet 08:00:2b:4c:29:32;
        fixed-address toto.fugue.com;
        option host-name "toto";
      }

Une instruction option host-name au sein d'une déclaration d'hôte remplacera l'utilisation du nom dans la déclaration d'hôte.
La clause authoritative

 authoritative;

 not authoritative;
Normalement le serveur serveur DHCP supposera que les informations de configuration d'un segment de réseau donné sont correctes et font autorité. Aussi si un client demande une adresse IP sur un segment de réseau que le serveur sait être invalide pour ce segment, le serveur répondra par un message DHCPNAK, provoquant chez le client l'abandon de son adresse IP et la demande d'une nouvelle.
Si un serveur DHCP est en train d'être configuré par quelqu'un d'autre que l'administrateur réseau et qui par conséquent ne souhaite pas endosser ce niveau d'autorité, alors l'instruction not authoritative devrait être écrite dans le bloc approprié dans le fichier de configuration.
Habituellement, écrire not authoritative; au plus haut niveau du fichier devrait être suffisant, cependant, si un serveur DHCP est configuré par quelqu'un qui sait qu'il fait autorité sur certains réseaux et pas sur les autres, il peut être plus approprié de déclarer l'autorité au niveau de chaque segment réseau.
Remarquez que la portée de bloc la plus spécifique pour ce concept d'autorité qui a un sens est le segment physique du réseau~: c'est donc soit un réseau partagé, soit un sous-réseau qui ne fait pas parti d'un réseau partagé. Ça n'a aucun sens de spécifier qu'un serveur fait autorité pour certains sous-réseaux d'un réseau partagé et pas pour les autres, de même ça n'a pas de sens de spécifier qu'un serveur fait autorité pour certaines déclarations d'hôte et pas pour les autres.
Le paramètre use-lease-addr-for-default-route (utiliser l'adresse de concession comme route par défaut)

 use-lease-addr-for-default-route flag;
Si le paramètre use-lease-addr-for-default-route est vrai dans un bloc donné, alors au lieu d'envoyer la valeur spécifiée dans l'option des routeurs (ou de n'envoyer rien du tout), l'adresse IP de la concession en train d'être attribuée est envoyée au client. C'est supposé provoquer la résolution ARP pour les machines Win95, ce qui peut être utile si votre routeur est configuré en proxy ARP.
Si use-lease-addr-for-default-route est activé et que l'option router et aussi dans le même bloc, l'option router sera choisie. La raison pour cela est qu'il y a des situations où vous voudrez utiliser cette caractéristique. Par exemple vous voulez l'activer pour un ensemble important de machines Win95, et l'écraser pour quelques autres machines. Malheureusement, si le contraire est vrai pour votre site (un petit nombre de machines Win95, et l'écrasement sur un nombre important d'autres machines), vous ferez mieux de ne pas essayer d'utiliser ce paramètre.
Le paramètre always-reply-rfc1048 (toujours répondre en rfc1048)

 always-reply-rfc1048 flag; 
Certains clients BOOTP clients s'attendent à des réponses de type RFC1048, mais n'envoie pas leurs requêtes dans ce format. Vous pouvez supposer qu'un client à ce problème s'il ne récupère pas les options que vous lui avez configuré et que vous voyez dans les messages de log du serveur "(non-rfc1048)" pour chaque BOOTREQUEST enregistré.
Si vous voulez envoyer des options rfc1048 à un tel client, vous pouvez positionner l'option always-reply-rfc1048 dans la déclaration d'hôte d'un client, et le serveur DHCP pourra répondre avec un champ d'option de type RFC-1048. Ce paramètre peut être positionné dans tout bloc et il affectera tous les clients couverts par la portée de ce bloc.
Le paramètre server-identifier identificateur du serveur

 server-identifier hostname;
Le paramètre server-identifier peut être utilisé pour définir la valeur que prendra l'option d'identificateur du serveur DHCP dans la portée d'un bloc. La valeur spécifiée doit être l'adresse IP d'un serveur DHCP, et être atteignable par tous les clients servis par ce contexte particulier.
L'utilisation du paramètre server-identifier n'est pas recommandée - la seule raison de l'utiliser, c'est pour forcer une valeur autre que celle par défaut et pour être envoyé dans des occasions où la valeur par défaut pourrait être incorrecte. La valeur par défaut est la première adresse IP associée à l'interface réseau matérielle sur laquelle la requête est arrivée.
Le cas habituel où le paramètre server-identifier a besoin d'être envoyé c'est lorsqu'une interface matérielle qui possède plusieurs adresses IP et que celle qui envoyée par défaut est inappropriée pour certains clients servis par cette interface. Un autre cas commun c'est lorsqu'un alias est défini dans le but d'avoir une adresse constante pour le serveur DHCP,et que l'on désire que les clients utilisent cette adresse pour contacter le serveur DHCP.
Fournir une valeur pour l'option dhcp-server-identifier option est équivalent à utiliser le paramètre server-identifier.

Les options des déclarations DHCP sont documentées dans la page de manuel dhcp-options(5).

dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.

dhcpd(8) a été écrit par Ted Lemon <mellon@vix.com> dans le cadre d'un contrat avec Vixie Labs. Le financement de ce projet a été pris en charge par l'Internet Software Corporation. Pour en savoir plus sur l'Internet Software Consortium, rendez-vous sur http://www.isc.org/isc.

Sébastien Blanchet, 2001