LIER

LIER
Donnee de base
développeur	Consortium des systèmes Internet
Année de parution	16 septembre 2000 (version 9.0.0)
Version actuelle	9.16.20 ( 10 août 2021 )
Version préliminaire actuelle	9.17.10 (17 février 2021)
système opérateur	Système de type Unix , Microsoft Windows , OpenBSD
langage de programmation	C.
Catégorie	Logiciel DNS
Licence	Licence publique Mozilla
parlant allemand	non
isc.org/software/bind

BIND est une open source - logiciel pour la résolution de noms dans le système de noms de domaine . Son nom remonte au Berkeley Internet Name Domain Server , ou BIND Server en abrégé . En plus du serveur , le progiciel comprend un client et des programmes de test. Le serveur est de loin le plus utilisé du genre sur Internet . En raison de son utilisation généralisée et de la mise en œuvre rapide des RFC DNS actuels , BIND est considéré depuis des années comme un logiciel de référence DNS.

histoire

Avant que le DNS n'existe, les noms étaient résolus en adresses IP à l' aide de listes (/etc/hosts.txt, cf. /etc/hosts sur les systèmes Unix d'aujourd'hui), qui devaient être disponibles sur chaque ordinateur sur Internet. Les modifications étaient initialement effectuées manuellement sur un serveur maître, puis distribuées aux ordinateurs individuels via le téléchargement de fichiers. Avec l'augmentation du nombre d'abonnés IP, cette méthode est devenue de plus en plus lourde.

En 1983, Paul Mockapetris a spécifié le Domain Name System (DNS). La même année, le premier logiciel DNS - JEEVES - a été implémenté sur un ordinateur DEC . Un peu plus tard, les trois premiers serveurs racine Internet sont entrés en service.

Au début des années 1980, l' Université de Berkeley travaillait au développement ultérieur d'UNIX. Certains étudiants ont commencé à écrire un logiciel DNS pour UNIX, qu'ils ont nommé BIND (Berkeley Internet Name Domain). BIND était en constante évolution et la version 4 est devenue la norme mondiale. Après l'arrêt du développement du logiciel par l'université de Berkeley, la responsabilité a été brièvement reprise par DEC puis par Vixie Enterprises . Paul Vixie était le moteur du projet à l'époque.

A partir de la version 4.9.3, BIND est devenu sous la responsabilité de l' asbl ISC ( Internet Software Consortium - à partir de 2004 : Internet Systems Consortium ). La version 8 a été achevée en 1997. En 1999, ISC a chargé Nominum Inc. de développer la version 9. Sa première version, BIND 9.0.0, a été publiée le 16 septembre 2000. BIND 9 est la norme depuis 2007 et, avec la version 8, qui est toujours répandue, constitue l'épine dorsale du système mondial de noms de domaine .

À partir d'août 2007, la version 8 n'était plus maintenue ( obsolète ) et ISC a conseillé à tous les utilisateurs de passer à la version 9.

Le 1er avril 2009, le développement de Bind 10 a commencé, le 21 février 2013, la version BIND 10 : 1.0.0 est sortie.

Le 23 avril 2014, l'ISC a annoncé de manière surprenante qu'il arrêterait le développement de BIND10. On veut se concentrer sur le développement futur de BIND9.

sécurité

La version 4 a longtemps été considérée comme obsolète et le fonctionnement continu des serveurs BIND 4 comme un risque de sécurité ; Le développement de BIND 8 a également été interrompu en 2007. ISC recommande à tous les administrateurs DNS de migrer vers BIND 9 le plus rapidement possible ; des informations détaillées à ce sujet sont disponibles sur le site Web de l'ISC. En raison de l'interopérabilité étendue entre les versions, il n'y a aucun besoin technique de migrer. B. sur la liste de diffusion bind-users@isc.org .

En février 2008, Dan Kaminsky a découvert un nouveau type de méthode d' attaque qui permet à l' empoisonnement du cache d'avoir lieu en peu de temps, afin de rediriger l'utilisateur vers d'autres serveurs via de fausses réponses DNS. Il s'agit d'une lacune dans la conception du système de noms de domaine qui a affecté plusieurs autres serveurs de noms en plus de BIND. En collaboration avec des développeurs et des opérateurs de serveurs de noms, dont Paul Vixie , des correctifs ont été développés pour réduire la probabilité d'une attaque réussie. En juillet 2008, Kaminsky a publié les détails de la vulnérabilité et a estimé que 41 % des serveurs DNS étaient encore vulnérables.

