DNSMASQ(8) | System Manager's Manual | DNSMASQ(8) |
Dnsmasq - Un serveur DHCP et cache DNS poids-plume.
dnsmasq [OPTION]...
dnsmasq est un serveur à faible empreinte mémoire faisant DNS, TFTP, PXE, annonces de routeurs et DHCP. Il offre à la fois les services DNS et DHCP pour un réseau local (LAN).
Dnsmasq accepte les requêtes DNS et y répond soit en utilisant un petit cache local, soit en effectuant une requête à un serveur DNS récursif externe (par exemple celui de votre fournisseur d'accès internet). Il charge le contenu du fichier /etc/hosts afin que les noms locaux n'apparaissant pas dans les DNS globaux soient tout de même résolus, et assure également la résolution de nom pour les hôtes présents dans le service DHCP. Il peut aussi agir en temps que serveur DNS faisant autorité pour un ou plusieurs domaines, permettant à des noms locaux d'apparaitre dans le DNS global.
Le serveur DHCP de Dnsmasq supporte les définitions d'adresses statiques et les réseaux multiples. Il fournit par défaut un jeu raisonnable de paramètres DHCP, et peut être configuré pour fournir n'importe quelle option DHCP. Il inclut un serveur TFTP sécurisé en lecture seule permettant le démarrage via le réseau/PXE de clients DHCP et supporte également le protocole BOOTP. Le support PXE est complet, et comprend un mode proxy permettant de fournir des informations PXE aux clients alors que l'allocation d'adresse via DHCP est effectuée par un autre serveur.
Le serveur DHCPv6 de dnsmasq possède non seulement les mêmes fonctionnalités que le serveur DHCPv4, mais aussi le support des annonces de routeurs ainsi qu'une fonctionnalité permettant l'addition de ressources AAAA pour des clients utilisant DHCPv4 et la configuration IPv6 sans état (stateless autoconfiguration). Il inclut le support d'allocations d'adresses (à la fois en DHCPv6 et en annonces de routeurs - RA) pour des sous-réseaux dynamiquement délégués via une délégation de préfixe DHCPv6.
Dnsmasq est développé pour de petits systèmes embarqués. Il tend à avoir l'empreinte mémoire la plus faible possible pour les fonctions supportées, et permet d'exclure les fonctions inutiles du binaire compilé.
Notes : Il est possible d'utiliser des options sans leur donner de paramètre. Dans ce cas, la fonction correspondante sera désactivée. Par exemple --pid-file= (sans paramètre après le =) désactive l'écriture du fichier PID. Sur BSD, à moins que le logiciel ne soit compilé avec la bibliothèque GNU getopt, la forme longue des options ne fonctionne pas en ligne de commande; elle est toujours supportée dans le fichier de configuration.
Le domaine le plus spécifique l'emporte sur le domaine le moins spécifique, ainsi : --server=/google.com/1.2.3.4 --server=/www.google.com/2.3.4.5 enverra les requêtes pour *.google.com à 1.2.3.4, à l'exception des requêtes *www.google.com, qui seront envoyées à 2.3.4.5.
L'adresse spéciale '#' signifie "utiliser les serveurs standards", ainsi --server=/google.com/1.2.3.4 --server=/www.google.com/# enverra les requêtes pour *.google.com à 1.2.3.4, à l'exception des requêtes pour *www.google.com qui seront envoyées comme d'habitude (c-à-d aux serveurs définis par défaut).
Il est également permis de donner une option -S avec un nom de domaine mais sans adresse IP; Cela informe Dnsmasq que le domaine est local et qu'il doit répondre aux requêtes le concernant depuis les entrées contenues dans le fichier /etc/hosts ou les baux DHCP, et ne doit en aucun cas transmettre les requêtes aux serveurs amonts. local est synonyme de server ("serveur") afin de rendre plus claire l'utilisation de cette option pour cet usage particulier.
Les adresses IPv6 peuvent inclure un identifiant de zone sous la forme %interface tel que par exemple fe80::202:a412:4512:7bbf%eth0.
La chaîne de caractères optionnelle suivant le caractère @ permet de définir la source que Dnsmasq doit utiliser pour les réponses à ce serveur de nom. Il doit s'agir d'une des adresses IP appartenant à la machine sur laquelle tourne Dnsmasq ou sinon la ligne sera ignorée et une erreur sera consignée dans le journal des événements, ou alors d'un nom d'interface. Si un nom d'interface est donné, alors les requêtes vers le serveur de nom seront envoyées depuis cette interface; si une adresse IP est donnée, alors l'adresse source de la requête sera l'adresse en question. L'option query-port est ignorée pour tous les serveurs ayant une adresse source spécifiée, mais il est possible de la donner directement dans la spécification de l'adresse source. Forcer les requêtes à être émises depuis une interface spécifique n'est pas possible sur toutes les plateformes supportées par dnsmasq.
Un exemple devrait rendre cela plus clair : La configuration --synth-domain=thekelleys.org.uk,192.168.0.0/24,internal- permet de retourner internal-192-168-0-56.thekelleys.org.uk lors d'une requête sur l'adresse 192.168.0.56 et vice-versa pour la requête inverse. La même logique s'applique pour IPv6, avec la particularité suivante : les adresses IPv6 pouvant commencer par '::', mais les noms DNS ne pouvant pas commencer par '-', si aucun préfixe n'est donné, un zéro est ajouté en début de nom. Ainsi, ::1 devient 0--1.
La plage d'adresses peut être de la forme <adresse IP>,<adresse IP> ou <adresse IP>/<masque réseau>
Active le serveur DHCP. Les adresses seront données dans la plage comprise entre <adresse de début> et <adresse de fin> et à partir des adresses définies statiquement dans l'option dhcp-host. Si une durée de bail est donnée, alors les baux seront donnés pour cette durée. La durée de bail est donnée en secondes, en minutes (exemple : 45m), en heures (exemple : 1h) ou être la chaine de caractère "infinite" pour une durée indéterminée. Si aucune valeur n'est donnée, une durée de bail par défaut de une heure est appliquée. La valeur minimum pour un bail DHCP est de 2 minutes.
Pour les plages IPv6, la durée de bail peut être égale au mot-clef "deprecated" (obsolète); Cela positionne la durée de vie préférée envoyée dans les baux DHCP ou les annonces routeurs à zéro, ce qui incite les clients à utiliser d'autres adresses autant que possible, pour toute nouvelle connexion, en préalable à la renumérotation.
Cette option peut être répétée, avec différentes adresses, pour activer le service DHCP sur plus d'un réseau. Pour des réseaux directement connectés (c'est-à-dire des réseaux dans lesquels la machine sur laquelle tourne Dnsmasq possède une interface), le masque de réseau est optionnel : Dnsmasq la déterminera à partir de la configuration des interfaces.
Pour les réseaux pour lesquels le service DHCP se fait via un relais DHCP ("relay agent"), Dnsmasq est incapable de déterminer le masque par lui-même, aussi il doit être spécifié, faute de quoi Dnsmasq essaiera de le deviner en fonction de la classe (A, B ou C) de l'adresse réseau. L'adresse de broadcast est toujours optionnelle.
Il est toujours possible d'avoir plus d'une plage DHCP pour un même sous-réseau.
Pour IPv6, les paramètres sont légèrement différents : au lieu d'un masque de réseau et d'une adresse de broadcast, il existe une longueur de préfixe optionnelle. Si elle est omise, la valeur par défaut est 64. À la différence d'IPv4, la longueur de préfixe n'est pas automatiquement déduite de la configuration de l'interface. La taille minimale pour la longueur de préfixe est 64.
Pour IPv6 (et IPv6 uniquement), il est possible de définir les plages d'une autre façon. Dans ce cas, l'adresse de départ et l'adresse de fin optionnelle contiennent uniquement la partie réseau (par exemple ::1) et sont suivies par constructor:<interface>. Cela forme un modèle décrivant comment construire la plage, à partir des adresses assignées à l'interface. Par exemple
--dhcp-range=::1,::400,constructor:eth0
provoque la recherche d'adresses de la forme <réseau>::1 sur eth0 et crée une plage allant de <réseau>::1 à <réseau>:400. Si une interface est assignée à plus d'un réseau, les plages correspondantes seront automatiquement créées, rendues obsolètes puis supprimées lorsque l'adresse est rendue obsolète puis supprimée. Le nom de l'interface peut être spécifié avec un caractère joker '*' final.
provoque la recherche d'adresses sur eth0 et crée une plage allant de <réseau>::1 à <réseau>:400. Si l'interface est assignée à plus d'un réseau, les plages correspondantes seront respectivement automatiquement créées, rendues obsolètes et supprimées lorsque l'adresse est rendue obsolète et supprimée. Le nom de l'interface peut être spécifié avec un caractère joker '*' final. Les adresses autoconfigurées, privées ou obsolètes ne conviennent pas.
Si une plage dhcp-range est uniquement utilisée pour du DHCP sans-état ("stateless") ou de l'autoconfiguration sans état ("SLAAC"), alors l'adresse peut être indiquée sous la forme '::'
--dhcp-range=::,constructor:eth0
Il existe une variante de la syntaxe constructor: qui consiste en l'utilisation du mot-clef constructor-noauth. Voir --auth-zone pour des explications à ce sujet.
L'identifiant de label optionnel set:<label> fournie une étiquette alphanumérique qui identifie ce réseau, afin de permettre la fourniture d'options DHCP spécifiques à chaque réseau. Lorsque préfixé par 'tag:', la signification change, et au lieu de définir un label, il définit le label pour laquelle la règle s'applique. Un seul label peut- être défini mais plusieurs labels peuvent coïncider.
Le mot clef optionnel <mode> peut être égal à static ("statique") ce qui indique à Dnsmasq d'activer le service DHCP pour le réseau spécifié, mais de ne pas activer l'allocation dynamique d'adresses IP : Seuls les hôtes possédant des adresses IP statiques fournies via dhcp-host ou présentes dans le fichier /etc/ethers seront alors servis par le DHCP. Il est possible d'activer un mode "fourre-tout" en définissant un réseau statique comportant uniquement des zéros, c'est à dire : --dhcp=range=::,static Cela permet de retourner des réponses à tous les paquets de type Information-request (requête d'information) en mode DHCPv6 sans état sur le sous-réseau configuré.
Pour IPv4, le <mode> peut est égal à proxy , auquel cas Dnsmasq fournira un service de DHCP proxy pour le sous-réseau spécifié. (voir pxe-prompt et pxe-service pour plus de détails).
Pour IPv6, le mode peut être une combinaison des valeurs ra-only, slaac, ra-names, ra-stateless, off-link.
ra-only indique à dnsmasq de n'effectuer que des annonces de routeur (Router Advertisement, RA) sur ce sous-réseau, et de ne pas faire de DHCP.
slaac indique à dnsmasq d'effectuer des annonces de routeur sur ce sous-réseau et de positionner dans celles-ci le bit A, afin que les clients utilisent des adresses SLAAC. Lorsqu'utilisé conjointement avec une plage DHCP ou des affectations statiques d'adresses DHCP, les clients disposeront à la fois d'adresses DHCP assignées et d'adresses SLAAC.
ra-stateless indique à dnsmasq d'effectuer des annonces de routeur avec les bits 0 et A positionnés, et de fournir un service DHCP sans état ("stateless"). Les clients utiliseront des adresses SLAAC, et utiliseront DHCP pour toutes les autres informations de configuration.
ra-names active un mode qui fourni des noms DNS aux hôtes fonctionnant en double pile ("dual stack") et configurés pour faire du SLAAC en IPv6. Dnsmasq utilise le bail IPv4 de l'hôte afin de dériver le nom, le segment de réseau et l'adresse MAC et assume que l'hôte disposera d'une adresse IPv6 calculée via l'algorithme SLAAC, sur le même segment de réseau. Un ping est envoyé à l'adresse, et si une réponse est obtenue, un enregistrement AAAA est rajouté dans le DNS pour cette adresse IPv6. Veuillez-noter que cela n'arrive que pour les réseaux directement connectés (et non ceux pour lesquels DHCP se fait via relai), et ne fonctionnera pas si un hôte utilise les "extensions de vie privée" ("privacy extensions"). ra-names peut être combiné avec ra-stateless et slaac.
off-link indique à dnsmasq d'annoncer le préfixe sans le bit L (sur lien).
--dhcp-host=lap,192.168.0.199 spécifie à Dnsmasq d'allouer toujours à la machine portant le nom lap l'adresse IP 192.168.0.199.
Les adresses allouées de la sorte ne sont pas contraintes à une plage d'adresse spécifiée par une option --dhcp-range, mais elles se trouver dans le même sous-réseau qu'une plage dhcp-range valide. Pour les sous-réseaux qui n'ont pas besoin d'adresses dynamiquement allouées, utiliser le mot-clef "static" dans la déclaration de plage d'adresses dhcp-range.
Il est possible d'utiliser des identifiants clients (appelés "DUID client" dans le monde IPv6) plutôt que des adresses matérielles pour identifier les hôtes, en préfixant ceux-ci par 'id:'. Ainsi, --dhcp-host=id:01:02:03:04,..... réfère à l'hôte d'identifiant 01:02:03:04. Il est également possible de spécifier l'identifiant client sous la forme d'une chaîne de caractères, comme ceci : --dhcp-host=id:identifiantclientsousformedechaine,.....
Un seul dhcp-host peut contenir une adresse IPv4, une adresse IPv6, ou les deux en même temps. Les adresses IPv6 doivent être mises entre crochets comme suit : --dhcp-host=laptop,[1234::56] Les adresses IPv6 peuvent ne contenir que la partie identifiant de client : --dhcp-host=laptop,[::56] Dans ce cas, lorsque des plages dhcp sont définies automatiquement par le biais de constructeurs, la partie réseau correspondante est rajoutée à l'adresse.
A noter que pour le DHCP IPv6, l'adresse matérielle n'est pas toujours disponible, bien que ce soit toujours le cas pour des clients directement connectés (sur le même domaine de broadcast) ou pour des clients utilisant des relais DHCP qui supportent la RFC 6939.
En DHCPv4, l'option spéciale id:* signifie : "ignorer tout identifiant client et n'utiliser que l'adresse matérielle". Cela est utile lorsqu'un client présente un identifiant client mais pas les autres.
Si un nom apparaît dans /etc/hosts, l'adresse associée peut être allouée à un bail DHCP mais seulement si une option --dhcp-host spécifiant le nom existe par ailleurs. Seul un nom d'hôte peut être donné dans une option dhcp-host , mais les alias sont possibles au travers de l'utilisation des CNAMEs. (Voir --cname ). Le mot clef "ignore" ("ignorer") indique à Dnsmasq de ne jamais fournir de bail DHCP à une machine. La machine peut être spécifiée par son adresse matérielle, son identifiant client ou son nom d'hôte. Par exemple --dhcp-host=00:20:e0:3b:13:af,ignore Cela est utile lorsqu'un autre serveur DHCP sur le réseau doit être utilisé par certaines machines.
Le paramètre set:<identifiant réseau>
permet de définir un identifiant de réseau lorsque
l'option dhcp-host est utilisée. Cela peut servir à
sélectionner des options DHCP juste pour cet hôte. Plus
d'un label peut être fourni dans une directive dhcp-host (et dans
cette seule directive). Lorsqu'une machine coïncide avec une
directive dhcp-host (ou une impliquée par /etc/ethers), alors le
label réservé "known" ("connu") est
associé. Cela permet à Dnsmasq d'être
configuré pour ignorer les requêtes issus de machines
inconnue
par le biais de --dhcp-ignore=tag:!known.
Les adresses ethernet (mais pas les identifiants clients) peuvent être définies avec des octets joker, ainsi par exemple --dhcp-host=00:20:e0:3b:13:*,ignore demande à Dnsmasq d'ignorer une gamme d'adresses matérielles. Il est à noter que "*" doit être précédé d'un caractère d'échappement ou mis entre guillemets lorsque spécifié en option de ligne de commande, mais pas dans le fichier de configuration.
Les adresses matérielles coïncident en principe avec n'importe quel type de réseau (ARP), mais il est possible de les limiter à un seul type ARP en les précédant du type ARP (en Hexadécimal) et de "-". Ainsi --dhcp-host=06-00:20:e0:3b:13:af,1.2.3.4 coïncidera uniquement avec des adresses matérielles Token-Ring, puisque le type ARP pour une adresse Token-Ring est 6.
Un cas spécial, pour IPv4, correspond à l'inclusion d'une ou plusieurs adresses matérielles, c-à-d : --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2. Cela permet à une adresse IP d'être associé à plusieurs adresses matérielles, et donne à dnsmasq la permission d'abandonner un bail DHCP attribué à l'une de ces adresses lorsqu'une autre adresse dans la liste demande un bail. Ceci est une opération dangereuse qui ne fonctionnera de manière fiable que si une adresse matérielle est active à un moment donné et dnsmasq n'a aucun moyen de s'assurer de cela. Cela est utile, par exemple, pour allouer une adresse IP stable à un laptop qui aurait à la fois une connexion filaire et sans-fil.
Un traitement spécial est effectué sur les chaînes de caractères fournies pour l'option 119, conformément à la RFC 3397. Les chaînes de caractères ou les adresses IP sous forme de 4 chiffres séparés par des points donnés en arguments de l'option 120 sont traités conformément à la RFC 3361. Les adresses IP sous forme de 4 chiffres séparés par des points suivies par une barre montante "/", puis une taille de masque sont encodés conformément à la RFC 3442.
Les options IPv6 sont fournies en utilisant le mot-clef option6: suivi par le numéro d'option ou le nom d'option. L'espace de nommage des options IPv6 est disjoint de l'espace de nommage des options IPv4. Les adresses IPv6 en option doivent être entourées de crochets, comme par exemple : --dhcp-option=option6:ntp-server,[1234::56]
Attention : aucun test n'étant fait pour vérifier que des données d'un type adéquat sont envoyées pour un numéro d'option donné, il est tout à fait possible de persuader Dnsmasq de générer des paquets DHCP illégaux par une utilisation incorrecte de cette option. Lorsque la valeur est un nombre décimal, Dnsmasq doit déterminer la taille des données. Cela est fait en examinant le numéro de l'option et/ou la valeur, mais peut être évité en rajoutant un suffixe d'une lettre comme suit : b = un octet, s = 2 octets, i = 4 octets. Cela sert essentiellement pour des options encapsulées de classes de vendeurs (voir plus bas), pour lesquelles Dnsmasq ne peut déterminer la taille de la valeur. Les données d'options consistant uniquement de points et de décimaux sont interprétées par Dnsmasq comme des adresses IP, et envoyées comme telles. Pour forcer l'envoi sous forme de chaîne de caractère, il est nécessaire d'utiliser des guillemets doubles. Par exemple, l'utilisation de l'option 66 pour fournir une adresse IP sous la forme d'une chaîne de caractères comme nom de serveur TFTP, il est nécessaire de faire comme suit : --dhcp-option=66,"1.2.3.4"
Les options encapsulées de classes de vendeurs peuvent être aussi spécifiées (pour IPv4 seulement) en utilisant --dhcp-option : par exemple --dhcp-option=vendor:PXEClient,1,0.0.0.0 envoie l'option encapsulée de classe de vendeur "mftp-address=0.0.0.0" à n'importe quel client dont la classe de vendeur correspond à "PXEClient". La correspondance pour les classes de vendeur s'effectue sur des sous-chaînes de caractères (voir --dhcp-vendorclass pour plus de détails). Si une option de classe de vendeur (numéro 60) est envoyée par Dnsmasq, alors cela est utilisé pour sélectionner les options encapsulées, de préférence à toute option envoyée par le client. Il est possible d'omettre complètement une classe de vendeur : --dhcp-option=vendor:,1,0.0.0.0 Dans ce cas l'option encapsulée est toujours envoyée.
En IPv4, les options peuvent être encapsulées au sein d'autres options : par exemple --dhcp-option=encap:175, 190, iscsi-client0 enverra l'option 175, au sein de laquelle se trouve l'option 190. Plusieurs options encapsulées avec le même numéro d'option seront correctement combinées au sein d'une seule option encapsulée. Il n'est pas possible de spécifier encap: et vendor: au sein d'une même option dhcp.
La dernière variante pour les options encapsulées est "l'option de Vendeur identifiant le vendeur" ("Vendor-Identifying Vendor Options") telle que décrite dans le RFC3925. Celles-ci sont spécifiées comme suit : --dhcp-option=vi-encap:2, 10, text Le numéro dans la section vi-encap: est le numéro IANA de l'entreprise servant à identifier cette option. Cette forme d'encapsulation est également supportée en IPv6.
L'adresse 0.0.0.0 n'est pas traitée de manière particulière lorsque fournie dans une option encapsulée.
Le contrôle d'accès pour les clients DHCP suivent les mêmes règles que pour les serveurs DHCP : voir --interface, --except-interface, etc. Le nom d'interface optionel dans l'option dhcp-relay comporte une autre fonction : il contrôle l'interface sur laquelle la réponse du serveur sera acceptée. Cela sert par exemple dans des configurations à 3 interfaces : une à partir de laquelle les requêtes sont relayées, une seconde permettant de se connecter à un serveur DHCP, et une troisième reliée à un réseau non-sécurisé tel qu'internet. Cela permet d'éviter l'arrivée de requêtes usurpées via cette troisième interface.
Il est permis de configurer dnsmasq pour fonctionner comme serveur DHCP sur certaines interfaces et en temps que relais sur d'autres. Cependant, même s'il est possible de configurer dnsmasq de telle manière qu'il soit à la fois serveur et relais pour une même interface, cela n'est pas supporté et la fonction de relais prendra le dessus.
Le relais DHCPv4 et le relais DHCPv6 sont tous les deux supportés, mais il n'est pas possible de relayer des requêtes DHCPv4 à un serveur DHCPv6 et vice-versa.
Associe une chaîne de classe de vendeur à un label. La plupart des clients DHCP fournissent une "classe de vendeur" ("vendor class") qui représente, d'une certaine façon, le type d'hôte. Cette option associe des classes de vendeur à des labels, de telle sorte que des options DHCP peuvent être fournies de manière sélective aux différentes classes d'hôtes. Par exemple, dhcp-vendorclass=set:printers,Hewlett-Packard JetDirect ou dhcp-vendorclass=printers,Hewlett-Packard JetDirect permet de n'allouer des options qu'aux imprimantes HP de la manière suivante : --dhcp-option=tag:printers,3,192.168.4.4 La chaîne de caractères de la classe de vendeur fournie en argument est cherchée en temps que sous-chaîne de caractères au sein de la classe de vendeur fournie par le client, de façon à permettre la recherche d'un sous-ensemble de la chaîne de caractères ("fuzzy matching"). Le préfixe set: est optionnel mais autorisé afin de conserver une certaine homogénéité.
Notez qu'en IPv6 (et seulement en IPv6), les noms de classes de vendeurs sont dans un espace de nom associé au numéro attribué à l'entreprise par l'IANA. Ce numéro est fourni par le biais du mot-clef enterprise: et seules les classes de vendeurs associées au numéro spécifié seront cherchées.
--dhcp-match=set:efi-ia32,option:client-arch,6
spécifie le label "efi-ia32" si le numéro 6 apparaît dnas la liste d'architectures envoyé par le client au sein de l'option 93. (se référer au RFC 4578 pour plus de détails). Si la valeur est un chaine de caractères, celle-ci est recherchée (correspondance en temps que sous-chaîne).
Pour la forme particulière vi-encap:<numéro d'entreprise>, la comparaison se fait avec les classes de vendeur "identifiant de vendeur" ("vendor-identifying vendor classes") pour l'entreprise dont le numéro est fourni en option. Veuillez vous référer à la RFC 3925 pour plus de détails.
Ceci spécifie l'option de démarrage qui apparaitra dans un menu de démarrage PXE. <CSA> est le type du système client. Seuls des types de services valides apparaitront dans un menu. Les types connus sont x86PC, PC98, IA64_EFI, Alpha, Arc_x86, Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI et X86-64_EFI; D'autres types peuvent être spécifiés sous la forme d'une valeur entière. Le paramètre après le texte correspondant à l'entrée dans le menu peut être un nom de fichier, auquel cas Dnsmasq agit comme un serveur de démarrage et indique au client PXE qu'il faut télécharger ce fichier via TFTP, soit depuis ce serveur (l'option enable-tftp doit être spécifiée pour que cela marche), soit depuis un autre serveur TFTP si une adresse ou un nom de serveur est fournie. Veuillez noter que le suffixe de "couche" (en principe ".0") est fourni par PXE et ne doit pas être rajouté au nom de fichier. Si une valeur numérique entière est fournir pour le type de démarrage, en remplacement du nom de fichier, le client PXE devra chercher un service de démarrage de ce type sur le réseau. Cette recherche peut être faite via broadcast ou directement auprès d'un serveur si son adresse IP ou son nom sont fournis dans l'option. Si aucun nom de fichier n'est donné ni aucune valeur de type de service de démarrage n'est fournie (ou qu'une valeur de 0 est donnée pour le type de service), alors l'entrée de menu provoque l'interruption du démarrage par le réseau et la poursuite du démarrage sur un média local. L'adresse de serveur peut être donnée sous la forme de nom de domaine qui est recherché dans /etc/hosts. Ce nom peut être associé à plusieurs adresses IP, qui dans ce cas sont utilisées à tour de rôle (en "round-robin").
Dnsmasq peut servir de "proxy-DHCP" PXE, dans le cas où un autre serveur DHCP sur le réseau est responsable de l'allocation des adresses IP, auquel cas Dnsmasq se contente de fournir les informations données dans les options pxe-prompt et pxe-service pour permettre le démarrage par le réseau. Ce mode est activé en utilisant le mot-clef proxy dans dhcp-range.
L'environnement est hérité de celui de l'invocation du processus Dnsmasq, auquel se rajoute quelques unes ou toutes les variables décrites ci-dessous :
Pour IPv4 et IPv6 :
DNSMASQ_DOMAIN si le nom de domaine pleinement qualifié de l'hôte est connu, la part relative au domaine y est stockée. (Notez que le nom d'hôte transmis comme argument au script n'est jamais pleinement qualifié).
Si le client fournit un nom d'hôte, DNSMASQ_SUPPLIED_HOSTNAME.
Si le client fournit des classes d'utilisateur, DNSMASQ_USER_CLASS0 à DNSMASQ_USER_CLASSn.
Si Dnsmasq a été compilé avec l'option HAVE_BROKEN_RTC ("horloge RTC défectueuse"), alors la durée du bail (en secondes) est stockée dans la variable DNSMASQ_LEASE_LENGTH, sinon la date d'expiration du bail est toujours stocké dans la variable d'environnement DNSMASQ_LEASE_EXPIRES. Le nombre de secondes avant expiration est toujours stocké dans DNSMASQ_TIME_REMAINING.
Si un bail était associé à un nom d'hôte et que celui-ci est supprimé, un évênement de type "old" est généré avec le nouveau statut du bail, c-à-d sans nom d'hôte, et le nom initial est fourni dans la variable d'environnement DNSMASQ_OLD_HOSTNAME.
La variable DNSMASQ_INTERFACE contient le nom de l'interface sur laquelle la requête est arrivée; ceci n'est pas renseigné dans le cas des actions "old" ayant lieu après un redémarrage de dnsmasq.
La variable DNSMASQ_RELAY_ADDRESS est renseignée si le client a utilisé un relai DHCP pour contacter Dnsmasq, si l'adresse IP du relai est connue.
DNSMASQ_TAGS contient tous les labels fournis pendant la transaction DHCP, séparés par des espaces.
DNSMASQ_LOG_DHCP est positionné si --log-dhcp est activé.
Pour IPv4 seulement :
DNSMASQ_CLIENT_ID, si l'hôte a fourni un identifiant de client.
DNSMASQ_CIRCUIT_ID, DNSMASQ_SUBSCRIBER_ID, DNSMASQ_REMOTE_ID si un relai DHCP a rajouté l'une de ces options.
Si le client fournit une information de classe de vendeur, DNSMASQ_VENDOR_CLASS.
Pour IPv6 seulement :
Si le client fournit une classe de vendeur (vendor-class), positionne DNSMASQ_VENDOR_CLASS_ID avec comme contenu le numéro IANA de l'entreprise pour la classe, et DNSMASQ_VENDOR_CLASS0..DNSMASQ_VENDOR_CLASSn pour les données.
DNSMASQ_SERVER_DUID contient le DUID du serveur : cette valeur est la même pour chaque appel au script.
DNSMASQ_IAID contenant l'IAID pour le bail. Si le bail est une allocation temporaire, cela est préfixé par le caractère 'T'.
DNSMASQ_MAC contient l'adresse MAC du client, si celle-ci est connue.
A noter que le nom d'hôte fourni, la classe de vendeur ou les données de classe d'utilisateur sont uniquement fournies pour les actions "add" ou l'action "old" lorsqu'un hôte reprend un bail existant, puisque ces informations ne sont pas conservées dans la base de baux de dnsmasq.
Tous les descripteurs de fichiers sont fermés, sauf stdin, stdout et stderr qui sont ouverts sur /dev/null (sauf en mode déverminage).
Le script n'est pas lancé de manière concurrente : au plus une instance du script est exécutée à la fois (dnsmasq attend qu'une instance de script se termine avant de lancer la suivante). Les changements dans la base des baux nécessitant le lancement du script sont placé en attente dans une queue jusqu'à terminaison d'une instance du script en cours. Si cette mise en queue fait que plusieurs changements d'états apparaissent pour un bail donné avant que le script puisse être lancé, alors les états les plus anciens sont supprimés et lorsque le script sera finalement lancé, ce sera avec l'état courant du bail.
Au démarrage de Dnsmasq, le script sera invoqué pour chacun des baux existants dans le fichier des baux. Le script sera lancé avec l'action "del" pour les baux expirés, et "old" pour les autres. Lorsque Dnsmasq reçoit un signal HUP, le script sera invoqué avec une action "old" pour tous les baux existants.
Il existe deux autres actions pouvant apparaître comme argument au script : "init" et "tftp". D'autres sont susceptibles d'être rajoutées dans le futur, aussi les scripts devraient être écrits de sorte à ignorer les actions inconnues. "init" est décrite ci-dessous dans --leasefile-ro. L'action "tftp" est invoquée lorsqu'un transfert de fichier TFTP s'est terminé. Ses arguments sont la taille du fichier en octets, l'adresse à laquelle le fichier a été envoyé, ainsi que le chemin complet du fichier.
La fonction lease reçoit les informations détaillées dans --dhcp-script. Il reçoit deux arguments. Le premier spécifie l'action, qui est une chaîne de caractères contenant les valeurs "add" (ajout), "old" (réactivation d'un bail existant) ou "del" (suppression). Le deuxième est une table contenant des paires de valeurs de labels. Les labels correspondent pour l'essentiel aux valeurs d'environnement détaillées ci-dessus, ainsi le label "domain" (domaine) contient les mêmes données que la variable d'environnement DNSMASQ_DOMAIN. Il existe quelques labels supplémentaires contenant les données fournies comme arguments à --dhcp-script. Ces labels sont mac_address, ip_address (pour respectivement l'adresse MAC et l'adresse IP) et hostname (le nom d'hôte) dans le cas d'IPv4, et client_duid, ip_address (valeur DUID du client et adresse IP respectivement) ainsi que hostname (le nom d'hôte) dans le cas d'IPv6.
La fonction tftp est appelée de la même façon que la fonction "lease", et la table contient les labels destination_address, file_name et file_size (respectivement "adresse de destination", "nom de fichier" et "taille de fichier").
La gamme d'adresses peut être de la forme <adresse IP>,<adresse IP> ou <adresse IP>/<masque de réseau> voire une simple <adresse IP>. Voir --dhcp-fqdn qui peut changer le comportement de dnsmasq relatif aux domaines.
Si la gamme d'adresse est fournie sous la forme <adresse IP>/<taille de réseau>, alors le drapeau "local" peut être rajouté qui a pour effet d'ajouter --local-declarations aux requêtes DNS directes et inverses. C-à-d --domain=thekelleys.org.uk,192.168.0.0/24,local est identique à --domain=thekelleys.org.uk,192.168.0.0/24 --local=/thekelleys.org.uk/ --local=/0.168.192.in-addr.arpa/ La taille de réseau doit être de 8, 16 ou 24 pour être valide.
Au démarrage, Dnsmasq lis /etc/dnsmasq.conf, si ce fichier existe. (Sur FreeBSD, ce fichier est /usr/local/etc/dnsmasq.conf ) (voir cependant les options -C et -7 ). Le format de ce fichier consiste en une option par ligne, exactement comme les options longues détaillées dans la section OPTIONS, mais sans être précédées par "--". Les lignes commençant par # sont des commentaires et sont ignorées. Pour les options qui ne peuvent-être spécifiées qu'une seule fois, celle du fichier de configuration prends le pas sur celle fournie en ligne de commande. Il est possible d'utiliser des guillemets afin d'éviter que les ",",":","." et "#" ne soient interprétés, et il est possible d'utiliser les séquences d'échappement suivantes : \\ \" \t \e \b \r et \n. Elles correspondent respectivement à la barre oblique descendante ("anti-slash"), guillemets doubles, tabulation, caractère d'échappement ("escape"), suppression ("backspace"), retour ("return") et nouvelle ligne ("newline").
A la réception d'un signal SIGHUP, Dnsmasq vide son cache et recharge les fichiers /etc/hosts et /etc/ethers ainsi que tout autre fichier spécifié par les options --dhcp-hostsfile , --dhcp-optsfile ou --addn-hosts. Le script de changement de bail est appellé pour chaque bail DHCP existant. Si l'option --no-poll est positionnée, alors le fichier /etc/resolv.conf est également rechargé. SIGHUP ne provoque PAS de rechargement du fichier de configuration.
A la réception d'un signal SIGUSR1, Dnsmasq écrit des statistiques dans les traces système. Les informations fournies sont : la taille du cache, le nombre de noms ayant été supprimés du cache avant expiration afin de faire de la place pour les nouveaux noms, ainsi que le nombre total d'entrées ayant été insérées dans le cache. Pour chaque serveur amont, il fournit le nomnbre de requêtes transmises ainsi que le nombre de requêtes ayant résulté par une erreur. Lorsque Dnsmasq a été lancé via --no-daemon ou lorsque la traçabilité maximale a été activée ( -q ), la totalité du contenu du cache est de surcroît fournie.
A la réception d'un signal SIGUSR2 et lorsqu'il enregistre directement ses traces dans un fichier (voir --log-facility ), alors Dnsmasq ferme et rouvre le fichier de traces. Il faut noter que pendant cette opération Dnsmasq ne s'exécute pas en tant que "root". Lorsqu'il créé un fichier de traces pour la première fois, Dnsmasq change le propriétaire du fichier afin de le faire appartenir à l'utilisateur non "root" sous lequel Dnsmasq s'exécute. Le logiciel de rotation de fichiers de trace logrotate doit être configuré pour créer un nouveau fichier avec un propriétaire identique au fichier existant avant d'envoyer le signal SIGUSR2. Si une requête DNS TCP est en cours, l'ancien fichier de traces reste ouvert dans le processus fils qui traite la requête TCP et il peut y être écrit. Il existe cependant une limite de 150 secondes après laquelle tous les processus traitant des requêtes TCP expirent : pour cette raison, il est préférable de ne pas configurer la compression des fichiers de traces venant juste de faire l'objet d'une rotation. Dans le cas de l'utilisation du logiciel logrotate, les options requises sont create et delaycompress.
Dnsmasq est un logiciel de transmission de requêtes DNS : il n'est pas capable d'effectuer une résolution de nom récursive en partant des serveurs DNS racine, mais transmet de telles requêtes à un serveur DNS amont capable de telles recherches récursives, ce qui est typiquement le cas d'un serveur DNS de FAI. Par défaut, Dnsmasq lis /etc/resolv.conf pour découvrir les adresses IP des serveurs DNS amonts à utiliser, puisque cette information est en général stockée à cet endroit. A moins que l'option --no-poll ne soit utilisée, Dnsmasq vérifie la date de modification du fichier /etc/resolv.conf (ou l'équivalent si --resolv-file est utilisé), et le relis lorsqu'il change. Cela permet de définir les serveurs DNS amont de manière dynamique lorsque PPP ou DHCP sont utilisés, puisque ces protocoles fournissent cette information. L'absence du fichier /etc/resolv.conf ne conduit pas à une erreur, puisqu'il peut très bien ne pas être créé avant qu'une connexion PPP ne soit établie. Dans ce cas, Dnsmasq vérifie régulièrement pour voir si un fichier /etc/resolv.conf est créé. Dnsmasq peut être configuré pour lire plus d'un fichier resolv.conf. Cela est utile sur un ordinateur portable où PPP et DHCP peuvent être utilisés : Dnsmasq peut alors être configuré pour lire à la fois /etc/ppp/resolv.conf et /etc/dhcpc/resolv.conf et utilisera le contenu du fichier ayant changé en dernier, ce qui permet de passer automatiquement de serveurs DNS à d'autres.
Les serveurs amonts peuvent aussi être spécifiés sur la ligne de commande ou dans un fichier de configuration. Ces spécifications de serveurs peuvent éventuellement se voir adjoindre d'un nom de domaine qui précise à Dnsmasq quel serveur utiliser pour trouver les noms d'un domaine donné.
Pour configurer Dnsmasq afin qu'il se comporte comme un cache pour la machine sur laquelle il tourne, mettre "nameserver 127.0.0.1" dans le fichier /etc/resolv.conf afin de forcer les processus locaux à envoyer leurs requêtes à Dnsmasq. Ensuite, spécifier les serveurs DNS amont soit en les fournissant directement à Dnsmasq via l'option --server ou alors en mettant leurs adresses dans un autre fichier, par exemple /etc/resolv.dnsmasq et en lançant Dnsmasq avec l'option -r /etc/resolv.dnsmasq. Cette deuxième technique permet la mise-à-jour dynamique des adresses de serveurs DNS amont par le biais de PPP ou DHCP.
Les adresses dans /etc/hosts prennent le dessus sur celles fournies par le serveur DNS amont, ainsi "macompagnie.com 1.2.3.4" dans /etc/hosts assure que les requêtes pour "macompagnie.com" retourneront toujours 1.2.3.4, même si une requête au serveur DNS amont retournerait une adresse différente. Il y a une exception à ceci : si le DNS amont contient un CNAME qui pointe vers un nom présent dans /etc/hosts, alors la recherche du CNAME via Dnsmasq fournira l'adresse DNS amont. Pour contourner cela, il suffit de mettre l'entrée correspondant au CNAME dans /etc/hosts.
le système de label fonctionne comme suit : pour chaque requête DHCP, dnsmasq associe un ensemble de labels obtenus à partir des lignes de la configuration incluant set:<label>, y compris un pour la plage d'adresse ( dhcp-range ) utilisée pour allouer l'adresse, un pour chaque entrée dhcp-host associée (auquel est rajouté le mot-clef "known" si une entrée dhcp-host coïncide).
Le label "bootp" est associé aux requêtes BOOTP, un label dont le nom est le nom de l'interface sur laquelle la requête est arrivée.
Pour les lignes de configuration comportant des éléments tag:<label>, seules seront valides celles pour lesquels tous les labels correspondants seront présents. C'est typiquement le cas des lignes dhcp-options. Un dhcp-option possédant des labels sera utilisé de préférence à un dhcp-option sans label, pour peu que _tous_ les labels positionnés correspondent à l'ensemble de labels décrit plus haut. Le préfixe '!' sur un label est un indicateur de négation, ainsi --dhcp=option=tag:!purple,3,1.2.3.4 n'envoie l'option que lorsque le label "purple" n'est pas dans la liste de labels définis pour l'hôte considéré. (dans le cas de l'utilisation dans une ligne de commande au lieu d'un fichier de configuration, ne pas oublier d'échapper le caractère !, qui est un méta-caractère d'interpréteur de commande shell).
Lors de la sélection d'une option, une étiquette spécifiée par dhcp-range passe après les autres étiquettes, ce qui permet de facilement remplacer des option génériques pour des hôtes spécifiques, ainsi : dhcp-range=set:interface1,...... dhcp-host=set:monhote,..... dhcp-option=tag:interface1,option:nis-domain,"domaine1" dhcp-option=tag:monhote,option:nis-domain,"domaine2" va positionner l'option NIS-domain à domaine1 pour les hôtes dans la plage d'adresse, sauf pour monhote pour lequel cette valeur sera domaine2.
Veuillez noter que pour dhcp-range , les éléments tag:<label> et set:<label> sont tous les deux autorisés pour sélectionner la plage à utiliser selon, par exemple, le dhcp-host, et pour affecter l'option envoyée, sur la base de la plage sélectionnée.
Ce système a évolué d'un système plus ancien et aux possibilités plus limitées, et pour des raisons de compatibilité "net:" peut être utilisé à la place de "tag:" et "set:" peut être omis (à l'exception de dhcp-host, où "net:" peut être utilisé à la place de "set:"). Pour les mêmes raisons, '#' peut être utilisé à la place de '!' pour indiquer la négation.
Le serveur DHCP intégré dans Dnsmasq fonctionne également en temps que serveur BOOTP, pour peu que l'adresse MAC et l'adresse IP des clients soient fournies, que ce soit par le biais de l'option dhcp-host ou dans le fichier /etc/ethers , et que l'option dhcp-range soit présente afin d'activer le serveur DHCP pour un réseau donné (L'option --bootp-dynamic supprime la nécessité des associations statiques). Le paramètre "filename" (nom de fichier) de la requête BOOTP est utilisé comme label, ainsi que le label "bootp", permettant un certain contrôle sur les options retournées aux différentes classes d'hôtes.
Configurer dnsmasq pour agir en temps que serveur DNS faisant autorité est compliqué par le fait que cela implique la configuration de serveurs DNS externes pour mettre en place la délégation. Seront présentés ci-dessous trois scénarios de complexité croissante. Le pré-requis pour chacun de ces scénarios est l'existence d'une adresse IP globalement disponible, d'un enregistrement de type A ou AAAA pointant vers cette adresse, ainsi que d'un serveur DNS externe capable d'effectuer la délégation de la zone en question. Pour la première partie de ces explications, nous allons appeler serveur.exemple.com l'enregistrement A (ou AAAA) de l'adresse globalement accessible, et notre.zone.com la zone pour laquelle dnsmasq fait autorité.
La configuration la plus simple consiste en deux lignes de configuration, sous la forme :
auth-server=serveur.exemple.com,eth0 auth-zone=notre.zone.com,1.2.3.0/24
ainsi que deux enregistrements dans le DNS externe :
serveur.exemple.com A 192.0.43.10 notre.zone.com NS serveur.exemple.com
eth0 est l'interface réseau externe sur laquelle dnsmasq écoute, dont l'adresse IP (globalement accessible) est 192.0.43.10.
A noter que l'adresse IP externe peut parfaitement être dynamique (par exemple attribuée par un FAI via DHCP ou PPP). Dans ce cas, l'enregistrement de type A doit être lié à cet enregistrement dynamique par l'une ou l'autre des techniques habituelles de système DNS dynamique.
Un exemple plus complexe mais en pratique plus utile correspond au cas où l'adresse IP globalement accessible se trouve dans la zone pour laquelle dnsmasq fait autorité, le plus souvent à la racine. Dans ce cas nous avons :
auth-server=notre.zone.com,eth0 auth-zone=notre.zone.com,1.2.3.0/24
notre.zone.com A 1.2.3.4 notre.zone.com NS our.zone.com
L'enregistrement A pour notre.zone.com est dorénavant un enregistrement "colle" qui résout le problème de poule et d'oeuf consistant à trouver l'adresse IP du serveur de nom pour notre.zone.com lorsque l'enregistrement se trouve dans la zone en question. Il s'agit du seul rôle de cet enregistrement : comme dnsmasq fait désormais autorité pour notre.zone.com, il doit également fournir cet enregistrement. Si l'adresse externe est statique, cela peut être réalisé par le biais d'une entrée dans /etc/hosts ou via un --host-record.
auth-server=notre.zone.com,eth0 host-record=notre.zone.com,1.2.3.4 auth-zone=notre.zone.com,1.2.3.0/24
Si l'adresse externe est dynamique, l'adresse associée à notre.zone.com doit être dérivée de l'interface correspondante. Cela peut être fait en utilisant interface-name Sous la forme :
auth-server=notre.zone.com,eth0 interface-name=notre.zone.com,eth0 auth-zone=notre.zone.com,1.2.3.0/24
La configuration finale rajoute à cette base un serveur DNS secondaire. Il s'agit d'un autre serveur DNS qui apprend les données DNS de la zone en effectuant un transfert de zone, et qui joue le rôle de serveur de secours au cas où le serveur principal devenait inaccessible. La configuration de ce serveur secondaire sort du cadre de cette page de manuel. Les éléments de configuration à rajouter dans dnsmasq sont les simples :
auth-sec-servers=secondaire.monfai.com
et
notre.zone.com NS secondaire.monfai.com
L'addition d'une option auth-sec-servers active les transferts de zone dans dnsmasq, ce qui permet au serveur secondaire de venir collecter les données DNS. Si vous souhaitez restreindre l'accès à ces données à des hôtes spécifiques, vous pouvez le faire via :
auth-peer=<adresse IP du serveur secondaire>
Dnsmasq joue le rôle de serveur faisant autorité pour les domaines in-addr.arpa et ip6.arpa associés aux sous-réseaux définis dans la déclaration de zone auth-zone, ce qui fait que les requêtes DNS inversées (de l'adresse vers le nom) peuvent simplement être configurées avec un enregistrement NS adéquat. Par exemple, comme nous définissons plus haut les adresses 1.2.3.0/24 :
3.2.1.in-addr.arpa NS notre.zone.com
Veuillez noter que pour l'instant, les zones inverses ne sont pas disponibles dans les transferts de zone, donc il est inutile de configurer de serveur secondaire pour la résolution inverse.
Lorsque dnsmasq est configuré en temps que serveur faisant autorité, les données suivantes sont utilisées pour peupler la zone considérée :
--mx-host, --srv-host, --dns-rr, --txt-record, --naptr-record , pour autant que les noms des enregistrements se trouvent dans la zone en question.
--cname pour peu que le nom soit dans le domaine. Si la cible du CNAME n'est pas pleinement qualifiée, alors elle est qualifiée avec le nom de la zone pour laquelle le serveur fait autorité.
Les adresses IPv4 et IPv6 extraites de /etc/hosts (et --addn-hosts ) ainsi que les options --host-record fournissant des adresses situées dans l'un des sous-réseaux spécifiés dans --auth-zone.
Adresses spécifiées par --interface-name. Dans ce cas, l'adresse n'est pas limitée à l'un des sous-réseaux donné dans --auth-zone.
Les adresses de baux DHCP, si l'adresse est située dans l'un des sous-réseaux de --auth-zone OU dans une plage DHCP construite. Dans le mode par défaut, où le bail DHCP a un nom non qualifié, et éventuellement pour un nom qualifié construit via --domain , alors le nom dans la zone faisant autorité est construit à partir du nom non qualifié et du nom de domaine de la zone. Cela peut on non être égal celui fourni par --domain. Si l'option --dhcp-fqdn est fournie, alors les noms pleinement qualifiés associés aux baux DHCP sont utilisés, dès lors qu'ils correspondent au nom de domaine associé à la zone.
0 - Dnsmasq s'est correctement lancé en tâche de fond, ou alors s'est correctement terminé si le lancement en tâche de fond n'a pas été activé.
1 - Un problème de configuration a été détecté.
2 - Un problème est survenu avec un accès réseau (adresse déjà utilisée, tentative d'utiliser un port privilégié sans les permissions nécessaires).
3 - Un problème est survenu avec une opération sur un système de fichier (fichier ou répertoire manquant, permissions).
4 - Impossibilité d'allouer de la mémoire.
5 - Autre problème.
11 ou plus - un code de retour différent de 0 a été reçu lors de l'appel au processus "init" du script des bails. Le code de retour de Dnsmasq correspond au code de retour du script plus 10.
Les valeurs par défaut pour les limites de ressources de Dnsmasq sont en général conservatrices et appropriées pour des utilisations embarquées sur des machines de type routeur ayant des processeurs lents et une mémoire limitée. Sur du matériel plus performant, il est possible d'augmenter les limites et de gérer plus de clients. Les remarques suivantes s'appliquent à Dnsmasq version 2.37 et ultérieur : les versions précédentes ne montaient pas en charge aussi bien.
Dnsmasq est capable de gérer le DNS et DHCP pour au moins un millier de clients. Pour cela, la durée des bail ne doit pas être très courte (moins d'une heure). La valeur de --dns-forward-max peut être augmentée : commencer par la rendre égale au nombre de clients et l'augmenter si le DNS semble lent. Noter que la performance du DNS dépends également de la performance des serveurs amonts. La taille du cache DNS peut- être augmentée : la limite en dur est de 10000 entrées et la valeur par défaut (150) est très basse. Envoyer un signal SIGUSR1 à Dnsmasq le fait émettre des informations utiles pour paramétrer la taille de cache. Voir la section NOTES pour plus de détails.
Le serveur TFTP intégré est capable de plusieurs transferts de fichiers simultanés : La limite absolue est liée au nombre maximal de descripteurs de fichiers alloué à un processus et à la capacité de l'appel système select() à gérer un grand nombre de HANDLE de fichier. Si la limite est fixée trop haut par le biais de --tftp-max elle sera réduite et la limite actuelle sera enregistrée au démarrage. Il faut noter que plus de transferts sont possible lorsque le même fichier est transmis au lieu d'avoir un fichier différent pour chaque transfert.
Il est possible d'utiliser Dnsmasq pour bloquer la publicité sur la toile en associant des serveurs de publicité bien connus à l'adresse 127.0.0.1 ou 0.0.0.0 par le biais du fichier /etc/hosts ou d'un fichier d'hôte additionnel. Cette liste peut être très longue, Dnsmasq ayant été testé avec succès avec un million de noms. Cette taille de fichier nécessite un processeur à 1 Ghz et environ 60 Mo de RAM.
Dnsmasq peut être compilé pour supporter l'internationalisation. Pour cela, les cibles "all-i18n" et "install-i18n" doivent être données à make, en lieu et place des cibles standards "all" et "install". Lorsque compilé avec le support de l'internationalisation, dnsmasq supporte les noms de domaines internationalisés ("internationalised domain names" ou IDN), et les messages de traces ("logs") sont écrits dans la langue locale. Les noms de domaines dans /etc/hosts, /etc/ethers et /etc/dnsmasq.conf contenant des caractères non-ASCII seront transformés selon la représentation punycode interne aux DNS. Veuillez noter que dnsmasq détermine la langue pour les messages ainsi que le jeu de caractères susceptible d'être utilisé dans les fichiers de configuration à partir de la variable d'environnement LANG. Ceci devrait être configuré à la valeur par défaut du système par les scripts démarrant dnsmasq. Lorsque les fichiers de configuration sont édités, veuillez faire attention à le faire en utilisant la valeur de locale par défaut du système et non une valeur spécifique à l'utilisateur, puisque dnsmasq n'a aucun moyen de déterminer directement la valeur de jeu de caractère utilisé, et assume de ce fait qu'il s'agit de la valeur par défaut du système.
/etc/dnsmasq.conf
/usr/local/etc/dnsmasq.conf /var/run/dnsmasq/resolv.conf /etc/ppp/resolv.conf /etc/dhcpc/resolv.conf
/etc/resolv.conf
/etc/hosts
/etc/ethers
/var/lib/misc/dnsmasq.leases
/var/db/dnsmasq.leases
/var/run/dnsmasq.pid
Cette page de manuel a été écrite par Simon Kelley <simon@thekelleys.org.uk>.
La traduction dans un français bancal a été commise par Gildas Le Nadan <3ntr0p13@gmail.com> : Toute révision/correction permettant de corriger orthographe ou grammaire mais surtout les éventuelles fautes de sens sera la bienvenue!