Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
18 mars 2016

htmlpdflatexmanmd




arpaname

arpaname

Traduit les adresses IP en noms ARPA correspondants

   traduit les adresse IP (v4 et v6) en noms IN-ADDR.ARPA ou IP6.ARPA correspondants

^
14 septembre 2010

htmlpdflatexmanmd




Bind 9 - Présentation

Bind 9 - Présentation

service DNS

Exemple de configuration

Serveur de nom cache uniquement
// 2 sous réseaux autorisés à effectués des requêtes:
acl corpnets { 192.168.4.0/24 ; 192.168.7.0/24 ; }
options {
    directory { "/etc/namedb" ; };
    allow-query { corpnets ; };
};
    
zone "0.0.127.in-addr.arpa" {
    type master;
    file "localhost.rev";
    notify no;
};

Serveur de nom autoritatif uniquement :
options {
    directory "/etc/namedb";
    allow-query-cache { none ; };
    allow-query { any; };
    recursive no;
};
    
zone "0.0.127.in-addr.arpa" {
    type master;
    file "localhost.rev";
    notify no;
};
    
zone "example.com";
    type master;
    file "example.com.db";
    allow-transfert {
        192.168.4.14;
        192.168.5.53;
    };
};
    
zone "eng.example.com" {
    type slave;
    file "eng.example.com.bk";
    masters { 192.168.4.12; };
};

Load Balancing

   Le load balancing peut-être fait en utilisant plusieurs enregistrements pour un seul nom.

Notification

   La notification DNS est un mécanisme qui permet aux serveurs maître de notifier leurs esclaves des changements de données de zone. En réponse à une notification d'un maître, l'esclave va vérifier si sa version de la zone est la version courante, et dans le cas contraire, initier un transfert de zone.

Mise à jour automatique

   Dynamic update est une méthode pour ajouter, remplacer ou supprimer des enregistrements dans un serveur maître en envoyant des messages DNS spécifique.

  Le dynamic update est activé avec options allow-update ou une clause update-policy dans la déclaration de zone.

  Si update-policy est à local, les mises à jour de la zone seront permises pour la clé local-ddns, qui sera généré par named au démarrage.

  Les clauses tkey-gssapi-credential et tkey-domain dans les options autorisent le serveur de négocier les clés qui peut correspondre à celles dans update-policy ou allow-update.

Le fichier journal

   Tous les changements faits dans une zone en utilisant le dynamic update sont stockés dans un fichier journal de zone. Ce fichier est automatiquement crée par le serveur lors de la première mise à jour automatique effectuée. Ce journal possède l'extension .jnl et est au format binaire.

  Le serveur va occasionnellement écrire le contenu complet de la zone mise à jour dans son fichier de zone (toutes les 15 minutes). Quand un serveur redémarre après un crash, il va relire le journal et mettre à jour la zone si besoin.

  Les fichiers de zone dynamique ne peuvent pas être édités manuellement. La seul manière de s'assurer que le fichier de zone d'une zone dynamique est à jour est d'utiliser rndc stop.

   Si vous voulez effectuer des changements dans une zone dynamique manuellement, la procédure suivante fonctionne: désactiver le dynamic update de la zone en utilisant rndc freeze ZONE, ce qui va supprimer le journal et mettre à jour le fichier master. après modification, lancer rndc thaw ZONE pour recharger le zone changée et réactiver le dynamic update.

Transfert de zone incrémental

   Le protocole ICFR est une manière pour les serveurs esclaves de transférer uniquement les données changées, au lieu de transférer tout la zone. En agissant comme master, BIND 9 supporte ce protocole pour ces zones où l'historique des changements est disponible. Cela inclus les zones maîtres maintenues par dynamic update et les zones esclaves dont les données ont été obtenues par IXFR. Pour les zones maîtres maintenues manuellement, et pour les zones esclaves obtenues par transfert de zone complet (AXFR), IXFR est supporté seulement si l'option ixfr-from-differences est à yes. En agissant comme esclave, BIND 9 va tenter d'utiliser IXFR par défaut.

Split DNS

   Le split DNS consiste à paramétrer différentes vues, ou visibilitées, de l'espace DNS pour les resorvers interne et externe. Exemple de split DNS avec 2 zones public et 2 zone interne:

Configuration du serveur DNS interne:
acl internals { 172.16.72.0/24 ; 192.168.1.0/24 ; };
acl externals { bastion-ips-go-here ; };
    
options {
    ...
    ...
    forward only;
    forwarders { bastion-ips-go-here ; };
    allow-transfer { none ; };
    allow-query { internals; externals; };
    allow-recursion { internals ; };
    ...
    ...
};
    
zone "site1.example.com" {
    type master;
    file "site1.example.com";
    forwarders {};
    allow-query { internals ; externals ; };
    allow-transfer { internals ; };
};
    
zone "site2.example.com" {
    type slave;
    file "site2.example.com";
    masters { 172.16.72.3; };
    forwarders {};
    allow-query { internals; externals; };
    allow-transfer { internals; };
};
    
zone "site1.internal" {
    type master ;
    file "site1.internal" ;
    forwarders {};
    allow-query { internals ; };
    allow-transfer { internals ; };
;
    
zone "site2.internal" {
    type slave ;
    file "site2.internal" ;
    masters { 172.16.72.3 ; };
    forwarders {};
    allow-query { internals ; };
    allow-transfer { internals ; };
};

Configuration du serveur DNS externe:
acl internals { 172.16.72.0/24 ; 192.168.1.0/24 ; };
acl externals { bastion-ips-go-here ; };
    
options {
    ...
    ...
    allow-transfer { none ; };
    allow-query { any ; };
    allow-query-cache { internals ; externals ; };
    allow-recursion { internals ; externals ; };
    ...
    ...
};
    
zone "site1.example.com" {
    type master;
    file "site1.example.com";
    allow-transfer { internals; externals; };
};
    
zone "site2.example.com" {
    type slave;
    file "site2.example.com";
    masters { another_bastion_host_maybe ; };
    allow-transfer { internals; externals; };
};

TSIG

   BIND supporte TSIG principalement pour les communication serveur à serveur. Cela inclus le transfert de zone, notification, et message query récursifs. TSIG peut être également utile pour le dynamic update. Le programme nsupdate supporte TSIG. Un secret partagé est généré pour être partagé entre 2 hôtes. Un nom de clé arbitraire est choisis "host1-host2".

La commande suivante va générer une clé 128-bits HMAC-SHA256. la longueur max est de 256-bits.
dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2

   la clé est dans le fichier Khost1-host2.+163+00000.private. Rien n'utilise directement ce fichier, mais le chaîne encodée en base64 suivant "Key:" peut être extrait de ce fichier et utilisé comme clé partagées.

Imaginons 2 serveurs host1 et host2. Ajouter dans named.conf de chaque serveur:
key host1-host2. {
    algorithm hmac-sha256;
    secret "La/E5CjG9O+os1jq0a2jdA==";
};

Vu que les clés sont partagées entre 2 hôtes uniquement, le serveur doit savoir quand utiliser la clé. Ajouter dans named.conf
server 10.1.2.3 {
    keys { host1-host2. ; };
};

Contrôle d'accès basé sur les clés TSIG

BIND permet aux adresses et plages IP d'être spécifiées dans des ACL et les directives allow- query | transfer | update. Cela a été étendue pour les clés TSIG également:
allow-update { key host1-host2. ; };
Cela permet aux dynamic update de s'effectuer uniquement si la requête est signée par al clé spécifiée.

TKEY

   TKEY est un mécanisme pour générer automatiquement un secret partagée entre 2 hôtes. Il y'a de nombreux modes de TKEY qui spécifient comment la clé est générée ou assignée. BIND 9 implémente seulement un de ces modes, l'échange de clé diffie-Hellman. Les 2 hôtes requièrent d'avoir un record KEY diffie-hellman. Le processus TKEY doit utiliser des messages signés, signés soit par TSIG ou SIG(0). Le résultat de TKEY est un secret partagé qui peut être aussi utilisé pour supprimer des secrets partagées.

  Le processus TKEY est initialisé par un client ou un serveur en envoyant un query TKEY signé. La réponse du serveur, en cas de succès, contient un record TKEY et un clé appropriée. Après cet échange, tous les participants ont suffisamment d'information pour déterminer le secret partagé. Le processus dépend du mode TKEY. En utilisant le mode Diffie-Hellman, les clés Diffie-Hellman sont échangées, et le secret partagé est dérivé par les participants.

SIG(0)

   BIND 9 supporte partiellement les signatures de transaction DNSSEC SIG(0). SIG(0) utilise des clés public/privée pour authentifier les messages. Le contrôle d'accès est effectué de la même manière que les clé TSIG ; Les privilèges peuvent être donnée ou refusés en fonction du nom de clé. Quand un message signé SIG(0) est reçu, il va seulement être vérifié si la clé est connue et sûre par le serveur, le serveur ne tentera pas de validation de la clé.

DNSSEC

   L'authentification cryptographique d'information DNS est possible au travers des extensions DNSSEC. Pour paramétrer une zone DNSSEC, il y'a une série d'étapes qui doivent être suivies. BIND 9 intègre plusieurs outils qui sont utilisés dans ce processus.

Génération des clés

   le programme dnssec-keygen est utilisé pour générer les clés. Une zone sécurisée doit contenir une ou plusieurs clés de zone. Les clés de zone vont signer tous les enregistrements dans la zone. Les clés de zone doivent avoir le même nom que la zone. Actuellement le seul algorithme utilisé est RSASHA1.

Cette commande génère une clé 768-bits RSASHA1 pourla zone child.example.zone:
dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.

   2 fichiers de sortie sont produits: Kchild.example.+005+12345.key et Kchild.example.+005+12345.private. Le nom des fichiers de clé contient le nom de clé, l'algorithme (3 pour DSA, 1 pour RSAMD5 et 5 pour RSASHA1) et le tag de clé. La clé privée est utilisée pour générer des signatures, et la clé publique est utilisée pour vérifier la signature. Pour générer une autre clé avec les même propriétés ( mais avec un tag de clé différent), répéter la commande. le programme dnssec-keyfromlabel est utilisé pour obtenir une paire de clé depuis une cryptographie hardware et construire les fichiers de clé. il fonctionne similairement à dnssec-keygen. Les clés publiques devraient être insérées dans le fichier de zone en incluant les fichiers .key en utilisant $INCLUDE.

Signer la zone

   dnssec-signzone est utilisé pour signer une zone. Les fichiers keyset correspondant à une sous-zone sécurisée devraient être présents. Le signataire de zone va générer des records NSEC, NSEC3 et RRSIG pour la zone, et un DS pour les zones enfants si -g est spécifié.

La commande suivante signe la zone, assumant qu'il est dans un fichier appelé zone.child.example. Par défaut, toutes les clés de zones qui ont une clé privée disponible sont utilisés pour générer les signatures
dnssec-signzone -o child.example zone.child.example
Un fichier zone.child.example.signed sera produit. Ce fichier devrait être référencé par named.conf comme fichier d'entrée pour la zone.

   dnssec-signzone va aussi produire des fichiers keyset et dsset et optionnellement un fichier dlvset. Ils sont utilisés pour la zone parent avec les DNSKEY ( ou leur record DS correspondant) qui sont le point d'entrée sécurisé de la zone.

Configurer les serveurs

   Pour permettre à named de répondre aux requêtes depuis des clients DNSSEC, dnssec-enable doit être à yes. Pour permettre à named de valider les réponses depuis d'autres serveurs, dnssec-enable et dnssec-validation doivent être à yes, et au moins en groupe trust doit être configuré avec les options trusted-keys ou managed-keys.

   Les trusted-keys sont des copies des DNSKEY RR pour les zones qui sont utilisés pour former le premier lien dans la chaîne cryptographique. Toutes les clés listées dans trusted-keys sont considérées pour exister et seul les clés listées seront utilisés pour valider le DNSKEY RRset.

   managed-keys sont des clés de confiance qui sont automatiquement mis à jours via un groupe de maintenance de confiance.

   Une fois que DNSSEC est établit, une configuration DNSSEC typique va ressembler à la configuration ci-dessous. Il y'a une ou plusieurs clés publiques pour le root. Cela permet aux réponses en dehors de l'organisation d'être validées. Il y'a aussi plusieurs clés pour les parties de l'espace de nom que l'organisation contrôle.


managed-keys {
    /* root Key */
    "." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
        JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
        aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
        4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
        hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
        5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
        g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
        66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
        97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
        dgxbcDTClU0CRBdiieyLMNzXG3";
};
trusted-keys {
    /* Key for our organization’s forward zone */
    example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
        5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
        GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
        4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
        kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O
        g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
        TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
        FxmAVZP20igTixin/1LcrgX/KMEGd/biuv
        F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
        /oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o
        1OTQ09A0=";
/bin /boot /dev /etc /home /lib /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /@System.solv /tmp /usr /var Key for our reverse zone. */
2.0.192.IN-ADDRPA.NET. 257 3 5 "AQOnS4xn/IgOUpBPJ3bogzwc
        xOdNax071L18QqZnQQQAVVr+i
        LhGTnNGp3HoWQLUIzKrJVZ3zg
        gy3WwNT6kZo6c0tszYqbtvchm
        gQC8CzKojM/W16i6MG/eafGU3
        siaOdS0yOI6BgPsw+YZdzlYMa
        IJGf4M4dyoKIhzdZyQ2bYQrjy
        Q4LB0lC7aOnsMyYKHHYeRvPxj
        IQXmdqgOJGq+vsevG06zW+1xg
        YJh9rCIfnm1GX/KMgxLPG2vXT
        D/RnLX+D3T3UL7HJYHJhAZD5L
        59VvjSPsZJHeDCUyWYrvPZesZ
        DIRvhDD52SKvbheeTJUm6Ehkz
        ytNN2SN96QRk8j/iI8ib";
};
options {
    ...
    dnssec-enable yes;
    dnssec-validation yes;
};

DNSSEC, zones dynamiques, et auto-signature

   Il est possible de changer une zone dynamique non-sécurisée vers une zone signée, et inversement. Une zone sécurisée peut utiliser soit NSEC soit NSEC3.

Convertir en zone sécurisée

Celà peut être fait de 2 manières: utiliser un DNS dynamic update, ou l'option de zone auto-dnssec.
zone example.net {
    type master;
    update-policy local;
    file "dynamic/example.net";
    key.directory "/dynamic";
};

   si un KSK et une clé ZSK DNSKEY ont été générés, cette configuration va forcer tous les records dans la zone à être signés avec ZSK, et le DNSKEY RRset d'être signé avec KSK.

Méthode de mise à jour DNS Dynamic

Pour insérer les clés via dynamic update
% nsupdate
› ttl 3600
› update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3E
› update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZX
› send

   La requête va se compléter immédiatement, lazone ne sera pas complètement signée jusqu'à ce que named ait eu le temps de traverser la zone et générer les records NSEC et RRSIG.

Si vous voulez utiliser NSEC3 au lieu de NSEC, vous devriez ajouter un record NSEC3PARAM à la requête de mise à jour initiale. Si vous que la chaîne NSEC3 ai le bit OPTOUT mis, le définir dans les champs de flag du record NSEC3PARAM.
% nsupdate
› ttl 3600
› update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfB
› update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X
› update add example.net NSEC3PARAM 1 1 100 1234567890
› send

   De même, cette requête sera complétée immédiatement; cependant le record se sera pas visible tant que named n'a pas eu une chance de construire/supprimer le chaîne.

Signer une zone automatiquement

   Pour activer la signture automatique, ajouter auto-dnssec à la déclaration de zone. Cette options a 2 arguments possibles: allow et maintain.

  Avec auto-dnssec allow, named peut rechercher le répertoire de clé pour les clés correspondant à la zone, les insérer dans la zone, et les utiliser pour signer la zone. Il le fera uniquement quand il recevra la commande rndc sign ‹zone-name›

  auto-dnssec maintain inclue la même fonctionnalité, mais va également ajuster automatiquement les records DNSKEY de la zone en accord
^
07 mars 2016

htmlpdflatexmanmd




BIND 9.10

BIND 9.10

Service de nom de domaine

Introduction

   BIND (Berkeley Internet Name Domain) implémente un serveur de nom de domaine. Il peut agir en tant que serveur de nom Autoritatif (AA), Serveur Primaire ou esclave, serveur cache, stealth, et avoir plusieurs de ces rôles en même temps.

Ressources requises

   Les besoins matériel pour DNS sont généralement modeste, cependant, l'utilisation de DNSSEC peut éprouver les CPU. L'option max-cache-size permet de limiter la quantité de mémoire pour le cache. Additionnellement, l'options max-acache-size peut être utilisé pour limiter la quantité de mémoire utilisée par le mécanisme. C'est une bonne pratique d'avoir suffisamment de mémoire pour charger toutes les zones et données en cache. Cependant, la meilleur manière de déterminer la quantité de mémoire est de regarder le serveur en opérations. Après quelques semaines de traitement, le serveur atteind un niveau relativement stable où les entrées expirent dans le cache aussi vite qu'elles sont insérées.

Opérations du serveur de nom

   Cette section décrit de nombreux outils indispensable de diagnostique, d'administration et de supervision disponible pour contrôler et debugger le service.

dig (Domain Information Groper) est un outil complet de recherche. Il a 2 modes: interactif simple, et batch.
host Convertis le noms d'hôte en adresses Internet et inversement, et d'autres fonctionnalités
nslookup nslookup a 2 modes: interactif simple, et non-interactif. Il permet de récupérer de requêter des serveurs de nom.
named-checkconf Vérifie la syntaxe d'un fichier named.conf
named-checkzone Vérifie un fichier maître
named-compilezone Similaire à named-checkzone, mais dump le contenu dans un fichier spécifié
rndc (Remote Name Daemon Control) permet de contrôler les opérations de named

Signaux

SIGHUP Force le serveur à relire named.conf et recharger la base
SIGTERM Force le serveur à se terminer proprement
SIGINT Force le serveur à se terminer proprement

Résolveur léger

   traditionnellement, les applications sont liées avec une librairie résolveur qui envoient des requêtes DNS récursives à un serveur de nom cache. IPv6 introduit une nouvelle complexité dans le processus de résolution, tel que les chaînes A6 et les enregistrement DNAME, et la rechercher simultanné IPv4 et IPv6. BIND9 peut cependant fournir des services de résolution aux clients locaux en utilisant une combinaison d'une librairie de résolution légère et un processus de résolution dans l'hôte local. Ils communiquent en utilisant un protocole basé sur UDP qui est distinct et plus léger que le protocole DNS complet.

   Pour utiliser l'interface de résolution légère, le système doit lancer les service lwresd ou un serveur de nom local configuré avec la déclaration lwres.

   Par défaut, les applications utilisant la libraire de résolution légère vont faire des requêtes sur UDP sur la loopback sur le port 921. Le service ne fait que des recherches DNS, mais dans le future, pourra regarder dans hosts, NIS, etc.

   lwresd est essentiellement un serveur de nom cache uniquement. Parce qu'il doit fonctionner sur tous les hôtes, il est conçu pour fonctionner sans configuration ou avec une configuration minimale.

Éléments du fichier de configuration

   La liste suivante décris les éléments utilisé dans ce document:

acl_name Le nom d'une address_match_list comme définis par la déclaration acl
address_match_list Une liste d'un ou plusieurs ip_addr, ip_prefix, key_id ou acl_name
masters_list Une liste nommé d'un ou plusieurs ip_addr avec optionnellement key_id et/ou ip_port
domain_name Une chaîne qui est utilisée comme nom DNS
namelist Une liste d'un ou plusieurs éléments domain_name
doted_decimal Un à 4 entiers de 0 à 255 séparés par des '.'
ip4_addr Une adresse IPv4
ip6_addr Une adresse IPv6
ip_addr une ip4_addr ou ip6_addr
ip_dscp Un nombre entre 0 et 63, utilisé pour sélectionner un point de code de services différentiés (DSCP) à utiliser pour le trafique sortant dans les OS qui supportent DSCP.
ip_port Un numéro de port IP (0 à 65535)
ip_prefix Un masque de sous-réseau
key_id Une domain_name représentant le nom d'une clé partagée
key_list Une liste d'une ou plusieurs key_id
number Un nombre entien non-négatif 32bits
path_name Chemin de fichier
port_list Une liste d'un ip_port ou une plage de port
size_spec Entien non-signé 64bits
yes_or_no soit yes soit no
dialup_option yes, no, notify, notify-passive, refresh, ou passive.

Liste de correspondance d'adresses

Syntaxe:
address_match_list = address_match_list_element ; [ address_match_list_element; ... ]
address_match_list_element = [ ! ] (ip_address [/length] | key key_id | acl_name | { address_match_list } )

Commentaires

Syntaxe:
/*    ceci est un commentaire */
// ceci est un commentaire
# ceci est un commenentaire

Déclaration

acl Définis une liste d'adresse ip nommée
controls Déclare des canaux de contrôle utilisé par rndc
include Inclure un fichier
key Spécifie les information de clé pour l'authentification et l'autorisation
logging Spécifie ce que le serveur log, et où
lwres Configure named pour agir également comme résolveur léger
masters Définis une liste de serveurs maîtres.
options Contrôle les options de configuration globale au serveur
server Définis certaines options par serveur
statistics-channels Déclare des canaux de communication pour avoir accès aux statistiques de named
trusted-keys Définis les clés DNSSEC de confiance
managed-keys Liste les clé DNSSEC à conserver à jour avec rfc5011
view Définis une vue
zone définis une zone

ACL

   Les mots clés intégrés sont:

any Matche tous les hôtes
none Ne matche aucun hôte
localhost Matche les IPv4 et IPv6 de toutes les interfaces réseaux dans le système. Cette liste est dynamique
localnets Matche tous les hôtes dans un réseau IPv4 ou IPv6 pour lequel le système à une interface.

   Quand BIND 9 est construit avec GeoIP, les acl peuvent également être utilisées pour des restrictions d'accès géographique, avec un élément sous la forme geoip [db database] field value. field indique quel champ correspondre (country, region, city, continent, postal, metro, area, tz, isp, org, asnum, domain, et netspeed).

Controls


controls {
    [ inet ( ip_addr |    *    ) [ port ip_port ] allow { address_match_list } keys { key_list }; ] [ inet ...; ]
    [ unix path perm number owner number group number keys { key_list }; ] [ unix ...; ] };

   La déclaration controls déclare les canaux de contrôle à utiliser par les administrateurs système pour contrôler les opérations du serveur. Ces canaux sont utilisés par rndc. Un canal inet est un socket TCP. Le port par défaut est 953. La capacité à utiliser des commandes dans le canal est contrôlé par les clauses allow et keys. Un canal de contrôle unix est un socket unix écoutant dans le chemin spécifié.

   Si aucune déclaration controls n'est spécifiée, named en définis un sur l'interface de bouclage à l'adresse 127.0.0.1 et tente de charger une clé dans rndc.key dans $SYSCONFDIR (spécifié à la compilation). pour désactiver l'utilisation des canaux, créer une déclaration vide: controls { };

include

   Permet d'inclure d'autres fichiers de configuration

key

   La déclaration key définis une clé secrète partagée à utiliser avec TSIG ou un canal de commande. La déclaration key peut être définis globalement ou dans une déclaration view. L'algorithm spécifie l'algorithme utilisé. named supporte hmac-md5, hmac-sha1, hmac-sha224, hmac-sha384 et hmac-sha512.

logging

   La déclaration logging configure une variété d'option de logs pour le serveur. Ses canaux associent des méthodes de sortie, options de format de niveaux de sévérité avec un nom qui peut ensuite être utilisé avec la catégorie.

  Les catégories sont:

default définis les options de log pour les catégories qui n'ont pas de configuration définie.
general Tout ce qui n'est pas classifié dans des catégories sont définis ici
database Les messages liés aux bases de données utilisé en interne pour stocker les zones et données du cache
security Approbation et refus des requêtes
config traitement de fichier de configuration
resolver Résolution DNS, tel que les recherche récursives
xfer-in Transfer de zone reçus par le serveur
xfer-out Transfer de zone envoyés par le serveur
notify Le protocole NOTIFY
client traitement des demandes client
unmatched Messages que named n'est pas capable de déterminer la classe ou pour lesquels il n'y pas de vue.
network Opérations réseaux
update Mises à jour dynamique
update-security Approbation et refus de demandes de mise à jours
queries reporte les IP des client et numéro de port.
query-erros Informations sur les requêtes résultant de certaines erreurs
dispatch dispatching des packet entrants aux modules
dnssec traitement DNSSEC et TSIG
lame-servers Mauvaises configuration dans le serveurs distants, découvert par bind
delegation-only requêtes qui ont été forcés au NXDOMAIN en résultat d'une zone delegation-only
edns-disabled Requêtes qui ont été forcés à utiliser plain DNS dû à un timeoute.
RPZ Informations sur les erreurs en réponse à des stratégies de fichier de zone

query-errors

la catégorie query-errors est prévue pour un but de débuggage. au niveau de débug 1 ou +, chaque réponse avec le rcode SERVFAIL est loggé comme suit:
client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880

Qui signifie une erreur détecté à la ligne 3880 du fichier source query.c. Au debug niveau 2 et +, des informations détaillées de résolution récursive sont loggés:
fetch completed at resolver.c:2970 for www.example.com/A in 30.000183: timed out/success [domain:example.com,
referral:2,restart:7,qrysent:8,timeout:5,lame:0,neterr:0, badresp:1,adberr:0,findfail:0,valfail:0]

   La première partie avent le ':' montre qu'une résolution récursive pour des enregistrements AAA de www.example.com complétés en 30.000183 secondes et le résultat final a été déterminé à la ligne 2970 du fichier source resolver.c.

   La partie suivante montre le résultat final détecté et le dernier résultat de la validation DNSSEC. Dans cet exemple, la requête a échoué parce que tous les serveurs sont down ou inateignable. La dernière partie affiche des informations de statistiques collectés pour cette tentative de résolution:

referral Le nombre de référants que le résolveur a reçu durant le processus de résolution.
restart Le nombre de cycles que le serveur a tenter les serveurs distants du domaine.
qrysent Le nombre de requêtes que le résolveur en envoyés au domaine
timeout Le nombre de timeout depuis que le résolveur a reçu la dernière réponse
lame Le nombre de serveurs lames que le résolveur a détecté soit par une réponse invalide, ou en résultat d'une recherche dans la base d'adresse de BIND9 (ADB), où les serveurs lames sont en cache.
neterr Nombre de résultats erronés que le résolveur a rencontré en envoyant des requêtes au domaine. Peut être dû au serveur inateignable et le résolveur a reçus un ICMP unreachable.
badresp Le nombre de réponses attendus (autre que lame) aux requêtes envoyées par le résolveur au domaine
adberr Erreurs en trouvant des adresses de serveur distant du domaine dans la ADB. Un cas commun est que le nom du serveur distant n'a pas d'adresse
findfail Érreurs en résolvant les adresses de serveur distant. C'est un nombre total d'erreur via le processus de résolution.
valfail Erreurs de validation DNSSEC, dans le processus de résolution.

   Au débug niveau 3 et +, les mêmes messages que le niveau 1 sont loggés pour d'autres erreurs que SERVFAIL. Noter que des réponses négatives telles que NXDOMAIN ne sont pas vus comme erreurs ici.

   Au débug niveau 4 et +, les même message que le niveau 2 sont loggés pour d'autres erreurs que SERVFAIL.

lwres


lwres {
    [ listen-on { ip_addr [port ip_port] [dscp ip_dscp] ;
    [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ view view_name; ]
    [ search { domain_name ; [ domain_name ; ... ] }; ]
    [ ndots number; ]
};

   Plusieurs déclaration lwres peuvent être configurés avec différentes propriétés. view spécifie la vue ou placer le résolveur. search est équivalent à la déclaration dans /etc/resolv.conf. Elle fournis une liste de domaine qui sont ajoutés aux noms relatifs dans les requêtes. ndots est équivalent à la déclaration dans /etc/resolv.conf, et indique le nombre de '.' minimum dans un nom de domaine relatif qui devrait résulter en un match exact avant que les éléments de search soient ajoutés

masters


masters name [port ip_port] [dscp ip_dscp] { ( masters_list |
ip_addr [port ip_port] [key key] ) ; [...] };

   Les déclarations masters permettent à un jeu commun de masters d'être facilement utilisés par plusieurs zones stub et slaves.

options

La déclaration options définis les options globales utilisées par BIND. cette déclaration peut apparaître seulement une fois dans la fichier de configuration.
options {
    [ attach-cache cache_name; ]
    [ version version_string; ]
    [ hostname hostname_string; ]
    [ server-id server_id_string; ]
    [ directory path_name; ]
    [ key-directory path_name; ]
    [ managed-keys-directory path_name; ]
    [ named-xfer path_name; ] // obsolete
    [ tkey-gssapi-keytab path_name; ]
    [ tkey-gssapi-credential principal; ]
    [ tkey-domain domainname; ]
    [ tkey-dhkey key_name key_tag; ]
    [ cache-file path_name; ] //not-used
    [ dump-file path_name; ]
    [ bindkeys-file path_name; ]
    [ secroots-file path_name; ]
    [ session-keyfile path_name; ]
    [ session-keyname key_name; ]
    [ session-keyalg algorithm_id; ]
    [ memstatistics yes_or_no; ]
    [ memstatistics-file path_name; ]
    [ pid-file path_name; ]
    [ recursing-file path_name; ]
    [ statistics-file path_name; ]
    [ zone-statistics full | terse | none; ]
    [ auth-nxdomain yes_or_no; ]
    [ deallocate-on-exit yes_or_no; ] //obsolete
    [ dialup dialup_option; ]
    [ fake-iquery yes_or_no; ]//obsolete
    [ fetch-glue yes_or_no; ] //obsolete
    [ flush-zones-on-shutdown yes_or_no; ]
    [ has-old-clients yes_or_no; ]//obsolete
    [ host-statistics yes_or_no; ]//obsolete
    [ host-statistics-max number; ]//obsolete
    [ minimal-responses yes_or_no; ]
    [ multiple-cnames yes_or_no; ] //obsolete
    [ notify yes_or_no | explicit | master-only; ]
    [ recursion yes_or_no; ]
    [ request-sit yes_or_no; ]
    [ request-nsid yes_or_no; ]
    [ rfc2308-type1 yes_or_no; ]
    [ use-id-pool yes_or_no; ] //obsolete
    [ maintain-ixfr-base yes_or_no; ] //obsolete
    [ ixfr-from-differences (yes_or_no | master | slave); ]
    [ dnssec-enable yes_or_no; ]
    [ dnssec-validation (yes_or_no | auto); ]
    [ dnssec-lookaside ( auto | no | domain trust-anchor domain ); ]
    [ dnssec-must-be-secure domain yes_or_no; ]
    [ dnssec-accept-expired yes_or_no; ]
    [ forward ( only | first ); ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ dual-stack-servers [port ip_port] [dscp ip_dscp] { ( domain_name [port ip_port] [dscp ip_dscp] | ip_addr [port ip_port] [dscp ip_dscp]) ; ... }; ]
    [ check-names ( master | slave | response ) ( warn | fail | ignore ); ]
    [ check-dup-records ( warn | fail | ignore ); ]
    [ check-mx ( warn | fail | ignore ); ]
    [ check-wildcard yes_or_no; ]
    [ check-integrity yes_or_no; ]
    [ check-mx-cname ( warn | fail | ignore ); ]
    [ check-srv-cname ( warn | fail | ignore ); ]
    [ check-sibling yes_or_no; ]
    [ check-spf ( warn | fail | ignore ); ]
    [ allow-new-zones { yes_or_no }; ]
    [ allow-notify { address_match_list }; ]
    [ allow-query { address_match_list }; ]
    [ allow-query-on { address_match_list }; ]
    [ allow-query-cache { address_match_list }; ]
    [ allow-query-cache-on { address_match_list }; ]
    [ allow-transfer { address_match_list }; ]
    [ allow-recursion { address_match_list }; ]
    [ allow-recursion-on { address_match_list }; ]
    [ allow-update { address_match_list }; ]
    [ allow-update-forwarding { address_match_list }; ]
    [ update-check-ksk yes_or_no; ]
    [ dnssec-update-mode ( maintain | no-resign ); ]
    [ dnssec-dnskey-kskonly yes_or_no; ]
    [ dnssec-loadkeys-interval number; ]
    [ dnssec-secure-to-insecure yes_or_no ;]
    [ try-tcp-refresh yes_or_no; ] // obsolete
    [ allow-v6-synthesis { address_match_list }; ] // obsolete
    [ blackhole { address_match_list }; ]
    [ no-case-compress { address_match_list }; ]
    [ use-v4-udp-ports { port_list }; ]
    [ avoid-v4-udp-ports { port_list }; ]
    [ use-v6-udp-ports { port_list }; ]
    [ avoid-v6-udp-ports { port_list }; ]
    [ listen-on [ port ip_port ] [dscp ip_dscp] { address_match_list }; ]
    [ listen-on-v6 [ port ip_port] [dscp ip_dscp] { address_match_list }; ]
    [ query-source ( ( ip4_addr |    *    )
        [ port ( ip_port |    *    ) ]
        [ dscp ip_dscp] |
        [ address ( ip4_addr |    *    ) ]
        [ port ( ip_port |    *    ) ] )
        [ dscp ip_dscp] ; ]
    [ query-source-v6 ( ( ip6_addr |    *    )
        [ port ( ip_port |    *    ) ]
        [ dscp ip_dscp] |
        [ address ( ip6_addr |    *    ) ]
        [ port ( ip_port |    *    ) ] )
        [ dscp ip_dscp] ; ]
    [ use-queryport-pool yes_or_no; ] //obsolete
    [ queryport-pool-ports number; ] //obsolete
    [ queryport-pool-updateinterval number; ] //obsolete
    [ max-transfer-time-in number; ]
    [ max-transfer-time-out number; ]
    [ max-transfer-idle-in number; ]
    [ max-transfer-idle-out number; ]
    [ tcp-clients number; ]
    [ reserved-sockets number; ]
    [ recursive-clients number; ]
    [ serial-query-rate number; ]
    [ serial-queries number; ] //obsolete
    [ tcp-listen-queue number; ]
    [ transfer-format ( one-answer | many-answers ); ]
    [ transfers-in number; ]
    [ transfers-out number; ]
    [ transfers-per-ns number; ]
    [ transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ use-alt-transfer-source yes_or_no; ]
    [ notify-delay seconds ; ]
    [ notify-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-to-soa yes_or_no ; ]
    [ also-notify { ip_addr [port ip_port] [dscp ip_dscp] [key keyname] ; [ ip_addr [port ip_port] [dscp ip_dscp] [key keyname] ; ... ] };[ max-ixfr-log-size number; ]
    [ max-journal-size size_spec; ]
    [ coresize size_spec ; ]
    [ datasize size_spec ; ]
    [ files size_spec ; ]
    [ stacksize size_spec ; ]
    [ cleaning-interval number; ] //obsolete
    [ heartbeat-interval number; ]
    [ interface-interval number; ]
    [ statistics-interval number; ]
    [ topology { address_match_list }];
    [ sortlist { address_match_list }];
    [ rrset-order { order_spec ; [ order_spec ; ... ] ] };
    [ lame-ttl number; ]
    [ max-ncache-ttl number; ]
    [ max-cache-ttl number; ]
    [ max-zone-ttl number ; ]
    [ sig-validity-interval number [number] ; ]
    [ sig-signing-nodes number ; ]
    [ sig-signing-signatures number ; ]
    [ sig-signing-type number ; ]
    [ min-roots number; ]
    [ use-ixfr yes_or_no ; ] // obsolete
    [ provide-ixfr yes_or_no; ]
    [ request-ixfr yes_or_no; ]
    [ treat-cr-as-space yes_or_no ; ] // obsolete
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ port ip_port; ]
    [ dscp ip_dscp] ;
    [ additional-from-auth yes_or_no ; ]
    [ additional-from-cache yes_or_no ; ]
    [ random-device path_name ; ]
    [ max-cache-size size_spec ; ]
    [ match-mapped-addresses yes_or_no; ] // obsolete
    [ filter-aaaa-on-v4 ( yes_or_no | break-dnssec ); ]
    [ filter-aaaa-on-v6 ( yes_or_no | break-dnssec ); ]
    [ filter-aaaa { address_match_list }; ]
    [ dns64 ipv6-prefix {
        [ clients { address_match_list }; ]
        [ mapped { address_match_list }; ]
        [ exclude { address_match_list }; ]
        [ suffix IPv6-address; ]
        [ recursive-only yes_or_no; ]
        [ break-dnssec yes_or_no; ]
    }; ];
    [ dns64-server name ]
    [ dns64-contact name ]
    [ preferred-glue ( A | AAAA | NONE ); ]
    [ edns-udp-size number; ]
    [ max-udp-size number; ]
    [ max-rsa-exponent-size number; ]
    [ root-delegation-only [ exclude { namelist } ] ; ]
    [ querylog yes_or_no ; ]
    [ disable-algorithms domain { algorithm;
        [ algorithm; ] }; ]
    [ disable-ds-digests domain { digest_type;
        [ digest_type; ] }; ]
    [ acache-enable yes_or_no ; ]
    [ acache-cleaning-interval number; ]
    [ max-acache-size size_spec ; ]
    [ clients-per-query number ; ]
    [ max-clients-per-query number ; ]
    [ masterfile-format (text|raw|map) ; ]
    [ empty-server name ; ]
    [ empty-contact name ; ]
    [ empty-zones-enable yes_or_no ; ]
    [ disable-empty-zone zone_name ; ]
    [ zero-no-soa-ttl yes_or_no ; ]
    [ zero-no-soa-ttl-cache yes_or_no ; ]
    [ resolver-query-timeout number ; ]
    [ deny-answer-addresses { address_match_list } [ except-from { namelist } ];]
    [ deny-answer-aliases { namelist } [ except-from { namelist } ];]
    [ prefetch number [number] ; ]
    [ rate-limit {
        [ domain domain ; ]
        [ responses-per-second [size number] [ratio fixedpoint] number ; ]
        [ referrals-per-second number ; ]
        [ nodata-per-second number ; ]
        [ nxdomains-per-second number ; ]
        [ errors-per-second number ; ]
        [ all-per-second number ; ]
        [ window number ; ]
        [ log-only yes_or_no ; ]
        [ qps-scale number ; ]
        [ ipv4-prefix-length number ; ]
        [ ipv6-prefix-length number ; ]
        [ slip number ; ]
        [ exempt-clients { address_match_list } ; ]
        [ max-table-size number ; ]
        [ min-table-size number ; ]
    } ; ]
    [ response-policy {
        zone zone_name ;
        [ policy given | disabled | passthru | drop | nxdomain | nodata | cname domain
        [ recursive-only yes_or_no ; ]
        [ max-policy-ttl number ; ] ;
        [ recursive-only yes_or_no ; ]
        [ max-policy-ttl number ; ]
        [ break-dnssec yes_or_no ; ]
        [ min-ns-dots number ; ]
        [ qname-wait-recurse yes_or_no ; ]
    } ; ]
};


attach-cache ‹string› (options,view)autorise plusieurs vues à partager une seule base de cache. Chaque vue a sa propre base de cache, mais si plusieurs vues ont la même stratégie opérationnelle pour la résolution de nom et de cacheng, ces vues peuvent partager le même cache et sauver de la mémoire et possiblement améliorer l'efficacité de résolution en utilisant cette option. L'implémentation actuelle exige que les vues partageant le même cache soient consistant avec les options suivantes: check-names, cleaning-interval, dnssec-accept-expired, dnssec-validation, max-cache-ttl, max-ncache-ttl, max-cache-size, et zero-no-soa-ttl.
directory ‹path_name› Le répertoire de travail du serveur. Tout chemins non-absolus dans le fichier de configuration sera pris comme relatif à ce répertoire.
key-directory ‹path_name› Lors de mise à jours dynamique de zone sécurisés, le répertoire où sont les fichiers de clé DNSSEC et publique/privé (ne concerne pas bind.keys, rndc.key ni session.key)
managed-keys-directory ‹path_name› Spécifie le répertoire dans lequel stocker les fichiers qui suivent les clés DNSSEC.
tkey-gssapi-keytab ‹path_name› Le fichier keytab à utiliser pour les mises à jours GSS-TSIG. Si cette option est définie et pas gssapi-credential, les mises à jours seront autorisés avec toute clé matchant un principal dans le keytab
tkey-gssapi-credential ‹principal› L'accréditif de sécurité avec lequel le serveur devrait authentifier les clés demandées par le protocole GSS-TSIG. Actuellement seul kerberos 5 est supporté, et l'accréditif est un principal kerberos que le serveur peut obtenir via le fichier de clé système définis par tkey-gssapi-keytab. Normalement ce principal est sous la forme 'DNS/server.domain'. tkey-domain doit également être définis si un keytab spécifique n'est pas définis dans tkey-gssapi-keytab
tkey-domain ‹domainname› Le domaine ajouté à tous les noms de toutes les clés partagées générées avec TKEY.
tkey-dhkey key_name key_tag; Clé Diffie-Hellman utilisée par le serveur pour générer des clés partagées avec les clients en utilisant le mode dh. Le serveur doit être capable de charger les clés publique et privée depuis les fichiers dans le répertoire de travail courant. Dans la plupart des cas, le nom de clé devrait être le nom d'hôte du serveur.
dump-file path_name Chemin du fichier où le serveur dump la base, invoqué par rndc dumpdb.
memstatistics-file path_name chemin du fichier où le serveur écrit les statistiques d'utilisation mémoire.
pid-file path_name Chemin du fichier pid où le serveur écrit sont pid.
recursing-file path_name chemin du fichier où le serveur dump les requêtes recursives, invoqué par rndc recursing.
statistics-file path_name chemin du fichier où le serveur ajoute des statistiques, invoqué par rndc stats.
bindkeys-file path_name chemin du fichier pour remplacer les clés de confiance intégrée par named.
secroots-file path_name Le chemin du fichier où le serveur dumps les security root, invoqué par rndc secroots.
session-keyfile path_name chemin du fichier dans lequel écrire un clé de session TSIG générée par named à utiliser par nsupdate -l.
session-keyname key_name Le nom de la clé à utiliser pour la clé de session TSIG. défaut: local.ddns.
session-keyalg L'algorithme à utiliser pour la clé de session TSIG. (hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384, hmac-sha512 et hmac-md5)
port ip_port port UDP/TCP d'écoute du serveur. Défaut: 53
random-device path_name Source d'entropy à utiliser par le serveur
preffered-glue ( A | AAAA | NONE ) Si spécifié, le type listé sera émis avant d'autre glue dans la section additionnelle d'une réponse.
root-delegation-only [ exclude { namelist } ] ; Active la délégation-only dans les TLD et les zones root avec une liste d'exclusion optionnelle. Si une zone delegation-only déssert également une zone enfant, il n'est pas toujours possible de déterminer si une réponse vient de la zone delegation-only ou de la zone enfant. Les enregistrements SOA NS et DNSKEY sont des enregistrements apex uniquement et une réponse correspondante qui contient ces enregistrement ou DS est traitée comme venant d'une zone enfant. les enregistrements RRSIG sont également examinés pour voir s'il y a évidence que la réponse vient de la zone enfant. Les réponse déterminée comme venant de la zone enfant ne sont pas convertis en réponse NXDOMAIN. Noter que certains TLD ne sont pas délégation-only.
disable-algorithms domain { algorithm; [ algorithm; ] }; Désactive les algorithmes DNSSEC spécifiés. Peut être spécifié plusieurs fois. Seul la déclaration match le mieux sera utilisé.
disable-ds-digests domain { digest_type; [ digest_type; ] }; Désactive le types digests DS/DLV spécifiés. Peut être spécifié plusieurs fois. Seul la déclaration match le mieux sera utilisé.
dnssec-lookaside ( auto | no | domain trust-anchor domain ); Fournis le validateur avec une méthode alternative pour valider les enregistrements DNSKEY en haut de la zone.
dnssec-must-be-secure domain yes_or_no Spécifie les hiérarchies qui doivent être ou non sécurisés (signé et validé). à no, la validation DNSSEC permet des réponses non-sûres.
dns64 ipv6-prefix { [ clients { address_match_list }; ] [ mapped { address_match_list }; ] [ exclude { address_match_list }; ] [ suffix IPv6-address; ] [ recursive-only yes_or_no; ] [ break-dnssec yes_or_no; ] }; ]; Cette directive instruit named de retourner les adresses IPv4 mappées en requêtes AAAA quand il n'y a pas de records AAAA. Prévue pour être utilisé en conjonction avec NAT64. Chaque dns64 définis un préfix DNS64.

        exclude définis une liste d'IPv6 qui seront ignorées s'il elles apparaissent dans des enregistrement AAAA du nom de domaine.
        suffix définis les bits restants des bits d'adresse IPv4.
        recursive-only à yes la synthèse dns64 ne se produit que pour les requêtes récursives.
        break-dnssec à yes, la synthèse dns64 se produit même si le résultat, si validé, crée une erreur de validation DNSSEC.

dnssec-update-mode ( maintain | no-resign ); à maintain dans une zone master qui est signée avec DNSSEC et configurée pour les mises à jours dynamiques, et si named a accès à la clé de signature privée de la zone, named signe automatiquement toutes nouveaux enregistrements ou changement et maintient les signature pour la zone en régénérant les records RRSIG quand ils approchent de la date d'expiration. À no-resign, named signe les records mais la maintenance des signatures est désactivées.
max-zone-ttl number Spécifie une valeur maximale de TTL permise. Une zone avec un TTL supérieur est rejeté. C'est utile pour DNSSEC parce qu'en régénérant une nouvelle DNSKEY, l'ancienne clé doit rester disponible jusqu'à ce que les records RRSIG aient expirés des caches. Cette option garantie que le plus grand TTL dans le zone ne sera pas supérieur.
zone-statistics full | terse | none; ] Le serveur collecte des données statistiques dans toutes les zones (full), ou des statistiques minimales (terse). les statistiques sont disponible via les canaux de statistiques, ou rndc stats
automatic-interface-scan yes_or_no Si supporté par l'OS, rescanne automatiquement les interfaces réseaux quand les adresses sont ajoutées et supprimées
allow-new-zones yes_or_no à Yes, les zones peuvent être ajoutées en temps réel, via rndc addzone ou supprimées, via rndc delzone.
auth-nxdomain yes_or_no à yes, le bit AA est toujours mis dans les réponses NXDOMAIN, même si le serveur n'est pas autoritatif. Utile pour de très vieux serveur DNS.
memstatistics yes_or_no Écris les statistiques mémoire dans le fichier spécifié par memstatistics-file en quittant.
dialup dialup_option à yes, le serveur traite toutes les zones comme si elle faisaient du transfert de zone via un lien dialup. cette option peut également être spécifiée dans une vue ou une zone. Si la zone est master, alors le serveur envoie une demande NOTIFY à tous les esclaves. Cela déclenche la vérification du numéro de série de la zone dans l'esclave. Le jeu de serveur qui reçoivent le NOTIFY peut être contrôlé par notify et also-notify. Si la zone est esclave ou stub, le serveur supprime les requêtes de refresh régulières, et les effectue seulement quand heartbeat-interval expire en plus d'envoyer des requêtes NOTIFY. à 'notify', permet d'envoyer seulement des messages NOTIFY, 'notify-passive' envoie des message NOTIFY et supprime les requêtes de refresh normales quand heartbeat-interval expire, et passive qui désactive simplement le traitement refresh normal.

dialup mode | normal refresh | heart-beat refresh | heart-beat notify
no (default)________yes_______________no_______________no____________
yes_________________no________________yes______________yes___________
notify______________yes_______________no_______________yes___________
refresh_____________no________________yes______________no____________
passive_____________no________________no_______________no____________
notify-passive______no________________no_______________yes___________

flush-zones-on-shutdown yes_or_no Quand un serveur de nom quitte du à un SIGTERM, vide ou non les écritures de zone en attente.
minimal-responses yes_or_no à yes, en générant les réponses le serveur ajoute seulement les enregistrements de l'autorité, et les sections additionnelles quand elle sont requises. Améliore les performances du serveur.
notify yes_or_no | explicit | master-only à yes, les messages DNS NOTIFY sont envoyés quand une zone est changée. Les messages sont envoyés aux serveurs listés dans les enregistrements NS de la zone, excepté le serveur maître identifié dans le champ SOA MNAME), et à tous serveurs listés dans l'option also-notify. à 'master-only', notifie sont envoyés seulement pour les zones maître. à 'explicit', notifie seulement les serveurs explicitement listés dans also-notify. Peut également être spécifié dans les déclarations de zone.
notify-to-soa yes-on-no à yes, ne vérifie pas les serveurs de nom dans le RRset NS avec les SOA MNAME. Parfois, un slave est listé dans le SOA MNAME, cette option permet de lui envoyer les messages NOTIFY
recursion yes_or_no à yes, le serveur fait le travail nécessaire pour les requêtes récursives DNS et répondre au client. Noter que à no, cela n'empêche pas les clients d'avoir les réponses dans le cache. Le caching peut se produire à cause d'opérations interne du serveur, tel que les recherche d'adresses NOTIFY.
request-nsid yes_or_no à yes, une option EDNS(0) NSID (Name Server Identifier) vide est envoyée avec toutes les requêtes aux serveurs de noms autoritatifs durant la résolution itérative. Si le serveur autoritatif retourne une options NSID dans sa réponse, son contenu est loggé dans la catégorie resolver au niveau info.
request-sit yes_or_no à yes, une option EDNS SIT (Source Identity Token) est envoyée avec la requête. Si le résolveur à précédemment échoué à parler au serveur, le SIT retourné dans la précédente transaction est envoyée. C'est utilisé par le serveur pour déterminer si le résolveur lui a parlé avant.
sit-secret yes_or_no à yes, c'est une clé secrète partagée utilisée pour générer et vérifier les options EDNS SIT dans un cluster anycast. à no, génère un secret aléatoirement au démarrage.
rfc2308-type1 yes_or_no à yes, le serveur envoie des records NS avec le SOA pour les réponses négatives.
provide-ixfr yes_or_no détermine si le serveur local, agissant comme maître, répond avec un transfert de zone incrémental. à yes, le transfert incrémental est fournis quand c'est possible.
request-ixfr yes_or_no Détermine si le serveur local, agissant comme slave, demande des transferts de zone incrémental.
additional-from-auth, additional-from-cache yes_or_no Contrôle le comportement d'un serveur autoritatif en répondant aux requêtes qui ont des données additionnelles, ou en suivant les chaînes CNAME et DNAME. Quand ces 2 options sont a yes, et qu'une requête est répondue depuis une donnée autoritative, la section data additionnelle de la réponse sera remplie en utilisant les données d'autres zones autoritatives et depuis le cache. Éviter la recherche depuis ces données additionnelles accélèrent les opérations du serveur. Ces options sont prévues pour être utilisée uniquement dans les serveurs ou vues authoritative-only, Tenter de les mettre à no sans spécifier recursion no cause le serveur à ignorer les options et logger un message d'erreur.
filter-aaaa-on-v4 yes_or_no | break-dnssec Cette option est disponible si bind9 est compilé avec --enable-filter-aaaa. Aide la transition ipv4 vers ipv6 en ne donnant pas d'adresses IPv6 aux clients DNS sauf s'ils ont des connections IPv6 Internet.
filter-aaaa-on-v6 Identique, excepté qu'il filtre les réponses AAAA aux requêtes depuis les clients ipv6 au lieu des clients IPv4. Pour filtrer toutes les réponses, définir les 2 options à yes.
ixfr-from-differences yes_or_no | master | slave À yes, si le serveur charge une nouvelle version d'une zone maître depuis son fichier de zone ou reçois une nouvelle version d'un fichier slave via un transfert de zone, il compare la nouvelle version à la précédente et calcule un jeu de différences. La différence est ainsi loggées dans le fichier journal de la zone pour que les changements puissent être transmis aux slaves comme transfert de zone incrémental. accepte également 'master' et 'slave' aux niveaux vue et option qui permet d'activer pour toutes les zones master ou slaves respectivement.
multi-master yes_or_no Devrait être activé quand il y'a plusieurs serveurs maîtres pour une zone. À yes, named ne log rien quand le numéro de série dans le maître est inférieur à ce que named à.
dnssec-enable yes_or_no Active le support DNSSEC dans named.
dnssec-validation yes_or_no Active la validation DNSSEC dans named.
dnssec-accept-expired yes_or_no Accepte les signatures expirées en vérifiant les signature DNSSEC. Définir à yes laisse named vulnérable aux attaques replay.
querylog yes_or_no Spécifie si le query logging devrait être démarré quand named démarre. Si querylog n'est pas spécifié, alors le query logging est déterminé par la présence de la catégorie de logging queries.
check-names ( master | slave | response ) ( warn | fail | ignore ); Cette option est utilisée pour restreindre le jeu de caractère et syntaxe de certains nom de domaine dans les fichiers master et/ou dans les réponse DNS reçues du réseaux. Le défaut varie en accord avec l'utilisation. Pour les zones maître, le défaut est 'fail'. Pour les zones slave, le défaut est 'warn'. Pour les réponses reçues, le défaut est 'ignore'.
check-dup-records ( warn | fail | ignore ); Vérifie les zones maître pour les enregistrements qui sont traités différemment par DNSSEC mais sémantiquement égaux en DNS plain.
check-mx ( warn | fail | ignore ); vérifie si l'enregistrement MX apparaît pour référrer à une IP.
check-wildcard yes_or_no Cette option est utilisée pour vérifier les wildcard non terminals, qui sont généralement le résultat d'une erreur de compréhension de l'algorithme de matching wildcard. Cette option affectes les zones master.
check-integrity yes_or_no Effectue des vérifications d'intégrité avant de charger une zone. Cela vérifie que les records MX et SRV réfèrent à une adresse. Pour les records MX et SRV, seuls les noms d'hôte dans la zone sont vérifiés. Pour les records NS, seuls les noms sous le top of zone sont vérifiés.
check-mx-cname ( warn | fail | ignore ); définis le comportement de check-integrity en vérifiant les enregistrement MX qui réfèrent à des CNAME.
check-srv-cname ( warn | fail | ignore ); définis le comportement de check-integrity en vérifiant les enregistrement SRV qui réfèrent à des CNAME.
check-sibling yes_or_no vérifie également si des sibling glue existent.
check-spf ( warn | fail | ignore ); définis le comportement de check-integrity en vérifiant que 2 formes de record Sender Policy Framework (records TXT commençant avec 'v=spf1' et SPF) existent ou non.
zero-no-soa-ttl yes_or_no En retournant des réponses autoritatives négatives au demandes SOA, définis le TTL de l'enregistrement SOA retourné dans la section autorité à 0.
zero-no-soa-ttl-cache yes_or_no En cachant une réponse négative d'une requête SOA définis le TTL à zero.
update-check-ksk yes_or_no à yes, vérifie le bit ksk dans chaque clé pour déterminer comment la clé devrait être utilisée en générant les RRSIGs pour une zone sécurisée. Normalement, les clés de signature de zone (c'est à dire les clés avec le bit ksk mis) sont utilisés pour signer toute la zone, alors que les clé de signature de clé (les clés avec le bit ksk mis) sont seulement utilisé pour signer le RRset DNSKEY dans la zone apex. Cependant, si cette option est à no, le bit ksk est ignoré, les ksk sont traités comme s'ils étaient des ZSK et sont utilisé pour signer toute la zone.
dnssec-dnskey-kskonly yes_or_no a yes et update-check-ksk à yes, seul les clés de signature de clé seront utilisées pour signer les RRset DNSKEY dans la zone apex. Les clés de signature de zone seront utilisées pour signer le reste de la zone, mais par le RRset DNSKEY.
dnssec-loadkeys-interval Quand une zone est configurée avec auto-dnssec maintain, sont dépôt de clé doit être vérifié périodiquement pour voir si une nouvelle clé a été ajoutée ou la métadonnée de timing d'une clé existant a été mise à jours. cette option définis la fréquence de vérification automatique, en minute. défaut: 60 (de 1 à 1440)
try-tcp-refresh yes_or_no Tente de rafraîchir la zone en utilisant TCP si les requêtes UDP échouent. pour compatibilité avec BIND8.
dnssec-secure-to-insecure yes_or_no Permet à une zone dynamique de transiter d'une zone sécure à une zone insécure en supprimant tous les records DNSKEY.

Forwarding

   Les options suivantes peuvent être utilisées pour créer un grand cache sur quelques serveurs, réduisant le trafique sur les liens vers les serveurs de nom externe. Le forwarding peut également être utilisé pour autoriser les requêtes par les serveur qui n'ont pas d'accès directe à Internet, mais souhaitent rechercher des noms exterieurs. Le forwarding se produit seulement dans le requêtes pour lequels le serveur n'est pas autoritatif et n'a pas de réponse dans son cache.

forward only | first Cette option est seulement significative si une liste de forwarders n'est pas vide. À 'first', le serveur requête les forwarders en premier, puis recherche la réponse par lui-même. À 'only', le serveur ne requête que les forwarders.
forwaders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; Spécifie les adresses IP à utiliser pour le forwarding. Peut également être configuré par domaine.

Dual-stack

   Les serveurs dual-stack sont utilisés comme serveurs de secours pour fonctionner lors de problèmes d'accessibilité du à un manque de support pour IPv4 ou IPv6 sur la machine hôte.

dual-stack-servers Spécifie les noms d'hôte ou adresses des machine avec un accès aux transport IPv4 et IPv6. Si un nom d'hôte est utilisé, le serveur doit être capable de résoudre le nom en utilisant seulement le transport qu'il a. Si la machine est dual-stackée, alors cette option n'a pas d'effet sauf si un accès à un transport a été désactivé.

Contrôle d'accès

  

allow-notify Spécifie quels hôtes sont autorisés à notifier ce serveur, un slave, ou les changements de zone en plus des zones maître. Peut également être spécifié dans une déclaration zone. Est seulement significatif pour une zone slave. Si non spécifié, traite les messages de notification seulement pour les zones maître.
allow-query Spécifie quels hôtes sont autorisés à requêter le serveur. Peut également être spécifié dans une zone.
allow-query-on Spécifie quelles adresses locales peuvent accepter les requêtes DNS. Uniquement vérifié pour les requêtes qui sont permises par allow-query. Peut être spécifié dans les déclarations de zone
allow-query-cache Spécifie quels hôtes peuvent obtenir les réponses depuis les caches. défaut: localnets; localhosts;
allow-recursion spécifie quels hôtes sont autorisés à faire de requêtes récursives sur ce serveur. défaut: localnets; localhosts;
allow-recursion-on Spécifie quelles adresses peuvent accepter des requêtes récursives
allow-update Spécifie quels hôtes sont autorisés à envoyer des mises à jours Dynamic Updates pour les zones maître.
allow-update-forwarding Spécifie quels hôtes sont autorisés à envoyer des mises à jours Dynamic Uptates aux zones esclaves à forwarder au master. défaut none, peut être any, d'autres valeurs n'ont pas de sens, vu que c'est de la responsabilité du contrôle d'accès sur serveur maître de gérer ça.
allow-transfer Spécifie quels hôtes sont autorisés à recevoir les transferts de zone du serveur. Peut également être spécifié dans les zones.
blackhole Spécifie une liste d'adresses auxquelles le serveur refusera de répondre ou d'utiliser pour résoudre une requête.
filter-aaaa Spécifie une liste d'adresses auxquelles filter-aaaa-on-v4 s'applique
no-case-compress Spécifie une liste d'adresses qui nécessite que les réponses utilisent la compression sensible à la casse. Cet ACL peut être utilisée quand named doit travailler avec des client qui ne sont pas compliant rfc1034.
resolver-query-timeout La quantité de temps que le resolver passe à tenter de répondre à une requête récursive avant d'échouer, en seconde.

Interfaces

listen-on [ port port_num ] { acl_name; } Les interfaces et ports que le serveur utilise pour répondre aux requêtes peut être spécifié ici. Il s'agit d'adresses IPv4. Plusieurs déclarations peuvent être définis.
listen-on-v6 [ port port_num ] { acl_name; } Idem pour les adresse IPv6

adresse de requête

query-source address * port *; Si le serveur ne connaît pas la réponse à une question, il va requêter d'autres serveurs de nom. Cette option spécifie l'adresse et le port utilisé pour de telles requêtes.
query-source-v6 address * port *; Idem pour ipv6

Transfert de zone

   Bind a des mécanismes en place pour faciliter les transferts de zone et définir des limites sur la quantité de charge de ce transfert dans le système.

also-notify Définis une liste d'adresses de serveurs de nom à qui envoyer également les messages NOTIFY. Cela permet de s'assurer que les copies de zone sont rapidement convergés sur les serveurs Stealth. Optionnellement un port peut être spécifié avec chaque adresse. Une clé TSIG optionnelle peut aussi être spécifié avec chaque adresse. Les listes masters peuvent être utilisées pour cela.
max-transfer-time-in termine les transferts de zone entrants durant plus longtemps que ce délai en minute. défaut 120, max 40320
max-transfer-idle-in termine les transferts de zone entrants qui ne progressent plus depuis ce délai en minute. défaut 60
max-transfer-time-out termine les transferts de zone sortants durant plus longtemps que ce délai en minute. défaut 120, max 40320
max-transfer-idle-out termine les transferts de zone sortants qui ne progressent plus depuis ce délai en minute. défaut 60
serial-query-rate Les serveurs slave vont périodiquement requêter le master pour trouver si des numéros de zone ont changés. Chacune de ces requêtes utilise une quantité de bande passante du serveur slave. Cette options définis le nombre maximum de requêtes envoyées pas secondes. défaut: 20. contrôle également le taux d'émission des messages NOTIFY pour les zone slave et master.
transfer-format Les transferts de zone peuvent être envoyés en 2 format: one-answer et many-answers. Ce dernier est plus efficace mais seulement supporté par les serveur DNS récents.
transfers-in Nombre maximum de transferts de zone entrants qui peuvent être lancés simultanément. défaut: 10. Des valeurs plus grandes peuvent accelerer la convergence des zones slaves, mais augmente la charge du système.
transfer-out Le nombre maximum de transferts de zone sortants qui peuvent être lancés simultanément. défaut: 10. Les demandes de transfert de zone au delà de cette limite seront refusés.
transfer-per-ns Le nombre maximum de transferts de zone qui peuvent être lancés simultanément depuis un serveur de nom. défaut: 2. Des valeurs plus grandes peuvent accelerer la convergence des zones slaves, mais augmente la charge du système.
transfer-source Détermine quelles adresses locales seront utilisée pour les connections IPv4 TCP utilisées pour le transfert de zone entrant sur le serveur. Détermine également l'adresse IPv4 et optionnellement le port UDP, utilisé pour les requêtes de rafraîchissement et le forward de mises à jours dynamique.
transfer-source-v6 Idem, sur ipv6
notify-source Détermine quelles adresses locale source, et optionnellement le port UDP sera utilisé pour envoyer des messages NOTIFY. Cette adresse doit apparaître dans les masters de zone des serveurs slave ou dans une clause allow-notify.
notify-source-v6 idem, sur IPv6

Liste de ports UDP

use-v4-udp-ports { range 1024 65535; }; Spécifie les port udp à utiliser pour récupérer la plage de ports éphémère.
use-v6-udp-ports { range 1024 65535; }; idem sur ipv6
avoid-v4-udp-ports {}; Permet d'excluse une plage de port
avoid-v6-udp-ports {}; Idem sur ipv6

Limites de ressource système

   Les ressources du système utilisées par le serveur peuvent être limités. la valeur 'unlimited' désactive la limite, ou utilise la valeur maximale.

coresize Taille maximum d'un core dump.
datasize quantité maximum de données mémoire que le serveur peut utiliser. C'est une limite hard.
files Nombre maximum de fichiers que le serveur peut ouvrir simultanément.
stacksize Quantité de mémoire de pile que le serveur peut utiliser.

Limites de ressources serveur

   Les options suivantes définissent les limites de la consommation de ressource du serveur forcés en interne par le serveur au lieur de l'OS

max-journal-size Définis une taille maximum pour chaque fichier journal. À l'approche de cette taille, les anciens enregistrements sont supprimés. max 2Go.
recursive-clients nombre maximum de recherches récursives simultanés que le serveur effectue à la demande des client. défaut: 1000. Chaque client récursif utilise environ 20Ko de mémoire.
tcp-clients Nombre maximum de connexions TCP simultanés que le serveur accepte. défaut: 100
reserved-sockets Nombre de descripteur de fichier réservés pour TCP, stdio, etc. Doit être suffisant pour couvrir le nombre d'interfaces utilisées par named. Défaut 512, minimum 128, et maximum = maxsockets -128
max-cache-size Quantité de mémoire à utiliser pour le cache du serveur, en octets. Quand la limite est atteinte, les enregistrement expirent prématurément.
tcp-listen-queue Profondeur de file d'écoute. défaut et minimum: 10. Si le kernel support le filtre d'acceptation 'dataready', cela contrôle également combien de connexions TCP seront mis en file dans l'espace kernel en attendant que les données soient acceptés.

Intervals de tâches périodique

heartbeat-interval Le serveur effectue des tâche de maintenance de zone pour toutes les zones marquées dialup. défaut: 60minutes.
interface-interval Le serveur scanne la liste des interfaces réseaux. défaut 60minutes
statistics-interval les statistiques du serveur sont loggés à cet interval. défaut: 60minutes

topology

Quand le serveur choisi un serveur de nom à requêter depuis une liste de serveurs de noms, il préfère celui qui est topologiquement plus proche de lui. La déclaration topologie prend une liste d'adresse, et l'interprète. La position d'une adresse dans la liste indique sa distance. Le premier élément de la liste est le plus proche.
topology {
    10/8;
    !1.2.3/24;
    { 1.2/16; 3/8; };
};

sortlist

   La réponse à une requête DNS peut consister de plusieurs RR formant un RRset. Le serveur de nom va normalement retourner les RR dans le RRset dans un ordre indéterminé. Le résolveur client devrait réarranger les RR de manière approprié, en utilisant les adresses dans le réseau local de préférence. Cependant, tous les résolveurs ne peuvent pas le faire correctement. Quand un client utilise un serveur local, le trie peut être effectué dans le serveur, basé sur l'adresse du client. Cela nécessite seulement de configurer les serveurs de nom, pas les clients.

   La déclaration sortlist prend une address_match_list et l'interprète même plus spécifiquement que la déclaration topology. Chaque déclaration doit être un address_match_list avec 1 ou 2 éléments. Le premier élément ( qui peut être uni adresse IP, un préfixe IP, un nom d'ACL ou une address_match_list imbriquée ) de chaque liste est vérifiée avec l'adresse sources de la requête jusqu'à ce qu'un match est trouvé.

   Une fois l'adresse source de la requête est matchée, si la déclaration contient seulement un élément, l'élément est placé en premier dans la réponse. Si la déclaration est une liste de 2 éléments, le second élément est traité de la même manière que dans la déclaration topology. Chaque liste a une distance assignée et l'adresse dans la réponse avec la distance minimum est placée au début de la réponse.

   Dans l'exemple suivant, les requêtes reçues depuis une des adresses de l'hôte lui-même aura une réponse d'adresse préférés sur le réseau local. Ensuite, les adresses préférées sont les adresses dans le réseaux 192.168.1/24, puis soit 192.168.2/24 soit 192.168.3/24. Les requêtes reçues depuis un hôte dans le réseaux 192.168.4/24 ou 192.168.5/24 auront d'autres adresse sur ces réseaux. Les requêtes reçues depuis un hôte dans le réseau 192.168.1/24 va préférer d'autres adresses dans le réseaux 192.168.2/24 et 192.168.3/24. Les requêtes reçues depuis un hôte dans le réseau 192.168.4/24 ou 192.168.5/24 vont seulement préférer d'autres adresse dans leur réseau respectif.


sortlist {
    // IF the local host THEN first fit on the following nets
    { localhost;
        { localnets;
            192.168.1/24;
            { 192.168.2/24; 192.168.3/24; }; }; };
    // IF on class C 192.168.1 THEN use .1, or .2 or .3
        { 192.168.1/24;
            { 192.168.1/24;
                { 192.168.2/24; 192.168.3/24; }; }; };
    // IF on class C 192.168.2 THEN use .2, or .1 or .3
    { 192.168.2/24;
        { 192.168.2/24;
            { 192.168.1/24; 192.168.3/24; }; }; };
    // IF on class C 192.168.3 THEN use .3, or .1 or .2
    { 192.168.3/24;
        { 192.168.3/24;
            { 192.168.1/24; 192.168.2/24; }; }; };
    // IF .4 or .5 THEN prefer that net
    { { 192.168.4/24; 192.168.5/24; };
    };
};

rrset-order

Quand plusieurs records sont retournés dans une réponse, il peut être utile de configurer l'ordre des records placés dans la réponse. La déclaration rrset-order permet la configuration de l'ordre des records dans une réponse à plusieurs records. Un orders_spce est définis comme suit:
[class class name] [type type name] [name "domain name"] order ordering

   Si aucune classe n'est spécifiée, le défaut est ANY. Si aucun type n'est spécifié, le défaut est ANY. Si aucun nom n'est spécifié, le défaut est '*'. Les valeurs légales pour ordering sont:

fixed Les records sont retournés dans l'ordre qui ont été définis dans le fichier de zone.
random Les records sont retourné aléatoirement
cyclic Les records sont retourné en cycle round-robin.

Exemple:
rrset-order {
    class IN type A name "host.example.com" order random;
    order cyclic;
};

   Force les réponse pour les enregistrements de type A dans la classe IN ayant host.example.com comme suffixe, à toujours être retourné aléatoirement. Les autres enregistrements sont retournés de manière cyclique. Si plusieurs rrest-order sont spécifiés, ils ne sont pas combinés, le dernier s'applique.

tuning

lame-ttl Définis le ttl de mise en cache des serveur lame. 0 désactive la mise en cache. défaut 600, max 1800. Contrôle également la quantité de temps d'erreurs de validation DNSSEC qui sont mis en cache.
max-ncache-ttl Pour réduire le trafic réseau et augmenter les performances, le serveur stocke les réponses négative. Cette option définis la durée de rétention pour ces réponses dans le serveur en secondes. défaut: 10800, max 7 jours.
min-roots Nombre minimum de serveurs root requis pour une requête pour que les serveurs root soient acceptés. défaut: 2
sig-validity-interval Spécifie le nombre de jours dans le future d'expiration des signatures DNSSEC générées automatiquement en résultat à des mises à jours dynamique. Il y a un second champs optionnel qui spécifie le délai de régénération des signatures avant expiration. Le second champ est spécifié en jours si l'interval de base est supérieur à 7 jours, sinon il est spécifié en heures. l'interval de base est de 30 jours, donnant une re-signature de 7 jours et demi. Les valeurs maximum sont 10ans. 3660 jours.
sig-signing-nodes Spécifie le nombre maximum de nœuds à examiner dans chaque quantum en signant une zone avec une nouvelle DNSKEY. défaut: 100
sig-signing-signatures Spécifie un seuil de signatures qui vont terminer le traitement d'un quantum en signant une zone avec une nouvelle DNSKEY. défaut: 10.
sig-signing-type Spécifie un type RDATA privé à utiliser en génèrent des records d'état de signature. défaut: 65534. Il est prévu que ce paramètre soit supprimé une fois qu'il y aura un type standard.
min-refresh-time, max-refresh-time, min-retry-time, max-retry-time Ces options contrôlent le comportement du serveur en rafraîchissant une zone ou en retentant des transferts échoués. Généralement, les valeurs SOA pour la zone sont utilisés, mais ces valeurs sont définis par le master, donnant au serveur administrateurs de serveurs slaves peut de contrôle sur leur contenu. Ces options permettent à l'administrateur de définir un temps et tentative de refresh minimum et maximum soit par zone, par vue, ou globalement. Ces options sont valides pour les zone slaves et stub. Défaut: 300, 2419200, 500, 1209600
edns-udp-size Définis la taille de tampon UDP EDNS initial, pour contrôler la taille des paquets reçus depuis les serveurs autoritatifs en réponse aux requêtes récursives. Les valeurs valides sont 512 à 4096 (défaut). changer cette valeur est d'avoir des réponses udp à passer via des firewalls qui bloquent les paquets fragmentés et/ou bloquent les paquets DNS UDP supérieurs à 512 octets.
max-udp-size Définis la taille maximale de message UDP EDNS à envoyer en octets. Les valeurs valides sont 512 à 4096 (défaut). baisser cette valeur encourage l'utilisation de TCP.
masterfile-format Spécifie le format de fichier des fichiers de zone. Défaut: text, qui est la représentation standard, excepté pour les zone slaves, dans lequel le défaut est raw. Les autres formats sont à générer avec named-compilezone, ou dumpé par named.
clients-per-query, max-clients-per-query Définis la valeur initiale (minimal) et le nombre maximum de clients récursifs simultanément pour une requête données (‹qname,qtype,qclass›) que le serveur va accepter avant de de supprimer les clients additionnels. défaut: 10 et 100.
notify-delay Délai en secondes entre l'envoie d'un jeu de messages notify pour une zone. défaut 5
max-rsa-exponent-size Taille de l'exposant RSA maximum, en bits, qui sera accepté lors de la validation. de 35 à 4096bits.
prefetch Quand une requête est reçue pour une données cachée qui va expirer sous peut, named peut rafraîchir la donnée depuis le serveur autoritatif immédiatement, s'assurant que le cache a toujours la réponse disponible. Cette option spécifie le TTL déclencheur: quand une donnée en cache avec un TTL inférieur est rencontré durant le traitement d'une requête, elle sera rafraîchie. de 1 à 10secondes. Un second argument optionnel spécifie le TTL eligible: la plus petite valeur TTL original qui sera accepté pour un record pour être éligible au prefetching. Ce TTL doit être d'au moins 6 secondes de plus que le TTL déclencheur. défaut: 2 9.

informations de zones

   Le serveur fournis des informations de diagnostique utile au travers de zone intégrées sous le pseudo domain bind, dans la classe CHAOS. Ces zones font partie d'une vue intégrée de classe CHAOS qui est séparée de la vue par défaut de classe IN. La plupart des options de configurations globales s'appliquent à cette vue, mais certaines sont remplacées en interne: notify-recursion et allow-new-zones sont toujours à no, et rate-limit est mis pour autoriser 3 réponses par seconde. Pour désactiver ces zones, utiliser les options ci-dessous, ou cacher la vue CHAOS en définissant une vue explicite de classe CHAOS qui matche tous les clients.

version La version du serveur à reporter via une requête du nom version.bind avec le type TXT de classe CHAOS. Le défaut est le vrai numéro de version est utilisé. spécifier version none désactive le traitement des requêtes.
hostname Le nom d'hôte que le serveur devrait reporter via une requête du nom hostname.bind avec le type TXT, classe CHAOS. hostname none désactive le traitement des requêtes
server-id L'id que le serveur devrait reporter en reçevant une requête NSID (Name Server IDentifier), ou une requête de nom ID.SERVER avec le type TXT, classe CHAOS. server-id none le désactive.

Zones vide embarquées

   named a des zones embarquées vides. Ces zones devraient normalement être répondues localement et ne devraient pas être envoyées vers les serveurs root. En particulier, ces zones couvrent les espaces de nom pour les adresses des rfc1918, rfc5193, rfc5737 et rfc6598. Elles incluent l'espace de nom inversé pour les adresse locales IPv6, et les adresse de lien local, l'adresse de bouclage IPv6 et les adresses IPv6 inconnues. La liste actuelle est:

10.IN-ADDR.ARPA
16.172.IN-ADDR.ARPA
17.172.IN-ADDR.ARPA
18.172.IN-ADDR.ARPA
19.172.IN-ADDR.ARPA
20.172.IN-ADDR.ARPA
21.172.IN-ADDR.ARPA
22.172.IN-ADDR.ARPA
23.172.IN-ADDR.ARPA
24.172.IN-ADDR.ARPA
25.172.IN-ADDR.ARPA
26.172.IN-ADDR.ARPA
27.172.IN-ADDR.ARPA
28.172.IN-ADDR.ARPA
29.172.IN-ADDR.ARPA
30.172.IN-ADDR.ARPA
31.172.IN-ADDR.ARPA
168.192.IN-ADDR.ARPA
64.100.IN-ADDR.ARPA
65.100.IN-ADDR.ARPA
66.100.IN-ADDR.ARPA
67.100.IN-ADDR.ARPA
68.100.IN-ADDR.ARPA
69.100.IN-ADDR.ARPA
70.100.IN-ADDR.ARPA
71.100.IN-ADDR.ARPA
72.100.IN-ADDR.ARPA
73.100.IN-ADDR.ARPA
74.100.IN-ADDR.ARPA
75.100.IN-ADDR.ARPA
76.100.IN-ADDR.ARPA
77.100.IN-ADDR.ARPA
78.100.IN-ADDR.ARPA
79.100.IN-ADDR.ARPA
80.100.IN-ADDR.ARPA
81.100.IN-ADDR.ARPA
82.100.IN-ADDR.ARPA
83.100.IN-ADDR.ARPA
84.100.IN-ADDR.ARPA
85.100.IN-ADDR.ARPA
86.100.IN-ADDR.ARPA
87.100.IN-ADDR.ARPA
88.100.IN-ADDR.ARPA
89.100.IN-ADDR.ARPA
90.100.IN-ADDR.ARPA
91.100.IN-ADDR.ARPA
92.100.IN-ADDR.ARPA
93.100.IN-ADDR.ARPA
94.100.IN-ADDR.ARPA
95.100.IN-ADDR.ARPA
96.100.IN-ADDR.ARPA
97.100.IN-ADDR.ARPA
98.100.IN-ADDR.ARPA
99.100.IN-ADDR.ARPA
100.100.IN-ADDR.ARPA
101.100.IN-ADDR.ARPA
102.100.IN-ADDR.ARPA
103.100.IN-ADDR.ARPA
104.100.IN-ADDR.ARPA
105.100.IN-ADDR.ARPA
106.100.IN-ADDR.ARPA
107.100.IN-ADDR.ARPA
108.100.IN-ADDR.ARPA
109.100.IN-ADDR.ARPA
110.100.IN-ADDR.ARPA
111.100.IN-ADDR.ARPA
112.100.IN-ADDR.ARPA
113.100.IN-ADDR.ARPA
114.100.IN-ADDR.ARPA
115.100.IN-ADDR.ARPA
116.100.IN-ADDR.ARPA
117.100.IN-ADDR.ARPA
118.100.IN-ADDR.ARPA
119.100.IN-ADDR.ARPA
120.100.IN-ADDR.ARPA
121.100.IN-ADDR.ARPA
122.100.IN-ADDR.ARPA
123.100.IN-ADDR.ARPA
124.100.IN-ADDR.ARPA
125.100.IN-ADDR.ARPA
126.100.IN-ADDR.ARPA
127.100.IN-ADDR.ARPA
0.IN-ADDR.ARPA
127.IN-ADDR.ARPA
254.169.IN-ADDR.ARPA
2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
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.0.IP6.ARPA
1.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
8.B.D.0.1.0.0.2.IP6.ARPA
D.F.IP6.ARPA
8.E.F.IP6.ARPA
9.E.F.IP6.ARPA
A.E.F.IP6.ARPA
B.E.F.IP6.ARPA

   Les zones vides sont définissables au niveau de la vue et s'appliquent seulement aux vues de classe IN. Désactiver les zones vides sont seulement hérités depuis les options s'il n'y a pas de zones vide désactivée spécifiée au niveau de la vue. Pour remplacer la liste des zones désactivées, on peut désactiver la zone root au niveau de la vue, par exemple: disable-empty-zone ".";

empty-server spécifie que le nom de serveur va apparaître dans le record SOA retourné pour les zones vide. Si rien n'est spécifié, le nom de zone est utilisé
empty-contact Spécifie quel nom de contact appparaît dans le record SOA retourné pour les zones vides. Si rien n'est spécifié, '.' est utilisé
empty-zones-enables Active ou désactive les zones vide. Par défaut, elles sont activés.
disable-empty-zone Désactive des zones vide individuellement. Par défaut aucune n'est désactivée. Peut être spécifié plusieurs fois.

cache de section additionnel

   Le cache additionnel, également appelée acache, est un cache interne pour améliorer les performances de réponse de bind9. Quand une section de cache additionnel est activé, bind9 cache un raccourci interne vers la section additionnelle pour chaque réponse RR. Noter que acache est un mécanisme interne à bind9.

   Le cache additionnel ne change par le contenu de la réponse excepté l'ordre RRset de la section additionnelle, mais peut améliorer les performances de réponse significativement. C'est particulière efficace pour les serveurs autoritatifs pour une zone qui a de nombreuses délégations avec de nombreux glue RR.

   Pour obtenir un maximum de performances, définir additional-from-cache à no est recommandé, vu que l'implémentation actuelle de acache ne crée pas de raccourcis depuis le cache de données DNS. Un désavantage de acache est qu'il nécessite plus de mémoire. La cache de section additionnel a un effet mineur sur l'ordre RRset dans la section additionnelle. sans acache, l'ordre cyclic est effectif pour la section additionnelle aussi bien que les sections réponse et autorité. Cependant, le acache fixe l'ordre quand il est caché la première fois, et le même ordre est concervé ensuite sans regarder le rrset-order. L'effet devrait être minime vu qu'un RRset dans la section additionnelle ne contient généralement que peu de RR dans lequel l'ordre n'est pas important.

acache-enable active le acache. défaut: no.
acache-cleaning-interval en minute. Vide les entrées gelées du cache. défaut: 60
max-acache-size Taille maximale en Mo à utiliser pour le acache.

filtrage de contenu

   bind9 fournis la capacité de filtrer les réponses DNS des serveurs DNS externes contenant certains types de données dans le section réponse. Spécifiquement, il peut rejeter les adresses A ou AAAA si les adresses correspondantes matchent un liste donnée de l'option deny-answer-addresses. Il peut également rejeter les CNAME ou DNAME si le nom alias matche la liste de deny-answer-aliases. Si l'option namelist est spécifiée avec except-from, les records dont le nom requêté matche la liste seront acceptés sans regarder le filtre. De même, si le nom alias est un sous-domaine de la zone correspondancte, le filtre deny-answer-aliases ne s'applique pas; par exemple, même si example.com est spécifié pour deny-answer-aliases, www.example.com. CNAME xxx.example.com. retourné par un serveur example.com sera accepté.

deny-answer-addresses { address_match_list } [ except-from { namelist } ];] Définis les adresses ignorées et les exceptions
deny-answer-aliases { namelist } [ except-from { namelist } ]; Rejète les records CNAME ou DNAME si le nom alias matche la liste

Ré-écriture de zone de stratégie de réponse (RPZ)

   Bind9 inclus un mécanisme limité pour modifier les réponses DNS pour les demandes analogues aux blacklists DNS des anti-spams. Les réponses peuvent être changées pour refuser l'existance des domaines (NXDOMAIN), refuser l'existance d'adresses IP pour les domaines (NODATA), ou contenir d'autres adresses IP ou données.

   Les zones de stratégie de réponse sont nommés dans l'option response-policy pour la vue ou dans les options globales. Les zones de stratégie de réponse sont ordinairement des zones contenant des RRsets qui peuvent être requêtés normalement si autorisés. Il est généralement mieux de restreindre ces requête avec quelque-chose comme allow-query { localhost; };

   Une options response-policy peut supporter plusieurs zones de stratégie. Pour maximiser les performances, un arbre radix est utilisé pour rapidement identifier les zones de stratégie de réponse qui déclenchent le match de la requête actuelle. Cela impose une limite de 32 dans le nombre de zones de stratégie dans une simple response-policy. 5 déclencheurs de stratégie peuvent être encodés dans les records RPZ.

RPZ-CLIENT-IP Les records IP sont pilotés par l'adresse IP du client DNS. Ces déclencheurs sont encodés en records qui ont leur propre owner name qui sont des sous-domaines de rpz-client-ip relativisés au nom d'origine de la zone de stratégie et encode une adresse ou un block d'adresse. Les adresses IPv4 sont représentées sous la forme prefixlength.B4.B3.B2.B1.rpz-ip. Les préfixes IPv4 doivent être entre 1 et 32. Tous les 4 octets doivent être présents. B4 est la représentation décimale d'au moins un octet significatif de l'adresse IPv4 dans in-addr.arpa.

           Les adresses IPv6 sont encodés dans un format similaire: prefixlength.W8.W7.W6.W5.W4.W3.W2.W1.rpz-ip. Chaque Wx est un chiffre hexadécimal représentant 16bits de l'adresse IPv6. Tous les mots doivent être présents, excepté les 0 consécutifs, remplacés par .zz, analogue à '::'.

QNAME Les enregistrements de stratégie QNAME sont déclenchés par les recherches de nom des requêtes et cible des enregistrement CNAME résolu pour générer la réponse. Le nom d'un QNAME est le nom de recherche relativisé à la zone de stratégie.
RPZ-IP Les déclencheurs sont des adresses IP dans un enregistrement A ou AAA dans la section ANSWER d'une réponse. Ils sont encodé comme les déclencheurs client-IP excpté comme sous-domaine rpz-ip
RPZ-NSDNAME Déclenche les correspondance de nom des serveurs autoritatfs pour les demande de nom, un parent du nom de la recherche, un CNAME pour le nom recherché, ou un parent du CNAME. Ils sont encodés comme sous-domaine de rpz-nsdname relativisé au nom d'origine RPZ. NSIP déclenche la correspondance des adresses IP dans les RRsets A et AAAA pour les domaines qui peuvent être vérifiés avec les records de stratégie NSDNAME.
RPZ-NSIP Déclencheurs encodés comme déclencheurs IP excepté comme sous-domaine rpz-nsip. Les déclencheurs NSDNAME et NSIP sont vérifiés seulement avec les noms avec au moins min-ns-dots points. La valeur par défaut est 1 pour exclure les TLD.

   Les réponses sont vérifiés avec toutes les zones de stratégie de réponse, donc 2 ou plusieurs enregistrements de stratégie peuvent être déclenchés par une réponse. Parce que les réponse DNS sont ré-écrites en accord avec au moins un record de stratégie, un simple record encodant une action (autre que les actions DISABLED) doit être choisi. Les déclencheurs ou les records qui les encodent sont choisis pour la ré-écriture dans l'ordre suivant:

- Choisis le record déclenché dans la zone qui apparaît en premier dans l'option response-policy
- Préfère CLIENT-IP à QNAME à IP à NSDNAME à NSIP dans une simple zone
- Avec les déclencheurs NSDNAME, préférer le déclencheur qui matche le nom le plus petit dans l'ordre DNSSEC
- Avec IP ou NSIP, préfère le déclencheur avec le préfixe le plus long
- Avec les déclencheurs avec la même longueur de préfixe, préfère le déclencheur IP ou NSIP qui matche la plus petite adresse IP.

   Quand le traitement d'une réponse est redémarré pour résoudre des records DNAME ou CNAME et qu'un record de stratégie n'a pas été déclenché, tous les zones de stratégie de réponse sont consultées de nouveau pour les noms DNAME ou CNAME et les adresses.

   Les jeux de record RPZ sont tout type de record DNS excepté DNAME ou DNSSEC qui encode les actions ou réponses aux recherches individuelles. N'importe quelle de ces stratégies peuvent être utilisées avec n'importe quel de ces déclencheurs. Par exemple, bien que TCP-only est communément utilisé avec les déclencheurs client-IP, il peut être utilisé avec n'importe quel déclencheur pour forcer l'utilisation de TCP pour les réponses avec les owner names dans une zone.

PASSTHRU Stratégie de liste blanche spécifiée par un CNAME dont la cible est rpz-passthru. Il impose de ne pas ré-écrire la réponse.
DROP Startégie de blacklist spécifiée par un CNAME dont la cible est rpz-drop. Détruit la réponse. Rien n'est envoyée au client DNS.
TCP-Only Stratégie spécifiée par un CNAME dont la cible est rpz-tcp-only. Il change les réponses UDP en réponses DNS tronquées qui nécessite que le client DNS retente avec TCP. Utilisé pour limiter les attaque DNS reflection.
NXDOMAIN Le domaine indéfini est encodé par un CNAME dont la cible est '.'
NODATA Le jeu vide de RR est spécifié par un CNAME dont la cible est '*.'. Il ré-écrit la réponse à NODATA ou ANCOUNT=1
Local Data Un jeu de records DNS ordinaire peut être utilisé pour répondre aux requêtes. Les recherches pour les types de records qui ne sont pas dans le jeu sont répondus avec NODATA. Une forme spécifiale est un wildcard "*.example.com".

   Toutes les action spécifiées dans les records individuels dans un zone de stratégie peuvent être remplacés avec une clause policy dans l'option response-policy. Une organisation utilisant une zone de stratégie fournie par une autre organisation peut utiliser ce mécanisme pour rediriger les domaines vers sont propre walled garden.

GIVEN Indique 'ne pas remplacer mais effectuer l'action spécifiée dans la zone.
DISABLED La stratégie ne fait rien mais log ce qui aurait été fait.
PASSTHRU, DROP, TCP-Only, NXDOMAIN, NODATA Remplace avec la stratégie par record
CNAME domain Force tous les records RPZ à agir comme s'ils étaient des records 'cname domain'

   Par défaut, les actions encodés dans une zone de stratégie de réponse sont appliqués seulement aux requêtes qui demande une récursion. Ce défaut peut être changé pour une simple zone de stratégie ou pour toutes les zones de stratégie dans une vue avec une clause recursive-only no;.Cette fonctionnalité est utile pour servir les même fichiers de zone en et hors d'un cloud rfc1918 et utilisant RPZ pour supprimer les réponses qui contiendrait des valeurs rfc1918 dans la vue.

   Également, par défaut les action RPZ sont appliquées seulement aux demandes DNS qui ne demandent pas de métadonnées DNSSEC ou quand aucun record DNSSEC n'est disponible pour le nom demandé. Cela peut être changé avec break-dnssec yes.

   Aucun enregistrement DNS n'est nécessaire pour un déclencheur QNAME ou Client-IP. Le nom ou l'adresse IP elle-même est suffisante, donc en principe le nom recherché ne doit pas être recherché récursivement. Cependant, ne pas résoudre le nom demandé peut fuiter le fait que la ré-écriture est utilisé et que ce nom est listé dans une zone de stratégie. Pour empêcher cette fuite d'information, par défaut toute récursion nécessaire pour une recherche est faite avant tout déclencheur. Vu que les domaines listés ont souvent des serveurs autoritatifs lents, ce mode peut être couteux en temps. l'option qname-wait-recurse no; change ce mode. L'option n'affecte pas les déclencheurs QNAME ou client-ip dans les zones de stratégie listées après d'autres zones contenant des déclencheurs IP, NSIP et NSDNAME, parce que la réponse serait dépendant des records RRSIG trouvés durant la résolution. Utiliser cette option peut causer des erreurs de réponse tels que SERVFAIL.

   Le TTL d'un record modifié par les stratégie RPZ sont définis depuis le TTL de l'enregistrement dans le zone de stratégie. Il est limité à la valeur maximum. max-policy-ttl change ce maximum.

Par exemple, on peu utiliser cette déclaration:
response-policy { zone "badlist"; };
et cette déclaration de zone:
zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };

Avec ce fichier de zone:
$TTL 1H
@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
NS LOCALHOST.
; QNAME policy records. There are no periods (.) after the owner names.
nxdomain.domain.com CNAME . ; NXDOMAIN policy
*.nxdomain.domain.com CNAME . ; NXDOMAIN policy
nodata.domain.com CNAME *. ; NODATA policy
*.nodata.domain.com CNAME *. ; NODATA policy
bad.domain.com A 10.0.0.1 ; redirect to a walled garden
AAAA 2001:2::1
bzone.domain.com CNAME garden.example.com.

; do not rewrite (PASSTHRU) OK.DOMAIN.COM
ok.domain.com CNAME rpz-passthru.

; redirect x.bzone.domain.com to x.bzone.domain.com.garden.example.com
*.bzone.domain.com CNAME *.garden.example.com.

; IP policy records that rewrite all responses containing A records in 127/8
; except 127.0.0.1
8.0.0.0.127.rpz-ip CNAME .
32.1.0.0.127.rpz-ip CNAME rpz-passthru.

; NSDNAME and NSIP policy records
ns.domain.com.rpz-nsdname CNAME .
48.zz.2.2001.rpz-nsip CNAME .

; blacklist and whitelist some DNS clients
112.zz.2001.rpz-client-ip CNAME rpz-drop.
8.0.0.0.127.rpz-client-ip CNAME rpz-drop.

; force some DNS clients and responses in the example.com zone to TCP
16.0.0.1.10.rpz-client-ip CNAME rpz-tcp-only.
example.com CNAME rpz-tcp-only.
*.example.com CNAME rpz-tcp-only.

Limiter le taux de réponses

   Les réponses UDP excessivement identique peuvent être contrôlés en configurant un rate-limit dans une déclaration options ou view. Ce mécanisme réduit l'utilisation des serveurs autoritatifs pour amplifier les attaques DOS. Les réponses Short truncated (TC=1) peuvent être envoyées pour fournir des réponse limitées aux clients légitimes dans une plage d'adresses IP forgés. Les clients légitimes réagissent aux réponses tronquée ou supprimées en retentant avec UDP ou TCP, respectivement.

   Ce mécanisme est prévu pour les serveurs autoritatifs. Il peut être utilisé sur les serveurs récursifs mais peut ralentir les applications telles que les serveurs SMTP et les client HTTP qui recherche souvent le même domaine.

   rate-limite utilise un schéma de crédit ou un jeton. Chaque combinaison de réponse et client identique a un compte conceptuel qui apprend un nombre spécifié de crédits chaque seconde. Les réponses sont supprimées ou tronquées quand le compte est négatif. Les réponses sont suivies dans une fenêtre de temps qui est de 15 secondes par défaut, mais peut être changé avec l'option window (1 à 3600). Le compte ne peut plus être positif que sur la limite par seconde ou plus que la limite window. Quand le nombre spécifié de crédits pour une classe de réponse est 0, ces réponses ne sont plus limitées.

   Les notions de réponse identique et de client DNS pour le rate-limit ne sont pas simple. Tous les réponses à un block d'adresse sont comptés comme si c'était un seul client. Les longueurs de préfixe des blocks d'adresse sont spécifiées dans ipv4-prefix-lengh (défaut 24) et ipv6-prefix-lengh (défaut: 56).

   Tout réponse non-vide pour un nom de domaine valide (qname) et type d'enregistrement (qtype) sont identique et on une limite spécifiée par l'option responses-per-second (c à d, réponses par seconde avec seulement un simple argument et aucun modifieurs additionnels.) Le défaut est 0, qui indique qu'il ne devrait pas y avoir de limite. Les réponse vide (NODATA) sont limitées par nodata-per-second. Les demandes pour un ou tous les sous-domains indéfinis d'un domaine valide résultent en erreurs NXDOMAIN, et sont identiques sans regarder le type de recherche. Elles sont limitées par nxdomains-per-second. Cela contrôle certaines attaques en utilisant des noms aléatoire, mais peuvent être relaxés et désactivé dans les serveurs qui attendent de nombreuses réponses NXDOMAIN, tels que depuis les blacklists anti-spam. Les référants et délégations au serveur d'un domaine donné sont identique et sont limités par referrals-per-second.

   Les réponses générées depuis les wildcards locaux sont comptés et limités comme s'ils étaient pour le nom de domain parent. Cela contrôle le flooding en utilisant les noms aléatoires.

   Toutes les requêtes qui résultent en erreurs DNS autre que NXDOMAIN, tel que SERVFAIL et FORMERR, sont identique sans regarder le nom recherché (qname) ou le type de records (qtype). Cela contrôle les attaques utilisant les requêtes invalides ou distantes, sur les serveurs autoritatif cassés. Par défaut la limite sur les erreurs est la même que responses-per-second, mais peut être changé avec errors-per-seconds.

   De plus, jusqu'à 4 options responses-per-seconde (en plus de la valeur de base) peuvent être configurés, avec des paramètres additionnels pour indiquer qu'elles s'appliquent aux réponses plus grande qu'une taille donnée, ou avec un facteur d'amplification plus grand qu'une valeur donnée. Le paramètre size définis la taille de réponse DNS minimum qui va déclencher l'utilisation de cette option respones-per-second. Le paramètre ratio définis la taille de réponse / taille de requêtes DNS minimum qui sont dans la plage, à 2 décimales. Ces limites sélective sont appliquées après que d'autres limite aient été appliquées et ne s'appliquent qu'aux réponses positives.

Par exemple:
rate-limit {
    responses-per-second 10;
    responses-per-second size 1100 5;
};

Indique que les réponse devraient être limitées à 10 par seconde pour les réponses jusqu'à 1099 octets, mais seulement 5 par seconde pour les réponses plus grandes. Cette configuration:
rate-limit {
    responses-per-second 10;
    responses-per-second ratio 7.25 5;
    responses-per-second ratio 15.00 2;
};

Indiquent que les réponses devraient être limitées à 10 par seconde si le facteur d'amplification est inférieur à 7,25, 5 par seconde s'il est supérieur à 7,25, mais inférieur à 15, 2 par seconde au-delà de 15. Les tailles et ratios peuvent être utilisées ensemble, par exemple:
rate-limit {
    responses-per-second 10;
    responses-per-second size 1000 ratio 5.00 5;
    responses-per-second ratio 10.00 2;
};

   Cette configuration va limiter à 5 par seconde si le ration est au-dessus de 5 ou la taille supérieur à 1000.

   De nombreuses attaques utilisant DNS impliquent les requêtes UDP avec des adresses sources forgées. Limiter le taux empêche l'utilisation de BIND9 pour flooder un réseaux avec des réponses à des requêtes avec les adresses source forgées, mais pourrait laisser un tier bloquer les réponses aux requêtes légitimes. Il y a un mécanisme qui peut répondre à certaines requêtes légitimes d'un client dont l'adresse a été forgée dans un flood. Définir slip à 2 (son défaut) cause toute autre requête UDP à être répondue avec une réponse tronquée. La petite taille et la fréquence réduite, et le manque d'amplification des réponses les rendent moins attractive pour les attaques DOS. slip doit être entre 0 et 10. Une valeur de 0 ne tronque pas les réponses, elles sont supprimée. Une valeur de 1 cause chaque réponse à être tronquées. Certaines réponses d'erreurs telles que REFUSED ou SERVFAIL ne peuvent être remplacée avec des réponses tronquées et sont fuitées au taux slip.

   Quand le taux de recherche excède qps-scale, les valeurs responses-per-second, errors-per-second, nxdomains-per-second et all-per-second sont réduite par le ratio du taux courant à la valeur qps-scale. Cette fonctionnalité peut resserer les défense durant les ataques. Par exemple, avec qps-scale 250; responses-per-second 20; et un taux de recherche total de 1000 recherches par secondes pour toutes les recherches de tous les clients DNS incluant via TCP, alors la limite de réponses/seconde effective change à (250/1000)*20 ou 5. Les réponses envoyées via TCP ne sont pas limitées mais sont comptées pour calculer le taux de recherche par seconde.

   La clause optionnelle domain spécifie l'espace de nom auquel les limites s'appliquent. Il est possible d'utiliser différentes limites pour différents noms en spécifiant plusieurs blocks rate-limit.

   Les limiteurs de taux pour différents espaces de nom maintiennent des compteurs séparés: si, par exemple, il y a une déclaration rate-limit pour com et un autre pour example.com, les recherche correspondant à example.com ne seront pas débitée avec le limiteur de taux pour com. Si une déclaration rate-limit ne spécifie pas un domain, elle s'applique au domaine root et donc tout l'espace de nom DNS.

   Les communautés de clients DNS peuvent avoir leur propre limites en plaçant les déclaration rate-limit dans le vues. un rate-limit dans une vue remplace et ne complète pas les déclarations globales. Les clients DNS dans une vue peuvent être exemptés de limites avec la clause exempt-clients.

   Les réponses UDP de tous type peuvent être limitées avec la phrase all-per-second. Cette limite devrait être au moins 4 fois plus grand que les autres limites. La taille maximum de la table utilisée pour tracker les recherches et limiter le taux de réponses est définis avec max-table-size. Chaque entrée dans la table est entre 40 et 80 octets. La table a besoin approximativement d'autant d'entrée que le nombre de requêtes reçues par secondes. Défaut: 20000. Pour réduire le coût du démarrage à froid, min-table-size (défaut: 500) peut définir la taille minimum. Utiliser log-only yes; pour tester les paramètre de limitation sans supprimer une seul recherche.

server


server ip_addr[/prefixlen] {
    [ bogus yes_or_no ; ]
    [ provide-ixfr yes_or_no ; ]
    [ request-ixfr yes_or_no ; ]
    [ request-nsid yes_or_no ; ]
    [ request-sit yes_or_no ; ]
    [ edns yes_or_no ; ]
    [ edns-udp-size number ; ]
    [ nosit-udp-size number ; ]
    [ max-udp-size number ; ]
    [ transfers number ; ]
    [ transfer-format ( one-answer | many-answers ) ; ]]
    [ keys { string ; [ string ; [...]] } ; ]
    [ transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ query-source [ address ( ip_addr |    *    ) ]
        [ port ( ip_port |    *    ) ] [dscp ip_dscp] ; ]
    [ query-source-v6 [ address ( ip_addr |    *    ) ]
        [ port ( ip_port |    *    ) ] [dscp ip_dscp] ; ]
    [ use-queryport-pool yes_or_no; ] //obsolete
    [ queryport-pool-ports number; ] //obsolete
    [ queryport-pool-updateinterval number; ] //obsolete
};

   La déclaration server définis les caractéristiques à associer avec un serveur de noms distant. Si un préfixlen est spécifié, cela permet de couvrir plusieurs serveurs. La déclaration server peut se produire en haut de la configuration ou dans une déclaration view. Si une vue contient des déclarations server, les déclarations server dans la configuration globale sont ignorés pour la vue.

bogus yes_or_no Si un serveur distant donne de mauvaises données, empêche d'autres requêtes sur lui. défaut: no
provide-ixfr yes_or_no détermine si le serveur local, agissant comme maître, répond avec un transfert de zone incrémental. à yes, le transfert incrémental est fournis quand c'est possible.
request-ixfr yes_or_no Détermine si le serveur local, agissant comme slave, demande des transferts de zone incrémental.
request-nsid yes_or_no à yes, une option EDNS(0) NSID (Name Server Identifier) vide est envoyée avec toutes les requêtes aux serveurs de noms autoritatifs durant la résolution itérative. Si le serveur autoritatif retourne une options NSID dans sa réponse, son contenu est loggé dans la catégorie resolver au niveau info.
request-sit yes_or_no à yes, une option EDNS SIT (Source Identity Token) est envoyée avec le requête. Si le résolveur à précédemment échoué à parler au serveur, le SIT retourné dans la précédente transaction est envoyée. C'est utilisé par le serveur pour déterminer si le résolveur lui a parlé avant.
edns yes_or_no Détermine si le serveur local tente d'utiliser EDNS en communiquant avec le serveur distant. défaut: yes
edns-udp-size Définis la taille de tampon UDP EDNS initial, pour contrôler la taille des paquets reçus depuis les serveurs autoritatifs en réponse aux requêtes récursives. Les valeurs valides sont 512 à 4096 (défaut). changer cette valeur est d'avoir des réponses udp à passer via des firewalls qui bloquent les paquets fragmentés et/ou bloquent les paquets DNS UDP supérieurs à 512 octets.
max-udp-size Définis la taille maximale de message UDP EDNS à envoyer en octets. Les valeurs valides sont 512 à 4096 (défaut). baisser cette valeur encourage l'utilisation de TCP.
nosit-udp-size number Définis la taille maximum de réponses UDP qui seront envoyées pour les requêtes sans un token d'identité valide.
transfers number Limite le nombre de transfert de zones entrantes simultané du serveur spécifié. Non spécifié, la limite est définis en accord avec transfers-per-ns
transfer-format Les transferts de zone peuvent être envoyés en 2 format: one-answer et many-answers. Ce dernier est plus efficace mais seulement supporté par les serveur DNS récents.
keys { string ; [ string ; [...]] } Identifie une clé définie par la déclaration key, à utiliser pour une transaction TSIG en dialoguant avec le serveur distant.
transfer-source Détermine quelles adresses locales seront utilisée pour les connections IPv4 TCP utilisées pour le transfert de zone entrant sur le serveur. Détermine également l'adresse IPv4 et optionnellement le port UDP, utilisé pour les requêtes de rafraîchissement et le forward de mises à jours dynamique.
transfer-source-v6 Idem, sur ipv6
query-source address * port *; Si le serveur ne connaît pas la réponse à une question, il va requêter d'autres serveurs de nom. Cette option spécifie l'adresse et le port utilisé pour de telles requêtes.
query-source-v6 address * port *; Idem pour ipv6
[SECTION] name="statistics-channels" table="codes" imbrication="0"
statistics-channels {
 [ inet ( ip_addr | * ) [ port ip_port ]  [ allow { address_match_list } ]; ]
 [ inet ...; ] };

   Les déclaration statistics-channels déclarent des canaux de communication à utiliser par les administrateurs système pour obtenir un accès à des informations de statistiques du serveur de nom. Cette déclaration est prévue pour être flexible pour supporter plusieurs protocoles de communication dans le future, mais actuellement seul l'accès HTTP est supporté. Il nécessite que bind9 soit compilé avec libxml2 et/ou json-c. Ces déclarations sont acceptées même s'il est construit sans la librairie, mais les accès HTTP vont échouer dans erreur.

   Un canal de contrôle inet est un socket TCP en écoute au port spécifié sur l'ip spécifiée qui peut être une adresse IPv4 ou IPv6. La tentative d'ouvrir un canal de statistique est restreinds par la clause allow. Les statistiques sont disponible dans divers formats et vues en fonction de l'URI utilisée pour y accéder. Le format xml est accéssible via http://127.0.0.1:8888/ ou ‹http://127.0.0.1:8888/xml. Un fichier CSS est inclus qui peut formater les statistiques XML en tables quand il est lus dans un navigateur, et en graphique avec Google Charts API quand il est utilisé avec un navigateur javascript.

http://127.0.0.1:8888/xml/v2› schéma xml v2
http://127.0.0.1:8888/xml/v3› schéma xml v3
http://127.0.0.1:8888/xml/v3/status Sous-jeu de statistiques (uptime et dernières reconfigurations)
http://127.0.0.1:8888/xml/v3/server Statistiques serveur et résolveur
http://127.0.0.1:8888/xml/v3/zones Statistiques de zone
http://127.0.0.1:8888/xml/v3/net status réseau et socket
http://127.0.0.1:8888/xml/v3/mem statistiques mémoire
http://127.0.0.1:8888/xml/v3/tasks statistiques des tâches
http://127.0.0.1:8888/json Jeu complet de statistiques au format JSON
http://127.0.0.1:8888/json/v1/status Sous-jeu de statistiques (uptime et dernières reconfigurations) JSON
http://127.0.0.1:8888/json/v1/server Statistiques serveur et résolveur au format JSON
‹http://127.0.0.1:8888/json/v1/zones Statistiques de zone au format JSON
‹http://127.0.0.1:8888/json/v1/net status réseau et socket au format JSON
‹http://127.0.0.1:8888/json/v1/mem statistiques mémoire au format JSON
‹http://127.0.0.1:8888/json/v1/tasks statistiques des tâches au format JSON

trusted-keys


trusted-keys {
    string number number number string ;
    [ string number number number string ; [...]]
};

   La déclaration trusted-keys définis les racines de sécurité DNSSEC. Une racide de sécurité est définie quand la clé publique pour une zone non-authoritative est connue, mais ne peut pas être obtenue de manière sécurisée via DNS, soit parce que c'est une zone root DNS ou parce que sa zone parent n'est pas signée. Une fois qu'une clé a été configurée comme clé de confiance, elle est traitée comme si elle avait été validée. Le résolveur tente la validation DNSSEC sur toutes les données dans les sous-domaines d'un security root.

   Toutes les clés (et zones correspondantes) listées dans trusted-keys sont réputés exister sans regarder de quelle zone parent il s'agit. Similairement pour toutes les clés listées dans trusted-keys, elles sont utilisées pour valider le RRsed DNSKEY. Le RRset DS du parent ne sera pas utilisé.

   Cette déclaration peut contenir plusieurs clés, chacune consistant du nom de domaine de la clé, les flags, protocoles, algorithmes, et la représentation base64 de la clé. La déclaration trusted-keys peut être définis globalement, ou dans une vue. Si les 2 sont en place, elles sont additives.

managed-keys


managed-keys {
    name initial-key flags protocol algorithm key-data ;
    [ name initial-key flags protocol algorithm key-data ; [...]]
};

   la déclaration managed-keys, tout comme trusted-keys, définis les DNSSEC security roots. La différence est que managed-keys peut être conservé à jour automatiquement, sans l'intervention de l'opérateur. Cette déclaration possède un mot clé supplémentaire, initial-key, contenant la clé d'initialisation.

view


view view_name
    [class] {
    match-clients { address_match_list };
    match-destinations { address_match_list };
    match-recursive-only yes_or_no ;
    [ view_option; ...]
    [ zone_statement; ...]
};

   La déclaration view implémente le split-dns. Elle possède ses propres zones. Les zones disponible dans une vue ne sont accessible que pour cette vue. De nombreuses options de la déclaration options peuvent également être utilisées dans une déclaration vue.

zone

zone master:
zone zone_name [class] {
    type master;
    [ allow-query { address_match_list }; ]
    [ allow-query-on { address_match_list }; ]
    [ allow-transfer { address_match_list }; ]
    [ allow-update { address_match_list }; ]
    [ update-check-ksk yes_or_no; ]
    [ dnssec-dnskey-kskonly yes_or_no; ]
    [ dnssec-loadkeys-interval number; ]
    [ update-policy local | { update_policy_rule [...] }; ]
    [ also-notify { ip_addr [port ip_port] [dscp ip_dscp] ;
        [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ check-names (warn|fail|ignore) ; ]
    [ check-mx (warn|fail|ignore) ; ]
    [ check-wildcard yes_or_no; ]
    [ check-spf ( warn | fail | ignore ); ]
    [ check-integrity yes_or_no ; ]
    [ dialup dialup_option ; ]
    [ file string ; ]
    [ masterfile-format (text|raw|map) ; ]
    [ journal string ; ]
    [ max-journal-size size_spec; ]
    [ forward (only|first) ; ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ ixfr-base string ; ]
    [ ixfr-from-differences yes_or_no; ]
    [ ixfr-tmp-file string ; ]
    [ request-ixfr yes_or_no ; ]
    [ maintain-ixfr-base yes_or_no ; ]
    [ max-ixfr-log-size number ; ]
    [ max-transfer-idle-out number ; ]
    [ max-transfer-time-out number ; ]
    [ notify yes_or_no | explicit | master-only ; ]
    [ notify-delay seconds ; ]
    [ notify-to-soa yes_or_no; ]
    [ pubkey number number number string ; ]
    [ notify-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ zone-statistics full | terse | none; ]
    [ sig-validity-interval number [number] ; ]
    [ sig-signing-nodes number ; ]
    [ sig-signing-signatures number ; ]
    [ sig-signing-type number ; ]
    [ database string ; ]
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ key-directory path_name; ]
    [ auto-dnssec allow|maintain|off; ]
    [ inline-signing yes_or_no; ]
    [ zero-no-soa-ttl yes_or_no ; ]
    [ serial-update-method increment|unixtime; ]
    [ max-zone-ttl number ; ]
};

zone slave:
zone zone_name [class] {
    type slave;
    [ allow-notify { address_match_list }; ]
    [ allow-query { address_match_list }; ]
    [ allow-query-on { address_match_list }; ]
    [ allow-transfer { address_match_list }; ]
    [ allow-update-forwarding { address_match_list }; ]
    [ dnssec-update-mode ( maintain | no-resign ); ]
    [ update-check-ksk yes_or_no; ]
    [ dnssec-dnskey-kskonly yes_or_no; ]
    [ dnssec-loadkeys-interval number; ]
    [ dnssec-secure-to-insecure yes_or_no ; ]
    [ try-tcp-refresh yes_or_no; ]
    [ also-notify [port ip_port] [dscp ip_dscp] { ( masters_list | ip_addr
        [port ip_port]
        [dscp ip_dscp]
        [key key] ) ; [...] }; ]
    [ check-names (warn|fail|ignore) ; ]
    [ dialup dialup_option ; ]
    [ file string ; ]
    [ masterfile-format (text|raw|map) ; ]
    [ journal string ; ]
    [ max-journal-size size_spec; ]
    [ forward (only|first) ; ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ ixfr-base string ; ]
    [ ixfr-from-differences yes_or_no; ]
    [ ixfr-tmp-file string ; ]
    [ maintain-ixfr-base yes_or_no ; ]
    [ masters [port ip_port] [dscp ip_dscp] { ( masters_list | ip_addr
        [port ip_port]
        [dscp ip_dscp]
        [key key] ) ; [...] }; ]
    [ max-ixfr-log-size number ; ]
    [ max-transfer-idle-in number ; ]
    [ max-transfer-idle-out number ; ]
    [ max-transfer-time-in number ; ]
    [ max-transfer-time-out number ; ]
    [ notify yes_or_no | explicit | master-only ; ]
    [ notify-delay seconds ; ]
    [ notify-to-soa yes_or_no; ]
    [ pubkey number number number string ; ]
    [ transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source-v6 (ip6_addr | *)
        [port ip_port]
        [dscp ip_dscp] ; ]
    [ use-alt-transfer-source yes_or_no; ]
    [ notify-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ notify-source-v6 (ip6_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ zone-statistics full | terse | none; ]
    [ sig-validity-interval number [number] ; ]
    [ sig-signing-nodes number ; ]
    [ sig-signing-signatures number ; ]
    [ sig-signing-type number ; ]
    [ database string ; ]
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ key-directory path_name; ]
    [ auto-dnssec allow|maintain|off; ]
    [ inline-signing yes_or_no; ]
    [ multi-master yes_or_no ; ]
    [ zero-no-soa-ttl yes_or_no ; ]
};

zone hint
zone zone_name [class] {
    type hint;
    file string ;
    [ delegation-only yes_or_no ; ]
    [ check-names (warn|fail|ignore) ; ] // Not Implemented.
};

zone stub
zone zone_name [class] {
    type stub;
    [ allow-query { address_match_list }; ]
    [ allow-query-on { address_match_list }; ]
    [ check-names (warn|fail|ignore) ; ]
    [ dialup dialup_option ; ]
    [ delegation-only yes_or_no ; ]
    [ file string ; ]
    [ masterfile-format (text|raw|map) ; ]
    [ forward (only|first) ; ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ masters [port ip_port] [dscp ip_dscp] { ( masters_list | ip_addr
        [port ip_port]
        [dscp ip_dscp]
        [key key] ) ; [...] }; ]
    [ max-transfer-idle-in number ; ]
    [ max-transfer-time-in number ; ]
    [ pubkey number number number string ; ]
    [ transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ transfer-source-v6 (ip6_addr | *)
        [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source (ip4_addr | *) [port ip_port] [dscp ip_dscp] ; ]
    [ alt-transfer-source-v6 (ip6_addr | *)
        [port ip_port] [dscp ip_dscp] ; ]
    [ use-alt-transfer-source yes_or_no; ]
    [ zone-statistics yes_or_no ; ]
    [ database string ; ]
    [ min-refresh-time number ; ]
    [ max-refresh-time number ; ]
    [ min-retry-time number ; ]
    [ max-retry-time number ; ]
    [ multi-master yes_or_no ; ]
};

zone static-stub:
zone zone_name [class] {
    type static-stub;
    [ allow-query { address_match_list }; ]
    [ server-addresses { [ ip_addr ; ... ] }; ]
    [ server-names { [ namelist ] }; ]
    [ zone-statistics yes_or_no ; ]
};

zone forward:
zone zone_name [class] {
    type forward;
    [ forward (only|first) ; ]
    [ forwarders { [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
    [ delegation-only yes_or_no ; ]
};

zone redirect:
zone "." [class] {
    type redirect;
    file string ;
    [ masterfile-format (text|raw|map) ; ]
    [ allow-query { address_match_list }; ]
    [ max-zone-ttl number ; ]
};

zone delegation-only:
zone zone_name [class] {
    type delegation-only;
};

zone référencée:
zone zone_name [class] {
    [ in-view string ; ]
};

types de zone

master Le serveur a une copie maître des données de la zone et est capable de fournir des réponse autoritatives pour lui.
slave une zone esclave est un réplica de la zone maître.
stub Une zone stub est similaire à une zone esclave, excepté qu'elle ne réplique que les records NS de la zone maître et non la zone entière. Les zones stub ne sont pas standard. Non recommandé.
static-stub Similaire à une zone stub, mais les données de zone sont configurés statiquement.
forward Une zone forward est une manière de configurer un forwarding par domaine. Une zone forward peut contenir des déclations forward et/ou forwarders.
hint Le jeu de serveurs de nom racine est spécifié en utilisant ce type de zone.
redirect Les zones redirect sont utilisées pour fournir des réponses aux requêtes quand la résolution normale retourne NXDOMAIN. Seul une zone redirect est supportée par vue.
delegation-only C'est utilisé pour forcer le status de delegation-only des zones d'infrastructure (COM, NET, ORG). Toute réponse reçue sans délégation implicite ou explicite dans la section authority seront traité comme NXDOMAIN. Ne s'applique pas dans l'apex de zone.

Classes

   Le nom de la zone peut optionnellement être suivi par une classe. Si une classe n'est pas spécifiée, la classe IN est assumée. La classe hesiod est nommée pour un service d'information du projet Athena du MIT. Elle est utilisée pour partager des informations sur diverses bases de données, tels que les utilisateurs, groupes, imprimantes, etc. HS est synonyme de hesiod. Un autre développement du MIT est chaosnet, un protocole LAN créé dans les années 1970.

options de zone

update-policy local | { update_policy_rule [...] }; voir plus bas
also-notify n'a de sens que si notify est actif pour cette zone. Le jeu de machines qui vont recevoir un messages DNS NOTIFY pour cette zone.
check-names ( fail | warn | ignore ) Cette option est utilisée pour restreindre le jeu de caractères et la syntaxe de certains noms de domaine dans les fichiers master et/ou les réponses DNS reçues du réseaux
database Spécifie le type de base à utiliser pour stocker les données de zone. La chaîne est interprétée comme une listed de mots séparés par un espace blank. Le premier mot identifie le type de base, et les autres mots sont passés en argument à la base à interpréter. (défaut: rbt), la base red-black-tree in-memory natif de bind9. Cette base n'a pas d'argument.
delegation-only Ce flag ne s'applique qu'aux zones forward, hint, et stub. À yes, toutes les zones sont également traitées comme si elle étaient également de type delegation-only.
forward ( only | first ) N'a de sens que si la zone a une liste forwarders. only échoue si le forwarding échoue, first, tente dans ce cas une résolution normale.
forwarders non spécifié dans une zone forward, aucun forwarding n'est fait.
journal permet d'écraser le nom de fichier du journal par défaut.
zone-statistics yes_or_no à yes, le serveur conserve des informations de statistique pour cette zone, qui peuvent être dumpé dans le statistics-file définis dans les options du serveur.
server-address dans les zone static-stub, liste d'adresses IP pour lesquelles les requêtes devraient être envoyés en résolution récursive pour la zone.
server-names dans les zone static-stub, liste les noms de domaine des serveurs de nom qui agissent comme serveurs autoritatifs.
ixfr-from-differences Noter que les choix master et slave ne sont pas disponible au niveaux des zones.
auto-dnssec ( allow | maintain | off ) Les zones configurées pour le DNS dynamique peuvent également utiliser cette option pour permettre différents niveaux de gestion de clé DNSSEC automatique. 'allow' permet aux clés d'être mises à jours et de resigner la zone quand l'utilisateur émet la commande rndc sign zonename. 'maintain' est identique, mais ajuste également automatiquement les clés DNSSEC de la zone en accord avec les métadonnées de timing de clé. 'off' désactive la fonctionnalité
serial-update-method (increment | unixtime ) Les zones configurées pour le DNS dynamique peuvent utiliser cette option pour définir la méthode de mise à jours qui sera utilisée pour le numéro de série de la zone dans le SOA.
inline-signing à yes, active la signature "bump in the wire" d'une zone, où une zone non-signée y est transférée et chargée depuis le disque et une version signée de la zone est servie, avec possiblement, un numéro de série différent. désactivé par défaut.

Stratégie de mise à jours dynamique

   BIND9 supporte 2 méthodes alternatives d'acceptation de clients pour effectuer des mises à jours dynamique dans une zone, configuré par les options allow-update et update-policy, respectivement.

   allow-update fonctionne de la même manière que dans les versions précédentes de bind. Il donne aux clients la permission de mettre à jours les enregistrements de n'importe quel nom dans la zone.

   update-policy permet un contrôle plus fin sur les mises à jours permises. Un jeu de règles est spécifié, où chaque règle autorise ou refuse l'accès pour un ou plusieurs noms à mettre à jours. Si la mise à jours dynamique nécessite que le message soit signé, l'identité du signataire peut être déterminé.

   Les règles sont spécifiées dans l'option de zone update-policy, et sont seulement significatifs pour les zones maître. Quand la déclaration update-policy est présente, allow-update ne doit pas être présent. La déclaration update-policy examine seulement le signataire du message; l'adresse sources n'est pas utilisée.

   Il y a une règle update-policy prédéfinie qui peut être activée avec la commande update-policy local. Activer cette règle génère une clé de session TSIG et la place dans un fichier (par défaut: /var/run/named/session.key, le nom de la clé local-ddns, et l'algorithm HMAC-SHA256, peut être changé avec les options session-‹xxx›), et autorise cette clé à mettre à jours la zone.

   Un client fonctionnant sur le système local, avec les permissions appropriées, peut lire ce fichier et l'utiliser pour signer les demandes de mise à jours. Cette règle est équivalente à update-policy { grant local-ddns zonesub any; };

   La commande nsupdate -l envoie des demandes de mise à jours à l'hôte local, et les signes en utilisant a clé de session.

D'autres définitions ressemblent à:
( grant | deny ) identity nametype [ name ] [ types ]

   Chaque règle autorise ou refuse les privilèges. Une fois qu'un message matche une règle, l'opération est immédiatement autorisé ou refusé et aucune autre règle n'est examinée. Une règle est matchée quand le signataire matche le champs identity, le nom matche le champ name avec le champs nametype, et le type matche les types spécifiés dans le champs type.

   Aucun signataire n'est requis pour tcp-self et 6to4-self cependant la conversion du mappage inverse / préfixe doit matcher le champ identity.

   Le champ identity spécifie un nom ou un nom wildcard. Normalement, c'est le nom d'une clé TSIG utilisée pour signer le demande de mise à jour. Quand un échange TKEY a été utilisé pour créer un secret partagé, l'identité de la clé partagée est la même que l'identité de la clé utilisée pour authentifier l'échange TKEY. TKEY est également la méthode de négociation utilisée par GSS-TSIG, qui établis une identité que est le principal Kerberos du client, tel que 'user@host.domain'. Quand le champ identity spécifie un nom wildcard, il est sujet à l'expansion DNS, donc la règle s'applique à plusieurs identités. Le champs identity doit contenir un nom fqdn.

   Pour les types de nom krb5-self, ms-self, krb5-subdomain, et ms-subdomain, le champ identity spécifie le royaume Windows ou Kerberos auquel la machine appartient.

   Le champs nametype a 13 valeurs:

name Exact match. Cette réglè est identique au contenu du champ name.
subdomain Cette règle matche quand le nom à mettre à jours est un sous-domaine au, ou identique au, contenu du champ name.
zonesub similaire, excepté qu'elle matche quand le nom à mettre à jours est un sou-domaine de la zone dans laquelle update-policy apparaît.
wildcard Le champs nom est sujet à expansion DNS, et cette règle matche quand le nom à mettre à jours est une expansion valide
self Cette règle matche quand le nom à mettre à jours matche le contenu de identity. Le champ name est ignoré mais devrait être identique à identity.
selfsub Similaire à self excepté que les sous-domaines de self sont également mis à jours.
selfwild Similaire à self excepté que seul les sous-domaines de self sont mis à jours.
ms-self Cette règle prend un principal de machine Windows (machine@REALM) et le convertit en machine.realm.
ms-subdomain Cette règle prend un principal de machine Windows (machine@REALM) et le convertit en machine.realm pour mettre à jours les sous-domaines de machine.realm.
krb5-self Cette règle prend un principal de machine Kerberos (host/machine@REALM) et le convertit en machine.realm.
krb5-subdomain Cette règle prend un principal de machine Kerberos (host/machine@REALM) et le convertit en machine.realm pour mettre à jours les sous-domaines de machine.realm.
tcp-self Autorise les mises à jours qui ont été envoyés via TCP et pour lequelles le mappage standard pour initier l'adresse IP dans in-adddr.arpa et ip6.arpa match le nom à mettre à jours. Noter qu'il est théoriquement possible de spoofer ces sessions TCP.
6to4-self Autorise le préfixe 6to4 à être mis à jours par une connexion TCP depuis le réseaux 6to4 ou depuis l'adresse IPv4 correspondante. C'est prévu pour pouvoir ajouter des RRsets NS ou DNAME.
external Cette règle autorise named à déférer la décision de l'accès à un service exterme. La méthode de communication avec le service est spécifié dans le champs identity, le format est "local:path" où path est l'emplacement d'un socket unix. Actuellement local est le seul mécanisme supporté. Les requêtes au service externe sont envoyés via le socket unix en datagrammes. Le service répond avec une valeur 4 octets contenant soit 0 soit 1.

   Dans tous les cas le champ name doit spécifier un nom fqdn. Si aucun type n'est spécifié explicitement, cette règle matche tous les types excepté RRSIG, NS, SOA, NSEC, NSEC3. Les types peuvent être spécifiés par nom, incluant "ANY" qui matche tous les types sauf NSEC et NSEC3, qui ne peuvent jamais être mis à jours.

Plusieurs vues

   Quand les vues sont utilisées, une zone peut être référencée par plus d'une d'entre-elles. Souvent, les vues contiennent différentes zones avec le même nom, permettant à différents client de reçevoir des réponses différentes pour la même requête. Parfois, plusieurs vues contiennent des zones identiques. La zone in-view fournis une manière efficace de le faire: elle permet à une vue de référencer une zone qui a été définie dans le vue précédemment définie.

Fichier de zone

   Un nom de domaine identifie un nœud. Chaque nœud a un jeu d'informations de ressources, qui peut être vide. Ce jeu de ressources associé avec un nom particulier est composé de RR séparés. L'ordre RR dans un jeu n'est pas significatif et n'a pas besoin d'être préservé par les serveurs de nom, résolveurs, ou autres parties du DNS. Cependant, trier plusieurs RR est permis dans un but d'optimisation. Les composants d'un Resource Records sont:

owner name Le nom de domaine où le RR est trouvé
type Une valeur 16bits qui spécifie le type d'enregistrement
TTL le TTL du RR. Ce champs est un entier 32bits en secondes, utilisé par les résolveurs quand ils cachent les RR.
class Une valeur 16bits qui identifie une famille de protocole ou une instance de protocole.
RDATA La donnée de ressource. Le format des données est spécifique au type.

   Les types suivants sont des RR valides:

A Une adresse IPv4 d'hôte décrite dans la rfc1035
AAAA adresse IPv6, décrite dans la rfc1886
A6 Adresse IPv6. Peut être une adresse partielle (un suffixe) et une indirection vers le nom où le reste de l'adresse peut être trouvée. Expérimental. Décrit dans la rfc2874.
AFSDB Emplacement des serveurs de base de données AFS. Expérimental. décris dans la rfc1183
APL Liste de préfixe d'adresse. Expérimental. Décrit dans la rfc3123
CERT Maintient un certificat numérique. Décris dans la rfc2538
CNAME Identifie le nom canonique d'un alias. décris dans la rfc1035
DHCID Uilisé pour identifier quel client DHCP est associé avec ce nom. Décris dans la rfc4701
DNAME Remplace le nom de domaine spécifié avec un autre nom de domaine à recherche. Alias effectivement toute une arborescence de l'espace de nom de domaine au lieu d'un simple enregistrement comme dans le cas d'un CNAME. Décris dans la rfc2672
DNSKEY Stocke une clé publique associée avec une zone DNS signée. Décrit dans la rfc 4034
DS Stocke le hash d'une clé publique associée avec une zone DNS signée. Décris dans la rfc4034
GPOS Spécifie la position globale. Remplacée par LOC
HINFO Identifie le CPU et l'OS utilisé par un hôte. Décris dans la rfc1035
IPSECKEY Fournis une méthode pour stocker un clé IPsec dans DNS. Décris dans la rfc4025
ISDN Resprésentation des adresses ISDN. Expérimental. Décris dans la rfc1183.
KEY Stocke une clé publique associée avec un nom DNS. Utilisé dans DNSSEC original, remplacé par DNSKEY dans DNSSECbis, mais reste utilisé avec SIG(0). Décris dans la rfc2535 et 2931
KX Identifie un échangeur de clé pour ce nom DNS. Décris dans la rc2230
LOC Pour stocker les informations GPS. Décris dans la rfc1876. Expérimental.
MX Identifie un échange de mail pour le domaine avec un préfixe 16-bits suivis par le nom d'hôte de l'échange de mail. Décris dans les rfc974 et 1035
NAPTR Name authority Pointer. Décris dans la rfc1706
NSAP Un point d'accès de service réseaux. Décris dans la rfc1706
NS Serveur de nom autoritatif pour le domaine. Décris dans la rfc1035
NSEC Utilisé dans DNSSECbis pour indiquer que les RR avec un owner name dans un certain interval de nom n'existent pas dans une zone et indique quels types de RR sont présent pour un nom existant. Décris dans la rfc4034
NSEC3 Identique à NSEC, mais est plus couteux pour le serveur et le client. Décris dans la rfc5155
NSEC3PARAM Utilisé dans DNSSECbis pour dire au serveur autoritatif quelles chaînes NSEC3 sont disponibles. Décris dans la rfc5155.
NXT remplacé par NSEC dans DNSSECbis. Dcéris dans la rfc2535
PTR Un pointer vers une autre partie de l'espace de nom de domaine. Décris dans la rfc1035
PX Fournis le mappage entre la rfc822 et les adresse X.400. Décris dans la rfc2163
RP Information des personnes responsable du domaine. expérimental. Décris dans la rfc1183
RRSIG Contients les données de signature DNSSECbis. Décris dans la rfrc4034
RT liaison route-through pour les hôtes qui n'ont pas leur propre aire d'adresse réseaux. Expérimental. Décris dans la rfc1183
SIG Contient les données de signature DNSSEC. Remplacé par RRSIG dans DNSSECbis. Décris dans la rfc2535 et 2931
SOA Identifie le départ de la zone d'autorité. Décris dans la rfc1035
SPF Contient le Sender Policy Framework pour un domaine de messagerie donné. Décris dans la rfc4408
SRV Information sur des services connus (remplace WKS). Décris dans la rfc2782.
SSHFP Fournis une manière sécurisée de publier des empreintes de clés ssh. Décris dans la rfc4255.
TXT enregistrement text. Décris dans la rfc1035
WKS Remplacé par SRV
X25 Représentation des adresse réseaux X.25. Expérimental. Décris dans la rfc1183

   Les classes suivante sont valides:

IN l'Internet
CH Chaosnet.
HS Hesiod

Définir les TTL

   Le TTL du champ RR est une entier 32 bits représenté en unités de secondes, et est principalement utilisés par les résolveurs quand ils cachent leur RR. Le TTL décris combien de temps un RR peut être maintenu en cache avant d'être supprimé. 3 types de TTL sont actuellement utilisés dans une zone:

SOA Le dernier champs dans le SOA est la TTL de cache négatif. Il contrôle le temps que d'autres serveurs vont maintenir en cache le no-such-domain (NXDOMAIN) pour vous. Le temps maximum est 3 heures.
$TTL La directive TTL en haut de la zone (avant le SOA) donne un TTL par défaut pour tous les RR sans jeu TTL spécifique.
RR TTLs Chaque RR peut avoir un TTL comme second champs dans le RR, qui va contrôler la durée en cache.

Mappage inverse dans IPv4

   La résolution de nom inverse est accomplie au moyen d'un domaine in-addr.arpa et d'enregistrements PTR. Les entrées dans le domaine in-addr.arpa sont créés dans l'ordre inverse. La ligne $ORIGIN sert à fournir le contexte.

Autres directives de fichier de zone

   Le format de fichier maître a été initialement définis dans la rfc1035 et a ensuite été étendu. Bien que le format de fichier maître lui-même est indépendant de la classe, tous les enregistrements dans un fichier maître doivent être de même classe. Les directives de fichier maître incluent $ORIGIN, $INCLUDE, et $TTL.

@ Utilisé dans un label ou nom, ce symbole représente l'origine courante. au début de la zone, c'est le nom de la zone.
$ORIGIN domain-name [comment] Jeux de nom de qui sont ajoutés à tout enregistrement non qualifié.
$INCLUDE filename [origin] [comment] Lit et traite le fichier comme s'il étair dans le fichier.
$TTL default-ttl [comment] Définis le TTL pour les enregistrements suivants.

Extension de fichier maître BIND


$GENERATE range lhs [ttl] [class] type rhs [comment]

   $GENERATE est utilisé pour créer une série d'enregistrement qui diffèrent uniquement des autres par un itérateur. $GENERATE peut être utilisé pour faciliter la génération de jeux d'enregistrements requis pour supporter les sous-délégations inversées /24 décrites dans la rfc2317: la délégation sans classe IN-ADDR.ARPA.


$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-2 @ NS SERVER$.EXAMPLE.
$GENERATE 1-127 $ CNAME $.0

est équivalent à:
0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE.
0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
...
127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.

Génère un jeu d'enregistrements A et MX. Noter que MX est un chaîne entre guillemets, qui sont enlevés au traitement:
$ORIGIN EXAMPLE.
$GENERATE 1-127 HOST-$ A 1.2.3.$
$GENERATE 1-127 HOST-$ MX "0 ."

est équivalent à:
HOST-1.EXAMPLE. A 1.2.3.1
HOST-1.EXAMPLE. MX "0 ."
HOST-2.EXAMPLE. A 1.2.3.2
HOST-2.EXAMPLE. MX 0 .
HOST-3.EXAMPLE. A 1.2.3.3
HOST-3.EXAMPLE. MX 0 .
...
HOST-127.EXAMPLE. A 1.2.3.127
HOST-127.EXAMPLE. MX 0 .

Statistiques

   BIND9 maintient beaucoup de statistiques et fournis de nombreuses interfaces pour que les utilisateurs aient accès à ces statistiques. Les statistiques disponible incluent tous les compteurs qui étaient disponible dans BIND8 et ont du sens dans BIND9, plus d'autres informations. Les informations de statistiques sont catégorisés dans les sections suivantes:

Incoming Requests Le nombre de requêtes DNS entrantes pour chaque OPCODE
Incoming Queries Le nombre de demandes entrantes pour chaque type de RR
Outgoing Queries Le nombre de demandes sortantes pour chaque types de RR envoyé depuis le résolveur interne. maintenu par vue.
Name Server Statistics Compteurs de statistiques sans regarder les opérations de maintenance de zone telles que les transferts de zone.
Zone Maintenance Statistics Compteurs d'opérations de maintenances des zones telles que les tranfers de zone
Resolver Statistics Compteurs sur la résolution de noms dans le résolveur interne. Maintenu par vue.
Cache DB RRsets Nombre de RRsets par type de RR et noms non-existants stockés dans la base de cache. un ! indique un type de RRset étant non-existant (NXRRSET). Maintenu par vue.
Tocket I/O statistics Compteur de statistiques sur les événements réseaux

   Un sous-jeu de Name Server Statistics est collecté et affiché par zone pour lequel le serveur a l'autorité quand zone-statistics est à yes. Ces compteurs sont affichés avec leur noms de zone et vue. Dans certains cas le nom de la vue est omis pour la vue par défaut.

   Il y a actuellement 2 interfaces pour accéder aux statistiques. Une est en texte claire stocké dans le fichier statistics-file. L'autre est accessible à distance via un canal de statistiques.

Fichier de statistiques

Le format texte commence avec une ligne comme:
+++ Statistics Dump +++ (973798949)

Le nombre entre parenthèses est un horodatage Unix, mesuré en secondes depuis l'epoch. La suite est un jeu d'informations, qui sont catégorisés comme décris plus haut. Chaque section commence avec une ligne comme:
++ Name Server Statistics ++

   Chaque section consiste de lignes, chacune contenant la valeur de compteurs suivie par sa description contextuelle. Pour simplifier, les compteurs avec une valeur de 0 ne sont pas affichés.

Le fichier se termine avec une ligne similaire à la première (même horodatage):
— Statistics Dump — (973798949)

Compteurs

   Les tables suivantes résument les compteurs statistique que BIND9 fournis.

Name Server Statistics Counters

Requestv4 Requêtes IPv4 reçues. Note: compte également les requêtes non répondues.
Requestv6 Requêtes IPv6 reçues. Note: compte également les requêtes non répondues.
ReqEdns0 Requêtes EDNS(0) reçues
ReqBadEDNSVer Requêtes avec une version EDNS non-supportée reçues
ReqTSIG Requêtes avec TSIG reçues
ReqSIG0 Requêtes avec SIG(0) reçues
ReqBadSIG Requêtes avec une signature TSIG ou SIG(0) invalide reçues
ReqTCP Requêtes TCP reçues
AuthQryRej Requêtes autoritatives rejetées
RecQryRej Requêtes récursives rejetées
XfrRej Requêtes de tranfers de zone rejetées
UpdateRej Requêtes de mise à jour dynamique rejetées
Response Réponses envoyées
RespTruncated Réponses tronquées envoyées
RespEDNS0 Réponses avec EDNS(0) envoyés
RespTSIG Réponses avec TSIG envoyés
RespSIG0 Réponses avec SIG(0) envoyés
QrySuccess Demande résultant une réponses réussie. (réponse NOERROR avec au moins un RR)
QryAuthAns Requêtes résultant une réponse autoritative
QryNoauthAns Requêtes résultant une réponse non-autoritative
QryReferral Requêtes résultant une réponse référantes.
QryNxrrset Requêtes résultant une réponse NOERROR sans données.
QrySERVFAIL Demandes résultant un SERVAIL
QryFORMERR Demandes résultant un FORMERR
QryNXDOMAIN Demandes résultant un NXDOMAIN
QryRecursion Demande qui ont impliqué une récursion pour trouver la réponse finale
QryDuplicate Demande que le serveur à tenter en récursion mais découvert qu'une demande avec la même IP, port, queryID, nom, type et classe à déjà été traité.
QryDropped Recherches récursive pour lequelles le serveur a découvert un nombre excessif de recherches pour le même nom, classe et type. C'est le nombre de recherches supprimées dues aux options clients-per-query et max-clients-per-query
QryFailure Autres erreurs de recherche.
XfrReqDone Demande de transfert de zone complétés
UpdateReqFwd Demandes de mise à jours forwardés
UpdateRespFwd Réponses de mise à jours forwardés
UpdateFwdFail Mise à jours dynamique forwardés échoués
UpdateDone Mise à jours dynamique forwardés complétées
UpdateFail Mise à jours dynamique échouées
UpdateBadPrereq Mise à jours dynamique rejetées à cause de prérequis non respectés
RateDropped Réponses supprimées par les limites
RateSlipped Réponses tronquées par les limites
RPZRewrites Réponses de ré-écriture de policy zone.

Zone Maintenance Statistics Counters

NotifyOutv4 notifications IPv4 envoyées
NotifyOutv6 notifications IPv6 envoyées
NotifyInv4 notifications IPv4 reçues
NotifyInv6 notifications IPv6 reçues
NotifyRej Notifications entrantes rejetées
SOAOutv4 Recherches de SOA IPv4 envoyées
SOAOutv6 Recherches de SOA IPv6 envoyées
AXFRReqv4 AXFR IPv4 demandées
AXFRReqv6 AXFR IPv6 demandées
IXFRReqv4 IXFR IPv4 demandées
IXFRReqv6 IXFR IPv6 demandées
XfrSuccess Demandes de transferts de zone réussies
XfrFail Demandes de transferts de zone échouées

Resolver Statistics Counters

Queryv4 Recherches IPv4 envoyées
Queryv6 Recherches IPv6 envoyées
Responsev4 Réponses IPv4 reçues
Responsev6 Réponses IPv6 reçues
NXDOMAIN NXDOMAIN reçues
SERVFAIL SERVFAIL reçues
FORMERR FORMERR reçues
OtherError Autres erreurs reçues
EDNS0Fail Recherches EDNS(0) échouées
Mismatch Réponses non-correspondantes reçues. le DNS ID l'adresse source et/ou le port sources de la réponse ne correspond pas à ce qui était attendu. Peut indiquer une tentative de cache poisoning
Truncated Réponses tronquées reçues
Lame Lame délégations reçues
Retry Retentatives de recherche effectuées
QueryAbort Recherche annulées du à un contrôle de quotas
QuerySockFail Erreur en ouvrant des sockets. Généralement due à un limitation des descripteurs de fichier.
QueryTimeout Timeouts de recherche
GlueFetchv4 recherches d'adresse NS IPv4 invoquées
GlueFetchv6 recherches d'adresse NS IPv6 invoquées
GlueFetchv4Fail recherches d'adresse NS IPv4 échouées
GlueFetchv6Fail recherches d'adresse NS IPv4 échouées
ValAttempt Validation DNSSEC tentées
ValOk Validation DNSSEC réussie
ValNegOk Validation DNSSEC sur des informations négatives réussies
ValFail validations DNSSEC échouées
QryRTTnn Table de fréquence des RTTs de recherche.

Socket I/O Statistics Counters

‹TYPE›Open Sockets ouverts avec succès
‹TYPE›OpenFail Erreur d'ouverture de sockets
‹TYPE›Close Sockets fermés
‹TYPE›BindFail Bind de sockets échoués
‹TYPE›ConnFail Erreurs de connexions aux sockets
‹TYPE›Conn Connections établies avec succès
‹TYPE›AcceptFail Erreur d'acceptation de demandes de connexion entrantes. Non applicable à UDP
‹TYPE›Accept Connexions entrant acceptées. Non applicable à UDP
‹TYPE›SendErr Erreurs dans les opération d'envois sur socket
‹TYPE›RecvErr Erreurs d'opérations de reception sur socket

chroot and setuid

   BIND9 peut être lancé dans un environnement chroot. Il n'est pas nécessaire de compiler named statiquement, mais en fonction de l'OS, il peut être nécessaire de définir /dev/zero, /dev/random, /dev/log, et /etc/localtime.
^
18 mars 2016

htmlpdflatexmanmd




ddns-confgen

ddns-confgen, tsig-keygen

Outil de génération de clé ddns

   tsig-keygen et ddns-confgen sont des méthodes d'invocation pour un utilitaire qui génère des clé à utiliser dans les signatures TSIG. Les clés résultante peuvent être utilisée, par exemple, pour sécuriser les mises à jours dynamiques, ou pour le canal de commande rndc.

   lancé en tant que tsig-keygen, un nom de domaine peut être spécifié sur la ligne de commande qui est utilisé comme nom pour la clé générée. Défaut: tsig-key

   Lancé en tant que ddns-confgen, la clé générée est accompagniée par un texte de configuration et des instruction qui peuvent être utilisée avec nsupdate et named pour définir DDNS, incluant un exemple de déclaration update-policy.

OPTIONS

-a algorithm Spécifie l'algorithme à utiliser pour la clé TSIG
-k keyname Spécifie le nom de clé pour la clé d'authentification ddns. Défaut: ddns-key
-q (ddns-confgen uniquement) Mode silencieux. Affiche seulement la clé.
-r randomfile Spécifie une source de données aléatoires
-s name (ddns-confgen uniquement) Génère un exemple de configuration pour autoriser les mises à jours dynamiques d'un simple hostname.
-z zone (ddns-confgen uniquement) Génère un exemple de configuration pour autoriser les mises à jours dynamiques d'une zone.
^
18 mars 2016

htmlpdflatexmanmd




delv

delv

Utilitaire de recherche et de validation DNS

   delv (Domain Entity Lookup & Validation) est un outil pour envoyer des requêtes DNS et valider les résultats en utilisant le même résolveur et validateur interne de named.

   delv envoie à un serveur de nom spécifié toutes les requêtes nécessaires pour obtenir et valider les données demandées, incluant la requête originale, les requêtes sous-jacentes pour suivre les chaînes CNAME ou DNAME, et les requêtes pour les records DNSKEY, DS et DLV pour établir une chaîne de confiance pour la validation DNSSEC. Il n'effectue pas de résolution itérative, mais simule le comportement du serveur de nom configuré pour la validation DNSSEC et le forwarding

   Par défaut, les réponses sont validées en utilisant les ancres de confiance DNSSEC embarqués pour la zone root et pour la zone de validation ISC DNSSEC (dlv.isc.org). Les enregistrements retournés par delv sont soit validées ou non signées. Si la validation échoue, une explication de l'erreur est incluse dans la sortie.

   Sauf mention, delv tente chaque serveur listé dans /etc/resolv.conf, et si aucune adresse n'est utilisable, utilise 127.0.0.1 ou ::1. Sans arguments ni options, delv effectue une requête NS pour '.'

   La syntaxe de base est delv @server name type, où

server est le nom ou l'adresse IP d'un serveur à requêter.
name est le nom de la ressource à rechercher
type est le type de requête (ANY, A, MX, SIG, etc)

OPTIONS

-a anchor-file Spécifie un fichier depuis lequel lire les TA DNSSEC. défaut: /etc/bind.keys, qui est inclus avec bind9 et contient les TA pour la zone root et pour dlv.isc.org.
-b address Définis l'adresse IP source de la requête
-c class Définis la classe de la requête. Actuellement seul IN est supporté
-d level Niveau de débug, de 0(pas de debug) à 99
-i Mode non-secure. Désactive la validation DNSSEC
-m Debuggage de l'utilisation mémoire
-p port# Spécifie le port de destination pour la requête
-q name Définis le nom de la requête. Utile pour éviter toute ambiguïté
-t type Définis le type de requête. Utile pour éviter toute ambiguïté
-x addr Indique une requête inverse
-4 Force l'utilisation d'IPv4
-6 Force l'utilisation d'IPv6

Options de recherche

+[no]cdflag Définis le bit CD dans la requête. Utile pour les problèmes DNSSEC derrière un resoleur
+[no]class Affiche la CLASS en affichant l'enregistrement
+[no]ttl Affiche le TTL en affichant l'enregistrement
+[n]rtrace Active le logging du résolveur
-[no]mtrace Active le logging de message. Produit un dump détaillé des réponses reçues
+[no]vtrace Active le logging de validation. Affiche le processus interne du validateur
+[no]short affiche une réponse courte
+[no]comments affiche les commentaires dans la sortie
+[no]rrcomments Affiche les commentaires par enregistrement dans la sortie.
+[no]crypto Affiche les champs cryptographiques dans les enregistrements DNSSEC
+[no]trust Affiche le niveau de confiance en affichant un enregistrement.
+[no]split[=W] Split les champs base64 ou hexa long en portions de W caractères (arrondis au multiple de 4 le plus proche)
+[no]all Affiche les options (+comments, +rrcomment, +trust) comme un groupe
+[no]multiline Affiche les records comme les records SOA dans un format multi-ligne.
+[no]root[=ROOT] Indique si la validation DNSSEC est effectuée de manière conventionnelle, et spécifie le nom d'un TA.
+[no]dlv[=DLV] Effectue la validation DNSSEC, et spécifier le nom du TA DLV. Défaut: dlv.isc.org.
^
18 mars 2016

htmlpdflatexmanmd




dig

dig

Utilitaire de recherche DNS

   dig est un outil flexible pour interroger les serveurs de nom DNS. Sans spécifier de serveur, dig tente chaque serveur listé dans /etc/resolv.conf. Si aucune adresse serveur n'est utilisable, dig tente une requête locale. Sans arguments ni options, dig effectue une requête NS pour ".".

   Il est possible de définir des options par utilisateur via ${HOME}/.digrc. Ce fichier est lu et toute options qui s'y trouve est appliquée avant les arguments de la ligne de commande.

   La syntaxe de base est dig @server name type, où

server est le nom ou l'adresse IP d'un serveur à requêter.
name est le nom de la ressource à rechercher
type est le type de requête (ANY, A, MX, SIG, etc)

OPTIONS

-b address Définis l'adresse IP source de la requête.
-c class Spécifie la classe de la requête (IN, HS ou CH)
-f filename Permet d'opérer en mode batch en lisant une liste de recherche à traiter dans le fichier spécifié
-k filename Clé TSIG à utiliser avec -y
-m Active le debuggage de l'utilisation mémoire
-p port# Port pour la requête.
-q name Définis le nom de la requête. utile pour distinguer le nom des autres arguments.
-t type Définis le type de la requête (A par défaut). Un transfert de zone peut être demandé avec type=AXFR, pour un transfer incrémentale utiliser ixfr=N ou N est le numéro de série.
-v affiche la version et quitte
-x addr Indique une requête inverse
-y [hmac:]name:key] Permet de signer les requêtes DNS envoyées par dig et leur réponses en utilisant TSIG. La clé est spécifiée avec -k
-4 Force l'utilisation d'IPv4
-6 Force l'utilisation d'IPv6

Options de recherche

+[no]tcp Utilise TCP pour les requêtes Défaut: utilise UDP sauf pour les requêtes AXFR et IXFR
+[no]ignore Ignore les réponses UDP tronquées au lieu de retenter avec TCP.
+domain=somename Définis la liste de recherche pour contenir le seul domaine spécifié, comme si spécifié dans la directive domain de /etc/resolv.conf, et active le traitement de la liste de recherche comme si l'option +search était donné
+[no]search Utilise la liste de recherche définie par searchlist ou domain dans /etc/resolv.conf. Cette liste n'est pas utilisée par défaut.
+[no]showsearch Effectue une cherche en affichant les résultats intermédiaires.
+[no]aaonly Définis le flag aa dans le requête
+[no]aaflag Synonyme de aaonly
+[no]adflag Définis le bit AD dans la requête.
+[no]cdflag Définis le bit CD dans la requête
+[no]cl Affiche la CLASS en affichant l'enregistrement
+[no]ttlid Affiche le TTL en affichant l'enregistrement
+[no]recurse Met le bt RD dans la requête
+[no]nssearch Tente de trouver les serveurs de noms autoritatifs pour la zone contenant le nom recherché et afficher le SOA
+[no]trace Active le tracing du chemin de délégation depuis les serveurs racine pour le nom recherché.
+[no]cmd affiche la commande initial en commentaire dans la sortie
+[no]short affiche une réponse courte
+[no]identify l'IP et le port qui fournit la réponse en utilisant +[no]short
+[no]comments affiche les commentaires dans la sortie
+[no]rrcomments Affiche les commentaires par enregistrement dans la sortie.
+[no]crypto Affiche les champs cryptographiques dans les enregistrements DNSSEC
+split=W Split les champs base64 ou hexa long en portions de W caractères (arrondis au multiple de 4 le plus proche)
+[no]stats affiche les statistics dans la sortie
+[no]qr Affiche la requête quand elle est envoyée.
+[no]question Affiche la section question d'une requête quand une réponse est retournée
+[no]answer Affiche la section réponse
+[no]authority Affiche la section authority
+[no]additional Affiche la section additional
+[no]all Affiche les flags
+time=T Définit le timeout pour une requête en secondes. défaut 5
+tries=T Définit le nombre de tentatives UDP. défaut 3
+retry=T Définit le nombre de tentatives UDP. Défaut 2. idem à +tries mais n'inclue pas la requête initiale
+ndots=D Définis le nombre de points qui doivent apparaîtrent dans name.
+bufsize=B Définis le buffer du message UDP utilisant EDNS0
+edns=# Spécifie la version EDNS à utiliser +noedns efface la version
+[no]multiline Affiche les records comme les records SOA dans un format multi-ligne.
+[no]onesoa Affiche seulement un record SOA au départ en effectuant un AXFR. Défaut: affiche au départ et à la fin.
+[no]fail Ne retente pas le serveur suivant en cas d'une réponse SERVFAIL
+[no]besteffort Tente d'afficher le contenus des messages qui sont malformés
+[no]dnssec demande les records DNSSEC en mettant le bit DNSSEC OK (DO) dans le record OPT dans la section additionnelle de la requête
+[no]sigchase Poursuit les chaînes de signature DNSSEC.
+trusted-key=#### Spécifie un fichier contenant les clés de confiance à utiliser avec +sigchase. Sinon dig regarde /etc/trusted-key.key puis trusted-key.key dans le répertoire courant.
+[no]topdown en poursuivant les chaînes de signature DNSSEC, effectue une validation top-down
+[no]nsid Inclue un EDNS name server ID request en envoyant une requête.
+[no]keepopen Conserve le socket TCP ouvert entre les requête et le réutilise
+[no]sit[=####] Envois l'option SIT.
+[no]subnet=addr/prefix Envoie une option EDNS Client Subnet avec l'adresse IP ou le préfixe réseau spécifié
+[no]expire Envoie une option EDNS Expire. Actuellement en envoyant la valeur expérimentale 65002.

Requêtes multiple

   dig permet de spécifier plusieurs requêtes sur la ligne de comande ( en plus de l'option -f). Chacune de ces requêtes peut être fournie avec son propre jeux de flags, options et options de requêtes.

   Dans ce cas, chaque argument query représente une requête individuelle. Chacune consiste d'options et flags, le nom à rechercher, le type de requête et de classe et des options de requêtes.

Un jeu global d'options de requête, qui devrait être appliqué à toutes les requêtes peut également être spécifié. Ces options de requêtes globales doivent précéder la première requête. Les options de requêtes globales (excepté +cmd) peuvent être remplacées pas des options spécifiques à la requête.
dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr

   Cet exemple monte comment effectuer 3 rechercher: une requête ANY pour www.isc.org, une requête inversée pour 127.0.0.1, et une requête pour les enregistrement ns de isc.org

Support IDN

   dig intègre le support IDN (Internationalized Domain Name), et peut accepter et afficher les noms de domaine non-ASCII. Pour désactiver le support IDN, définir la variable IDN_DISABLE.
^
18 mars 2016

htmlpdflatexmanmd




dnssec-checkds

dnssec-checkds

Vérification de consistance de délégation DNSSEC

   dnssec-checkds vérifie le validité des enregistrements DS (Delegation Signer) ou DLV (DNSSEC Lookaside Validation) pour les clés dans une zone spécifiée.

OPTIONS

-f file Lis la zone depuis ce fichier pour trouver les records DNSKEY, sinon recherche les records dans le DNS.
-l domain Vérifie le record DLV dans le domaine spécifié, au lieu de vérifier un DS dans la zone du parent.
-d dig path Spécifie un chemin du binaire dig.
-D dsfromkey path Spécifie un chemin du binaire dnssec-dsfromkey.
^
18 mars 2016

htmlpdflatexmanmd




dnssec-coverage

dnssec-coverage

Vérifie la couverture DNSKEY future pour une zone

   Vérifie que les clés DNSSEC pour une zone donnée ou un jeu de zones ont des métadonnées de timing correct pour s'assurer qu'aucune défaillance future dans la couverture DNSSEC.

   Si la zone est spécifiée, les clés trouvée dans le dépôt de clé correspondant à cette zone sont scannés, et une liste ordonnée est générée de l'événement planifié pour cette clé (publication, activation, inactivation, suppression). La liste d'événements est suivie dans l'ordre d'occurrence. Des alertes sont générées si des événements sont planifiées qui causeraient la zone d'entrer dans un état d'erreur de validation.
   Si la zone n'est pas spécifiée, toutes les clé dans le dépôt de clé seront scannées, et toutes les zones pour lesquelles il y a des clé seront analysées.

OPTIONS

-K directory Répertoire où trouver les clé.
-f file Si spécifié, la zone est lu depuis ce fichier
-l duration La durée pour la vérification de couverture DNSSEC.
-m maximum TTL Définis la valeur à utiliser comme TTL max pour la ou les zones à analyser pour déterminer s'il y a une erreur de validation possible
-d DNSKEY TTL Définis la valeur à utiliser comme DNSKEY TTL pour la ou les zones à analyser.
-r resign interval Définis la valeur à utiliser comme intervalle de re-signature pour la zone.
-k Vérifie seulement la couverture KSK
-z Vérifie seulement la couverture ZSK
-c compilezone path Spécifie un chemin du binaire named-compilezone
^
18 mars 2016

htmlpdflatexmanmd




dnssec-dsfromkey

dnssec-dsfromkey

Outil de génération de DS RR

   dnssec-dsfromkey affiche le DS RR (Delecation Signer Resource Record) comme définis dans la rfc3658 et la rfc4509, pour les clé données.

OPTIONS

-1 Utilise SHA-1 (utilise SHA-1 et SHA-256 par défaut)
-2 Utilise SHA-256
-a algorithm Séléctionne l'algorithme. peut être SHA1, SHA256, SHA-384, ou GOST
-T TTL Spécifie le TTL opur les records DS
-K directory Répertoire contenant les fichiers de clé
-f file mode fichier de zone : à la place du nom de fichier de clé, l'argument est le nom de domaine d'un fichier de zone maître, qui peut être lu depuis le fichier spécifié
-A Inclue ZSK en générant les records DS. Sans cette option, seul les clés qui ont le flag KSK mis sera convertis en record DS et affiché. Utile uniquement en mode fichier de zone.
-l domain Génère un jeu DLV (DNSSEC Lookaside Validation) au lieu d'un jeu DS. Le domaine spécifié est ajouté au nom pour chaque record dans le jeu
-s mode Keyset : à la place du nom de fichier clé, l'argument est un nom de domaine d'un fichier keyset
-c class Spécifie la classe DNS
-v level spécifie le niveau de debug

Exemples

Pour construire le SHA-256 DS RR depuis le nom de fichier Kexample.com.+003+26160 :
dnssec-dsfromkey -2 Kexample.com.+003+26160
La commande affichera
example.com. IN DS 26160 5 2 3A1EADA7A74B8D0BA86726B0C227AA85AB8BBD2B2004F41A
^
18 mars 2016

htmlpdflatexmanmd




dnssec-importkey

dnssec-importkey

Importe les records DNSKEY depuis des système externe pour qu'ils puissent être gérés

   Il lit un record DNSKEY publique et génère une paire de fichiers .key/.private. Le record DNSKEY peut être lu depuis un fichier .key existant, auquel cas un fichier .private sera généré, ou peut être lu depuis un autre fichier ou depuis l'entrée standard, auquel cas les fichiers .key et .private seront générés.

   Le nouveau fichier .private créé ne contient pas de donnée de clé privée, et ne peut pas être utilisée pour signer. Cependant,avoir un fichier .private rend possible les durées de publication (-P) et de suppression (-D) pour la clé, ce qui signifie que la clé publique peut être ajoutée et supprimée du DNSKEY RRset avec un événement planifié si la vrai clé privée est stockée offline.

OPTIONS

-f filename Mode fichie de zone. Au lieu d'un nom de fichier keyfile, l'argument est un nom de domaine DNS d'un fichie de zone maître, qui est lus depuis le fichier spécifié. à '-', les données de zones sont lue depuis l'entrées standard.
-K directory Répertoire où trouver les clé
-L ttl Définis le ttl par défaut à utiliser pour cette clé quand elle est convertie en DNSKEY RR. Si la clé est importée dans une zone, c'est le TTL qui sera utilisé, sauf si elle a déjà un RRset, auquel cas le TTL existant aura précédence. à '0' ou 'none' le supprime
-v level Définis le niveau de debug
-P date/offset Définis la date à laquelle une clé doit être publiée dans la zone. Après cette date, la clé sera incluse dans la zone mais ne sera pas utilisée pour la signer.
-D date/offset Définis la date à laquelle la clé est supprimée. Après cette date, la clé ne sera plus incluse dans la zone.

Options de temps

   Les dates peuvent être exprimées au format YYYYMMDD ou YYYYMMDDHHMMSS. Si l'argument commence par un '+', ou un '-', il est interprété comme relatif au temps présent. Si un tel temps relatif est suivi pas un des suffixes 'y', 'mo', 'w', 'd', 'h', ou 'mi', alors le temps relatif est calculé en année, mois (de 30 jours), semaines, heure ou minute respectivement. Sans suffix, le temps relatif est exprimé en seconde. Pour empêcher de définir une date, utiliser 'none' ou 'never'
^
18 mars 2016

htmlpdflatexmanmd




dnssec-keyfromlabel

dnssec-keyfromlabel

Outil de génération de clé crypto hardware DNSSEC

   dnssec-keyfromlabel génère des fichiers de paire de clé qui référence un objet clé stocké dans un module cryptographique (HSM). Le fichier de clé privée peut être utilisé pour signer une zone de donnée comme si elle était une clé de signature conventionnelle créé par dnssec-keygen, mais la clé est stockée dans le HSM.

   Le nom de la clé est spécifié sur la ligne de commande. Il doit correspondre au nom de la zone pour laquelle la clé est générée.

OPTIONS

-a algorithm Sélectionne l'algorithme cryptographique (RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256, ou ECDSAP384SHA384). Défaut: RSASHA1.
-3 Utilise un algorithme capable de gérer NSEC3 opur générer une clé DNSSEC. Défaut: NSEC3RSASHA1
engine Spécifie le hardware cryptographique à utiliser
-l label Spécifie le label pour une paire de clé crypto hardware
nametype Spécifie le type propriétaire de la clé. ZONE (pour une clé de zone DNSSEC), HOST, ou ENTITY (pour une clé associée avec un hôte), USER (pour une clé associée avec un utilisateur), ou OTHER (DNSKEY)
-C Mode compatibilité: génère des clé ancien style, dans métadonnée.
-c class Indique que le record DNS contenant la clé devrait avoir la classe spécifiée. Défaut: IN
-f flag Définis le flag spécifié dans le champ flag du record KEY/DNSKEY. Les seuls flags reconnus sont KSK et REVOKE
-G Génère une clé, mais ne la publie pas et ne signe rien avec. Incompatible avec -P et -A
-K directory Définis le répertoire dans lequel les fichiers sont écris
-k Génère des records KEY au lieu de DNSKEY
-L ttl Définis le ttl par défaut à utiliser pour cette clé quand elle est convertie dans un DNSKEY RR. Si la clé est importée dans une zone, c'est le TTL qui sera utilisée pour elle, sauf si un DNSKEY RRset est déjà définis, auquel cas il a précédence.
-p protocol Définis la valeur protocol pour la clé. Le protocol est un nombre entre 0 et 255. Défaut: 3 (DNSSEC). D'autres valeurs possible sont listées dans la rfc2535 et ses successeurs.
-S key Génère une clé comme successeur explicite d'une clé existante. Le nom, l'algorithme, la taille, et le type de clé doivent matcher le prédécesseur. La date d'activation de la nouvelle clé sera mis à la date de désactivation de cette existante. La date de publication sera définis à la date d'activation moins l'interval de pré-publication, qui est 30 jours par défaut.
-t type Indique l'utilisation de la clé. AUTHCONF, NOAUTHCONF, NOAUTH, ou NOCONF. Défaut: AUTHCONF. AUTH réfèrre à la capacité d'authentifier les données, et CONF à la capacité de chiffrer les données.
-v level Définis le niveau de debug
-y Permet de générer des fichiers de clé DNSSEC même si l'ID de clé est en colision avec une clé existante, dans le cas d'une clé à révoquer.
-P date/offset Définis la date à laquelle une clé doit être publiée dans la zone. Après cette date, la clé sera incluse dans la zone mais ne sera pas utilisée pour la signer.
-A date/offset Définis la date à laquelle la clé est activé. Après cette date, la clé sera incluse dans la zone et utilisée pour la signer.
-R date/offset Définis la date à laquelle la clé est révoquée. Après cette date, la clé sera flagé révoquée. Elle sera inclus dans la zone et utilisée pour la signer
-I date/offset Définis la date à laquelle la clé est retiré. Après cette date, la clé sera incluse dans la zone, mais ne sera pas utilisée pour la signer
-D date/offset Définis la date à laquelle la clé est supprimée. Après cette date, la clé ne sera plus incluse dans la zone.
-i interval Définis l'interval de pré-publication pour une clé.

Options de temps

   Les dates peuvent être exprimées au format YYYYMMDD ou YYYYMMDDHHMMSS. Si l'argument commence par un '+', ou un '-', il est interprété comme relatif au temps présent. Si un tel temps relatif est suivi pas un des suffixes 'y', 'mo', 'w', 'd', 'h', ou 'mi', alors le temps relatif est calculé en année, mois (de 30 jours), semaines, heure ou minute respectivement. Sans suffix, le temps relatif est exprimé en seconde. Pour empêcher de définir une date, utiliser 'none' ou 'never'

Fichiers générés

   Les fichier de clé générés sont nommés sous la forme Knnnn.+aaa+iiiii. Cette chaîne d'identification signifie:

nnnn Est le nom de la clé
aaa La représentation numérique de l'algorithme
iiiii L'identifiant de clé (ou empreinte)

   dnssec-keyfromlabel créé 2 fichiers, avec des noms basés sous la forme Knnnn.+aaa+iiiii.key et Knnnn.+aaa+iiiii.private. Le fichier .key contient un record DNS KEY qui peut être inséré dans un fichier de zone, et le fichier .private contient les champs spécifiques à l'algorithme. Ce fichier n'a pas de permission de lecture.
^
18 mars 2016

htmlpdflatexmanmd




dnssec-keygen

dnssec-keygen

Outil de génération de clé DNSSEC

   dnssec-keygen génère de clé pour DNSSEC, tel que définis dans la rfc2535 et la rfc4034. Il peut également générer des clé pour TSIG tel que définis dans la rfc2845, ou TKEY tel que définis dans la rfc2930. Le nom de la clé est spécifié sur la ligne de commande. Pour les clés DNSSEC, il doit correspondre au nom de la zone pour laquelle la clé est générée.

OPTIONS

-a algorithm Sélectionne l'algorithme cryptographique (RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256, ou ECDSAP384SHA384). Pour TSIG/TKEY, la valeur doit être DH, HMAC-MD5, HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, ou HMAC-SHA512. Défaut: RSASHA1.
-b keysize Spécifie la taille de la clé.
nametype Spécifie le type propriétaire de la clé. ZONE (pour une clé de zone DNSSEC), HOST, ou ENTITY (pour une clé associée avec un hôte), USER (pour une clé associée avec un utilisateur), ou OTHER (DNSKEY)
-3 Utilise un algorithme capable de gérer NSEC3 opur générer une clé DNSSEC. Défaut: NSEC3RSASHA1
-C Mode compatibilité: génère des clé ancien style, dans métadonnée.
-c class Indique que le record DNS contenant la clé devrait avoir la classe spécifiée. Défaut: IN
engine Spécifie le hardware cryptographique à utiliser
-f flag Définis le flag spécifié dans le champ flag du record KEY/DNSKEY. Les seuls flags reconnus sont KSK et REVOKE
-G Génère une clé, mais ne la publie pas et ne signe rien avec. Incompatible avec -P et -A
-g generator En générant une clé DH, utilise ce générateur. peut être entre 2 et 5.
-K directory Définis le répertoire dans lequel les fichiers sont écris
-L ttl Définis le ttl par défaut à utiliser pour cette clé quand elle est convertie dans un DNSKEY RR. Si la clé est importée dans une zone, c'est le TTL qui sera utilisée pour elle, sauf si un DNSKEY RRset est déjà définis, auquel cas il a précédence.
-p protocol Définis la valeur protocol pour la clé. Le protocol est un nombre entre 0 et 255. Défaut: 3 (DNSSEC). D'autres valeurs possible sont listées dans la rfc2535 et ses successeurs.
-q Mode silencieux. Supprime la sortie non-nécessaire
-r randomdev Spécifie la source de nombre aléatoire.
-S key Génère une clé comme successeur explicite d'une clé existante. Le nom, l'algorithme, la taille, et le type de clé doivent matcher le prédécesseur. La date d'activation de la nouvelle clé sera mis à la date de désactivation de cette existante. La date de publication sera définis à la date d'activation moins l'interval de pré-publication, qui est 30 jours par défaut.
-s strength Spécifie la valeur de force de clé. La force est un nombre entre 0 et 15, et n'a aucun but définis dans DNSSEC actuellement
-T rrtype Spécifie le type de RR à utiliser pour la clé. DNSKEY ou KEY.
-t type Indique l'utilisation de la clé. AUTHCONF, NOAUTHCONF, NOAUTH, ou NOCONF. Défaut: AUTHCONF. AUTH réfèrre à la capacité d'authentifier les données, et CONF à la capacité de chiffrer les données.
-v level Définis le niveau de debug
-P date/offset Définis la date à laquelle une clé doit être publiée dans la zone. Après cette date, la clé sera incluse dans la zone mais ne sera pas utilisée pour la signer.
-A date/offset Définis la date à laquelle la clé est activé. Après cette date, la clé sera incluse dans la zone et utilisée pour la signer.
-R date/offset Définis la date à laquelle la clé est révoquée. Après cette date, la clé sera flagé révoquée. Elle sera inclus dans la zone et utilisée pour la signer
-I date/offset Définis la date à laquelle la clé est retiré. Après cette date, la clé sera incluse dans la zone, mais ne sera pas utilisée pour la signer
-D date/offset Définis la date à laquelle la clé est supprimée. Après cette date, la clé ne sera plus incluse dans la zone.
-i interval Définis l'interval de pré-publication pour une clé.

Options de temps

   Les dates peuvent être exprimées au format YYYYMMDD ou YYYYMMDDHHMMSS. Si l'argument commence par un '+', ou un '-', il est interprété comme relatif au temps présent. Si un tel temps relatif est suivi pas un des suffixes 'y', 'mo', 'w', 'd', 'h', ou 'mi', alors le temps relatif est calculé en année, mois (de 30 jours), semaines, heure ou minute respectivement. Sans suffix, le temps relatif est exprimé en seconde. Pour empêcher de définir une date, utiliser 'none' ou 'never'

Fichiers générés

   Les fichier de clé générés sont nommés sous la forme Knnnn.+aaa+iiiii. Cette chaîne d'identification signifie:

nnnn Est le nom de la clé
aaa La représentation numérique de l'algorithme
iiiii L'identifiant de clé (ou empreinte)

   dnssec-keyfromlabel créé 2 fichiers, avec des noms basés sous la forme Knnnn.+aaa+iiiii.key et Knnnn.+aaa+iiiii.private. Le fichier .key contient un record DNS KEY qui peut être inséré dans un fichier de zone, et le fichier .private contient les champs spécifiques à l'algorithme. Ce fichier n'a pas de permission de lecture.

Exemples

Génerer une clé DSA 768bits pour le domaine example.com
dnssec-keygen -a DSA -b 768 -n ZONE example.com
^
18 mars 2016

htmlpdflatexmanmd




dnssec-revoke

dnssec-revoke

Révoquer des clés DNSSEC. Définis le bit REVOKED dans une clé DNSSEC

OPTIONS

-K directory Répertoire où trouver les clé
-r Après écriture, supprime les fichiers keyset originaux
-v level Définis le niveau de debug
engine Spécifie le hardware cryptographique à utiliser
-f Force l'écrasement
-R Affiche le tag de clé de la clé avec le bit REVOKE mais ne révoque pas la clé
^
18 mars 2016

htmlpdflatexmanmd




dnssec-settime

dnssec-settime

Définis les métadonnées de temps pour une clé DNSSEC

   dnssec-settime lit une clé privée DNSSEC et définis les métadonnées de temps spécifié. Ces métadonnées peuvent être utilisées par dnssec-signzone pour déterminer quand une clé doit être publiée, si elle devrait être utilisée pour signer une zone, etc. Sans options de temps, affiche simplement la métadonnée de temps déjà stockées dans la clé. Quand les champs sont changés, les fichiers sont regénérés.

OPTIONS

-f Force une mise à jours pour une clé au format ancien sans métadonnée.
-K directory Répertoire où trouver les clé
-v level niveau de debug
engine Spécifie le hardware cryptographique à utiliser
-L ttl Définis le ttl par défaut à utiliser pour cette clé quand elle est convertie dans un DNSKEY RR. Si la clé est importée dans une zone, c'est le TTL qui sera utilisée pour elle, sauf si un DNSKEY RRset est déjà définis, auquel cas il a précédence. 0 ou none pour la supprimer
-P date/offset Définis la date à laquelle une clé doit être publiée dans la zone. Après cette date, la clé sera incluse dans la zone mais ne sera pas utilisée pour la signer.
-A date/offset Définis la date à laquelle la clé est activé. Après cette date, la clé sera incluse dans la zone et utilisée pour la signer.
-R date/offset Définis la date à laquelle la clé est révoquée. Après cette date, la clé sera flagé révoquée. Elle sera inclus dans la zone et utilisée pour la signer
-I date/offset Définis la date à laquelle la clé est retiré. Après cette date, la clé sera incluse dans la zone, mais ne sera pas utilisée pour la signer
-D date/offset Définis la date à laquelle la clé est supprimée. Après cette date, la clé ne sera plus incluse dans la zone.
-S predecessor key Sélectionne un clé pour laquel la clé modifiée sera un successeur explicite. Le nom, l'algorithme, la taille et le type de clé doivent correspondre. La date d'activation de la nouvelle clé sera mis à la date de désactivation de cette existante. La date de publication sera définis à la date d'activation moins l'interval de pré-publication, qui est 30 jours par défaut.
-i interval Définis l'interval de pré-publication pour une clé.
-u Affiche les dates au format UNIX epoch
-p C/P/A/R/I/D/all Affiche une valeur de métadonnée spécifique ou toutes les valeurs. C (date de création), P (date de publication), A (date d'activation), R (Date de révocation), I (date de désactivation), D (Date de suppression).

Options de temps

   Les dates peuvent être exprimées au format YYYYMMDD ou YYYYMMDDHHMMSS. Si l'argument commence par un '+', ou un '-', il est interprété comme relatif au temps présent. Si un tel temps relatif est suivi pas un des suffixes 'y', 'mo', 'w', 'd', 'h', ou 'mi', alors le temps relatif est calculé en année, mois (de 30 jours), semaines, heure ou minute respectivement. Sans suffix, le temps relatif est exprimé en seconde. Pour empêcher de définir une date, utiliser 'none' ou 'never'
^
18 mars 2016

htmlpdflatexmanmd




dnssec-signzone

dnssec-signzone

Outil de signature de zone DNSSEC

   dnssec-signzone permet de signer une zone. Il génère des records NSEC et RRSIG et produit une version signée de la zone. Le status de sécurité de la zone signée (c'est à dire si les zones enfants sont sécurisées ou non) est déterminé par la présence ou l'absence d'un fichier keyset pour chaque zone enfant.

OPTIONS

-a Vérifie toutes les signatures générées
-c class Spécifie la classe de la zone
-C mode compatibilité : génère un fichier keyset-zonename en plus de dsset-zonename utilisé par d'anciennes versions de dnssec-signzone
-d directory Répertoire où trouver les fichier dsset- ou keyset-
-D Affiche seulement les type de record automatiquement gérés par dnssec-signzone, ex RRSIG, NSEC, NSEC3 et NSEC3PARAM.
engine Hardware cryptographique à utiliser.
-g Génère les records DS pour les zones enfant depuis le fichier dsset- ou keyset-. Les records DS existant seront supprimés.
-K directory Répertoire où trouver les clés
-k key Traite la clé spécifiée comme clé de signature de clé en ignorant les flags de clé. Peut être spécifié plusieurs fois.
-l domain Génère un set DLV en plus d'un set DS. Le domain spécifié est ajouté au nom des records.
-M maxttl Définis le TTL maximum pour la zone signée. Un TTL supérieur sera réduit à cette valeur dans la sortie.
-s start-time Spécifie la date et l'heure où les records RRSIG deviennent valides
end-time Spécifie la date et l'heure où les records RRSIG expirent.
-X extended end-time Spécifie la date à laquelle les records RRSIG pour le DNSKEY RRset expire. Utilisé dans les cas où les signature DNSKEY doivent persister plus longtemp que les signatures dans d'autres records.
-f output-file Le nom du fichier de sortie contenant la zone signée. par défaut, ajoute .signed au nom du fichier d'entrée.
-i interval Quand un zone précédemment signée est passée en entrée, les records peuvent être resignés. Spécifie le cycle d'interval relatif à l'heure courante (en secondes).
-I input-format Le format du fichier de zone en entrée. peut être text ou raw.
-j jitter En signant une zone avec une durée de vie de signature fixe, tous les records RRSIG émis à la date d'expiration de signature expire en même temps. Si la zone est signée incrémentalement, toutes les signatures expirées doivent être générées au même moment. Cette option spécifie une fenêtre qui est utilisée pour rendre la date d'expiration aléatoire.
-L serial En écrivant une zone signée au format raw ou map, définis la valeur source serial dans l'en-tête à la valeur spécifiée.
ncpus Spécifie le nombre de threads à utiliser. Défaut: 1 thread par CPU
-N soa-serial-format Format du sérial SOA. Peut être keep (ne modifie pas le sérial), increment (incrément le SOA en utilisant l'arithmétique rfc1982) et unixtime(définis le sérial au temps epoch)
-o origin La zone d'origine. Si non spécifié, le nom du fichier de zone est assumé.
-O output-format Le format du fichier de sortie contenant la zone signée. Peut être text (défaut), full (format text utilisable pour le traitement pas des scripts), map, raw, et raw=N où N spécifie la version du format. à 0, le fichier peut être lu pat toute version, à 1 le fichier ne peut être lu que pas la version 9.9.0 ou supérieur. Défaut: 1.
-p Utilise des données pseudo-aléatoire en signant la zone. C'est plus rapide mais moins sécurisé.
-P Désactive le teste de vérification de signature
-Q Supprime les signatures depuis les clés qui ne sont plus actives.
-R Supprime les signatures des clés qui ne sont plus publiées
-r randomdev Spécifie la source de random
-S Recherche dans le répertoire de clés, les clés correspondant à la zone à signer, et les inclus dans la zone si approprié.
-T ttl Spécifie le ttl à utiliser pour les nouveaux records DNSKEY importés dans la zone.
-t Affiche les statistiques une fois terminé
-u Met à jour la chaîne NSEC/NSEC3 en re-signant une zone précédemment signée. Avec cette option, une zone signée avec NSEC peut passer en NSEC3, ou une zone signée avec NSEC3 peut passer en NSEC ou en NSEC3 avec des paramètres différents.
-v level Définis le niveau de debug
-x Signe uniquement le DNSKEY RRset avec les clés key-signing, et omet les signatures des clés zone-signing
-z Ignore le flag KSK dans la clé en déterminant quoi signer. Celà force les clés avec le flag KSK de signer tous les records, pas seulement le DNSKEY RRset.
-3 salt Génère une chaîne NSEC3 avec le salt spécifié (en hexa). Un point peut être utilisé pour indiquer qu'aucun 'salt' n'est utilisé.
-H iterations En générant une chaîne NSEC3, utilise le nombre d'itérations spécifié, 10 par défaut.
-A En générant une chaîne NSEC3, met le flag OPTOUT dans tous les records NSEC3 et ne génère pas de records NSEC3 pour les délégations non sécurisées. -AA désactive le flag OPTOUT pour tous les records, utile avec l'option -u
zonefile Le fichier contenant la zone à signer key
Spécifie quelle clé doit être utilisée pour signer la zone. Sinon recherche les records DNSKEY de la zone.

Exemples

Signer la zone example.com avec la clé DSA générée par dnssec-keygen (Kexample.com.+003+17247).
dnssec-signzone -g -o example.com db.example.com Kexample.com.+003+17247
Re-signer une zone précédemment signée avec les paramètres par défaut. Assume que la clé privée est dans le répertoire courant
cp db.example.com.signed db.example.com
dnssec-signzone -o example.com db.example.com
^
18 mars 2016

htmlpdflatexmanmd




dnssec-verify

dnssec-verify

Outil de vérification de zone DNSSEC

   dnssec-verify vérifie qu'une zone est entièrement signée pour chaque algorithme trouvé dans le RRset DNSKEY pour la zone, et que les chaînes NSEC/NSEC3 sont complètes.

OPTIONS

-c class Spécifie la clé DNS de la zone
engine Hardware cryptographique à utiliser
-I input-format Format du fichier d'entrée text ou raw
-o origin Origine de la zone. Si non spécifié, le nom du fichier de zone est utilisé
-v level niveau de debug
-x Vérifie uniquement le le RRset DNSKEY est signé avec la clé de signature de clé. Dans ce flag, assume de ce RRset est signé par toutes les clé actives.
-z Ignore le flag KSK dans les clé en déterminant si la zone est correctement signée.
^
18 mars 2016

htmlpdflatexmanmd




genrandom

genrandom

Génère un fichier contenant des données aléatoires

   genrandom génère un fichier ou un jeu de fichiers contenant une quantité spécifiée de données pseudo-aléatoires qui peuvent être utilisée comme source d'entropy pour d'autres commandes sur les systèmes dans périphérique aléatoire.

OPTIONS

number Au lieu de générer un fichier, génère n fichiers (de 2 à 9), en ajoutant number au nom de fichier
size Taille du fichier en Ko à générer
filename Nom du fichier à générer
^
18 mars 2016

htmlpdflatexmanmd




host

host

Utilitaire pour effectuer des recherches DNS

   host est un utilitaire simple pour effectuer des recherches DNS. Il est normalement utilisé pour convertir des noms en IP et vice versa.

OPTIONS

-a Equivalent à l'option -v pour une requête ANY
-C tente d'afficher les records SOA pour la zone
-c Spécifie la classe de la requête.
-v, -d mode verbeux
-l mode liste, effectue un transfert de zone. affiche les records NS, PTR A/AAAA
-i les recherches inversées IPv6 doivent utiliser le domaine IP6.INT au lieu de IP6.ARPA
-N Définis le nombre de point qui est considéré comme absolu dans le nom. Si non spécifié, utilise l'option ndots dans /etc/resolv.conf
-R indique combien de fois host va répéter une requête
-r effectue des requêtes non-recursives
-T Utilise TCP pour les requêtes
-4 utilise IPv4 uniquement
-6 utilise IPv6 uniquement
-t type de la requête
-W délai maximum d'attente d'une réponse
-w attend indéfiniment la réponse.
-s n'envoie pas la requête au serveur suivant si le premier répond par un SERVFAIL
-m Définis les flags de debuggage d'utilisation mémoire record, usage et trace
^
13 mars 2010

htmlpdflatexmanmd




inadyn

inadyn

Inadyn est un client DNS dynamique. Il vérifie si l’adresse public a changé et met à jour le serveur dns dynamique.

OPTIONS

--username, -u nom d’utilisateur
--password, -p mot de passe
--alias, -a nom d’hôte, peut apparaitre plusieurs fois.
--input file fichier d’options, par défaut /etc/inadyn.conf
--ip_server_name local-url. Défaut : checkip.dyndns.org /
--dyndns_server_name le serveur qui reçoit la requête de mise à jour DNS.
--dyndns_server_url URL relative au serveur Dyndns root. Ex: /some_script.php?hostname=
--dyndns_system Type de service Dyndns. Devrait être une des valeurs suivante:

        www.dyndns.org dyndns@dyndns.org ou statdns@dyndns.org ou customdns@dyndns.org.
        www.freedns.afraid.org default@freedns.afraid.org
        www.zoneedit.com default@zoneedit.com
        www.no-ip.com default@no-ip.com
        generic DNS system custom@http_svr_basic_auth

--proxy_server [name[:port]] le nom du server proxy http
--update_period délay de vérification de l’IP en ms (défaut 1min, max 10jours)
--update_period_sec délay de vérification de l’IP en secondes (défaut 1min, max 10jours)
--forced_update_period délay pour forcer la mise a jour même si l’IP n’est pas changée (en sec)
--log_file fichier de log
--background lancer en tache de fond, sortie vers le fichier de log ou syslog
--verbose mode verbeux, de 0 à 5
--iterations nombre de mises a jour DNS, 0 par défaut, qui signifie infini.
--syslog force les logs dans syslog
--change_persona uid[:gid] après initialisation, passe sur l’utilisateur:groupe

Exemple

vous pouvez spécifier les options directement dans la commande, ou les placer dans une fichier de config (par défaut /etc/inadyn.conf) :
username user
password password
alias uubu.dyndns.org
dyndns_system dyndns@dyndns.org
update_period_sec 60
log_file /var/log/inadyn.log
change_persona 1002:1002
background
verbose 5
^
18 mars 2016

htmlpdflatexmanmd




isc-hmac-fixup

isc-hmac-fixup

Fixe les clé HMAC générées par d'anciennes versions de BIND

   Les versions de BIND9 jusqu'à BIND 9.6 avaient un bug causant les clé HMAC-SHA* qui étaient plus longues que la longueurs du hash d'être utilisées incorrectement, générant un MAC qui était incompatible avec d'autres implémentations dns.Les secrets qui ont été convertis avec isc-hmac-fixup sont raccourcis.

^
14 septembre 2010

htmlpdflatexmanmd




named

named

service DNS

   named est un serveur de nom de domaine. Invoqué sans argument, named lit le fichier de configuration /etc/named.conf, lit les données initiales et écoute les requêtes.

OPTIONS

-4 utilise IPv4 uniquement
-6 utilise IPv6 uniquement
-c config-file utilise le fichier de configuration spécifié
-d debug-level Définis le niveau de débug
-D string Spécifie la chaîne utilisée pour identifier une instance de named dans la liste de processus.
engine-name Spécifie le hardware cryptographique à utiliser
-f ne place pas le serveur en tâche de fond
-g lance le serveur en tache de fond et force tous les log dans stderr.
-m flag active les flags de debuggage de l'utilisation mémoire.
#cpus Crée #cpus threads pour profiter des systèmes à plusieurs CPU. Défaut: 1 thread par cpu.
-p port Écoute les requêtes sur le port spécifié.
-s Écrit des statistiques d'utilisation mémoire sur stdout en quittant
-S #max-socks Permet à named d'utiliser #max-socks sockets. Défaut: 4096 (21000 lorsque compilé avec --with-tuning=large)
-t directory chroot dans le répertoire spécifié, mais avant de lire le fichier de configuration.
-U #listeners Utilise le nombre de threads pour l'écoute de packets UDP entrants sur chaque adresse. Défaut: CPUs / 2
-u user définit l'utilisateur après avoir complété les opérations privilégiés.
-V Affiche la version et les options de build, puis quitte

Signaux

SIGHUP force named à relire sa configuration
SIGINT,SIGTERM Arrêter le serveur
^
14 septembre 2010

htmlpdflatexmanmd




named-checkconf

named-checkconf

Vérifie la syntaxe de la configuration de named

OPTIONS

-t directory chroot dans le répertoire spécifié
-p Affiche le fichier named.conf et tous les fichiers inclus en forme canonique si aucune erreur n'a été detectée
-x Avec -p, cache les clé partagées en les remplaçant pas des '?'
-z Effectue un teste de charge de toutes les zones master trouvé dans named.conf
-j En chargeant un zonefile lit le journal s'il existe
filename le nom du fichier de configuration à vérifier (défaut /etc/named.conf)
^
14 septembre 2010

htmlpdflatexmanmd




named-checkzone

named-checkzone, named-compilezone

Vérification de validité et d'intégrité

   named-checkzone vérifie la validité et l'intégrité d'un fichier de zone. named-compilezone est similaire, mais il dump toujours le contenu de la zone dans un fichier de zone dans un format spécifié.

OPTIONS

-q mode silencieux
-j En chargeant le fichier de zone, lit le journal s'il existe.
-J filename Lit le journal depuis le fichier spécifié (implique -j)
-c class spécifie la classe de la zone. Si non spécifié "IN" est assumé.
-i mode Effectue des vérifications d'intégrité de zone post-load. les modes possible sont full, full-sibling, local, local-sibling et none

        mode full vérifie que les records MX, SRV et NS refère à un record A ou AAA.
        mode local vérifie seulement que les records MX, SRV et NS refère à des noms d'hôte dans la zone.
        mode full-sibling et local-sibling sont identiques à full et local, mais désactive la vérification du sibling glue.

-f format Spécifie le format du fichier de zone. peut être text ou raw
-F format Spécifie le format du fichier de sortie spécifiée. peut être text ou raw
-k mode Effectue une vérification "check-names" avec le mode d'échec spécifié. Peut être fail, warn ou ignore
-l ttl Définis un TTL max permis pour le fichier d'entrée. Tout enregistrement supérieur implique le rejet de la zone
-m mode Spécifie si les records MX réfèrent à une adresse. Peut être fail, warn ou ignore
-M mode Vérifie si un record MX réfère à un CNAME. peut être fail, warn ou ignore
mode Vérifie si les records NS réfèrent à une adresse. peut être fail, warn ou ignore
-o filename Écrit la sortie dans le fichier spécifié
-r mode Vérifie les records qui sont traités différemment par DNSSEC mais sont sémantiquement égal.
-s style Spécifie le style du fichier de zone dumpé. Peut être full ou relative.
-S mode Vérifie si un record SRV réfère à un CNAME
-t directory chroot au répertoire spécifié
-T mode Vérifie si les record TXT et SPF existent on non. Une erreur est émise s'ils ne correspondent pas. (warn ou ignore)
-w directory chdir vers le répertoire spécifié pour que les chemins relatifs dans les directives $INCLUDE fonctionnent.
-D Dump le fichier de zone au format canonique. Toujours activé pour named-compilezone
-W mode Spécifie si la vérification est pour les non-terminal wildcards
zonename Le nom de domaine de la zone à vérifier
filename Le nom du fichier de zone
^
18 mars 2016

htmlpdflatexmanmd




named-journalprint

named-journalprint

Affiche le journal de zone au format human-readable

   Les fichiers journaux sont automatiquement créés par named quand des changements sont fait dans les zones dynamiques. Chaque ajout ou suppression y est enregistré au format binaire, permettant de ré-appliquer les changements dans la zone quand le serveur est redémarré après un crash. Par défaut, le nom des fichier journaux se terminent avec l'extension .jnl.

^
18 mars 2016

htmlpdflatexmanmd




named-rrchecker

named-rrchecker

Vérificateur de syntaxe pour les RR

   named-rrchecker lit un RR depuis l'entrée standard et vérifie sa syntaxe.

OPTIONS

-o origin Spécifie un origine à utiliser pour interpréter l'enregistrement
-p Affiche l'enregistrement résultant au format canonique
-u Affiche l'enregistrement résultant dans une forme inconnue
-C, -T, -P Affiche la classe, type standard, et type privé, respectivement.
^
18 mars 2016

htmlpdflatexmanmd




nsec3hash

nsec3hash

Générer des hash NSEC3

   nsec3hash génère un hash NSEC3 basé sur un jeu de paramètre NSEC3. Il peut être utilsé pour vérifier la validité des enregistrements NSEC3 dans une zone signée

Arguments

salt Le salt fournis à l'algorithme de hashage
algorithm Un nombre indiquant l'algorithme de hashage. (actuellement 1=SHA-1)
iterations Nombre de temps additionnel de génération de hash
domain Nom du domaine
^
14 septembre 2010

htmlpdflatexmanmd




nsupdate

nsupdate

Envoie des requêtes de mise à jour dynamique

OPTIONS

-d mode debug
-D Affiche des info de debuggage additionnels à -d
-L Définit le niveau de debug.
-g Active le mode GSS-TSIG standard
-o utilise une variant de GSS-TSIG utilisé par windows 2000
-y [hmac:]keyname:secret génère une signature avec [hmac:]keyname:secret
-k keyfile lit le secret partagé depuis le fichier spécifié. Ce fichier peut être de 2 formats différent, un simple fichier contenant une déclaration de clé dans le style named.conf, qui peut être déclaré par ddns-confgen, ou une paire de fichiers dont les noms sont au format Kname.+157.+random.key et Kname.+157.+random.private, qui peuvent être générés par dnssec-keygen.
-l lance nsupdate en mode localhost uniquement. Définis l'adresse du serveur à localhost. Les connections utiliserons une clé TSIG trouvé dans /var/run/named/session.key, automatiquement généré par named si une zone maitre a update-policy à local.
-v force l'utilisation de TCP
-p définis le numéro de port par défaut pour les connections au serveur de nom
-t timeout définis le temps maximum d'une requête de mise à jours avant d'être abordées. défaut 300sec.
-u udptimeout définit l'interval UDP retry. défaut 3 sec. à 0, calcul l'interval depuis le timeout et le nombre de retry.
-r définis le nombre de retry. défaut : 3
-R randomdev Spécifie la source de random.
-P Affiche les listes de type non-méta pour lequels le format de présentation spécifique au type sont connus. Affiche la liste de types privés spécifiques à named.
-T Idem, mais affiche la liste de type assignés par l'IANA

Format d'entrée

server servername [port] Envoie les requêtes au serveur de noms spécifié
local address [port] Envoie les requêtes en utilisant l'adresse local spécifiée.
zone zonename Spécifie que toues les mises à jours sont faites dans la zone spécifiée
class classname Spécifie la calle par défaut
ttl seconds Spécifie le ttl par défaut pour les records. none efface le ttl par défaut
key [hmac:]keyname secret Spécifie le clé pour signer toutes les mises à jours.
gsstsig Utilise GSS-TSIG pour signer la mise à jours. équivalent à -g
ordgsstsig Utilise la version Windows 2000 de GSS-TSIG pour signer la mise à jours. Équivalent à -o
realm [realm_name] Avec GSS_TSIG, utiliser le domaine spécifié au lieu du domaine kerberos de krb5.conf
[prereq] nxdomain domain-name Requière qu'aucun record n'existe avec le nom domain-name
[prereq] yxdomain domain-name Requière que domain-name existe
[prereq] nxrrset domain-name [class] type requière qu'aucun record du type spécifié n'existe.
[prereq] yxrrset domain-name [class] type requière qu'un record du type spécifié existe
[update] del[ete] domain-name [ttl] [class] [type [data...]] supprime tout record correspondant au domain-name, type et class
[update] add domain-name ttl [class] type data... Ajoute un nouveau record
show Affiche le message courant, contenant tous les prérequis et updates spécifiés depuis le dernier envoie
send Envoie le message courant. Est équivalent à entrer une ligne blanche
answer Affiche la réponse
debug Active le debuggage

Exemples

supprimer et ajouter des records pour la zone example.com
nsupdate
› update delete oldhost.example.com A
› update add newshost.example.com 86400 A 172.16.1.1
› send
Vérifie qu'il n'existe pas déjà un record avant de l'ajouter:
nsupdate
› prereq nsdomain nickname.example.com
› update add nickname.exaple.com 86400 CNAME somehost.example.com
› send
^
24 juin 2016

htmlpdflatexmanmd




pkcs11-destroy

pkcs11-destroy

Détruit les clés stockées dans un périphérique PKCS#11

OPTIONS

-m module Spécifie le module PKCS#11
-s slot slot à utiliser en ouvrant la session. Défaut: 0
-i ID Liste seulement les objets avec l'ID spécifié
-l label liste seulement les objets avec le label spécifié
-p PIN Spécifie le PIN pour le périphérique
-w seconds Spécifie le délay avant de détruire la clé. Défaut: 5 secondes. À 0, la destruction est immédiate
^
24 juin 2016

htmlpdflatexmanmd




pkcs11-keygen

pkcs11-keygen

Générer une nouvelle paire de clé

OPTIONS

-a algorithm RSA, DSA, DH, ECC ou un algorithme de signature DNSSEC (ex: NSEC3RSASHA1, ECDSAP256SHA256). Défaut: RSA
-b keysize Taille de la clé (256 ou 384)
 -e Pour RSA uniquement, utilise en grand exporsant
-i id Spécifie l'id pour la création des objets
-m module Spécifie le module PKCS#11
-P Définis la nouvelle clé privée non-sensible et extractible
-p PIN Spécifie le PIN pour le périphérique
-q mode silencieux
-S Pour les clé DH uniquement, utilise un nombre premier spécial 768, 1024 ou 1536 bits.
-s slot slot à utiliser en ouvrant la session. Défaut: 0
^
24 juin 2016

htmlpdflatexmanmd




pkcs11-list

pkcs11-list

Lister les objets PKCS#11

OPTIONS

-P Liste seulement les objets publiques
-m module Spécifie le module PKCS#11
-s slot slot à utiliser en ouvrant la session. Défaut: 0
-i ID Liste seulement les objets avec l'ID spécifié
-l label liste seulement les objets avec le label spécifié
-p PIN Spécifie le PIN pour le périphérique
^
24 juin 2016

htmlpdflatexmanmd




pkcs11-tokens

pkcs11-tokens

Liste les périphériques pkcs#11 disponible

OPTIONS

-m module Spécifie le module PKCS#11
^
13 mars 2010

htmlpdflatexmanmd




resolv.conf

resolv.conf

Configuration des serveurs DNS

   Ce fichier contient le(s) serveur(s) DNS. Ce fichier est automatiquement mis à jour par le client DHCP. Si vous utilisez une configuration réseau fixe, il est necessaire de renseigner ce fichier. Pour spécifier un serveur DNS utiliser la directive nameserver. Vous pouvez spécifier jusqu’à 3 serveurs DNS.

OPTIONS

domain indique le domaine local de la machine. Sans cette options, déduit le domain via gethostname(2), sinon le domain est root.
search indique les domaines de recherche. Normalement déterminé par domain, permet de spécifier des domaines de recherche spécifiques (max 6 - 256 caractères). Pour une liste de sous domaines, utiliser l’option ndots pour éviter les attaques MITM. Cette options peut générer beaucoup de trafic réseau si les domaines listés ne sont pas locaux.
debug active le débuggage
ndots:n seuil pour le nombre de ’.’ qui doivent apparaître dans un nom donné à res_query(3) avant qu’une requête absolue initiale soit faite. défaut : 1, ce qui signifie que si le nom contient un ’.’, il sera d’abord tenté comme nom absolu.
timeout:n Délai en second de timeout d’un requête (défaut 30s)
attemps:n Nombre de tentative de requête avant de retourner une erreur (défaut 5)
rotate effectue un round-robin sur la liste des serveur de noms spécifiés
no-check-names Ne vérifie pas si les noms contiennent des caractères invalide tels que ’_’, caractères non-ascii ou des caractères de contrôle
int6 Affecte les requêtes AAAA avant une requête A dans la fonction gethostbyname(3) et le mappage des réponses IPv4 dans une forme tunnelisée IPv6 si aucun enregistrement AAAA n’est trouvé mais qu’un enregistrement A existe.
ip6-bytestring Les recherches IPv6 inverse sont faites en utilisant le format décrit dans la RFC 2673. Désactivé, le format nibble est utilisé.
ip6-dotint/no-ip6-dotint Désactivé, les recherches inverses IPv6 sont faites dans la zone ip6.int (déprécié), sinon dans ip6.arpa. Activé par défaut
edns0 Active le support pour les extensions DNS (RFC2671)

Exemples

nameserver 81.253.149.9
nameserver 80.10.246.3
nameserver 192.169.1.1
domain uubu.fr
search uubu.fr
options timeout:3
options attempts:4
options rotate
^
21 juin 2016

htmlpdflatexmanmd




rfc4033

rfc4033

Introduction à la sécurité DNS et aux pré-requis

   Les DNS Security Extensions (DNSSEC) sont une collection de nouveaux enregistrements et modifications de protocole qui ajoutent un authentification de l'origine des données et l'intégrité des données à DNS.

Définition des termes DNSSEC important

Authentication Chain Une séquence alternée de RRsets de clé publique DNS (DNSKEY) et de RRset de Delegation Signer (DS) forment une chaîne de donnée signée, et chaque lien dans la chaîne étant garant de la suivante. Un RR DNSKEY est utilisé pour vérifier la signature couvrant un RR DS et permet au RR DS d'être authentifié. Le RR DS contient un hash d'un autre RR DNSKEY et ce nouveau RR DNSKEY en retour authentifie un autre RRset DNSKEY et , en retour, certains RR DNSKEY dans ce jeu peuvent être utilisés pour authentifiier un autre RR DS, et ainsi de suite jusqu'à ce que la fin de la chaîne se termine avec un RR DNSKEY dont la clé privée correspondante signe la donnée DNS souhaitée. Par exemple, le RRset DNSKEY root peut être utilisé pour authentifier le RRset DS pour "example.". Le RRset DS "example." contient un hash qui matche une DNSKEY "example.", et la clé privée correspondante à ce DNSKEY signe le RRset DNSKEY "example." Les RRset DNSKEY signe les données enregistré tel que "www.example." et les RR DS pour les délégation comme "subzone.example."
Authentication key Une clé publique qu'un résolveur a vérifié et peut ainsi l'utiliser pour authentifier les données. Un résolveur peut obtenir les clés d'authentification de 3 manières. D'abord, le résolveur est généralement configuré pour connaître au moins une clé publique; cette donnée configurée est généralement soit la clé publique elle-même ou un hash de la clé publique tel que trouvé dans le RR DS. Ensuite, le résolveur peut utiliser une clé publique authentifiée pour vérifier un RR DS et le RR DNSKEY pour lequel le RR DS réfère. Enfin, le résolveur peut être capable de déterminer qu'une nouvelle clé publique a été signée par la clé privée correspondante à une autre clé publique que le résolveur a vérifié. Noter que le résolveur doit toujours être guidé par la stratégie locale quand il décide d'authentifier une nouvelle clé publique même si la stratégie locale est simplement pour authentifier une nouvelle clé publique pour laquelle le résolveur est capable de vérifier la signature.
Authoritative RRset Dans le contexte d'une zone particulière, un RRset est authoritatif si et seulement si le nom propriétaire du RRset est dans le sous-jeu de l'espace de nom qui est au niveau ou sous le zone apex et au niveau ou sous la séparation de la zone de ses enfant, s'il y en a. Tous les RRsets dans la zone apex sont authoritatifs, excepté pour certains RRsets à ce nom de domaine qui, si présent, appartient au parent de cette zone. Ces RRset peuvent inclure un RRset DS, le RRset NSEC référençant ce RRset DS (le NSEC parental), et les RR RRSIG associés avec ces RRset, tous étant authoritatif dans la zone parente. Similairement, si cette zone contient des points de délégation, seul le RRset NSEC parent, les RRsets DS, et tou RR RRSIG associés avec ces RRsets sont autoritatifs pour cette zone
Delegation Point Terme utilisé pour décrire le nom côté parent d'une coupure de zone. C'est à dire, le point de délégation pour "foo.example" serait le nœud foo.example dans la zone "example" (opposé à l'apex de zone de la zone foo.example").
Island of Security Termet utilisé pour décrire une zone signée et déléguée qui n'a pas de chaîne d'authentification de son parent déléguant. C'est à dire qu'il n'y a pas de RR DS contenant un hash d'un RR DNSKEY pour l'île dans la zone du parent déléguant. Une île de sécurité est désservie par des serveurs de nom sécurisés et peut fournir des chaînes d'authentification à toute zone enfant déléguée. Les réponses d'une île de sécurité ou ses descendants peut seulement être authentifié si ses clés d'authentification peuvent être authentifiés par un moyen de confiance en dehors du protocole DNS
Key Signing Key Une clé d'authentification qui correspond à une clé privée utilisée pour signer une ou plusieurs autres clé d'authentification pour une zone donnée. Typiquement, la clé privée correspondant à une KSK va signer une clé de signature de zone, qui en retour a une clé privée correspondante qui va signer les données de la zone. La stratégie locale peut nécessiter que la clé de signature de zone soit changée fréquemment, alors que la KSK peut avoir une période de validité plus longue pour fournir un point d'entrée sécurisé plus stable dans la zone. Désigner une clé d'authentification comme KSK est purement un problème opérationnel: La validation DNSSEC ne distingue pas les KSK et les autres clé d'authentification DNSSEC, et il est possible d'utiliser une seul clé pour signer les clé et signer la zone.
Non-Validation Security-Aware Stub Resolver Un résolveur sécurisé qui valide un ou plusieurs serveurs de noms récursifs sécurisés pour effectuer plus de tâches discutés dans ce document. En particulier, un tel résolveur est une entité qui envoie des requêtes DNS, reçois les réponses DNS, et est capable d'établir un canal sécurisé approprié vers un serveur récursif sécurisé qui fournir ces services à la demande.
Non-Validating Sub Resolver Un terme plus simple pour Non-Validation Security-Aware Stub Resolver
Security-Aware Name Server Une entité agissant dans le rôle d'un serveur de noms qui comprend les extensions de sécurité DNS définis dans ce document. En particulier, un serveur de nom sécurisé est une entité qui reçois des requêtes DNS, envoie des réponses DNS, supporte l'extension EDNS0 et le bit D0, et supporte les types RR et bits d'en-tête de messages définis dans ce document.
Security-Aware Recursive Name Server Une entité qui agit comme serveur de nom sécurisé et résolveur sécurisé.
Security-Aware Resolver Une entité agissant dans le rôle d'un résolveur qui comprend les extensions de sécurité DNS pour fournir des services additionnels. Ces résolveurs peuvent être soit validateurs soit non-validateurs, dépendant si le résolveur vérifie les signatures DNSSEC par lui-même ou fait confiance à un serveur de nom sécurisé pour le faire.
Security-Oblivious ‹anything} tout ce qui n'est pas sécurisé
Signed Zone Une zone dont les RRset sont signés et qui contiennent des enregistrements DNSKEY, RRSIG, NSEC et optionnellement DS
Trust Anchor Un RR DNSKEY configuré ou un hash RR DS d'un RR DNSKEY. Un résolveur sécurisé validant utilise cette clé publique ou le hash comme point de départ pour construire la chaîne d'authentification d'une réponse DNS. En général, un résolveur validateur obtient les valeurs initiales de ses ancres de confiance via un moyen sécurisé en dehors du protocole DNS. La présence d'une ancre de confiance implique également que le résolveur s'attende à ce que la zone vers laquelle l'ancre de confiance soit signée.
Unsigned Zone Une zone qui n'est pas signée
Validating Security-Aware Stub Resolver Un résolveur sécurisé qui envoie des requêtes en mode récursif mais qui valide la signature par lui-même au lieu de simplement faire confiance à un serveur de nom sécurisé.
Validating Stub Resolver Un terme plus simple pour Validating Security-Aware Stub Resolver
Zone Apex Terme utilisé pour décrire le nom d'une coupure de zone côté client
Zone Signing Key Une clé d'authentification qui correspond à une clé privée utilisée pour signer une zone. Typiquement, une ZSK fait partie du même RRset DNSKEY que la KSK dont la clé privée correspondante signe ce RRset DNSKEY, mais la ZSK est utilisée dans un but différent et peut être différente de la KSK en autre, sur sa durée de vie.

Services fournis par la sécurité DNS

   Les extensions de sécurité DNS fournissent l'authentification de l'origine des données et l'intégrité des données, incluant les mécanismes pour authentifier le refus de l'existance de données DNS.

   Ces mécanismes nécessitent de changer le protocole DNS. DNSSEC ajoute 4 nouveaux types d'enregistement de ressource: Resource Record Signature (RRSIG), DNS Publik Key (DNSKEY), Delegation Signer (DS), et Next Secure (NSEC). Il ajoute également 2 nouveaux bits d'en-tête: Checking Disables (CD) et Authenticated Data (AD). Pour supporter des tailles de messages DNS plus grands, DNSSEC exige le support EDNS0. Finallement, DNSSEC nécessite le support pour le bit d'en-tête DNSSEC OK (DO) pour qu'un résolveur sécurisé puissent indiquer dans ses requêtes qu'il souhaite reçevoir les RR DNSSEC dans les réponses.

Authentification de l'origine des données et intégrité des données

   DNSSEC fournis l'authentification en associant des signature numérique générées cryptographiquement avec les RRset DNS. Ces signatures numérique sont stockées dans un nouvel enregistrement de ressource, l'enregistrement RRSIG. Généralement, il y a une seule clé privée qui signe les données d'une zone, mais plusieurs clés sont possibles. Par exemple, il peut y avoire des clés pour chaque algorithme de signature. Si un résolveur sécurisé apprend un clé publique de zone, il peut authentifier les données signées de cette zone. Un concept DNSSEC important est que la clé qui signe les données d'une zone est associée avec la zone elle-même et pas avec les serveurs de nom ayant autorité sur la zone. (Les clé publique pour les mécanismes d'authentification de transaction DNS peuvent également apparaître dans les zone, mais DNSSEC lui-même est concerné par la sécurité des données DNS, par la sécurité des canaux de transaction DNS. Les clés associées avec la sécurité des transaction peuvent être stockés dans des types RR différents)

   Un résolveur sécurisé peut apprendre une clé publique d'une zone soit en ayant une ancre de confiance configuré dans le résolveur ou par résolution normale DNS, auquel cas les clé publiques sont stockées dans un nouveau type d'enregistrement de ressource, le RR DNSKEY. Noter que les clés privées utilisée pour signer les donées de la zone doivent être conservé de manière sécurisés et devraient être stockés hors-line. Pour découvrir un clé publique de manière sûre via la résolution DNS, la clé cible elle-même doit être signée par une clé d'authentification configurée ou une autre clé qui a été authentifiée précédemment. Les résolveurs sécurisés authentifient les information de zone en formant une chaîne d'auhentification depuis une nouvelle clé publique apprise vers une clé publique authentifiée connue, qui en retour a été soit configurée dans le résolveur ou doit avoir été apprise et vérifiée précédemment. Donc, le résolveur doit être configuré avec au moins un trust anchor.

   Si l'ancre de confiance configurée est une clé de signature de zone, elle authentifie la zone associée; si la clé configurée est une clé de signature de clé, elle authentifie une clé de signature de zone. Si l'ancre de confiance configuré est le hash d'une clé au lieu de la clé elle-même, le résolveur peut obtenir la clé via une requête DNS. Pour aider les résoleurs à établir cette chaîne d'authentification, les serveurs de noms tentent d'envoyer les signatures nécessaire à authentifier les clé publique de la zone dans le message de réponse DNS avec la clé publique elle-même.

   Le type RR Delegation Signer (DS) simplifie certaines tâches administratives en signant les délégation entre les limites administratives. Le RRset DS réside au point de délégation dans une zone parent et indique les clé publique correspondante aux clé privées utilisée pour signer les RRset DNSKEY dans l'apex de zone enfant déléguée. L'administrateur de la zone enfant, en retour, utilise les clés privée correspondantes à une ou plusieurs des clé publique dans ce RRset DNSKEY pour signer les données de la zone enfant. La chaîne d'authentification est donc DNSKEY-›[DS›DNSKEY]*-›RRset, où '*' dénote 0 ou plusieurs sous-chaînes DS-›DNSKEY. DNSSEC permet des chaînes d'authentification plus complexes, tels que des couches additionnelles de RR DNSKEY signant d'autres RR DNSKEY dans une zone.

   Un résolveur sécurisé construit normalement cette chaîne d'authentification depuis la racine de la hiérarchie DNS jusqu'aux zones basés sur une connaissance configurée de la clé publique pour root. La stratégie locale, cependant, peut également permettre au résolveur d'utilisen une ou plusieurs clé publique configurées (ou hash de ces clé) autre que la clé publique root, peuvent ne pas fournir de connaissance configuré de la clé publique root, ou peuvent empêcher le résolveur d'utiliser des clé publique particulières pour des raisons arbitraires, même si ces clés publique sont signées correctement et vérifiables. DNSSEC fournis des mécanismes par lesquels un résolveur peut déterminer si la signature d'un RRset est valide. Dans l'analyse finale, cependant, authentifier les clé DNS et les donnée est sujet à la stratégie locale, qui peut étendre ou même remplacer les extensions de protocole définis dans ce document.

Authentifier les noms et la non-existence de type

   Le mécanisme de sécurisé décris ci-dessus ne fournis qu'une manière de signer des RRset exsistant dans une zone. Le problème des réponses négatives avec le même niveau d'intégrité et d'authentification exige l'utilisation d'un nouveau type d'enregistrement de ressource, NSEC. NSEC permet à un résolveur d'authentifier une réponse négative depuis soit le nom, ou la non-existance du type avec les même mécanisme utilisés pour authentifier les autres réponses DNS. L'utilisation des enregistrements NSEC nécessite une représentation canonique et d'ordre pour les noms de domaine dans les zones. Les chaînes d'enregistrement NSEC décrivent explicitement les gaps, ou espace vides, entre les noms de domaine dans une zone et la liste des types de RRset présent aux noms existant. Chaque enregistrement NSEC est signé et authentifié en utilisant les mécanismes décris plus haut.

Services non-fournis par la sécurité DNS

   DNS a été conçus à l'origine avec la supposition que DNS retourne la même réponse à une requête donnée sans regarder qui a émis la requête, et que toutes les données dans DNS est donc visible. DNSSEC n'est pas conçus pour fournir la confidentialité, les listes de contrôle d'accès, ou d'autres moyens de différencier les questionneurs.

   DNSSEC ne fournis pas de protection contre les attack DOS. Les résolveurs et les serveurs de nom sécurisé sont vulnérables à uen classe d'attaque DOS additionnel basé sur les opérations cryptographiques.

   Les extensions de sécurité DNS fournissent l'authentification de l'origine des données DNS. Les mécanismes définis plus haut ne sont pas conçus pour protéger es opérations telles que les transferts de zone et les mises à jours dynamiques. Les schéma d'authentification de message décris dans les rfc2845 et rfc3007 adressent les opérations de sécurité pour ces transactions.

Périmètre du document et problème Last Hop

   La spécification dans ce jeu de document définis le comportement pour les signataires de zone et les serveurs de nom sécurisés et les résolveurs qui valident les entités peuvent déterminer de manière non-ambigües l'état des données. Un résolveur validateur peut déterminer les 4 états suivants:

Secure Le résolveur validant a une ancre de confiance, a une chaîne de confiance, et est capable de vérifier toutes les signatures dans la réponse.
Insecure Le résolveur validant a une ancre de confiance, une chaîne de confiance, et, à certains points de délégation, la preuve signées de la non-existance d'un enregistrement DS. Celà indique que les branches sous-jacents dans l'arborescence sont probablement non-sécurisés. Un résolveur peut avoir une stratégie local pour marquer les parties de l'espace de domaine comme insécure.
Bogus Le résolveur validant a une ancre de confiance et une délégation sécurisée indique que les données subsidiaires sont signées, mais la réponse échoue la validation: signatures manquantes, signatures expirées, signatures avec des algorithmes non-supportés, données manquantes, etc.
Indeterminés Il n'y a pas d'ancre de confiance qui indique qu'une portion spécifique de l'arborescence est sécurisé. C'est le mode d'opération par défaut.

   Cette spécification définis seulement comment les serveurs de nom sécurisés peuvent signaler aux résolveurs non-validateurs que les données trouvés sont à l'état bogus (en utilisant RCODE=2 "Server Failure")

   Il y a un mécanisme pour les serveurs de nom sécurisés pour signaler aux résolveurs sécurisé que les données sont sécurisés (en utilisant le bit AD)

   Cette spécification ne définis pas de format pour communiquer la raison des réponses bogus ou insecure.

   Une méthode pour signaler les codes d'erreur avancés et les stratégies entre un résolveur sécurisé et les serveurs de noms récursifs est un sujet pour un travail future, tout comme l'interface entre un résolveur sécurisé et les applications qui l'utilisent. Noter, cependant, que le manque de spécification d'une telle communication n'empêche pas de déployer des zones signées ou le déploiement de serveurs de noms récursifs sécurisés qui empêchent la propagation de données bogus aux applications.

Considérations du résolveur

   Un résolveur sécurisé doit être capable d'effectuer des fonctions cryptographiques nécessaires à la vérification de signatures numérique en utilisant au moins les algorithmes obligatoire. Ces résolveurs doivent être capable de former une chaîne d'authentification depuis une nouvelle zone apprise vers une clé authentifiée, tel que décris plus haut. Ce processus peut nécessiter des requêtes additionnelles aux zones intermédiaires pour obtenir les enregistrements DNSKEY, DS, et RRSIG. Un résolveur devrait être configuré avec au moins une ancre de confiance comme point de départ depuis lequel il tente d'établir les chaînes d'authentification.

   Si un résolveur est séparé des serveurs de nom autoritatifs par un serveur de nom récursif ou par un périphérique intermédiaire qui agit comme proxy pour DNS, et si le serveur de nom récursif ou le périphérique intermédiaire n'est pas sécurisé, le résolveur n'est pas capable d'opérer dans un mode sécurisé. Par exemple, si les paquets d'un résolveur sont routés via un NAT qui inclus un proxy DNS qui n'est pas sécurisé, le résolveur peut avoir des difficultés ou l'impossibilité d'obtenir ou valider la données DNS signée.

   Si un résolveur sécurisé doit faire confiance à une zone non-signée ou un serveur de nom qui n'est pas sécurisé, le résolveur n'est pas capable de valider les réponses DNS et à besoin d'une stragégie locale pour accepter les réponses non-vérifiées

   Un résolveur sécurisé doit prendre en compte la période de validité en déterminant le TTL des données en cache, pour éviter que les données signées en cache soient au-delà de la période de validité de la signature. Cependant, il devrait être permis que l'horloge du résolveur soit fausse. Donc, un résolveur qui fait partie d'un serveur de nom récursif doit faire attention aux bit CD. Cela permet d'éviter le blocage des signatures valide via d'autres résolveurs qui sont clients de ce serveur de nom récursif.

Considérations du résolveur cache

   Bien que non strictement requis par le protocole, beaucoups de requêtes DNS ont pour origine les résolveurs cache. Ces résolveurs, par définition, sont des résolveurs minimals qui utilisent les requête récursives pour décharger le travaille de la résolution DNS à un serveur de nom récursif. L'architecture DNSSEC doit prendre en compte les résolveurs cache, mais les fonctionnalités de sécurité dans le résolveur cache diffèrent de ceux nécessaires dans un résolveur itératif sécuris.

   Même un résolveur cache non sécurisé peut bénéficier de DNSSEC si les serveurs de noms récursifs qu'il utilise sont sécurisés, mais pour que le résolveur cache puisse s'appuyer sur les services DNSSEC, le résolveur doit faire confiance à serveurs de nom récursifs en question et aux canaux de communication entre lui et ces serveurs de nom. Le premier de ces problème est un problème de stratégie locale: un résolveur non-sécurisé n'a pas le choix mais se place lui-même à la merci des serveurs de noms récursifs qu'il utilise, vu qu'il ne valide pas DNSSEC. Le second problème nécessite un mécanisme de canal sécurisé; l'utilisation des mécanismes d'authentification de transaction sécurisé comme SIG(0) ou TSIG est suffisant, et est approprié avec IPsec. Les implémentations peuvent avoir d'autres choix disponible, tels que des mécanisme de communication interprocess spécifiques à l'OS. La confidentialité n'est pas nécessaire pour ce canal, mais l'intégrité des données et l'authentification des messages le sont.

   Un résolveur sécurisé fait confiance aux serveurs de noms sécurisé et ses canaux de communication et peut choisir d'examiner le bit AD dans l'en-tête des messages qu'il reçoit. Le résolveur peut utiliser ce flag pour voir si le serveur de nom récursif est capable de valider les signatures pour toutes les données dans les sections d'autorité et de réponse

   Il y a une étape de plus qu'un résolveur sécurisé peut effectuer, s'il n'est pas capable d'établir une relation de confiance avec les serveurs de nom récursifs qu'il utilise: il peut effectuer sa propre validation de signature en définissant le bit CD dans ses requêtes. Un résolveur est capable de traiter les signatures DNSSEC comme relation de confiance entre les administrateurs de zone et le résolveur lui-même.

Considérations de zone

   Il y a de nombreuses différences entre des zones signées et non-signées. Une zone signée contient des enregistrements liées à la sécurité additionnels (RRSIG, DNSKEY, DS, et NSEC). Les enregistrements RRSIG et NSEC peuvent être générées par un procéssus de signature avec de servir la zone. Les enregistrements RRSIG qui accompagnent les données de zone ont une date de création et d'expiration définis qui établissent une période de validité pour les signatures et les données de zone que les signatures couvrent.

Valeurs TTL vs Période de validité RRSIG

   Il est important de noter la distinction entre la valeur TTL des RRset et la période de validité de signature spécifiée par le RR RRSIG couvrant ce RRset. DNSSEC ne change par la définition ou la fonction de la valeur TTL, qui est prévue pour maintenir la cohérence de la base dans les caches. Un résolveur cache purge les RRest de ses caches à la fin de la période spécifiée par les champs TTL et ces RRsets, sans regarder si le résolveur est sécurisé.

   Les champs de création et d'expiration dans le RR RRSIG, spécifient la période durant laquelle la signature peut être utilisée pour valider les RRset couvert. Les signatures associées avec les données de zone signées sont seulement valides pour la période de temps spécifiés par ces champs dans les RR RRSIG en question. Les valeurs TTL ne peuvent pas étendre la période de validit des RRset signés dans le cache du résolveur, mais le résolveur peut utiliser le temps restant avant l'expiration du la période de validité de la signature d'un RRset comme limite supérieur pour le TTL du RRset signé et ses RR RRSIG associés dans le cache.

Problème de dépendance temporelle pour les zones

   L'information dans une zone signée a une dépendance temporelle qui n'existe pas dans le protocole DNS original. Une zone signée nécessite une maintenance régulière pour s'assurer que chaque RRset dans la zone a un RR RRSIG valide. La période de validité de signature d'un RR RRSIG est un interval durant lequel la signature pour un RRset signé particulier peut être considéré comme valide, et les signatures des différents RRset dans une zone peuvent expirer à des moments différents. Resigner un ou plusieurs RRset dans une zone va changer un ou plusieurs RR RRSIG, qui en retour nécessite d'incrémenter le numéro de série SOA de la zone pour indiquer qu'une zone a changé et resigner le RRset SOA lui-même. Donc, resigner un RRset dans une zone peut également déclencher des messages DNS NOTIFY et des opération de transfert de zone.

Considérations de serveur de nom

   Un serveur de nom sécurisé devrait inclure les enregistrements DNSSEC appropriés (RRSIG, DNSKEY, DS, et NSEC) dans toutes les réponses aux requêtes des résolveurs qui ont signalé leur volonté de recevoir de tels enregistrement via l'utilisation du bit DO dans l'en-tête EDNS, sujet aux limitations de taille de message. À cause de l'ajout de ces RR DNSSEC pouvant facilement tronquer le message UDP et retourner en TCP, un serveur de nom sécurisé doit également supporter le mécanisme UPD "sender's UDP payload".

   Si possible, la partie privée de chaque paire de clé DNSSEC devrait être conservée hors-ligne, mais ce n'est pas possible pour une zone pour laquelle les mises à jours dynamiques sont permis. Dans le cas des mises à jours dynamiques, le serveur maître primaire pour la zone doit resigner la zone quand elle est mise à jours, dont la clé privée correspondant à la ZSK doit être online. C'est une exemple de situation dans laquelle la capacité de séparer le RRset DNSKEY de la zone en ZSK et KSK peut être utile, vu que la KSK peut rester offline et peut avoir une durée de vie plus longue que les ZSK.

   Par lui-même, DNSSEC n'est pas suffisant pour protéger l'intégrité d'une zone durant les opérations de transfert de zone, vu que même une zone signée contient des données non-signées, non-authoritatives si la zone a des enfants. Donc, les opérations de maintenance de zone nécessitent des mécanismes additionnels (tels que TSIG, SIG(0) ou IPsec)

Famille de document de sécurité DNS

   Le jeu de document DNSSEC peut être partitionné en plusieurs groupes sous les documents du protocole DNS de base. Les jeu de document de protocole DNSSEC réfère à 3 documents qui forment le cœur des extensions de sécurité DNS:

1. Introduction et exigents pour la sécurité DNS (ce document)
2. Enregistrements de ressource pour les extensions de sécurité DNS (rfc4034)
3. Modification de protocole pour les extensions de sécurité DNS (rfc4035)

   Le jeu de document de spécification d'algorithme de signature numérique réfère au groupe de documents qui décrivent comme les algorithmes de signature numérique devraient être implémentés dans DNSSEC. Voir la rfc4034 pour la liste des algorithmes définis.

   Le jeu de documents de protocole d'authentification de transaction réfère au groupe de documents qui gérènt l'authentification des messages DNS, incluant l'établissement et la vérification des clé secrètes.

   Je jeu de document d'utilisation des nouvelles sécurités réfère aux documents qui visent à utiliser les extensions de sécurité DNS proposés pour d'autres but de sécurité. DNSSEC ne fournis pas de sécurité directe pour ces nouvelles utilisations mais peuvent être utilisé pour les supporter. Les documents qui rentre dans cette catégorie incluent l'utilisation de DNS dans le stockage et la distribution de certificats
^
27 juin 2016

htmlpdflatexmanmd




rfc4034

rfc4034

Enregistrements de ressource pour les extensions de sécurité DNS

   Les extensions de sécurité DNS introduisent 4 nouveaux type d'enregistrement de ressource DNS: DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), Next Secure (NSEC), et Delegation Signer (DS). Ce document définis le but de chacun de ces RR, le format RDATA de ces RR, et leur format de présentation (ASCII).

   DNSSEC utilise la cryptographie à clé publique pour signer et authentifier les jeus d'enregistrement de ressources (RRsets). Les clé publiques sont stockées dans les RR DNSKEY et sont utilisé dans le processus d'authentification DNSSEC.: Une zone signe son RRset authoritatif en utilisant une clé privée et stocke la clé publique correspondante dans un RR DNSKEY. Un résolveur peut ainsi utiliser la clé publique pour valider les signature couvrant les RRset dans la zone, et donc les authentifier.

   Le RR DNSKEY n'est pas prévu comme un enregistrement pour stocker des clé publiques arbitraires et ne doit pas être utilisé pour stocker des certificats ou des clé publiques non liées à l'infrastructure DNS.

   La valeur Type pour le RR DNSKEY est 48, le RR DNSKEY est indépendant de la class et n'a pas de requis de TTL spécial.

Format DNSKEY RDATA

Le RDATA pour un RR DNSKEY consiste d'un champ de Flags à 2 octets, un champ Protocole 1 octet, en champ Algorithme 1 octet, et le champ de clé publique:
_____________________1_1_1_1_1_1_1_1_1_1_2_2_2_2_2_2_2_2_2_2_3_3____
____0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
___|______________Flags____________|____Protocol___|___Algorithm___|
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
___/_______________________________________________________________/
___/____________________________Public_Key_________________________/
___/_______________________________________________________________/
___+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Flags

   Le bit 8 est le flag de clé de zone. Si le bit 7 est mis, l'enregistrement DNSKEY maintient une clé de zone DNS, et le nom propriétaire du RR DNSKEY doit être le nom d'une zone. S'il est non-mis, l'enregistrement DNSKEY maintien un autre type de clé publique DNS et ne doit pas être utilisé pour vérifier les RRSIG qui couvrent les RRsets.

   Le bit 15 est le flag de point d'entrée sécurisé, décris dans la rfc3757. Mis, l'enregistrement DNSKEY maintient une clé utilisée comme point d'entrée. Ce flag est seulement prévu pour être un départ de signature de zone, ou pour débugger les logiciel; les validateurs ne doivent pas altérer leur comportement durant le processus de validation de signature en se basant sur ce bit. Il signifie également qu'un RR DNSKEY avec le bit SEP mis à également besoin du flag Zone Key mis pour être capablede générer des signature légalement. Un RR DNSKEY avec SEP mis et le bit 7 non mis ne doivent pas être utilisés pour vérifier les RRSIG qui couvrent les RRsets.

Champ Protocol

   Le champ Protocol doit avoir la valeur 3, et le RR DNSKEY doit être traité comme invalide durant la vérification de la signature si une autre valeur est trouvée.

Champ Algorithm

   Identifie l'algorithme cryptographique à clé publique et détermine le format du champ de clé publique.

Champ Public Key

   Maintien la clé publique. Le format dépend de l'algorithme de la clé stockée et est décrit dans un document séparé.

Notes sur le design de DNSKEY RDATA

   Bient que le chaps Protocol a toujours la valeur 3, il est retenu pour compatibilité avec les premières versions de l'enregistrement KEY

Format de présentation des RR DNSKEY

   Le format de présentatin de la portion RDATA est comme suit:

- Le champ Flag doit être représenté comme entier décimal non-signé. Avec les flags actuellement définis, les valeurs possibles sont: 0, 256 et 257.
- Le champ protocol doit être représenté comme entier décimal non-signé avec une valeur de 3
- Le champ algorithm doit être resprésenté comme entier décimal non-signé, ou comme mnémonique d'algortihme.
- La clé publique doit être représentée en base64.

Exemple de RR DNSKEY

Le RR DNSKEY suivant stocke un clé de zone DNS pour example.com.
example.com. 86400 IN DNSKEY 256 3 5 (_AQPSKmynfzW4kyBv015MUG2DeIQ3
_______________________________________Cbl+BBZH4b/0PY1kxkmvHjcZc8no
_______________________________________kfzj31GajIQKY+5CptLr3buXA10h
_______________________________________WqTkF7H6RfoRqXQeogmMHfpftf6z
_______________________________________Mv1LyBUgia7za6ZEzOJBOztyvhjL
_______________________________________742iU/TpPSEDhm2SNKLijfUppn1U
_______________________________________aNvv4w==__)

   Les 4 premiers champs spécifient le nom propriétaire, le TTL, la Classe , et le type de RR (DNSKEY). Une valeur 256 indique que le bit de clé de zone est mis. La valeur 3 est la valeur de protocole. La valeur 5 indique l'algorithme à clé publique (RSA/SHA1). Le reste est la clé publique encodé en base64

L'enregistrement de ressource RRSIG

   DNSSEC utilise la cryptographie à clé publique pour signer et authentifier les RRset. Les signatures numériques sont stockées dans les RRSIG et sont utilisé dans le processus d'authentification DNSSEC décris dans la rfc4035. Un validateur peut utiliser ces RRSIG pour authentifier les RRest de la zone. Le RR RRSIG doit seulement être utilisé pour valider les signatures numérique utilisés pour sécuriser les opérations DNS.

   Un enregistrement RRSIG contient la signature pour un RRset avec un nom, classe et type. Le RR RRSIG spécifie un interval de validité pour la signature et utilise Algorithm, nom du signataire, et le Key Tag pour identifier le RR DNSKEY contenant la clé publique qu'un validateur peut utiliser pour vérifier la signature.

   Parce que tout RRset authoritatif dans une zone doit être protégé par une signature numérique, les RR RRSIG doivent être présents pour les noms contenant un RR CNAME. C'est un changement de la spécification DNS (rfc1034), qui status que si un CNAME est présent pour un nom, il est seulement du type permis pour ce nom. Un RRSIG et NSEC doivent exister pour le même nom qu'un enregistrement de ressource CNAME dans une zone signée.

   La valeur de Type pour le RR RRSIG est 46. Le RR RRSIG est indépendant de la classe. Un RR RRSIG doit avoir la même classe que le RRset qu'il couvre. La valeur TTL d'un RRSIG doit correspondre au TTL du RRset qu'il couvre. C'est une exception des règles de la rfc2181 pour les valeurs TTL des RR individuels dans un RRset: les RR RRSIG individuels avec le même nom propriétaire ont différentes valeur TTL si le RRset qu'ils couvrent ont différentes valeurs TTL.

Format RRSIG RDATA

Le RDATA pour un RR RRSIG consiste d'un champ Type à 2 octets, un champ Algorithm à 1 octet, un champ Labels 1 octet, un champ TTL 4 octets, un champ Signature Expiration 4 octets, un champ Signature Inception 4 octets, en tag Key 2 octets, le champ du nom du signataire et le champ Signature.
_-_-_-_-_-_-_-_-_-_-_1_1_1_1_1_1_1_1_1_1_2_2_2_2_2_2_2_2_2_2_3_3_
_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_2_3_4_5_6_7_8_9_0_1_
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|________Type_Covered___________|__Algorithm____|_____Labels____|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_________________________Original_TTL__________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|______________________Signature_Expiration_____________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|______________________Signature_Inception______________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|____________Key_Tag____________|_______________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_________Signer's_Name_________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________________________________________________/
/____________________________Signature__________________________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Type Covered

   Ce champ identifie le type du RRset couvert pas cet enregistrement RRSIG

Champ Algorithm Number

   Ce champ identifie l'algorithme cryptographique utilisé pour créer la signature.

Champ Labels

   Spécifie le nombre de labels dans le nom propriétaire du RR RRSIG. La signification de ce champs est qu'un validateur l'utilise pour déterminer si la réponse a été synthétisée depuis un wildcard. Si c'est le cas, il peut être utilisé pour déterminer quel nom propriétaire a été utilisé pour générer la signature.

   Pour valider une signature, le validateur a besoin du nom propriétaire original qui a été utilisé pour créer la signature. Si ce nom contient un label wildcard, le nom propriétaire peut avoir été étendu par le serveur durant le processus de réponse, auquel cas le validateur doit reconstruire le nom original pour pouvoir valider la signature. La rfc4035 décris comment utiliser le champ Labels pour reconstruire le nom propriétaire original.

   La valeur du champ Label ne doit pas compter le label null (root) qui termine le nom propriétaire ni le label wildcard. La valeur du champ Labels doit être inférieur ou égal au nombre de labels dans le nom propriétaire RRSIG. Par exemple, "www.example.com." a une valeur de champ Labels de 3, et "*.example.com." a une valeur de 2. Root ('.') a une valeur de 0.

   Bien que le label wildcard n'est pas inclus dans le compteur stocké dans le champ Labels du RR RRSIG, le label wildcard fait partie du nom propriétaire du RRset quant la signature est générée ou vérifiée.

Champ TTL Original

   Spécifie le TTL du RRset couvert tel qu'il apparaît dans le zone authoritative.

   Ce champ est nécessaire parce que le cache du résolveur décrémente la valeur TTL d'un RRset en cache. Pour valider une signature, un validateur nécessite le TTL original. la rfc4035 décris comment utiliser ce champ pour reconstruire le TTL original.

Champs Signature Expiration et Inception

   Ces champ spécifie la période de validité pour la signature. L'enregistrement RRSIG ne doit pas être utilisé pour authentifier avant la date de début, et ne doit pas être utilisée pour l'authentification après la date d'expiration.

   Ce champsspécifie une date et heure sous la forme d'un nombre non-signé 32bits en secondes depuis le 1 Janvier 1970 00:00:00 UTC. L'interval le plus long qui peut être exprimé par ce format est approximativement de 136ans. Un RR RRSIG peut avoir un champ Expiration qui est numérique plus petit que le champ Inception si la valeur du champ du champ d'expiration est proche du maximum 32bits ou si la signature a une durée de vie longue.

Champ Key Tag

   Contient la valeur de tag de clé du RR DNSKEY qui valide cette signature.

Champs Signer's Name

   Ce champ identifie le nom propriétaire du RR DNSKEY qu'un validateur est supposé utiliser pour valider cette signature. Ce champ doit contenir le nom de la zone du RRset couvert. Un émetteur ne doit pas utiliser la compression de nom DNS dans ce champ en transmettant un RR RRSIG

Champ Signature

   Le champ signature contient la signature cryptographique qui couvre le RDATA RRSIG (excluant le champ signature) et le RRset spécifié par le nom du RRSIG, la classe RRSIG, et le type RRSIG. Le format de ce champ dépend de l'algorithme utilisé.

Calcul de Signature

Une signature couvre le RDATA RRSIG et couvre les données RRset spécifiées par le nom propriétaire RRSIG, la classe et le type couvert RRSIG. Le RRset est sous la forme canonique et est signé comme suit:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )

ou '|' dénote une concaténation. RRSIG_RDATA est le format des champs RDATA RRSIG avec le champ Signer's Name sous forme canonique et le champ Signature est exclus.
RR(i) = owner | type | class | TTL | RDATA length | RDATA

   owner est le nom propriétaire pleinement qualifié du RRset sous la forme canonique. Chaque RR doit avoir le même nom propriétaire et la même classe que le RR RRSIG. Chaque RR dans le Rset doit avoir le type RR listé dans le champ Type Covered du RR RRSIG. Tous nom DNS dans le champ RDATA de chaque RR doit être sous la forme canonique, et le RRset doit être trié dans l'ordre canonique.

Format de présentation RR RRSIG

   Le format de présentation de la portion RDATA est comme suit:

- Le champ Type Covered est représenté comme un mnémonique du type RR. Quand le mnémonique n'est pas connus, la représentation du TYPE rfc3597 doit être utilisé.
- Le champ Algorithm doit être représenté soit comme entier décimal non-signé ou comme mnémonique.
- Le champ Labels doit être représenté comme entier décimal non-signé
- Le champ Original TTL doit être représenté comme entier décimal non-signé
- Les champs Signature Expiration Time et Inception Time doivent être représenté soit comme entier décimal non-signé indiquant les secondes depuis le 1 Janvier 1970 00:00:00 UTC, ou sous la forme YYYMMDDHHmmSS en UTC.

           Noter qu'il est toujours possible de faire la distinction entre les 2 format parce que le format YYYYMMDDHHmmSS fait toujours exactement 14 chiffres, alors que la représentation décimale 32bits ne peut jamais dépasser 10 chiffres.

- Le champ Key Tag doit être représenté comme entier décimal non-signé
- Le champ Signer's Name doit être représenté en nom de domaine
- Le champ Signature est représenté en Base64.

Exemple de RR RRSIG

Le RR RRSIG suivant stocke la signature pour un RRset A de host.example.com:
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
_______________________________20030220173103 2642 example.com.
_______________________________oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
_______________________________PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
_______________________________B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
_______________________________GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
_______________________________J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

   Les 4 premiers champs spécifient le nom propriétaire, le TTL, la classe, et le type RR (RRSIG). Le A represente le type couvert. La valeur 5 identifie l'algorithme (RSA/SHA1), la valeur 3 est le nombre de labels dans le nom propriétaire original. 86400 est le TTL d'origine pour le RRset A couvert. 20030322173103 et 20030220173103 sont les date de début et de fin de validité de la signature. 2642 est le Key Tag, et example.com. est le nom du signataire.

   Noter la combinaison du nom, classe et type couvert du RR indiquent que ce RRSIG couvret le RRset A host.example.com. La valeur Labels indique qu'il n'y a pas d'expansion wildcard. Algorithm, Signer's Name et Key Tag indiquent que cette signature peut être authentifiée en utilisant un RR DNSKEY dans la zone example.com dont l'algorithme est 4 et dont le tag de clé est 2642

Enregistrement de ressource NSEC

   Le RR NSEC liste 2 choses séparée: le prochain nom propriétaire qui contient les données autoritatives ou un point de délégation RRset NS, et le jeu de type RR présents au nom propriétaire du RR NSEC (rfc3845). Le jeu complet de RR NSEC dans une zone indique quels RRset autoritatif existe dans une zone et forme également une chaîne de noms propriétaires authoritatifs dans la zone. Cette information est utilisée pour fournir un déni d'existance authentifié pour les données DNS, comme décris dans la rfc4035.

   Parce que tout nom autoritatif dans une zone doit faire partie d'une chaîne NSEC, les RR NSEC doivent être présents pour les noms contenant un RR CNAME. C'est un changement par rapport à la spécification DNS (rfc1034), qui status que si un CNAME est présent pour un nom, il est seulement du type permis pour ce nom. Un RRSIG et NSEC doivent exister pour le même nom comme le fait un RR CNAME dans une zone non-signée.

   La valeur du type pour un RR NSEC est 47. Le RR NSEC est indépendant de la classe et devrait avoir le même TTL que le champ SOA minimum TTL.

Format NSEC RDATA

Le RDATA d'un RR NSEC est comme suit:
_-_-_-_-_-_-_-_-_-_-_1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/______________________Next_Domain_Name_________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________Type_Bit_Maps___________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Next Domain Name

   Ce champ contient le nom propriétaire qui a les données autoritatives ou contient un RRset NS de point de délégation. La valeur de ce champ dans le dernier enregistrement NSEC dans la zone est le nom de l'apex de zone (le nom propriétaire du RR SOA de la zone). Cela indique que le nom propriétaire du RR NSEC est le dernier nom dans l'ordre canonique de la zone.

   Un émetteur ne doit pas utiliser la compression de noms DNS dans ce champ en le transettant. Les noms propriétaires des RRset pour lesquel la zone donnée n'est pas autoritative (comme les enregistrements glue) ne doivent pas être listés dans ce champ sauf si au moins un RRset autoritatif existe avec le même nom propriétaire.

Champ Type Bit Maps

Identifie les types du RRset qui existe au niveau du nom propriétaire du RR NSEC. L'espace du type RR est splitté en 256 blocks, chacun représentant les 8bits LSB de l'espace du type RR 16-bits. Chaque block qui a au moins un type RR actif est encodé en utilisant un simple octet de numéro de fenêtre ( de 0 à 255), un simple octet de longueur (de 1 à 32) indiquant le nombre d'octets utilisés pour le bitmap de block, et jusqu'à 32 octets (256bits) de bitmaps. Les blocks sont présent dans le RDATA du RR NSEC en augmentant l'ordre numérique:
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

   où "|" dénote la concaténation

   Chaque bitmap encode les 8bits LSB des types RR dans le block, dans l'ordre de bit réseau. Le premier bit est le bit 0. Pour le block de fenêtre 0, le bit 1 correspond au type RR 1 (A), le bit 2 correspond au RR type 2 (NS), etc. pour le block de fenêtre 1, le bit 1 correspond au RR type 257, et le bit 2 correspond au RR type 258. Si un bit est mis, il indique qu'un RRset de ce type est présent pour le nom propriétaire NSEC.

   Les bits représentant les pseudo-type doivent être effacés, vu qu'ils n'apparaîssent pas dans la zone de données. Si rencontré, ils doivent être ignorés

   Les blocks sans type ne doivent pas être inclus. Les 0 restant dans le bitmap doivent être omis. La longueur de chaque bitmap de block est déterminé par le code de type avec la valeur numérirque la plus grande.

   Le bitmap pour le RR NSEC au point de délégation nécessite une attension spéciale. Les bits correspondant au RRset NS de délégation et les type RR pour lequels la zone parent a une donnée autoritative doivent être mis; les bits correspondants à tout RRset non-NS pour lequel le parent n'est pas autoritatif doivent être effacés.

   Une zone ne doit pas inclure le RR NSEC pour un domaine qui ne maintient que des enregistrements glue.

Ajout des noms wildcard dans RDATA NSEC

   Il un nom wildcard apparaît dans une zone, le label wildcard est traité comme symbole littéral et est traité de la même manière que pour tout nom propriétaire.

Format de présentation RR NSEC

   Le format de présentation de la portion RDATA est comme suit:

- Le champ Next Domain Name est représenté comme un nom de domaine
- Le champs Type Bit Map est resprésenté comme une séquence de mnémoniques de type RR.

Exemple de RR NSEC

L'exemple suivant identifie les RRset associés avec alfa.example.com. et identifie le nom autoritatif suivant après alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 )

   Les 4 premiers champs identifient le nom, TTL, class et type RR (NSEC). host.example.com. est le nom autoritatif suivant après alfa.example.com dans l'ordre canonique. Les mnémoniques A, MX, RRSIG, NSEC et TYPE1234 indiquent qu'il y a des RRsets correspondants associés avec le nom alfa.example.com.

  La section RDATA du RR NSEC serait encodé:


0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20

   Assumant que le validateur peut authentifier cet enregistrement NSEC, il peut être utilisé pour prouver que beta.example.com n'existe pas, ou pour prouver qu'il n'y a pas d'enregistrement AAAA associé avec alfa.example.com.

Enregistrement de ressource DS

   Le RR DS réfère à un RR DNSKEY et est utilisé dans le processus d'authentification DNSKEY. Un RR DS réfèrre à un RR DNSKEY en stockant le tag de clé, le numéro d'algorithme, et un hash du RR DNSKEY. Noter que bien que le hash soit suffisant pour identifier le clé publique, stocker le tag de clé et l'algorithme aide à le processus d'identification plus efficacement. En authentifiant l'enregistrement DS, un résolveur peut authentifier le RR DNSKEY pour lequel le RR DS pointe.

   Le RR DS et son RR DNSKEY correspondant ont le même nom propriétaire, mais ils sont stockés à différents emplacements. Le RR DS apparaît seulement côté parental d'une délégation, et est autoritatif dans la zone parent. Par exemple, le DS RR pour example.com est stocké dans la zone com. Le RR DNSKEY est stocké dans la zone example.com. Cela simplifie la gestion de zone DNS et la signature de zone en introduisant une traitement de réponse spécial pour le RR DS.

   Le type pour le RR DS est 43, et est indépendant de la classe. Le RR DS n'a pas de prérequis de TTL spécial.

Format DS RDATA

Le RDATA pour un RR DS consiste d'un champ 2 octets Key Tag, un champ algorithme 1 octet Algorithm un champ 1 octet Digest Type, et un champ Digest
_____________________1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|___________Key_Tag_____________|__Algorithm____|__Digest_Type__|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/_______________________________________________________________/
/____________________________Digest_____________________________/
/_______________________________________________________________/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champ Key Tag

   Le champ Key Tag liste le tag de clé du RR DNSKEY réferré par l'enregistrement DS. Le Key Tag utilisé par le RR DS est identique au Key Tag utilisé pas les RR RRSIG.

Champ Algorithm

   Le champ algorithme liste le numéro d'algorithme du RR DNSKEY correspondant à cet enregistrement DS.

Champ Digest Type

   Le RR DS réfèrre à un RR DNSKEY en inclant un hash de ce RR DNSKEY. Ce champ identifie l'algorithme utilisé pour construire le hash.

Champ Digest

Contient le hash du RR DNSKEY. Le hash est calculé en concaténant la forme canonique du nom propriétaire pleinement qualifié du RR DNSKEY uavec le RDATA DNSKEY et applique ainsi l'algorithme de hashage:
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

"|" dénote la concaténation.
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.

   La taille du hash peut varier en fonction de l'algorithme et de la taille du RR DNSKEY.

Traitement des RR DS en validant les réponses

   Les RR DS lient la chaîne d'authentification entre les zones, donc le RR DS nécessite une attention particulière dans le traitement. Le RR DNSKEY réferré dans le RR DS doit être une clé de zone DNSSEC. Les flags du RR DNSKEY doivent avoir le bit 7 mis. Si les flags DNSKEY n'indiquent pas une clé de zone DNSSEC, le RR DS (et le RR DNSKEY correspondant) ne doivent pas être utilisés pour le processus de validation.

Format de présentation du RR DS

   Le champ key tag doit être représenté comme entier décimal non-signé. Le champ algorithm doit être réprésenté comme entier décimal non-signé ou mnémonique d'algorithme. Le champ Digest Type doit être réprésenté comme entier décimal non-signé. Le champ Digest doit être reprsenté comme une séquence de chiffres hexadécimaux sensible à la casse.

Exemple de RR DS

L'exemple suivant montre un RR DNSKEY et son RR DS correspondant:
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshW
__________________________________________fwJr1AYtsmx3TGkJaNXV
__________________________________________2pHm822aJ5iI9BMzNXxe
__________________________________________DRD99WYwYqUSdjMmmAph
__________________________________________egXd/M5+X7OrzKBaMbCV
__________________________________________Uh6DhweJBjEVv5f2wwjM
__________________________________________nOf+EPbtG9DMBmADjFDc
__________________________________________ljwvFw==
__________________________________________) ; key id = 60485
    
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A
___________________________________________98631FAD1A292118 )

   Le 4 premiers champs spécifient le nom, TTL, classe et type RR (DS). La valeur 60485 est le tag de clé pour dskey.example.com. Les RR DNSKEY, et la valeur 5 dénotent l'algorithme utilisé par ce RR DNSKEY. La valeur 1 est l'algorithme utilisé pour construire le hash, et le reste est le hash.

Forme canonique et ordre d'enregistrement de ressource

   Cette section définis une forme canonique pour les enregistrements de ressource, un ordre canonique des noms DNS, et un ordre canonique d'enrgistrements de ressource dans un RRset. Un ordre de nom canonique est requis pour construire la chaîne de nom NSEC. Une forme RR canonique est l'ordre dans un RRset sont requis pour construire et vérifier les RR RRSIG.

Ordre de noms DNS canonique

   Pour la sécurité DNS, les noms propriétaires sont ordonnés en traitant les labels individuels comme chaînes d'octets non-signés justifiés à gauche. L'absence d'un trie d'octet avant un octet zéro, et les lettre US-ASCII majuscule sont traités comme s'ils étaient en minuscule.

   Pour calculer l'ordre canonique d'un jeu de noms DNS, on commence par trier les noms en accord avec leur labels les plus signifiant. Pour les noms dans lequel le label le plus signifiant est identique, on continue à trier en accord avec le label suivant, et ainsi de suite.

Par exemple, les noms suivants sont triés par ordre de nom DNS canoniques. Le lable le plus signifiant est "example". À ce niveau, "example" est en premier, suivis par les noms se terminant dans "a.example", puis par les noms se terminant par "z.example". Les noms dans chaque niveau sont traités de la même manière:
example
a.example
yljkjljk.a.example
Z.a.example
zABC.a.EXAMPLE
z.example
\001.z.example
*.z.example
\200.z.example

Forme RR canonique

   Pour la sécurité DNS, la forme canonique d'un RR est le format des RR où:

1. Tout nom de domaine dans le RR est étendu et pleinement qualifié)
2. Toute lettre US-ASCII majuscule dans le nom propriétaire du RR sont remplacés par les lettres minuscules.
3. Si le type du RR est NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, ou NSEC, toutes les lettres US-ASCII majuscule dans les noms DNS contenur dans le RDATA sont remplacés par des minuscules.
4. Si le nom propriétaire du RR est un nom wildard, le nom propriétaire est dans sa forme non-étendue originale, inclunat le label '*'
5. Le TTL du RR est mis à sa valeur d'origine telle qu'elle apparaît dans la zone autoritative d'origine ou le champ Original TTL du RR RRSIG.

Ordre RR canonique dans un RRset

   Pour la sécurité DNS, les RR avec le même nom propriétaire, class et type sont triés en traitant la portion RDATA de la forme canonique de chaque RR comme séquence d'octet non-signé justifié à gauche dans laquelle l'absence d'un octet trie avant un octet zéro.

   La rfc2181 spécifie qu'un RRset n'est pas autorisé à contenir des enregistrements dupliqués (plusieurs RR avec le même nom propriétaire, class, type, et RDATA). Cependant, si une implémentation détecte des RR dupliqués en plaçant le RRset dans une forme canonique, il doit traite comme une erreur de protocole. Si l'implémentation choisis de gérer cette erreur de protocole dans l'esprit du principe de robustesse, il doit supprimer les RR dupliqués pour calculer la forme canonique du RRset.

Considérations de sécurité

   L'enregistrement DS pointe vers un RR DNSKEY en utilisant un hash cryptographique, le type d'algorithme de clé, et un tag de clé. L'enregistrement DS est prévu pour identifier un RR DNSKEY existant, mais il est théoriquement possible pour un attaquant de générer un DNSKEY qui corresponde à ces champs. La probabilité de construire un DNSKEY qui correspond dépend de l'algorithme de hasha utilisé. Actuellement, seul SHA-1 est définis.

   Le tag de clé est utilisé pour sélectionner le RR DNSKEY efficacement, mais il n'identifie pas de manière unique un simple RR DNSKEY. Il est possible que 2 RR DNSKEY distincts aient le même nom propriétaire, le même type d'algorithme, et le même tag de clé. Une implémentation qui utiliser seulement le tag de clé pour sélectionner un RR DNSKEY peut sélectionner la mauvaise clé dans certaines circonstances.

Algorithme et types de hashage

Les extensions de sécurité DNS sont conçus pour être indépendants des algorithmes cryptographique. Les enregistrements de ressource DNSKEY, RRSIG, et DS utilisent tous un numéro d'algorithme DNSSEC pour identifier l'algorithme utilisé par le RR. le RR DS spécifie également un numéro d'algorithme de hashage.
Value_Algorithm_[Mnemonic]__Signing__References___Status
__-----_--------------------_---------_----------__---------
____0___reserved
____1___RSA/MD5_[RSAMD5]_________n______[RFC2537]__NOT_RECOMMENDED
____2___Diffie-Hellman_[DH]______n______[RFC2539]___-
____3___DSA/SHA-1_[DSA]__________y______[RFC2536]__OPTIONAL
____4___Elliptic_Curve_[ECC]______________TBA_______-
____5___RSA/SHA-1_[RSASHA1]______y______[RFC3110]__MANDATORY
__252___Indirect_[INDIRECT]______n__________________-
__253___Private_[PRIVATEDNS]_____y______see_below__OPTIONAL
__254___Private_[PRIVATEOID]_____y______see_below__OPTIONAL
__255___reserved

   Le numéro d'algorithme 253 est réservé pour une utilisation privée et n'est jamais assigné à un algorithme spécifique. La zone de clé publique dans le RR DNSKEY et la zone de signature dans le RR RRSIG commence avec un nom de domaine encodé, qui ne doit pas être compressé. Le nom de domaine indique l'algorithme utilisé, et le reste de la zone de clé publique est déterminé par cet algorithme.

   L'algorithme 254 est réservé pour une utilisation privée et n'est jamais assigné à un algorithme spécifique. La zone de clé publique dans le RR DNSKEY et la zone de signature dans le RR RRSIG commencent avec un octet de longueur non-signé suivi par un OID encodé BER du cette longueur. L'OID indique l'algorithme de clé privée utilisé.

Types de hash DNSSEC

Un champ Digest Type dans un RR DS identifie l'algorithme de hasha utilisé par le RR. La table suivante liste les types actuellement définis:
0 Réservé
1 SHA-1
2-255 non-assigné

Calcule du tag de clé

   Le champ key tag dans les RR RRSIG et DS fournissent un mécanisme pour sélectionner une clé publique efficacement. Dans la plupars des cas, une combinaison de nom propriétaire, algorithme, et tag de clé peut efficacement identifier un enregistrement DNSKEY. Il est essentiel de noter que le Key Tag n'est pas unique.

   Le tag de clé est le même pour tous les types d'algorithmes DNSKEY excpté l'algorithme 1. L'algorithme de tag de clé est la somme du format du RDATA DNSKEY séparé en 2 groupes d'octets. D'abord, le RDATA est traité comme séries de groupes de 2 octets. Ces groupes sont ainsi ajoutés ensemble, en ignorant les bits de retenu.

L'implémentation de référence ANSI C suivante calcule la valeur d'un Key Tag. Cette implémentation de référence s'applique à tous les algorithmes excepté l'algorithme 1. Le code est écrit pour la clarté, non l'efficacité:
/*
    On assure que l'entier fait au moins 16 bits
    Le premier octet du tag de clé sont les 8 bits MSB de la valeur retournée
    Le second octet du tag de clé sont les 8 bits LSB de la valeur retournée
*/
unsigned int
keytag (
    unsigned char key[], /*the RDATA part of the DNSKEY RR*/
    unsigned int keysize /*the RDLENGTH*/
)
{
    unsigned long ac; /*assumed to be 32 bits or larger*/
    int i; /*loop index*/
    
    for ( ac = 0, i = 0; i ‹ keysize; ++i )
        ac += (i & 1) ? key[i] : key[i] ‹‹ 8;
    ac += (ac ›› 16) & 0xFFFF;
    return ac & 0xFFFF;
}

Algorithme 1 pour le tag de clé

   Le type de clé pour l'algorithme 1 (RSA/MD5) est définis différemment du tag de clé pour tous les autres algorithmes, pour des raisons historiques. Pour un RR DNSKEY avec l'algorithme 1, le tag de clé est les 16bits les plus signifiant des 24bits les moins signifiants dans le modulo de la clé publique. Noter que l'algorithme 1 n'est pas recommandé.
^
11 juillet 2016

htmlpdflatexmanmd




rfc4035

rfc4035

Modifications de protocole pour les extensions de sécurité DNS

   Les DNS Security Extensions (DNSSEC) sont une collection de nouveaux enregistrements et modifications de protocole qui ajoutent un authentification de l'origine des données et l'intégrité des données à DNS. Ce document définis les modifications du protocole DNSSEC.

Signature de zone

   DNSSEC introdui le concept de zones signées. Une zone signée inclus une clé publique DNS (DNSKEY), un enregistrement de ressource de signature (RRSIG), Next Secure (NSEC), et optionnellement une délégation de signataire (DS). Une zone qui n'inclue pas ces enregistrements n'est pas une zone signée.

   DNSSEC nécessite un changement dans la définition de l'enrgistrement de ressource CNAME, pour permettre aux RR RRSIG et NSEC d'apparaître avec le même nom propriétaire que le fait un RR CNAME.

   DNSSEC spécifie le placement de 2 nouveaux type RR, RSEC et DS, qui peuvent être placés au niveau du parent (au point de délégation). C'est une exception à l'interdiction générale de placer des données dans la zone parent.

Inclure les RR DNSKEY dans une zone

   Pour signer une zone, l'administrateur de zone génère une ou plusieurs paires de clés publique/privée et les utilise pour signer les RRset authoritatif dans la zone. Pour chaque clé privée utilisée pour créer les RR RRSIG dans une zone, la zone doit inclure un RR DNSKEY de zone contenant la clé publique correspondante. Une clé de zone RR DNSKEY doit avoir le bit de clé de zone du champ de flags RDATA mis. Les clés publiques associées avec d'autres opérations DNS peuvent être stockées dans des RR DNSKEY et ne sont pas marquées comme clé de zone et ne doivent pas être utilisées pour vérifier les RRSIG.

   Si l'administrateur de zone prévois une zone signé pour être utilisable pour autre chose de la sécurité, l'apex de zone doit contenir au moins un RR DNSKEY pour agir comme point d'entrée sécurisé dans la zone. Ce point d'entrée sécurisé peut ainsi être utilisé comme cible d'une délégation sécurisé via un RR DS correspondant dans la zone parent.

Inclure les RR RRSIG dans une zone

   Pour chaque RRset autoritatif dans une zone signée, il doit y avoir au moins un enregistrement RRSIG qui rencontre les exigences suivantes:

        - Le nom propriétaire RRSIG est égal au nom propriétaire du RRset
        - La classe RRSIG est la même que la classe du RRset
        - Le champ Type Covered du RRSIG est égal au type du RRset
        - Le champ Original TTL du RRSIG est égal au TTL du RRset
        - Le champ Labels du RRSIG est égal au nombre de labels dans le nom propriétaire du RRset, sant compter le label root et le label le plus à gauche si c'est un wildcard
        - Le champ Signer's Name du RRSIG est égale au nom de la zone contenant le RRset
        - Les champs Algorithm, Signer's Name, et Key Tag identifient une clé de zone DNSKEY dans l'apex de la zone.

   Le processus pour construire le RR RRSIG pour un RRset donné est décris dans la rfc4034. Un RRset peut avoir plusieurs RR RRSIG associé avec lui. Un RR RRSIG lui-même ne doit pas être signé, vu que signer un RR RRSIG n'ajoute pas de valeur et créé une boucle infinie dans le processus de signature.

   Le RRset NS qui apparaît dans l'apex de la zone doit être signé, mais les RRset NS qui apparaîssent aux points de délégation ne doivent pas être signés. Les RRset Glue associés avec les délégation ne doivent pas être signés.

   Il doit y avoir un RRSIG pour chaque RRset utilisant au moins une DNSKEY de chaque algorithm dans le RRset DNSKEY de l'apex de la zone. Le RRset DNSKEY apex lui-même doit être signé par chaque algorithme apparaissant dans le RRset DS localisé dans le parent déléguant.

Inclure les RR NSEC dans une zone

   Chaque nom propriétaire dans la zone qui a une donnée autoritative ou un RRset NS point de délégation doit avoir un RR NSEC. Le format des RR NSEC et le processus pour le construire et donnée dans la rfc4034.

   La valeur TTL pour un RR NSEC devrait être la même que le TTL minimum de la zone.

   Un enregistrement NSEC (et son RRset RRSIG associé) ne doit pas être le seul RRset à un nom propriétaire particulier. C'est à dir, le processus de signature ne doit pas créer les RR NSEC ou RRSIG pour les nœuds de nom propriétaire qui n'est pas le nom propriétaire d'un RRset avant que la zone ne soit signée. La principale raison pour cela est un désire pour la consistance de l'espace de nom entre les versions signées et non signées de la même zone et un désire de réduire les risques de réponses inconsistantes dans les serveurs récursifs non sécurisés.

   Le bitmap de tout RR NSEC dans une zone signée doit indiquer la présence de l'enregistrement NSEC lui-même et les enregistrement RRSIG correspondants.

   La différence entre le jeu de noms propriétaire qui nécessite les enregistrements RRSIG et le jeu de noms propriétaire qui nécessitent les enregistrements NSEC est subtile et mérite d'être souligné. Les enregistrement RRSIG sont présent aux noms propriétaires de tous les RRset autoritatifs. Les enregistrements NSEC sont présents aux noms propriétaire et également aux noms propriétaires des délégations de la zone signée vers ses enfants. Ni NSEC ni RRSIG ne sont présents (dans la zone parente) aux noms propriétaire des RRset d'adresse glue. Noter, cependant, que cette distinction est généralement visible seulement durant le processus de signature de zone, vu que les RRset NSEC sont des données autoritatives et sont donc signées. Donc, tout nom propriétaire qui a un RRset NSEC aura des RR RRSIG également dans la zone signée.

   Le bitmap pour le RR NSEC au point de délégation nécessite une attention spéciale. Les bits correspondants au RRset NS délégation et tout RRset pour lequel la zone parent an une donnée autoritative doit être mis; les bits correspondants à un RRset non-NS pour lequel le parent n'est pas autoritatif doivent être effacés.

Inclure les RR DS dans une zone

   Le RR DS établis les chaînes d'authentification entre les zones DNS. Un RRset DS devrait être présent à un point de délégation quand la zone enfant est signée. Le RRset DS peut contenir plusieurs enregistrement, chacun référençant une clé publique dans la zone enfant utilisée pour vérifier le RRSIG dans cette zone. Tous les RRset DS dans une zone doivent être signés, et les RRset DS ne doivent pas apparaître dans l'apex de la zone.

   Un RR DS doit pointer vers un RR DNSKEY qui est présent dans le RRset DNSKEY de l'apex de l'enfant, et ce RRset doit être signé par la clé privée correspondante. Les RR DS qui échoue à ces conditios ne sont pas utilies pour la validation, mais parce que le RR DS et son RR DNSKEY sont dans des zones correspondantes, un erreur temporaire peut se produire.

   Le TTL d'un RRset DS matche le TTL du RRset NS déléguant (la zone contenant le RRset DS).

   La construction d'un RR DS nécessite la connaissance du RR DNSKEY correspondant dans la zone enfant, ce qui implique la communication entre les zones parent et enfant. Cette communication est un moyen opérationnel non couver par ce document.

Changement des RR CNAME

   Si un RRset CNAME est présent au nom d'une zone signée, les RRset RRSIG et NESC sont requis à ce nom. Un RRset KEY à ce nom pour les mises à jours dynamique sécurisé est également fournis (rfc3007). D'autre types ne doivent pas être présent à ce nom.

   C'est une modification de la définition du CNAME original de la rfc1034. La définition original du RR CNAME ne permet pas à d'autres type de cohexister avec un enregistrement CNAME, mais une zone signée exige les RR RRSIG et NSEC pour tout nom autoritatif. Pour résoudre ce conflit, cette spécification modifie la définition du RR CNAME pour lui permettre de cohexister vace les RR NSEC et RRSIG.

Type RR DNSSEC apparaissant aux coupures de zone

   DNSSEC a introduit 2 nouveaux types de RR qui sont inhabituels par le fait qu'ils peuvent apparaître du côté du parent. Au niveau du point de délégation, les RR NSEC sont requit au nom propriétaire. Un RR DS peut également être présent si la zone à déléguer est signée et cherche à avoir une chaîne d'authentification dans la zone parent. C'est une exception de la spécification DNS original, qui status que seul les RRset NS peuvent apparaître dans le point de délégation du parent.

   Cette spécification met à jours la spécification DNS pour permettre aux types RR NSEC et DS côté parent. Ces RRset sont autoritatif pour le parent quand ils apparaissent dans le point de délégation de la zone parent.

Service

   Cette section décris le comportement des entités qui incluent les fonctions des serveurs de nom sécurisés. Dans beaucoup de cas de telles fonctions font partie d'un serveur de nom récursif sécurisé, mais un serveur de nom autoritatif sécurisé possède certaines de ces exigences.

   Un serveur de nom sécurisé doit supporter EDNS0 (rfc2671), une taille de message d'au moins 1220 octets, et devrait supporter une taille de message de 4000 octets. Vu que les paquets IPv6 peuvent seulement être fragmentés par l'hôte source, un serveur de nom sécurisé devrait prendre en considération les étapes pour s'assurer que les datagrammes UDP qu'il transmet sur IPv6 sont fragmentés, si nécessaire, au MTU IPv6 minimum.

   Un serveur de nom sécurisé qui reçois une requête DNS qui n'inclus pas l'option EDNS pseudo-RR ou sans le bit DO doit traite les RR RRSIG, DNSKEY et NSEC comme si c'était un RRset sans traitement additionnel. Parce que le type RR DS a la propriété particulière de n'exister que dans la zone parente, les RR DS exigent toujours un traitement spécial.

   Les serveurs de nom sécurisés qui reçoivent des requêtes explicite pour les types RR de sécurité qui matchent le contenu de plus d'une zone qu'il déssert (par exemple, les RR NSEC, et RRSIG avant et après un point de délégation œu le sereur est autoritatif pour les 2 zones) devraient de comporter comme consistant. Tant que la réponse est toujours consistante pour chaque requête au serveur de nom, le serveur peut retourner au choix:

        - Les RRsets au dessus de la délégation
        - Les RRsets au dessous de la délégation
        - Les 2
        - Une section réponse vide
        - Une autre réponse
        - Une erreur

   DNSSEC alloue 2 nouveaux bits dans l'en-tête de message DNS: CD (Checking Disabled) et AD (Authentic Data). Le bit CD est contrôlé par les résolveurs. Un serveur de nom sécurisé doit copier le bit CD de la requête dans la réponse correspondante. Le bit AD est contrôlé par les serveurs de noms, et un serveur de nom sécurisé doit ignorer le bit AD dans les requêtes.

   Un serveur de nom sécurisé qui synthétise les RR CNAME depuis les RR DNAME (rfc2672) ne devrait pas générer de signatures pour les RR CNAME synthétisés.

Serveur de nom autoritatif

   Une fois une requête reçue qui a le bit DO de l'option EDNS(0) pseudo-RR, un serveur de nom autoritatif sécurisé pour une zone signée doit inclure les RR RRSIG, NSEC et DS, en accord avec les règles suivantes:

- Les RR RRSIG qui peuvent être utilisés pour authentifier une réponse doivent être inclus dans la réponse
- Les RR NSEC qui peuvent être utilisé pour fournir un refus d'existance authentifié doivent être inclus dans la réponse
- Soit un RRset DS ou un RR NSEC prouvant qu'aucun RR DS n'existe doit être inclus dans les référrants

   Ces règles s'appliquent seulement aux réponses où les sémantiques véhiculent des informations sur la présence ou l'absence d'enregistrement de ressource. C'est à dire, Ces règles ne sont pas prévues pour pour exclure les réponses tels que RCODE 4 (Not Implemented) ou RCODE 5 (Refused).

   DNSSEC ne change pas le protocole de transfert de zone.

Inclure les RR RRSIG dans une réponse

   En répondant à une requête qui a le bit DO mis, un serveur de nom devrait tenter d'envoyer les RR RRSIG qu'un résolveur peut utiliser pour authentifier les RRset dans la réponse. Un serveur de nom devrait tenter de conserver le RRset et ses RRSIG ensemble dans une réponse. L'ajout des RR RRSIG dans une réponse est sujet aux règles suivantes:

        - En plaçant un RRset signé dans une section Answer, le serveur de nom doit également placer ses RR RRSEG dans la section Answer. Les RR RRISG ont une priorité supérieur pour l'inclusion que tout autre RRset qui peuvent être inclus. Si l'espace ne permet pas d'inclure ces RR RRSIG, le serveur de nom doit mettre le bit TC.
        - En plaçant un RRset signé dans la section Authority, le serveur de nom doit également placer ses RR RRSIG dans la section Authority. Les RR RRSIG ont une priorité supérieur pour l'inclusion que tout autre RRset qui peuvent être inclus. Si l'espace ne permet pas d'inclure ces RR RRSIG, le serveur de nom doit mettre le bit TC.
        - En plaçant un RRset signé dans la section Additional, le serveur de nom doit également placer ses RR RRSIG dans la section Additional. Si l'espace ne permet pas d'inclure le RRset et ses RR RRSIG associés, le serveur de nom peut retenir le RRset et enlever les RR RRSIG. Si cela se produit, le serveur de nom ne doit pas définir le bit TC.

Inclure les RR DNSKEY dans une réponse

   En répondant à une requête qui a le bit DO mis et que demande les RR SOA et NS à l'apex d'une zone signée, un serveur de nom autoritatif pour cette zone peut retourner le RRset DNSKEY de l'apex dans la section Additional. Dans cette situation, le RRset DNSKEY et les RR RRSIG associés ont une priorité inférieur que d'autres informations à placer dans la section additionnelle. Le server de nom ne devrait pas inclure le RRset DNSKEY sauf s'il y a suffisamment de place dans la réponse pour le RRset DNSKEY et les RR RRSIG associés. S'il n'y a pas assez de place, le server de nom doit les omettre et ne doit pas inclure le bit TC uniquement pour ces RR.

Inclure les RR NSEC dans une réponse

   En répondant à une requête qui a le bit DO mis, un serveur de nom autoritatif pour une zone signée doit inclure les RR NSEC dans chacun de ces cas:

No Data: La zone contient des RRset qui matche exactement ‹SNAME, SCLASS› mais ne contient pas de RRset qui match exactement ‹SNAME, SCLASS, STYPE›.
Name Error: La zone ne contient pas de RRset qui match ‹SNAME, SCLASS›, soit exactement, soit via l'expansion wildcard
Wildcard Answer: La zone ne contient pas le RRset qui match exactement ‹SNAME, SCLASS› mais contient un RRset qui match ‹SNAME, SCLASS, STYPE› via l'expansion wildcard
Wildcard No Data: La zone ne contient pas de RRset qui match exactement ‹SNAME, SCLASS› et contient un ou plusieurs RRset que match ‹SNAME, SCLASS› via l'expansion wildcard, mais ne contient pas de RRset qui match ‹SNAME, SCLASS, STYPE› via l'expansion wildcard.

   Dans chacun de ces cas, le serveur de nom inclus les RR NSEC dans la réponse pour prouver qu'un match exact pour ‹SNAME, SCLASS, STYPE› n'était pas présent dans la zone et que la réponse que le serveur retourne les données dans la zone est correct.

Inclure les RR NSEC: No Data Response

   Si la zone contient des RRset matchant ‹SNAME, SCLASS› mais ne contient pas de RRset matchant ‹SNAME, SCLASS, STYPE›, le serveur de nom doit inclure le RR NSEC pour ‹SNAME, SCLASS›, puis le serveur de nom doit inclure le RR NSEC pour ‹SNAME, SCLASS› avec les RR RRSIG associés dans la section Authority de la réponse. Si l'espace ne permet pas d'inclure le RR NSEC ou les RR RRSIG associés, le serveur de nom doit mettre le bit TC.

   Vu que le nom recherché existe, l'expansion wildcard ne s'applique par à cette requête, et un simple RR NSEC suffit à prouver que le type RR demandé n'existe pas.

Inclure les RR NSEC: Name Error Response

   Si la zone ne contient pas de RRset matchant ‹SNAME, SCLASS› soit exactement soit via l'expansion wildcard, le serveur doit incluse les RR NSEC suivants dans la section Authority, avec les RR RRSIG associés:

- Un RR NSEC prouvant qu'il n'y a pas de match exace pour ‹SNAME, SCLASS›
- Un RR NSEC prouvant que la zone ne contient pas de RRset qui match ‹SNAME, SCLASS› via l'expansion wildcard

   Dans certains cas, un simple RR NSEC peut prouver ces 2 points. Si c'est le cas, le serveur devrait seulement inclure le RR NSEC et les RR RRSIG une seule fois dans la section Authority

   Si l'espace ne le permet pas, le serveur doit mettre le bit TC.

   Les noms propriétaires de ces RR NSEC et RRSIG ne sont pas sujet à l'expansion wildcard quand ces RR sont inclus dans la section Authority de la réponse.

   Noter que cette forme de réponse inclus les cas dans lesquels SNAME correspond à un nom non-terminal vide dans la zone (un nom qui n'est pas le nom propriétaire pour un RRset mais qui est le nom parent d'un ou plusieurs RRset).

Inclure les RR NSEC: Wildcard Answer Response

   Si la zone ne contient pas de RRset qui matche exactement ‹SNAME, SCLASS› mais contient un RRset qui matche ‹SNAME, SCLASS, STYPE› via l'expansion wildcard, le serveur de nom doit inclure la réponse étendue et les RR RRSIG étendus correspondants dans la section Answer et doit inclure dans la section Authority un RR NSEC et les RR RRSIG associés prouvant que la zone ne contient pas de match à ‹SNAME, SCLASS›. Si l'espace ne permet pas d'inclure les RR NSEC et RRSIG, le serveur doit mettre le bit TC.

Inclure les RR NSEC: Wildcard No Data Response

   Ce cas est une combinaison des précédents cas. La zone ne contient pas de match exacte pour ‹SNAME, SCLASS›, et bien que la zen contient des RRset qui match ‹SNAME, SCLASS› via l'expansion wildcard, aucun RRset ne match STYPE. Le serveur de nom doit inclure les RR NSEC suivants dans la section Authority, avec les RR RRSIG associés:

- Un RR NSEC prouvant qu'il n'y a pas de RRset correspondant à STYPE au nom propriétaire wildcard qui match ‹SNAME, SCLASS›
- Un RR NSEC prouvant qu'il n'y a pas de RRset dans la zone qui aurait matché pour ‹SNAME, SCLASS›

   Dans certains cas, un simple RR NSEC peut prouver les 2. Les noms propriétaire de ces RR NSEC et RRSIG ne sont pas sujet à l'expansion wildcard quand ces RR sont inclus dans la section Authority de la réponse. Si l'espace ne permet pas d'inclure les RR NSEC et RRSIG, le serveur de nom doit mettre le bit TC.

Trouver les bon RR NSEC

   Comme expliqué plus haut, il y a de nombreuses situations dans lesquelles un serveur de nom doit localiser un RR NSEC qui prouve qu'aucun RRset correspondant à un SNAME n'existe. Localiste un tel RR NSEC dans une zone autoritative est relativement simple, du moins dans le concept. La suite assume que le serveur de nom est autoritatif pour la zone. L'algorithme ci-dessous est écrit pour clareté, non pour l'efficacité.

   Pour trouver les NSEC qui prouve qu'aucun RRset ne match le nom N dans la zone Z, constuire une séquence, S, consistant des noms propriétaire de tout RRset dans Z, trié dans l'ordre canonique, sans noms dupliqué. Trouver le nom M qui aurait précédé immédiatement N dans S si un RRset avec le nom N existait. M est le nom propriétaire du RR NSEC qui prouve qu'aucun RRset n'existe avec le nom N.

   L'algorithme pour trouver le RR NSEC qui prouve qu'un nom donné n'est pas couvert par un wildcard applicable est similaire mais nécessite une étape supplémentaire. Plus précisemment, l'algorithme pour trouver le NSEC prouvant qu'aucun RRsec n'existe avec le nom wildcard applicable est précisemment le même que l'algorithme pour trouver le RR NSEC qui prouve que les RRset avec un nom propriétaire n'existe pas. La partie manquante est une méthode pour déterminer le nom du wildcard applicable non-existant. En pratique, c'est facile, parce que le serveur de nom autoritatif à déjà vérifié la présence de ce nom wildcard dans l'étape (1)(c) de l'algorithme de recherche décrit dans la rfc1034.

Inclure les RR DS dans une réponse

   En répondant à une requête qui a le bit DO mis, un serveur de nom autoritatif retournant un référant inclus les données DNSSEC avec le RRset NS.

   Si un RRset DS est présent au point de délégation, le serveur de nom doit retourner le RR DS et ses RR RRSIG associés dans la section Authority avec le RRset NS.

   Si aucun RRset DS n'est présent au point de délégation, le serveur de nom doit retourner le RR NSEC qui prouve que le RRset DS n'est pas présent et les RR RRSIG associés du RR NSEC avec les RRset NS. Le serveur de nom doit placer le RRset NS avant les RRset NSEC et les RR RRSIG associés.

   En incluant ces RR DS, NSEC, et RRSIG, la taille de message augmente et peut causer l'omission de tous les RR glue. Si l'espace ne permet pas d'inclure les RRset DS ou NSEC et RRSIG, le serveur de nom doit mettre le bit TC.

Répondre aux requêtes pour les RR DS

   Le type RR DS n'est pas courant par le fait qu'il apparaît seulement dans la zone parente. Par exemple, le RRset DS pour la délégation de "foo.example" est stockée dans la zone "example". Cela nécessite un traitement spéciale pour les serveurs de nom et les résolveurs, vu que le serveur de nom pour la zone enfant est autoritative pour le nom à la coupure de zone par les règles DNS normales mais la zone enfant ne contient pas le RRset DS.

   Un résolveur sécurisé envoie des requêtes à la zone parent en recherchant un RR DS au point de délégation. Cependant, des règles spéciales sont nécessaires pour éviter la confusion des résolveurs non sécurisés qui peuvent traiter une telle requête (par exemple, dans une configuration réseau qui force un résolveur sécurisé à canaliser ses requêtes via un serveur de nom récursif non sécurisé). Le reste de cette section décris comment un serveur de nom sécurisé traite les requêtes DS pour éviter ce problème.

   Le besoin pour un traitement spécial par un serveur de nom sécurisé survient seulement quand toutes les conditions suivantes sont rencontrées:

- Le serveur de nom a reçu une requête pour le RRset DS à la coupure de zone
- Le serveur de nom est autoritaire pour la zone enfant
- Le serveur de nom n'est pas autoritatif pour la zone parent
- Le serveur de nom n'offre pas de récursion

   Dans tous les autres cas, le serveur de nom a soit une manière d'obtenir le RRset DS soit ne s'attend pas à avoir le RRset DS même si les règles de traitement pré-DNSSEC, donc le serveur de nom peut retourner soit le RRset DS ou une erreur en accord avec les règles de traitement normal.

   Si toutes les conditions ci-dessus sont rencontrées, cependant, le serveur de nom est autoritatif pour SNAME mais ne peut pas fournir le RRset demandé. Dans ce cas, le serveur de nom doit retourner une réponse "no data" montrant que le RRset DS n'existe pas dans l'apex de la zone enfant.

Répondre aux requêtes pour le type AXFR ou IXFR

   DNSSEC ne change par le processus de transfert de zone. Une zone signée contient les RR RRSIG, DNSKEY, NSEC, et DS, mais ces enregistrement n'ont pas de signification spéciale dans les opérations de transfert de zone.

   Un serveur de nom autoritatif n'est pas tenu de vérifier qu'une zene est proprement signée avent d'envoyer ou d'accepter un transfert de zone. Cependant, un serveur de nom autoritatif peut choisir de rejeter tout le transfert de zone si la zone ne répond pas à toutes les exigences décrites dans la section Signature de zone. L'objectif principal d'un transfert de zone est de s'assurer que tous les serveurs de nom autoritatifs ont une copie identique de la zone. Un serveur de nom autoritatif qui choisis d'effectuer sa propre validation de zone ne doit pas rejeter sélectivement certains RR et en accepter d'autres.

   Les RRset DS apparaîssent seulement coté parent d'une coupure de zone et sont des données autoritatives dans la zone parent. Comme avec tout autre RRset autoritatif, le RRset DS doit être inclus dans le transfert de zone dans lequel le RRset est une donnée autoritative. Dans la cas du RRset DS, c'est la zone parent.

   Les RR NSEC apparaissent dans les zones parent et enfant à la coupure de zone et sont autoritatifs dans ces 2 zones. Les RR NSEC à la coupure de zone parent et enfant ne sont jamais identique, vu que le RR NSEC dans l'apex de la zone enfant indiquent toujours la présence du RR SOA de la zone enfant alors que le RR NSEC du parent ne l'indique pas. Comme avec tout autre RR autoritatif, les RR NSEC doivent être inclus dans les transferts de zone dans lequels ils sont des données autoritatives. Le RR NSEC parent doit être inclus dans le transfert de zone de la zone parent, et le NSEC de l'apex de la zone enfant doit être inclus dans le transfert de la zone enfant.

   Les RR RRSIG apparaissent dans les zones parent et enfant à la coupure de zone et sont autoritatifs dans la zone contenant contenant le RRset autoritatif pour lequel le RR RRSIG fournis la signature. C'est à dire, le RR RRSIG pour un RRset DS ou un RR NSEC parent à la coupure de zone sera autoritatif dans la zone parent, et le RRSIG pour un RRset dans l'apex de la zone enfant sera autoritatif dans la zone enfant. Les RR RRSIG parent et enfant à la coupure de jone ne sont jamais identique. Comme d'autres RR autoritatif, les RR RRSIG doivent être inclus dans le transfert de zone dans lequel ils sont des données autoritatives.

bits AD et CD dans une réponse autoritative

   Les bits CD et AD sont conçus pour être utilisés dans une communication entre des résolveurs sécurisés et des serveurs de nom récursifs sécurisés. Ces bits ne sont pas significatif pour le traitement par les serveurs de nom autoritatifs.

   Un serveur de nom sécurisé ne valide pas la signature pour une donnée autoritative durant le traitement de la requête, même quand le bit CD est effacé. Un serveur de nom sécurisé devrait effacer le bits CD en créant une réponse autoritative.

   Un serveur de nom sécurisé ne doit pas mettre le bit AD dans une réponse à moins que le serveur considère que tous les RRset dans les section Answer et Authority de la réponse sont authentiques. La stratégie locale d'un serveur de nom sécurisé peut considérer les données d'une zone autoritative comme authentique sans autre validation. Cependant, le serveur de nom ne doit pas le faire à moins qu'il n'obtienne la zone autoritative via un moyen sécurisé (tel qu'un mécanisme de transfert de zone sécurisé) et ne doit pas le faire sauf si ce comportement a été configuré explicitement.

   Un serveur de nom sécurisé qui supporte la récursion doit suivre les règles suivantes pour les bits CD et AD donnés ci-dessous en générant un réponse qui implique des données obtenus via la récursion.

Servers de nom récursifs

   Comme indiqué dans la rfc4033, un serveur de nom récursif sécurisé est une entité qui agit dans les rôles de serveur de nom sécurisé et de résolveur sécurisé. Cette section utilise les termes "partie serveur de nom" et "partie résolveur" pour référrer au code dans un serveur de nom qui implémente ces 2 rôles.

   La partie résolveur suis les règles usuelles pour le caching et le caching négatif qui s'applique à tout résolveur sécurisé

Le bit DO

   La partie résolveur doit mettre le bit DO en envoyant les requêtes, sans regarder l'état du bit DO dans la requête initiale reçue par la partie serveur de nom. Si le bit DO dans une requête initiale n'est pas mise, la partie serveur de nom doit enlever tous RR DNSSEC authentifiant de la réponse mais ne doit pas enlever les type RR DNSSEC que la requête initiale a demandé explicitement.

Le bit CD

   Le bit CD existe pour permettre à un résolveur sécurisé de désactiver la validation de la signature dans le traitement du serveur de nom d'une requête particulière.

   La partie serveur de nom doit copier le paramètre du bit CD de la requête à la réponse correspondante.

   La partie serveur de nom doit passer l'état du bit CD à la partie résolveur avec le reste de la requête initiale, pour que la partie résolveur sache s'il est nécessaire de vérifier la réponse qu'il retourne à la partie serveur de nom. Si le bit CD est mis, il indique que le résolveur d'origine souhaite effectuer une authentification via sa stratégie locale. Donc, la partie résolveur n'a pas besoin d'effectuer d'authentification dans les RRset dans la réponse. Quand le bit CD est mis, le serveur de nom récursif devrait, si possible, retourner la donnée demandée au resolveur d'origine, même si la stratégie locale du serveur aurait rejeté les enregistrements en question. C'est à dire, en définissant le bit CD, le résolveur d'origine a indiqué qu'il prend la responsabilité pour effectuer sa propre authentification, et le serveur de nom n'interfers pas.

   Si la partie résolveur implémente un cache BAD et la partie serveur de nom reçois une requête qui matche une entrée dans ce cache, La réponse de la partie serveur dépend de l'état du bit CD dans la requête originale. Si le bit CD estmis, la partie serveur de nom devrait retourner la données depuis le cache; si le bit CD n'est pas mis, la partie serveur de nom doit retourner le RCODE 2 (server failure)

   L'intention de cette règle est de fournir les données brute aux clients capable d'effectuer eux-même la vérification de la signature tout en protégeant le client qui dépent de cette vérification.

Le bit AD

   La partie serveur de nom ne doit pas mettre le bit AD dans une réponse à moins que le serveur considère tous les RRset dans les section Answer et Authority de la réponse comme étant authentiques. La partie serveur de nom devrait mettre le bit AD si et seulement si la partie résolveur considère tous les RRset dans les serveur Answer et Authority comme étant authentiques. La partie résolveur doit suivre la procédure décrite dans la section "Authentifier les réponses DNS" pour déterminer si les RR en question sont authentiques. Cependant, pour compatibilité, un serveur de nom récursif peut mettre le bit AD quand une réponse incluse des RR CNAME non signés si ces RR CNAME démontrent avoir été synthétisés depuis un RR DNAME authentique qui est également inclus dans la réponse en accord avec les règles de synthèse de la rfc2672.

Résolution

   Cette section décrit le comportement des entités qui incluent des fonctions de résolution sécurisé. Dans la plupart des cas de telles fonctions font partie d'un serveur de nom récursif sécurisé, mais un résolveur sécurisé a de nombreuses exigences similaires. Les fonctions spécifique aux serveurs de nom récursif sécurisés sont décrits dans la section précédente.

Support EDNS

   Un résolveur sécurisé doit inclure un OPT pseudo-RR EDNS avec le bit DO mis en envoyant les requêtes

   Un résolveur sécurisé doit supporter une taille de message d'au moins 1220 octets, devrait supporter une taille de message de 4000 octets, et doit utiliser le champ sender,' UDP payload size dans le pseudo-RR pour annoncer la taile de message qu'il est prêt à accepter. Un couche IP du résolveur sécurisé doit gérer les paquets UDP fragmentés correctement sans regarder si ces fragments sont reçus via IPv4 ou IPv6.

Support de vérification de signature

   Un résolveur sécurisé doit supporter les mécanismes de vérification de signature et devrait les appliquer à chaque réponse reçue, excepté quand:

- Le résolveur sécurisé fait partie d'un serveur de nom récursif, et la réponse est le résultat d'une récursion à la demande d'une requête reçue avec le bit CD mis;
- La réponse est le résultat d'une requête générée directement via une interface d'application qui a instruit le résolveur de ne pas effectuer de validation pour cette requête;
- La validation pour cette requête a été désactivée par stratégie locale.

   Le support d'un résolveur sécurisé pour la vérification de signature doit inclure le support pour la vérification des noms propriétaires wildcard.

   Les résolveurs sécurisés peuvent requêter les RR de sécurité manquant en tentant d'effectuer une validation; les implémentations qui choisissent de le faire doit être prêt à recevoir une réponse qui n'est pas suffisante pour valider la réponse originale. Par exemple, une mise à jours de zone peut avoir changé ou supprimé l'information désirée entre les requêtes original et les requêtes suivantes.

   En tentant de récupérer les RR NSEC manquant qui résident dans le parent, un résolveur en mode itératif doit requêter les serveurs de nom pour la zone parent, pas la zone enfant.

   En tentant de récupérer un DS manquant, un résolveur en mode itératif doit requêter les serveurs de nom pour la zone parent. Comme vu plus haut, les serveurs de nom doivent appliquer des traitements spéciaux pour gérer le RR DS, et dans certaines situations le résolveur peut également nécessiter d'appliquer les règles spéciales pour localiser les serveurs de nom pour la zone parent si le résolveur n'a pas le RRset NS du parent. Pour localiser le RRset NS parent, le résolveur peut commencer avec le nom de délégation, enlever le label le plus à gauche, et requêter un RRset NS par ce nom. Si aucun RRset NS n'est présent à ce nom, le résolveur enlève le label le plus à gauche et retente la requête pour ce nom, en répétant le processus jusqu'à ce qu'il trouve le RRset NS ou n'ai plus de label.

Déterminer le status de sécurité des données

   Un résolveur doit être capable de déterminer s'il doit s'attendre à un RRset particulier signé. Plus précisemment, un résolveur sécurisé doit être capable de faire la distinction entre 4 cas:

Sécure: Un RRset pour lequel le résolveur est capable de construire une chaîne de RR DNSKEY et DS signés depuis une ancre de confiance au RRset. Dans ce cas, le RRset devrait être signé et est sujet à validation de signature.
Insecure: Un RRset pour lequel le résolveur sait qu'il n'a pas de chaîne de RR DNSKEY et DS signé. Cela se produit quand le RRset cible est dans une zone non signée. Dans ce cas le résolveur ne peut pas vérifier la signature.
Bogus: Un RRset pour lequel le résolveur estime qu'il est en mesure d'établir une chaîne de confiance, mais n'est pas capable de le faire, soit en raison de signature qu'il ne parvient par à valider, soit à cause de données manquantes que les RR DNSSEC indiquent qu'elles devraient être présentes. Ce cas peut indiquer une attaque ou une erreur de configuration.
Indeterminate: Un RRset pour lequel le résolveur n'est pas capable de déterminer si le RRset est signé, vu que le résolveur n'est pas capable d'obtenir les RR DNSSEC nécessaire. Cela peut se produire quand le résolveur sécurisé n'est pas capable de contacter les serveurs de nom pour les zones concernées.

Ancres de confiance configurés

   Un résolveur sécurisé doit être capable d'être configuré avec au moin une clé publique ou ur RR DS et devrait être capable d'être configuré avec plusieurs clé ou RR DS. Vu qu'un résolveur sécurisé n'est pas capable de valider les signatures sans ancre de confiance, le résolveur devrait avoir un mécanisme robuste pour obtenir de telles clé quand il démarre; par exemple un stockage non-volatile (disque dur) ou une configuration réseau local de confiance. Noter que les ancres de confiance couvrent également les clé qui sont mis à jours de manière sécurisé, qui peut être un support physique, un protocole d'échange de clé, ou d'autres moyens tiers.

Cacher les réponses

   Un résolveur sécurisé devrait mettre en cache chaque réponse comme simple entrée atomique contenant toute la réponse, incluant le RRset nomé et tout RR DNSSEC associé. Le résolveur devrait supprimer l'entrée quand un des RR qu'il contient expire. Dans beaucoup de cas le l'index de cache approprié pour l'entrée atomique est le triplet ‹QNAME, QTYPE, QCLASS›, mais pour les cas décris dans la section "inclure les RR NSEC: Name Error Response", l'index sera ‹QNAME, QCLASS›.

   La raison de ces recommandations est que, entre la requête initiale et l'expiration des données du cache, les données autoritatives peuvent avoir changé. Il y a 2 situation pour lesquel c'est important:

1. En utilisant l'enregistrement RRSIG, il est possible de déduire qu'une réponse a été synthétisée depuis un wildcard. Un serveur de nom récursif pourrait stocker cette donnée wildcard et l'utiliser pour générer des réponses positives aux requêtes autre que le nom pour lequel la réponse originale a été reçue.
2. Les RR NSEC reçues pour prouver la non-existance d'un nom pourrait être réutilisée par un résolveur pour prouver la non-existence d'un nom dans la plage de noms.

   En théorie, un résolveur pourrait utiliser les wildcard ou les RR NSEC pour générer des réponses positives et négatives (respectivement) jusqu'à ce que le TTL ou les signatures dans les enregistrement n'expirent. Cependant, il semble prudent pour les résolveurs d'éviter de bloquer les nouvelles données autoritatives ou de synthétiser de nouvelles donnés par eux même. Les résolveurs qui suivent cette recommandation auront une vue plus consistante de l'espace de nom.

Gérer les bits CD et AD

   Un résolveur sécurisé peut mettre le bit CD d'une requête pour indiquer que le résolveur prend la résponsabilité d'effectuer toute authentification que sa stratégie locale exige sur les RRsets dans la réponse.

   Un résolveur doit effacer le bit AD en créant une requête pour se protéger contre les serveurs de nom buggés qui copient bêtement les en-têtes qu'ils ne comprennent pas de la requête dans la résponse.

   Un résolveur doit ignorer la signification des bits CD et AD dans une réponse sauf si la réponse a été obtenue en utilisant un canal sécurisé ou le résolveur a été configuré spécifiquement pour le faire.

Cache des données BAD

   Bien que de nombreuses erreurs de validation sont transitoires, certaines sont persistantes, tel que les erreurs administratives. Vu que redemander n'aide pas dans ces cas, les résolveurs validateurs peuvent générer un quantité significative de trafique DNS non-nécessaire en mettant en cache les signatures invalides, avec quelques réstrictions.

   Conceptuellement, cacher de telles données est similaire aux caching négatif (rfc2308), excepté qu'au lieu de cacher une réponse invalide, le résolveur cache le fait qu'une réponse particulière à échoué la validation. Ce document réfèrre au cache de telles données au cache BAD.

   Les résolveurs qui implémentent un cache BAD doit effectuer certaines étapes pour éviter que le cache soit utilisé comme amplificateur d'attaque DOS, particulièrement:

- Vu que les RRset qui échouent la validation n'ont pas de TTL de confiance, l'implémentation doit leur assigner un TTL. Ce TTL devrait être petit, pour mitiger l'effet de cache de résultat d'une attaque.
- Pour éviter de cacher des erreurs de validation aléatoires (qui peuvent être le résultat d'une attaque), les résolveurs devraient suivre les requêtes qui résultent en erreurs de validation de devraient seulement répondre depuuis le cache BAD après que le nombre de fois que les réponse aux requêtes pour ce ‹QNAME, QTYPE, TCLASS› particulier a échoué la validation a excédé un valeur seuil.

   Les résolveurs ne doivent pas retourner les RRset depuis le cache BAD sauf si le résolveur n'a pas à valider les signature des RRset en question.

CNAME synthétisés

   Un résolveur sécurisé validateur doit traiter la signature d'un RR DNAME signé valide comme couvrant égaleent les RR CNAME non-signés qui pourraient avoir été synthétisés depuis le RR DNAME, tel que décris dans la rfc2672, au moins dans la mesure de ne pas rejeter une réponse parce qu'elle contient seulement de tels RR CNAME.

Résolveurs stub

   Un résolveur stub sécurisé doit supporter les types de RR DNSSEC, au moins pour éviter de mal gérer les réponses simplement parce qu'elles contiennent des RR DNSSEC.

Gérer les bit DO

   Un résolveur stub sécurisé non-validateur peut inclure les RR DNSSEC retournés par un serveur de nom récursif sécurisé comme partie des données que le stub resolver envoie à l'application, mais ce n'est pas obligatoire. Un stub resolver qui le fait doit mettre le bit DO pour recevoir les RR DNSSEC depuis le serveur de nom récursif.

   Un stub resolver sécurisé validateur doit mettre le bit DO, parce que sinon il ne reçoit pas les RR DNSSEC qu'il a besoin pour la validation de la signature.

Gérer le bit CD

   Un stub resolver sécurisé non-validateur ne devrait pas mettre le bit CD en envoyant les requêtes sauf s'il est demandé par l'application, vu que par définition, un stub resolver non-validateur dépend du serveur de nom récursif sécurisé qui effectue la validation pour lui.

   Un résolveur stub sécurisé validateur devrait mettre le bit CD, parce que sinon le serveur de nom récursif va répondre à la requête en utilisant la stratégie locale du serveur de nom, qui peut empêcher le stub resolver de reçevoir des données qui seraient acceptables pour la stratégie local du stub resolver.

Gérer le bit AD

   Un stub resolver sécurisé non-validateur peut choisir d'examiner le bit AD dans les réponses qu'il reçoit pout déterminer si le serveur de nom récursif sécurisé qui envoie la réponse prétend avoir cryptographiquement vérifié les données dans les section Answer et Authority de la réponse. Noter, cependant, que les réponse reçues par un stub resolver sécurisé dépend de la stratégie locale du serveur de nom sécurisé. Un stub resolver ne doit pas placer de confiace dans la prétendue validation de signature effectuée, exceptée quand le stub resolver sécurisé a obtenu les données en question depuis un serveur de nom récursif sécurisé de confiance via un canal sécurisé.

   Un résolveur stub validateur ne doit pas examiner le bit AD dans les messages de réponse, vu que par définition, le stub resolver effectue sa propre validation de signature.

Authentifier les réponses DNS

   Pour utiliser les RR DNSSEC pour d'authentification, un résolveur doit connaître au moins un RR DNSKEY ou DS authentifié. Le processus pour obtenir et authentifier cet ancre de confiance initial est fait via un mécanisme externe. Le reste de cette section assume que le résolveur a obtenu le jeu initial d'ancres de confiance.

   Un RR DNSKEY initial peut être utilisé pour authentifier un RRset DNSKEY dans l'apex de la zone. Pour authentifier un RRset DNSKEY apex en utilisant une clé initiale, le résolveur doit:

1. Vérifier que le RR DNSKEY initial apparaît dans le RRset DNSKEY apex, et que le RR DNSKEY a le Zone Key Flag mis.
2. Vérifier qu'il y a un RR RRSIG qui couvre le RRset DNSKEY apex, et que la combinaison du RR RRSIG et du RR DNSKEY authentifient le RRset DNSKEY. Le processus pour utiliser un RR RRSIG pour authentifier un RRset est décris plus bas.

   Une fois que le résolveur a authentifié le RRset DNSKEY apex en utilisant un RR DNSKEY initial, les délégation depuis cette zone peuvent être authentifiés en utilisant les RR DS. Celà permet à un résolveur de démarrer depuis une clé initiale et d'utiliser les RRset DS pour traiter récursivement l'arborescence DNS, en obtenant les autres RRset DNSKEY apex. Si le résolveur était configuré avec un RR DNSKEY root, et si chaque délégation a un RR DS associé avec lui, le résolveur peut obtenir et valider tout RRset DNSKEY apex. Le processus d'utilisation les RR DS pour authentifier les référrants est décris plus bas.

   Quand un résolveur indique le support pour DNSSEC (en définissant le bit DO), un serveur de nom sécurisé devrait tenter de fournir les RRset DNSSEC nécessaires dans une réponse. Cependant, un résolveur sécurisé peut reçevoir une réponse dans laquelle il manque des RR DNSSEC. Un résolveur devrait attendre les informations d'authentification des zones signées. Un résolveur devrait croire qu'une zone est signée si le résolveur a été configuré avec des informations de clé publique pour la zone, ou si le parent de la zone est signée, et contient un RRset DS.

Considérations spéciales pour les îlots de sécurité

   Les îlots de sécurité sont les zones signées pour lequelles il n'est pas possible de construire une chaîne d'authentification vers la zone depuis son parent. Valider les signature dans un îlot de sécurité nécessite que le validateur ait un moyen d'obtenir une clé de zone authentifiée initiale pour l'îlot. Si un validateur ne peut pas obtenir une telle clé, il devrait opérer comme si les zones étaient non-signées.

   Tous les processus normaux pour valider les réponse s'appliquent aux îlots de sécurité. La seul différence entre une validation normale et la validation d'une un îlot de sécurité et la manière dont le validateur obtient une ancre de confiance pour la chaîne d'authentification.

Authentifier les référrants

   Une fois le RRset DNSKEY apex pour une zone parent signée est authentifiée, les RRset DS peuvent être utilisés pour authentifier la délégation pour une zone enfant signée. Un RR DS identifie un RR DNSKEY dans le RRset DNSKEY apex de la zone enfant. Un RR DS identifie un RR DNSKEY dans le RRset DNSKEY dans l'apex de la zone enfant. L'utilisation d'un algorithme de hashage fort s'assure qu'il est impossible pour un attaquant de générer un RR DNSKEY qui matche le hash. Donc, authentifier le hash permet au résolveur d'authentifier le RR DNSKEY. Le résolveur peut ainsi utiliser ce RR DNSKEY pour authentifier tout le RRset DNSKEY apex enfant.

   En donnant un RR DS pour une délégatio, le RRset DNSKEY apex de la zone enfant peut être authentifié si:

- Le RR DS a été authentifié en utilisant un RR DNSKEY dans le RRset DNSKEY apex du parent.
- Algorithm et Key Tag dans le RR DS match les champs Algorithm et Key Tag d'un RR DNSKEY dans le RRset DNSKEY apex de la zone enfant, et, quand le nom propriétaire du RR DNSKEY et RDATA sont hashés en utilisant l' algorithme de hashage spécifié dans le champ Digest Type dans le RR DS, les valeurs de hash correspondent.
- Le RR DNSKEY correspondant dans la zone enfant a le bit Zone Flag mis, la clé privée correspondante a signé le RRset DNSKEY apex de la zone, et le RR RRSIG résultant authentifie le RRset DNSKEY apex de la zone enfant.

   Si le référant de la zone parent ne contient pas un RRset DS, la réponse devrait inclure un RRset NSEC signé prouvant qu'il n'y a pas de RRset DS pour le nom délégué. Un résolveur sécurisé doit requêter les serveurs de nom pour la zone parent à la recherche du RRset DS si le réferrant n'inclus ni un RRset DS ni un RRset NSEC prouvant que le RRset DS n'existe pas.

   Si le validateur authentifie un RRset NSEC qui prouve qu'aucun RRset DS n'est présent pour cette zone, il n'y a pas de chemin d'authentification entre le parent et l'enfant. Si la résolveur a un DNSKEY initial ou un RR DS qui appartient à la zone enfant ou pour une délégation sous la zone enfant, le RR initial peut être utilisé pour ré-établir un chemin d'authentification. Si un tel RR n'existe pas, le validateur ne peut pas authentifier les RRset.

   Si le validateur ne support aucun algorithme listé dans le RRset DS authentifié, le résolveur n'a pas de chemin d'authentification. Le résolveur devrait traiter ce cas comme si un RRset NSEC authentifié prouvait qu'il n'y a pas de DS RRset.

   Note que, pour une délégation signée, il y a 2 RR NSEC associés avec le nom délégué. Un RR NSEC réside dans la zone parent et peut être utilisé pour prouver si un RRset DS existe pour le nom délégué. Le second réside dans la zone enfant et identifie quels RRset sont présent à l'apex de la zone.

   Si le résolveur ne supporte aucun algorithme listé dans un RRset DS, le résolveur n'est pas capable de vérifier le chemin d'authentification pour la zone enfant. Dans ce cas, le résolveur devrait traiter la zone enfant comme si elle était non-signée.

Authentifier un RRset avec un RR RRSIG

   Un validateur peut utiliser un RR RRSIG et le RR DNSKEY correspondant pour tenter d'authentifier les RRset. Le validateur vérifie d'abord le RR RRSIG pour vérifier qu'il couvre le RRset, a un interval de temps valide, et identifier un RR DNSKEY valide. Le validateur construit ensuite la forme canonique de la donnée signée en ajoutant le RDATA RRSIG (sans le champ Signature) avec la forme canonique du RRset couvert. Finalement, le validateur utilise la clé publique et la signature pour authentifier la donnée signée.

Vérifier la validité RR RRSIG

   Un résolveur sécurisé peut utiliser un RR RRSIG pour authentifier un RRset si toutes les conditions suivantes sont maintenues:

- Le RR RRSIG et le RRset doivent avoir le même nom propriétaire et la même classe
- Le champ Signer's Name du RR RRSIG doit être le nom de la zone qui contient le RRset
- Le champ Type Covered du RR RRSIG doit être égal au type du RRset.
- Le nombre de labels dans le nom propriétaire du RRset doit être supérieur ou égal à la valeur dans le champ Label du RR RRSIG
- La notion du validateur du temps courant doit être inférieur ou égal au temps listé dans le champ Expiration du RR RRSIG
- La notion du validateur du temps courant doit être supérieur ou égal au temps listé dans le champ Inception du RR RRSIG.
- Les champs Signer's Name, Algorithm, et Key Tag du RR RRSIG doivent correspondre au nom propriétaire, algorithm et key tag d'un RR DNSKEY dans le RRset DNSKEY de l'apex de zone.
- Le RR DNSKEY correspondant doit être présent dans le RRset DNSKEY de l'apex de zone, et doit avoir le bit Zone Flag mis.

   Il est possible que plus d'un RR DNSKEY corresponde aux conditions ci-dessus. Dans ce cas, le validateur ne peut pas prédéterminer lequel utiliser pour authentifier la signature, et doit tenter chaque RR DNSKEY jusqu'à ce que la signature soit validée.

   Noter que ce procéssus d'authentification est seulement significatif si le validateur authentifie le RR DNSKEY avant de l'utiliser pour valider les signatures. Le RR DNSKEY correspondant est considéré authentique si:

- Le RRset DNSKEY apex contenant le RR DNSKEY est considéré comme authentique, ou
- Le RRset couvert par le RR RRSIG est le RRset DNSKEY apex lui-même, et le RR DNSKEY match soit un RR DS authentifié de la zone parent ou matche une ancre de confiance.

Reconstruire les données signées

Une fois le RR RRSIG validé, le validateur doit reconstruire la donnée signée original. Cette donnée inclus le RDATA RRSIG (sans le champ signature) et la forme canonique du RRset. En plus d'être ordonné, la forme canonique peut également différer du RRset reçu à cause de la compression de nom DNS, des TTLs décrémentés, ou de l'expansion wildcard. La validateur devrait utiliser le reconstruction suivante:
signed_data = RRSIG_RDATA | RR(1) | RR(2)...

où "|" dénote un concaténation.
RR(i) = name | type | class | OrigTTL | RDATA length | RDATA

name est calculé en accord avec la fonction plus bas
class est la classe du RRset
type est le type du RRset et de tous les RR dans la classe
OrigTTL est la valeur du champ Original TTL du RRSIG
- Tous les noms dans le champ RDATA sont sous la forme canonique
- Le jeu de RR(i) est trié par ordre canonique

Pour calculer le nom:
let rrsig_labels = La valeur du champ Labels RRSIG
    
let fqdn = nom de domaine pleinement qualifié sous la forme canonique
    
let fqdn_labels = compteur de label dans le fqdn
    
if rrsig_labels = fqdn_labels, name = fqdn
    
if rrsig_labels ‹ fqdn_labels, name = "*." | Les labels rrsig_label les plus à droite du fqdn
    
if rrsig_labels › fqdn_labels
    le RR RRSIG ne passe pas nécessairement la validation et ne doit pas être utilisé pour authentifier ce RRset.

   Les RRset NSEC au point de délégation nécessitent un traitement spécial. Il y a 2 RRset NSEC distinct associé avec un nom signé délégué. Un RRset NSEC réside dans la zone parent, et spécifique quels RRset snt présent dans la zone parent. L'autre réside dans la zone enfant et identifie quels RRset sont présent à l'apex dans la zone enfant. En reconstruisant le RRset NSEC original puor la délégation depuis la zone parent, le RR NSEC ne doit pas être combiné avec les RR NSEC de la zone enfant. En reconstruisant le RRset NSEC original pour l'apex de la zone enfant, les RR NSEC ne doivent pas être combinés avec les RR NSEC de la zone parent.

   Noter que les 2 RRset NSEC au point de délégation ont un RR RRSIG correspondant avec un nom propriétaire correspondant au nom délégué, et chacun de ces RR RRSIG est une donnée autoritative associée avec la zone qui contient le RRset NSEC.

Vérifier la signature

   Une fois que le résolveur a validé le RR RRSIG et reconstruit les données signées originales, le validateur peut tenter d'utiliser la signature cryptographique pour authentifier les données signées, et donc finalement, authentifier le RRset.

   Le champ Algorithm dans le RR RRSIG identifie l'algoritme cryptographique utilisé pour générer la signature. La signature elle-même est contenue dans le champ Signature du RDATA RRSIG, et la clé publique utilisée pour vérifier la signature est contenue dans le champ Public Key du ou des RR DNSKEY correspondants

   Si le champ Labels du RR RRSIG n'est pas égal au nombre de labels dans le nom propriétaire pleinement qualifié du RRset, le RRest est soit invalide, ou le résultat d'une expansion wildcard. Le résolveur doit vérifier que l'expansion wildcard a été appliqué correctement avant de considérer le RRset comme authentique.

   Si d'autre RR RRSIG couvrent également ce RRset, la stratégie de sécurité locale du résolveur détermine s'il doit tester les RR RRSIG et comment gérer les conflits si les RR RRSIG donnent différents résultats.

   Si le résolveur accèpte le RRset, le validateur doit mettre le TTL du RR RRSIG et chaque RR dans le RRset authentifié à une valeur pas supérieur au minimum de:

- Le TTl du RRset reçu dans la réponse
- Le TTL du RR RRSIG reçu dans la réponse
- La valeur dans le champ Original TTL du RR RRSIG, et
- La différence du temps d'expiration de la signature du RR RRSIG et la date courante.

Authentifier un RRset wilcard étendu positif

   Si le nombre de labels dans le nom propriétaire du RRset est supérieur au champ Labels du RR RRSIG couvrant, le RRset et sont RR RRSIG ont été créés en résultat d'une expansion wildcard. Une fois que le validateur a vérifié la signature, il doit vérifier la non-existance d'un match exacte pour la requête.

   Noter que la réponse reçue par le résolveur devrait inclure tous les RR NSEC nécessaire pour authentifier la réponse.

Authentifier la non-existance

   Un résolveur peut utiliser les RR NSEC authentifiés pour prouver qu'un RRset n'est pas présent dans une zone signée. Les serveurs de nom sécurisés devraient automatiquement inclure les RR NSEC nécessaires pour les zones signées dans leur réponses aux résolveurs sécurisés.

   La non existance est déterminée par les règles suivantes:

- Si le RR demandé match le nom propriétaire d'un RR NSEC authentifié, le bit du type RR NSEC liste tous les types de RR présents au nom propriétaire, et un résolveur peut prouver que le type RR demandé n'existe pas en vérifiant le type RR dans le bit map. Si le nombre de labels dans un nom propriétaire du RR NSEC est égal au champ Labels du RR RRSIG couvrant, l'existence du RR NSEC prouve que l'expansion wildcard n'a pas été utilisé pour matcher la requête.
- Si le nom RR demandé apparaît après le nom propriétaire du RR NSEC authentifié et avant le nom listé dans le champ Next Domain du RR NSEC en accord avec l'ordre DNS canonique définis dans la rfc4034, alors aucun RRset avec le nom demandé n'existe dans la zone. Cependant, il est possible qu'un wildcard ait été utilisé pour correspondre au nom propriétaire et type du RR demandé, donc prouver que le RRset demandé n'existe pas nécessite également qu'aucun RRset wildcard possible n'existe qui pourrait être utilisé pour générer une résponse positive.

   De plus, les résolveurs sécurisés doivent authentifier les RRset NSEC qui incluent la preuve de non-existence. Pour prouver la non-existence d'un RRset, le résolveur doit être capable de vérifier les RRset demandés qui n'existent pas et dont aucun RRset wildcard n'existe. Prouver cela peut nécessiter plus d'un RRset NSEC de la zone. Si le jeu complet de RRset NSEC n'est pas présent dans une réponse (par ex, dû à un message tronqué), le résolveur sécurisé doit renvoyer la demande pour pouvoir tenter d'obtenir la collection de RR NSEC nécessaire pour vérifier la non-existence de RRset demandé. Comme avec toutes les opération DNS, cependant, le résolveur doit délimiter le travail qu'il place dans la réponse d'une requête particulière.

   Vu que le RR NSEC validé prouve la non-existence de lui-même et de ses RR RRSIG correspondants, un validateur doit ignorer les paramètres des bits NSEC et RRSIG dans un RR NSEC.

Comportement des résolveurs si les signatures échouent

   Si aucun des RRSIG ne peut être validé, la résponse devrait être considérée BAD. Si la validation a été faite pour desservir une requête récursive, le serveur de nom doit retourner RCODE 2 au client. Cependant, il doit retourner la réponse complète si et seulement si la requête originale avait le bit CD mis.
^
14 septembre 2010

htmlpdflatexmanmd




rndc

rndc

Contrôle les opérations du serveur de noms

OPTIONS

-b source-address adresse source pour la connexion au serveur
-c config-file Spécifie le fichier de configuration à utiliser (défaut /etc/rndc.conf).
-k key-file utilise le fichier de clé spécifié au lieu de /etc/rndc.key par défaut.
-s server nom ou adresse sur serveur de noms.
-p port Port TCP pour la connection au serveur de noms.
-q Mode silencieux. N'affiche que les erreurs
-v mode verbeux
-y key_id utilise la clé spécifié dans le fichier de configuration

Commandes

reload recharge la configuration et les zones
reload zone [class [view]] Recharge une simple zone
refresh zone [class [view]] Effectue une maintenance pour la zone
retransfer zone [class [view]] Retransfert une simple zone sans vérifier le numéro de série
sign zone [class [view]] Prend les clé DNSSEC pour la zone donnée dans le répertoire de clés. Si elles sont dans leur période de publication, les fusionne dans le RRset DNSKEY de la zone. Si ce RRset est changé, la zone est automatiquement re-signée avec le nouveau jeu de clé. Cette commande requière l'option de zone auto-dnssec à allow ou maintain, ainsi que la permission de mise à jours dynamique
loadkeys zone [class [view]] Prend les clé DNSSEC pour la zone donnée dans le répertoire de clés. Si elles sont dans leur période de publication, les fusionne dans le RRset DNSKEY de la zone. la zone n'est pas immédiatement re-signée par les nouvelles clés.
freeze [zone [class [view]]] Suspend les updates pour une zone dynamique ou toutes les zones
thaw zone [class [view]] Active les updates pour une zone dynamique ou toutes les zones
scan Scanne la liste d'interfaces réseaux à la recherche de changement, sans effectuer une reconfiguration complète ou attendre le timer interface-interval.
sync [-clean] [zone [class [view]]] Synchronise les changements dans le fichier journal pour une zone dynamique dans le fichier master. -clean supprime également le fichier journal.
notify zone [class [view]] Renvoie les messages NOTIFY pour la zone
reconfig Recharge le fichier de configuration et les nouvelles zones uniquement
zonestatus [zone [class [view]]] Affiche le status de la zone donnée, incluant le nom du fichier maître et les fichier include, la date de dernière lecture, le numéro de série, nombre de nœuds, si la zone est DDNS, DNSSEC, DNSSEC automatique, etc.
stats Écrit les statistiques du serveur dans le fichier de statistiques.
querylog [on|off] Active le logging des requêtes.
dumpdb [-all|-cache|-zones] [view ...] Dump les caches dans le fichier dump
secroots [view ...] Dump les security roots du serveur dans le fichier secroots pour les vues spécifiées.
stop -p Sauve les updates en cours et stop le serveur. -p retourne le PID du processus.
halt -p Stop le serveur sans sauver les updates en cours. -p retourne le PID du processus.
trace level Change le niveau de debug. (sans spécifier de level, incrémente le niveau de debug de 1)
notrace Définit le niveau de debuggage à 0.
flush Vide le cache du serveur
flushname name [view] Vide le nom donné du cache du serveur DNS et, si applicable, dans la base d'adresse de serveur de nom du serveur ou du cache bad-server
flushtree [-all] name [view] Vide le nom donné, et tous ses sous-domaines, depuis le cache DNS du serveur, la base d'adresse ou le cache bad-server
status Affiche le status du serveur.
recursing Dump les requêtes qui sont recursives
validation (on|off|check) [view] Active/desactive la validation DNSSEC. dnssec-enable doit être à yes ou auto.
tsig-list Liste les noms de toutes les clés TSIG actuellement configurées pour l'utilisation par named dans chaque vue.
tsig-delete keyname [view] Supprime un clé TKEY du serveur. Ne s'applique pas aux clé configurées statiquement.
addzone zone [class [view]] configuration Ajoute une zone à chaud. Nécessite allow-new-zones à yes. La configuration est sauvée dans un fichier appelé hash.nzf où hash est le hash du nom de la vue.
delzone [-clean] zone [class [view]] Supprime un zone à chaud
signing [( -list | -clear keyid/algorithm | -clear all | -nsec3param ( parameters | none )] Liste, édite, ou supprime les enregistrement d'état de signature DNSSEC pour la zone spécifiée. Le status des opérations DNSSEC sont stockés sous la forme de RR de type sig-signing-type. -list convertis ces records dans un format lisible.

Exemples

Ajouter une zone
$rndc addzone example.com ’{ type master; file "example.com.db"; };’
^
18 mars 2016

htmlpdflatexmanmd




rndc-confgen

rndc-confgen

Outil de génération de clé rndc

   rndc-confgen génère des fichiers de configuration pour rndc.

OPTIONS

-a Génère automatiquement une configuration rndc.
-a algorithm Spécifie l'algorithme à utiliser pour la clé TSIG
-b keysize Spécifie la taille de la clé d'authentification en bits
-c keyfile Utilisé avec -a pour spécifier un emplacement alternatif à rndc.key
-k keyname Spécifie le nom de la clé d'authentification. Défaut: rndc-key
-r randomfile Source de données aléatoire pour la génération de l'authorisation
-s address Adresse IP où named écoute pour les connection rndc
-t chrootdir Utilisé avec -a pour spécifier un répertoire où named est chrooté
-u user Utilisé avec -a pour définir le propriétaire de fichier rndc.key généré.
^
14 septembre 2010

htmlpdflatexmanmd




rndc.conf

rndc.conf

Fichier de configuration pour rndc. Il utilise 3 déclarations: options, server, et key

Déclaration options

default-server Spécifie le nom ou l'adresse du serveur de noms.
default-key Spécifie le nom d'un clé, identifiée par une déclaration key
default-port Définit le port de connexion au serveur.
default-source-address Définit l'interface local utilisé pour se connecter au serveur
default-source-address-v6 Idem pour IPv6

Déclaration server

key Spécifie le nom d'un clé, identifiée par une déclaration key
port définit le port de connection au serveur.
addresses Spécifie l'adresse du serveur de nom et optionnellement le port.

Déclaration key

algorithm identifie l'algorithme utilisé
secret Contient le secret partagé.

Exemples

options {
    default-server localhost;
    default-key samplekey;
};
    
server localhost {
    key    samplekey;
};
    
server testserver {
    key     testkey;
    addresses { localhost port 5353; };
};
    
key samplekey {
    algorithm    hmac-sha256;
    secret    "6FMfj43Osz4lyb24OIe2iGEz9lf1llJO+lz";
};
    
key testkey {
    algorithm    hmac-sha256;
    secret    "R3HI8P6BKw9ZwXwN3VZKuQ==";
};