configuration

Le comportement du composant central du programme de BIND, le démon " named", est déterminé par des fichiers de configuration et de zone qui peuvent être créés ou modifiés manuellement par l'administrateur ou automatiquement via des scripts, mais aussi à l'aide de frontaux . Au moins deux fichiers sont nécessaires pour le fonctionnement de base, une fois le fichier de configuration, souvent appelé " named.conf", et un fichier de zone pour chaque zone , dont le nom est généralement composé du nom de la zone et de l'extension de fichier " .db". Au lieu de fichiers en texte brut , des bases de données, par exemple BDB , peuvent également être utilisées comme source ; un module de pilote approprié doit être compilé pour cela.

La documentation officielle de BIND est le manuel de référence de l'administrateur BIND 9 , ou ARM en abrégé. Vous y obtenez un aperçu complet mais facile à comprendre de toutes les directives de configuration et de la structure des fichiers de zone.

Fichiers de zones

Le terme zone a été inventé par opposition au domaine car, bien qu'ils soient liés les uns aux autres, ils ne sont pas nécessairement congruents : une zone peut bien représenter un sous - ensemble d' un domaine et, d'autre part, ne peut se limiter à des déclarations d'hôte au sein d'un domaine, mais des références à des hôtes contenus dans des domaines « étrangers ».

Les fichiers de zone maître contiennent au moins un enregistrement de ressource SOA et un ou plusieurs serveurs de noms significatifs pour la zone ( enregistrements de ressource NS ), ainsi qu'un certain nombre d'autres enregistrements de ressource (RR) tels que des enregistrements de ressource A ou des enregistrements de ressource PTR . En général, les RR sont notés comme suit :

Côté gauche [facultatif : valeur de durée de vie] [facultatif : nom de classe] Tapez côté droit

LeftSide et RightSide sont essentiellement des chaînes de caractères dont le format est déterminé par le type . Les RRs représentent donc des paires de valeurs, séparées par l'affectation de type - A, NS, SOAetc. - et des attributs optionnels supplémentaires, à savoir un à vivre à temps valeur et une désignation de classe, ( » IN" pour Internet , qui est supposé comme défaut si la classe n'est pas spécifié , et " CH" Pour CHAOSnet et " HS" pour Hésiode , deux noms pour les étapes préliminaires historiques du développement d'Internet, quant à eux sans importance). LeftSide peut également être vide (comme un espace blanc , c'est-à-dire des caractères blancs ou de tabulation), auquel cas la valeur LeftSide du RR précédent s'applique .

Les éventuelles informations qui peuvent être interrogées sont donc toujours notées à gauche et les valeurs de réponse associées à droite. Un A-RR renvoie l' adresse IP attribuée à un nom d' hôte (" localhost IN A 127.0.0.1"); Les PTR-RR, quant à eux, servent dans le cas inverse, l'attribution de certains noms d'hôtes à des adresses IP interrogées ( DNS inversé , " 127.0.0.1 IN PTR localhost.").

Les fichiers de zone pour la résolution avant et arrière doivent être formulés de manière cohérente ; De même qu'en principe, un RR doit être présent dans le fichier de zone correspondant pour chaque information individuelle qui peut être interrogée : il n'y a pas de dérivation automatique et déductive d'aucune information DNS, comme cela serait concevable pour la fourniture d' une résolution DNS inverse (par en ajoutant, par exemple, des requêtes PTR via une résolution "inverse" des A-RR existants - côté droit : question, côté gauche : réponse - répondrait).

Cependant, des RR dits " génériques " sont possibles, dans lesquels un astérisque (" *") représente n'importe quel nom d'hôte sur la gauche. Cependant, ceux-ci sont généralement considérés comme problématiques car ils ouvrent un autre scénario d'attaques contre l'intégrité d'un réseau ou d'un service : il est plus facile pour n'importe quel ordinateur d'assumer une fausse identité.

Les fichiers de zone définissent ainsi le contenu d'une zone, essentiellement - mais pas exclusivement - ce sont les noms d'hôtes au sein d'un domaine (c'est-à-dire les A-RR, qui sont naturellement les plus fréquemment interrogés par les clients DNS). Le serveur de messagerie responsable d'un domaine ( MX Resource Record , Mail Exchanger), les noms d'alias pour les noms d'hôtes existants (CNAME-RRs, Canonical Names) ou les méta-informations (TXT-RRs) sont également définis.

