\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{geometry}
\geometry{top=15mm, bottom=15mm, left=1cm, right=1cm}
\usepackage[french]{babel}
\usepackage{pslatex}
\usepackage[colorlinks=true,urlcolor=black]{hyperref}
\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\footrulewidth}{0.4pt}
\fancyfoot[L]{Uubu.fr}
\fancyfoot[R]{mar. sept. 14 16:19:28 CEST 2010}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={Bind 9 - Présentation},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={service DNS},
CreationDate={D:20100914161928},
ModDate={D:20100914161928},
Keywords={DNS;Domain Names Service}
}}
\begin{document}
 
\begin{center}
{\Huge Bind 9 - Présentation }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large service DNS}
 
\vspace{10mm}
 
\vspace{1cm}{\huge Exemple de configuration }
 
\
 
\hspace{1mm} Serveur de nom cache uniquement
 
{\ttfamily
// 2 sous réseaux autorisés à effectués des requêtes:\\ acl corpnets \{ 192.168.4.0/24 ; 192.168.7.0/24 ; \}\\ options \{\\ \hspace{2mm}directory \{ "/etc/namedb" ; \};\\ \hspace{2mm}allow-query \{ corpnets ; \};\\ \};\\ \hspace{2mm}\\ zone "0.0.127.in-addr.arpa" \{\\ \hspace{2mm}type master;\\ \hspace{2mm}file "localhost.rev";\\ \hspace{2mm}notify no;\\ \};\\
}
\vspace{8mm}
 
\hspace{1mm} Serveur de nom autoritatif uniquement :
 
{\ttfamily
options \{\\ \hspace{2mm}directory "/etc/namedb";\\ \hspace{2mm}allow-query-cache \{ none ; \};\\ \hspace{2mm}allow-query \{ any; \};\\ \hspace{2mm}recursive no;\\ \};\\ \hspace{2mm}\\ zone "0.0.127.in-addr.arpa" \{\\ \hspace{2mm}type master;\\ \hspace{2mm}file "localhost.rev";\\ \hspace{2mm}notify no;\\ \};\\ \hspace{2mm}\\ zone "example.com";\\ \hspace{2mm}type master;\\ \hspace{2mm}file "example.com.db";\\ \hspace{2mm}allow-transfert \{\\ \hspace{2mm}\hspace{2mm}192.168.4.14;\\ \hspace{2mm}\hspace{2mm}192.168.5.53;\\ \hspace{2mm}\};\\ \};\\ \hspace{2mm}\\ zone "eng.example.com" \{\\ \hspace{2mm}type slave;\\ \hspace{2mm}file "eng.example.com.bk";\\ \hspace{2mm}masters \{ 192.168.4.12; \};\\ \};\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Load Balancing }
 
\
 
\hspace{1mm}  Le load balancing peut-être fait en utilisant plusieurs enregistrements pour un seul nom.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Notification }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Mise à jour automatique }
 
\
 
\hspace{1mm}  \textbf{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.
\vspace{5mm} \\
\hspace{1mm}  Le dynamic update est activé avec options \textbf{allow-update} ou une clause \textbf{update-policy} dans la déclaration de zone.
\vspace{5mm} \\
\hspace{1mm}  Si update-policy est à \textbf{local}, les mises à jour de la zone seront permises pour la clé \textbf{local-ddns}, qui sera généré par named au démarrage.
\vspace{5mm} \\
\hspace{1mm}  Les clauses \textbf{tkey-gssapi-credential} et \textbf{tkey-domain} dans les options autorisent le serveur de négocier les clés qui peut correspondre à celles dans update-policy ou allow-update.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Le fichier journal }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
\hspace{1mm}  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.
\vspace{5mm} \\
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm}  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 \textbf{rndc freeze ZONE}, ce qui va supprimer le journal et mettre à jour le fichier master. après modification, lancer \textbf{rndc thaw ZONE} pour recharger le zone changée et réactiver le dynamic update.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Transfert de zone incrémental }
 
\
 
\hspace{1mm}  Le protocole \textbf{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 \textbf{IXFR}. Pour les zones maîtres maintenues manuellement, et pour les zones esclaves obtenues par transfert de zone complet (\textbf{AXFR}), \textbf{IXFR} est supporté seulement si l'option \textbf{ixfr-from-differences} est à yes. En agissant comme esclave, BIND 9 va tenter d'utiliser IXFR par défaut.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Split DNS }
 
\
 
\hspace{1mm}  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:
\vspace{5mm} \\
 
 
\hspace{1mm} Configuration du serveur DNS interne:
 
{\ttfamily
acl internals \{ 172.16.72.0/24 ; 192.168.1.0/24 ; \};\\ acl externals \{ bastion-ips-go-here ; \};\\ \hspace{2mm}\\ options \{\\ \hspace{2mm}...\\ \hspace{2mm}...\\ \hspace{2mm}forward only;\\ \hspace{2mm}forwarders \{ bastion-ips-go-here ; \};\\ \hspace{2mm}allow-transfer \{ none ; \};\\ \hspace{2mm}allow-query \{ internals; externals; \};\\ \hspace{2mm}allow-recursion \{ internals ; \};\\ \hspace{2mm}...\\ \hspace{2mm}...\\ \};\\ \hspace{2mm}\\ zone "site1.example.com" \{\\ \hspace{2mm}type master;\\ \hspace{2mm}file "site1.example.com";\\ \hspace{2mm}forwarders \{\};\\ \hspace{2mm}allow-query \{ internals ; externals ; \};\\ \hspace{2mm}allow-transfer \{ internals ; \};\\ \};\\ \hspace{2mm}\\ zone "site2.example.com" \{\\ \hspace{2mm}type slave;\\ \hspace{2mm}file "site2.example.com";\\ \hspace{2mm}masters \{ 172.16.72.3; \};\\ \hspace{2mm}forwarders \{\};\\ \hspace{2mm}allow-query \{ internals; externals; \};\\ \hspace{2mm}allow-transfer \{ internals; \};\\ \};\\ \hspace{2mm}\\ zone "site1.internal" \{\\ \hspace{2mm}type master ;\\ \hspace{2mm}file "site1.internal" ;\\ \hspace{2mm}forwarders \{\};\\ \hspace{2mm}allow-query \{ internals ; \};\\ \hspace{2mm}allow-transfer \{ internals ; \};\\ ;\\ \hspace{2mm}\\ zone "site2.internal" \{\\ \hspace{2mm}type slave ;\\ \hspace{2mm}file "site2.internal" ;\\ \hspace{2mm}masters \{ 172.16.72.3 ; \};\\ \hspace{2mm}forwarders \{\};\\ \hspace{2mm}allow-query \{ internals ; \};\\ \hspace{2mm}allow-transfer \{ internals ; \};\\ \};\\
}
\vspace{8mm}
 
\hspace{1mm} Configuration du serveur DNS externe:
 
{\ttfamily
acl internals \{ 172.16.72.0/24 ; 192.168.1.0/24 ; \};\\ acl externals \{ bastion-ips-go-here ; \};\\ \hspace{2mm}\\ options \{\\ \hspace{2mm}...\\ \hspace{2mm}...\\ \hspace{2mm}allow-transfer \{ none ; \};\\ \hspace{2mm}allow-query \{ any ; \};\\ \hspace{2mm}allow-query-cache \{ internals ; externals ; \};\\ \hspace{2mm}allow-recursion \{ internals ; externals ; \};\\ \hspace{2mm}...\\ \hspace{2mm}...\\ \};\\ \hspace{2mm}\\ zone "site1.example.com" \{\\ \hspace{2mm}type master;\\ \hspace{2mm}file "site1.example.com";\\ \hspace{2mm}allow-transfer \{ internals; externals; \};\\ \};\\ \hspace{2mm}\\ zone "site2.example.com" \{\\ \hspace{2mm}type slave;\\ \hspace{2mm}file "site2.example.com";\\ \hspace{2mm}masters \{ another\_bastion\_host\_maybe ; \};\\ \hspace{2mm}allow-transfer \{ internals; externals; \};\\ \};\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge TSIG }
 
\
 
\hspace{1mm}  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".
\vspace{5mm} \\
 
 
\hspace{1mm} La commande suivante va générer une clé 128-bits HMAC-SHA256. la longueur max est de 256-bits. \\
\hspace{1mm} \textbf{dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2} \\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm} Imaginons 2 serveurs host1 et host2. Ajouter dans named.conf de chaque serveur:
 