Sous-domaines

Les sous-domaines sont définis par ce que l'on appelle la délégation de zone : le nom de sous-domaine souhaité est enregistré dans le fichier de zone du domaine de niveau supérieur en tant que référence au serveur de noms faisant autorité, c'est-à-dire contraignant et significatif pour le sous-domaine (c'est-à-dire un NS-RR), qui est souvent complété par un enregistrement A avec l'adresse IP du serveur de noms de sous-domaine en question, appelé enregistrement de colle (le terme «colle» - symbolise le fait que la connexion hiérarchique entre le domaine et le sous-domaine est établie de cette manière).

Ce dernier peut (ou même doit) être omis si le serveur de noms de sous-domaine lui-même n'est ancré ni dans le domaine secondaire ni dans le domaine supérieur (c'est-à-dire dans un "troisième" domaine pour lequel le serveur de noms qui vient d'être interrogé ne fait pas autorité ; BIND 9 rejette tels que les A-RR comme « données hors zone » et refuse de charger la zone concernée et donc éventuellement le démarrage du programme). Si une telle constellation peut par ailleurs être mise en œuvre sans aucun problème, dans la plupart des cas - d'un point de vue organisationnel - vous préférerez soit déléguer l'hébergement de la zone de sous-domaine à un serveur de noms dans ce sous-domaine, soit le "faire vous-même", en d'autres termes : à conserver sur le serveur de noms du domaine de niveau supérieur.

Si un enregistrement glue est disponible, il permet au serveur de noms de donner des réponses dites intelligentes : Si dans l'exemple suivant ns.example.com" sub.example.com" est demandé le nom d'hôte " " (un client ne fait généralement pas de différence entre les noms d'hôte et de domaine), la réponse est similaire : « sub.example.comJe ne connais pas d'adresse IP pour . Mais cela ns.sub.example.compeut aider, vous pouvez le trouver sous l'adresse IP 192.168.50.1. « Sans un enregistrement de colle, la dernière sous-phrase serait omise ou elle devrait être : « Découvrez l'adresse IP ns.sub.example.comvous-même ! » Si sa réelle requête a reçu une réponse négative, il est facultatif (avec une programmation appropriée « plus intelligente » de sa bibliothèque de résolveur ) d'évaluer les informations supplémentaires transmises à la place et ainsi d' ns.sub.example.comenregistrer une requête DNS pour résoudre «  ». À ce stade, il incombe toujours au résolveur de « travailler » jusqu'au serveur de noms de sous-domaine souhaité, que l' enregistrement de colle soit disponible ou non (bien qu'il utilise la capacité de récursivité d'un serveur de noms, ce qui est considéré ci - dessous peut , à condition qu'il s'agit du client en question autorisé).

Exemple de fichier de zone

L'exemple s'applique à un domaine avec " example.com"

• SOA et NS RR associés (" ns.example.com")
• un hôte " www.example.com"
• un sous-domaine " sub.example.com"

Le example.comdomaine " " est hébergé en tant que fichier de zone " example.com.db" sur " ns.example.com" :

; die Time-to-live-Direktive ist seit BIND v8 am Beginn einer Zonen-
; datei vorgeschrieben; sie gilt für alle RRs ohne explizites TTL-Feld:
$TTL 1d

; optionale Direktive; alle Hostnamen OHNE nachgestellten "." in dieser Zone sind rela-
; tiv zur ff. Domain (anders ausgedrueckt: werden implizit durch $ORIGIN ergaenzt):
$ORIGIN example.com.
; sofern hier nicht angegeben, ist der Wert von $ORIGIN implizit durch den in der zugehoe-
; rigen zone-Direktive (in named.conf) deklarierten Domainnamen bestimmt, ggf. kann letz-
; terer aber auch durch $ORIGIN ueberschrieben werden, daher ist auf Konsistenz zu achten

; Start of Authority und zustaendiger Nameserver sind obligatorisch für eine
; Zonendefinition ("@" ist ein Joker-Symbol für den Wert von $ORIGIN):
@       SOA ns.example.com. hostmaster.example.com. 42 3600 1800 604800 1800
        NS  ns.example.com.

; weist dem Domainnamen example.com eine IP-Adresse zu (was ihn somit auch zu
; einem Hostnamen macht):
        A   192.168.0.100
        AAAA 2001:db8::100

; macht der Welt die IP-Adresse des oben im SOA eingefuehrten ns.example.com bekannt:
ns      A   192.168.0.1
ns      AAAA 2001:db8::1

; definiert den Host www.example.com als Alias von example.com:
www     CNAME @

; definiert die Domain sub.example.com mit dem
; zustaendigen Nameserver ns.sub.example.com:
sub     NS  ns.sub

; Glue: Anfragen nach der IP-Adresse dieses Nameservers
; können direkt von ns.example.com beantwortet werden:
ns.sub  A   192.168.50.1

Un autre serveur de noms pour la zone « sub.example.com» doit alors résider sur 192.168.50.1 . Cependant, vous pouvez tout aussi bien faire ns.example.comgérer cela par " " - l'avant-dernier RR de l'exemple devient " sub NS ns", l'enregistrement de la colle peut toujours être omis, car BIND reconnaît automatiquement ici que vous faites autorité pour le sous-domaine (ce terme est utilisé sera discuté plus en détail sous peu).

En dessous de la hiérarchie des domaines de second niveau, chaque opérateur peut définir un serveur de noms à volonté sous-domaines, au même titre que les bureaux d'enregistrement de domaines réservés, qui à leur tour ont accès aux serveurs de noms des domaines de premier niveau.

Zones maître et esclave

Étant donné que, selon la spécification DNS, les serveurs de noms doivent rester redondants, mais que le maintien de fichiers de zone identiques sur deux ordinateurs indépendants ou plus est très fastidieux et sujet aux erreurs, une distinction est faite entre les serveurs maîtres et esclaves. Ce dernier récupère un fichier de zone à partir d'un serveur maître assigné via un transfert de zone . Le numéro de série défini dans l'enregistrement SOA de la zone est vérifié pour les changements, les données de la zone ne sont acceptées par l'esclave qu'après avoir été incrémentées ; Depuis BIND v8, il existe également une procédure de notification dans laquelle le serveur maître notifie les esclaves des modifications apportées aux fichiers de zone (afin de minimiser la latence des mises à jour de zone). L'administrateur peut utiliser les directives " notify" et " allow-notify" pour spécifier quel esclave doit être notifié par quel maître. Dans l'exemple "named.conf" ci-dessous, il y a un modèle pour un maître (" zone "example.com" ...") et une définition de zone esclave (" zone "example.net" ...").

Serveurs faisant autorité

Les serveurs de noms ou leurs réponses sont considérés comme faisant autorité si les requêtes DNS peuvent être répondues directement à partir d'un fichier de zone existant, contrairement aux données DNS obtenues par récursivité ou transfert, qui sont conservées dans le cache du serveur. Les serveurs de noms maîtres et esclaves peuvent générer des réponses de même autorité les uns aux autres (même si un esclave ne conserve « que » des copies des zones maîtres).

Récursivité et transfert

En plus de l'accès aux noms d'hôtes ancrés dans leurs fichiers de zone, les serveurs de noms maîtrisent également la résolution récursive des noms d'hôtes ou de domaine « inconnus », en partant de la droite, en les décomposant et en les envoyant aux serveurs de noms responsables du top respectif. -niveau et sous - domaines . La requête commence par les serveurs de noms racines , dont les adresses IP doivent être connues à l'avance de chaque serveur de noms et qui renvoient à leur tour des références aux serveurs de noms des domaines de premier niveau.

Les administrateurs DNS responsables configurent désormais leur serveur de manière à ce qu'un ou plusieurs serveurs de noms (réseau) topologiquement "voisins" (ou "superordonnés") soient interrogés (ce qu'on appelle le transfert) avant qu'une récursivité complète via le serveur racine ne soit initiée (pour soulager ce dernier). On suppose que les redirecteurs sont plus susceptibles d'avoir les informations requises (ou des parties de celles-ci, telles que la résolution du domaine de premier niveau interrogé) déjà dans leur cache.

Le fonctionnement optimisé et coopératif du système de noms de domaine à l'échelle d'Internet résulte du maillage minimisant le trafic des serveurs de noms en interaction et du stockage intermédiaire (mise en cache) des informations obtenues avec des « périodes de durabilité » minimales et maximales bien définies.

Alors que la redirection est activée par défaut dans une « toute nouvelle » distribution BIND (option « Forward first;»), la prudence est de mise lors de l'activation de la récursivité. Lorsqu'un serveur de noms qui à la fois l' intra - peut être atteint ainsi que depuis Internet, une récursivité ne doit être autorisée qu'aux utilisateurs de l'intranet (par exemple, par une option comme ". allow-recursion { 192.168.0.0/16; };"), Sinon il servira de passerelle pour le refus -Des attaques par empoisonnement de service et de cache provenant d'Internet peuvent être exploitées.

Fichier de configuration ( name.conf )

L'information est hébergée dans différents domaines. Les plus importants sont :

Zone mondiale

exactement une options {...};directive " "

Liste des serveurs

un nombre quelconque de " server {...};" directives

Liste des zones

un nombre quelconque de " zone {...};" directives

zone de contrôle

une controls {...};directive " "

zone d' exploitation forestière

une logging {...};directive " "

Dans la zone globale , des autorisations d'accès, des clés de chiffrement et des options sont définies (voir la section Options BIND dans la documentation en ligne). La liste de serveurs (facultative) contient des informations sur les serveurs partenaires (par exemple, si un serveur prend en charge le transfert de zone incrémentiel). La liste des zones contient une entrée pour chaque zone à fournir, qui contient le nom de la zone, le nom du fichier de zone affecté, le type de zone (maître ou esclave), les droits d'accès et les options. Avec ce dernier, les options qui ont déjà été définies globalement peuvent être à nouveau écrasées (et ne sont alors valables que dans le contexte de la zone respective). Une configuration minimale d'un serveur de noms contient un fichier de zone chacun pour résoudre le nom d'hôte " localhost" en l'adresse IP 127.0.0.1 et la zone inverse associée. Dans l'exemple "named.conf" ci-dessous, ce sont les deux premières zonedirectives " ". Les fichiers de zone associés sont triviaux et ont par ex. B. l'apparence suivante (un fichier de zone possible pour le domaine " example.com" a déjà été montré ci-dessus) :

; File "localhost.db":
$ORIGIN localhost.
$TTL 1d
@   IN  SOA @ root (
        42   ; serial nr, a tribute to Douglas Adams
        1h   ; refresh
        5m   ; retry
        7d   ; expire
        1d ) ; minimum TTL
    IN  NS  @
    IN  A   127.0.0.1
    IN  AAAA ::1

; File "localhost-rev.db":
$ORIGIN 0.0.127.in-addr.arpa.
$TTL 1d
@   IN  SOA localhost. hostmaster.localhost. (
            42   ; serial
            4h   ; refresh
            30m  ; retry
            7d   ; expire
            1d ) ; minimum TTL
 NS  localhost.
1 PTR localhost.

; File "localhost-rev6.db":
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
$TTL 1d
@   IN  SOA localhost. hostmaster.localhost. (
            42   ; serial
            4h   ; refresh
            30m  ; retry
            7d   ; expire
            1d ) ; minimum TTL
 NS  localhost.
1 PTR localhost.

La zone "root" ou "hint" (directive " zone "." IN {type hint; ...};" dans l'exemple "named.conf") peut être omise si nécessaire, car une liste correspondante des serveurs racines est déjà ancrée dans le code du programme. Cependant, en téléchargeant un named.rootfichier " " à jour et en l'incluant comme indiqué, vous pouvez facilement, i. H. les changements peuvent être traités sans modification ou recompilation du code source (la liste des serveurs racine est rarement modifiée, mais le plus récemment le 12 décembre 2008).

Le format du named.rootfichier " " correspond à celui d'un fichier de zone normal avec des RR NS et A, mais sans RR SOA préfixé. En plus de le télécharger depuis l' IANA , il peut être utilisé , par exemple. B. par la commande

    $> dig NS . @a.root-servers.net >named.root

à condition que l'adresse actuelle du serveur de noms A-Root soit connue.

La zone de contrôle définit un port de contrôle en tant qu'interface pour le programme de contrôle rndc et dans la zone de journalisation , divers types de fichiers journaux et leur affectation d'événements de programme (requêtes, erreurs, etc.) sont définis.

Exemple de fichier named.conf :

options {
  allow-transfer {
     localhost ;
     172.27.157.16 ;
  };
  host-statistics YES ;
  notify          YES ;
  forward first;
  forwarders { 172.27.157.16; };
};

server 172.27.157.16 {
  bogus          no ;
  support-ixfr   yes ;
};

zone "localhost" IN {
  type master;
  file "localhost.db";
  notify no;
};

zone "0.0.127.in-addr.arpa" IN {
  type master;
  file "localhost-rev.db";
  notify no;
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
  type master;
  file "localhost-rev6.db";
  notify no;
};


zone "." IN {
  type hint;
  file "named.root";
};

zone "example.com" {
  type master ;
  file "example.com.db" ;
  notify explicit;
  also-notify { 172.27.157.16; };
};

zone "example.net" {
   type           slave ;
   masters        "ns.example.net" ;
   file           "slave/example.net.db" ;
   allow-notify   "ns.example.net" ;
};

controls {
   inet * port 953 allow { localhost; }
   keys { "rndc-key"; };
};
key "rndc-key" {
   algorithmus hmac-md5;
   secret "password";
};

logging {
   channel default-log { file "logs/named.log"; severity debug; print-severity yes; };
   category default    { default-log; };
   channel queries-log { file "logs/queries.log"; severity info; };
   category queries    { queries-log; };
};

Fonctionnalité

Après lecture des fichiers de configuration, BIND accepte tous les paquets qui arrivent via UDP ou TCP sur le port 53 des interfaces configurées ou des adresses IP . Ces paquets peuvent être des requêtes DNS, des mises à jour dynamiques ou des transferts de zone. Normalement, les requêtes DNS utilisent UDP (paquets IP individuels), ce n'est que si les réponses du serveur dépassent la taille maximale des paquets IP, en particulier dans le cas des transferts de zone, que le système basculera vers TCP.

S'il y a une requête DNS, BIND essaie de la résoudre en utilisant les entrées dans les fichiers de zone. Dans le cas de noms de domaine inconnus (demandes de noms d'hôtes ne faisant pas autorité), le propre cache est d'abord vérifié , puis le cache du redirecteur et enfin une résolution récursive est tentée via le serveur racine.

Dans le cas de mises à jour DNS dynamiques , le fichier de zone concerné est mis à jour pendant l'exécution du démon nommé (les RR sont à nouveau ajoutés ou supprimés), à condition que le client initiateur soit autorisé et vérifié pour le faire. Les mises à jour DNS dynamiques sont notamment utilisées dans un intranet dans lequel les piles protocolaires TCP/IP des ordinateurs nouvellement ajoutés sont automatiquement configurées pour les rendre accessibles sous leur nom d'hôte actuel, qui n'est pas spécifié par une zone configurée statiquement.

Installation et fonctionnement

BIND est parfois inclus avec les systèmes UNIX ou Linux. Les nouvelles versions peuvent être téléchargées sur Internet soit sous forme de packages binaires (pour Windows) soit sous forme de code source. Une connaissance moyenne d'UNIX est suffisante pour installer et faire fonctionner un serveur BIND. Windows NT / 2000 télécharge un fichier binaire compressé qui contient un programme utilitaire qui aide à configurer nommé en tant que service système.

Lors de la modification des fichiers de zone, n'oubliez pas d'incrémenter leur numéro de série et de faire connaître cette modification à BIND, que ce soit via un redémarrage complet du serveur, un SIGHUP (UNIX) ou via les outils de gestion ndc (BIND 8) ou rndc (RELIER 9). Sans cette signalisation, la durée de vie saisie dans la zone doit d'abord s'écouler avant que named ne recharge la zone.

Le nom d'utilitaire NDC ou rndc moyens ( r emote) n om d Aemon c ontroller . En plus des commandes pour démarrer et arrêter le démon et pour recharger les fichiers de configuration et de zone, un certain nombre de fonctions de journalisation et de statistiques sont disponibles avec lesquelles le fonctionnement du logiciel peut être vérifié. En particulier, si BIND s'exécute sous des systèmes d'exploitation qui prennent en charge les threads ou si les mises à jour de zone dynamique sont prises en charge, la commande rndc stop doit toujours être utilisée pour arrêter le service. Avant que le serveur de noms ne fonctionne avec rndc , les hôtes autorisés doivent être entrés dans "named.conf" ; l'échange de données entre le démon et rndc est sécurisé cryptographiquement par une clé qui doit être saisie dans "named.conf" et "rndc.conf". Par défaut, rndc fonctionne via le port 953 (basé sur le port 53 réservé au DNS) ; si nécessaire, des règles de pare-feu doivent être configurées pour cela.

liens web

• dnstop et collecteur de statistiques DNS (anglais) (dsc)
• Enquête sur les serveurs DNS (anglais) : 70 % de tous les domaines utilisent Bind comme serveur de noms
• Modèle BIND sécurisé . Informations sur la sécurisation d'un serveur BIND.

Preuve individuelle