{\ttfamily
key host1-host2. \{\\ \hspace{2mm}algorithm hmac-sha256;\\ \hspace{2mm}secret "La/E5CjG9O+os1jq0a2jdA==";\\ \};\\
}
\vspace{8mm}
 
\hspace{1mm} 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
 
{\ttfamily
server 10.1.2.3 \{\\ \hspace{2mm}keys \{ host1-host2. ; \};\\ \};\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge Contrôle d'accès basé sur les clés TSIG }
 
\
 
\hspace{1mm} 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: \\
\hspace{1mm} \textbf{allow-update \{ key host1-host2. ; \};} \\
\hspace{1mm} Cela permet aux dynamic update de s'effectuer uniquement si la requête est signée par al clé spécifiée. \\
 
\vspace{1cm}{\huge TKEY }
 
\
 
\hspace{1mm}  \textbf{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.
\vspace{5mm} \\
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge SIG(0) }
 
\
 
\hspace{1mm}  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é.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge DNSSEC }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Génération des clés }
 
\
 
\hspace{1mm}  le programme \textbf{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.
\vspace{5mm} \\
 
 
\hspace{1mm} Cette commande génère une clé 768-bits RSASHA1 pourla zone child.example.zone: \\
\hspace{1mm} \textbf{dnssec-keygen -a RSASHA1 -b 768 -n ZONE child.example.} \\
 
\hspace{1mm}  2 fichiers de sortie sont produits: \textbf{Kchild.example.+005+12345.key} et \textbf{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 \textbf{dnssec-keyfromlabel} est utilisé pour obtenir une paire de clé depuis une cryptographie hardware et construire les fichiers de clé. il fonctionne similairement à \textbf{dnssec-keygen}. Les clés publiques devraient être insérées dans le fichier de zone en incluant les fichiers .key en utilisant \$INCLUDE.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Signer la zone }
 
\
 
\hspace{1mm}  \textbf{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é.
\vspace{5mm} \\
 
 
\hspace{1mm} 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 \\
\hspace{1mm} \textbf{dnssec-signzone -o child.example zone.child.example} \\
\hspace{1mm} 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. \\
 
\hspace{1mm}  \textbf{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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Configurer les serveurs }
 
\
 
\hspace{1mm}  Pour permettre à named de répondre aux requêtes depuis des clients DNSSEC, \textbf{dnssec-enable} doit être à yes. Pour permettre à named de valider les réponses depuis d'autres serveurs, \textbf{dnssec-enable} et \textbf{dnssec-validation} doivent être à yes, et au moins en groupe trust doit être configuré avec les options \textbf{trusted-keys} ou \textbf{managed-keys}.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les trusted-keys sont des copies des \textbf{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 \textbf{trusted-keys} sont considérées pour exister et seul les clés listées seront utilisés pour valider le DNSKEY RRset.
\vspace{5mm} \\
 
 
\hspace{1mm}  \textbf{managed-keys} sont des clés de confiance qui sont automatiquement mis à jours via un groupe de maintenance de confiance.
\vspace{5mm} \\
 
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
{\ttfamily
managed-keys \{\\ \hspace{2mm}/* root Key */\\ \hspace{2mm}"." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS\\ \hspace{2mm}\hspace{2mm}JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh\\ \hspace{2mm}\hspace{2mm}aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy\\ \hspace{2mm}\hspace{2mm}4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg\\ \hspace{2mm}\hspace{2mm}hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp\\ \hspace{2mm}\hspace{2mm}5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke\\ \hspace{2mm}\hspace{2mm}g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq\\ \hspace{2mm}\hspace{2mm}66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ\\ \hspace{2mm}\hspace{2mm}97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ\\ \hspace{2mm}\hspace{2mm}dgxbcDTClU0CRBdiieyLMNzXG3";\\ \};\\ trusted-keys \{\\ \hspace{2mm}/* Key for our organization’s forward zone */\\ \hspace{2mm}example.com. 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6\\ \hspace{2mm}\hspace{2mm}5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z\\ \hspace{2mm}\hspace{2mm}GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb\\ \hspace{2mm}\hspace{2mm}4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL\\ \hspace{2mm}\hspace{2mm}kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O\\ \hspace{2mm}\hspace{2mm}g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S\\ \hspace{2mm}\hspace{2mm}TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq\\ \hspace{2mm}\hspace{2mm}FxmAVZP20igTixin/1LcrgX/KMEGd/biuv\\ \hspace{2mm}\hspace{2mm}F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm\\ \hspace{2mm}\hspace{2mm}/oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o\\ \hspace{2mm}\hspace{2mm}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\\ \hspace{2mm}\hspace{2mm}xOdNax071L18QqZnQQQAVVr+i\\ \hspace{2mm}\hspace{2mm}LhGTnNGp3HoWQLUIzKrJVZ3zg\\ \hspace{2mm}\hspace{2mm}gy3WwNT6kZo6c0tszYqbtvchm\\ \hspace{2mm}\hspace{2mm}gQC8CzKojM/W16i6MG/eafGU3\\ \hspace{2mm}\hspace{2mm}siaOdS0yOI6BgPsw+YZdzlYMa\\ \hspace{2mm}\hspace{2mm}IJGf4M4dyoKIhzdZyQ2bYQrjy\\ \hspace{2mm}\hspace{2mm}Q4LB0lC7aOnsMyYKHHYeRvPxj\\ \hspace{2mm}\hspace{2mm}IQXmdqgOJGq+vsevG06zW+1xg\\ \hspace{2mm}\hspace{2mm}YJh9rCIfnm1GX/KMgxLPG2vXT\\ \hspace{2mm}\hspace{2mm}D/RnLX+D3T3UL7HJYHJhAZD5L\\ \hspace{2mm}\hspace{2mm}59VvjSPsZJHeDCUyWYrvPZesZ\\ \hspace{2mm}\hspace{2mm}DIRvhDD52SKvbheeTJUm6Ehkz\\ \hspace{2mm}\hspace{2mm}ytNN2SN96QRk8j/iI8ib";\\ \};\\ options \{\\ \hspace{2mm}...\\ \hspace{2mm}dnssec-enable yes;\\ \hspace{2mm}dnssec-validation yes;\\ \};\\
}
\vspace{8mm}
 
\vspace{1cm}{\huge DNSSEC, zones dynamiques, et auto-signature }
 
\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Convertir en zone sécurisée }
 
\
 
\hspace{1mm} Celà peut être fait de 2 manières: utiliser un DNS dynamic update, ou l'option de zone auto-dnssec.
 
{\ttfamily
zone example.net \{\\ \hspace{2mm}type master;\\ \hspace{2mm}update-policy local;\\ \hspace{2mm}file "dynamic/example.net";\\ \hspace{2mm}key.directory "/dynamic";\\ \};\\
}
\vspace{8mm}
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Méthode de mise à jour DNS Dynamic }
 
\
 
\hspace{1mm} Pour insérer les clés via dynamic update \\
\hspace{1mm} \textbf{\% nsupdate} \\
\hspace{1mm} \textbf{> ttl 3600} \\
\hspace{1mm} \textbf{> update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3E} \\
\hspace{1mm} \textbf{> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZX} \\
\hspace{1mm} \textbf{> send} \\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\hspace{1mm} 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. \\
\hspace{1mm} \textbf{\% nsupdate} \\
\hspace{1mm} \textbf{> ttl 3600} \\
\hspace{1mm} \textbf{> update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfB} \\
\hspace{1mm} \textbf{> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X} \\
\hspace{1mm} \textbf{> update add example.net NSEC3PARAM 1 1 100 1234567890} \\
\hspace{1mm} \textbf{> send} \\
 
\hspace{1mm}  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.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Signer une zone automatiquement }
 
\
 
\hspace{1mm}  Pour activer la signture automatique, ajouter \textbf{auto-dnssec} à la déclaration de zone. Cette options a 2 arguments possibles: allow et maintain.
\vspace{5mm} \\
\hspace{1mm}  Avec \textbf{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 \textbf{rndc sign <zone-name>}
\vspace{5mm} \\
\hspace{1mm}  \textbf{auto-dnssec maintain} inclue la même fonctionnalité, mais va également ajuster automatiquement les records DNSKEY de la zone en accord
\vspace{5mm} \\
 
\end{flushleft}
\end{document}
