<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
-<!-- English Revision : 507346 -->
+<!-- English Revision : 1332626 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<manualpage metafile="dns-caveats.xml.meta">
- <title>Problèmes liés au DNS avec Apache</title>
+ <title>Problèmes liés au DNS avec le serveur HTTP Apache</title>
<summary>
- <p>Cette page pourrait se résumer ainsi : configurez Apache de façon
+ <p>Cette page pourrait se résumer ainsi : configurez le
+ serveur HTTP Apache de façon
à ce qu'il n'ait pas besoin de résolution DNS pour interpréter les
- fichiers de configuration. Si Apache doit effectuer des résolutions
+ fichiers de configuration. Si httpd doit effectuer des résolutions
DNS pour interpréter les fichiers de configuration, votre serveur
pourra présenter des problèmes de fiabilité (en d'autres termes,
il est possible qu'il refuse de démarrer), ou d'attaques par déni ou
- usurpation de service (y compris le détournement d'informations
- utilisateurs).</p>
+ usurpation de service (y compris l'attribution de requêtes à un
+ serveur virtuel autre que le serveur virtuel voulu).</p>
</summary>
<section id="example">
<title>Un exemple simple</title>
- <example>
- # Cet exemple de configuration est invalide, ne l'utilisez pas comme base
- # de configuration
- <VirtualHost www.abc.dom> <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
- </VirtualHost>
- </example>
+ <highlight language="config">
+# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
+# de configuration
+<VirtualHost www.example.dom>
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
+</VirtualHost>
+ </highlight>
- <p>Pour fonctionner correctement, Apache a absolument besoin de deux
+ <p>Pour fonctionner correctement, le serveur a absolument besoin de deux
informations à propos de chaque serveur virtuel : le nom du serveur
défini par la directive <directive
module="core">ServerName</directive>, et au moins une adresse IP à
laquelle le serveur va se rattacher et répondre. L'exemple ci-dessus
- ne comporte pas d'adresse IP, si bien qu'Apache devra utiliser le
- DNS pour trouver l'adresse IP de <code>www.abc.dom</code>. Si pour
+ ne comporte pas d'adresse IP, si bien que httpd devra utiliser le
+ DNS pour trouver l'adresse IP de <code>www.example.dom</code>. Si pour
une raison quelconque, le DNS n'est pas disponible au moment où
votre serveur interprète son fichier de configuration, ce serveur
virtuel <strong>ne sera pas pris en compte dans la
configuration</strong>. Il sera incapable de
- répondre à toute requête pour ce serveur virtuel (avec les versions
- d'Apache antérieures à 1.2, le serveur ne démarrera tout simplement
- pas).</p>
+ répondre à toute requête pour ce serveur virtuel.</p>
- <p>Supposons que l'adresse de <code>www.abc.dom</code> soit
+ <p>Supposons que l'adresse de <code>www.example.dom</code> soit
192.0.2.1, et examinons cet extrait de configuration :</p>
- <example>
- # Cet exemple de configuration est invalide, ne l'utilisez pas comme base
- # de configuration
- <VirtualHost 192.0.2.1> <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
- </VirtualHost>
- </example>
+ <highlight language="config">
+# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
+# de configuration
+<VirtualHost 192.0.2.1>
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
+</VirtualHost>
+ </highlight>
- <p>Cette fois, Apache doit effectuer une recherche DNS inverse pour
+ <p>Cette fois, httpd doit effectuer une recherche DNS inverse pour
trouver le nom <code>ServerName</code> de ce serveur virtuel. Si
cette recherche inverse échoue, le serveur virtuel sera
- partiellement désactivé (avec les versions d'Apache antérieures à
- 1.2, le serveur ne démarrera tout simplement pas). Si le serveur
+ partiellement désactivé. Si le serveur
virtuel est à base de nom, il sera en fait totalement désactivé,
mais s'il est à base d'adresse IP, il fonctionnera probablement.
- Cependant, Apache échouera s'il doit générer une URL complète pour
- le serveur qui inclut ce nom de serveur.</p>
+ Cependant, httpd échouera s'il doit générer une URL complète pour
+ le serveur qui inclut ce nom de serveur (comme dans le cas d'une
+ redirection).</p>
<p>Voici un extrait de configuration qui permet d'éviter ces deux
types de problèmes :</p>
- <example>
- <VirtualHost 192.0.2.1> <br />
- ServerName www.abc.dom <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
- </VirtualHost>
- </example>
+ <highlight language="config">
+<VirtualHost 192.0.2.1>
+ ServerName www.example.dom
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
+</VirtualHost>
+ </highlight>
</section>
<section id="denial">
<title>Déni de service</title>
- <p>Il existe (au moins) deux formes possibles de déni de service. Si
- vous utilisez une version d'Apache antérieure à 1.2, votre serveur
- ne démarrera pas si une des deux recherches DNS mentionnées
- ci-dessus échoue pour au moins un de vos serveurs virtuels. Dans
- certains cas, cette recherche DNS ne sera même pas sous votre
- contrôle ; par exemple, si <code>abc.dom</code> est un de vos
- clients et s'il gère son propre DNS, il peut empêcher votre
- serveur (pre-1.2) de démarrer, simplement en supprimant
- l'enregistrement <code>www.abc.dom</code>.</p>
-
- <p>La deuxième forme de déni de service est beaucoup plus subtile.
- Examinons cet extrait de configuration :</p>
-
- <example>
- <VirtualHost www.abc.dom><br />
- <indent>
- ServerAdmin webgirl@abc.dom<br />
- DocumentRoot /www/abc<br />
- </indent>
- </VirtualHost><br />
- <br />
- <VirtualHost www.def.dom><br />
- <indent>
- ServerAdmin webguy@def.dom<br />
- DocumentRoot /www/def<br />
- </indent>
- </VirtualHost>
- </example>
-
- <p>Supposons que vous avez assigné 192.0.2.1 à
- <code>www.abc.dom</code> et 192.0.2.2 à <code>www.def.dom</code>. En
- outre, supposons que <code>def.dom</code> gère son propre DNS. Avec
- cette configuration, <code>def.dom</code> sera en mesure de
- détourner tout trafic destiné à <code>abc.dom</code>. Pour y
- parvenir, tout ce qu'ils ont à faire consiste à assigner 192.0.2.1 à
- <code>www.def.dom</code>. Comme ils gèrent leur propre DNS, vous ne
+ <p>Considérons cet extrait de configuration :</p>
+
+ <highlight language="config">
+<VirtualHost www.example1.dom>
+ ServerAdmin webgirl@example1.dom
+ DocumentRoot /www/example1
+</VirtualHost>
+<VirtualHost www.example2.dom>
+ ServerAdmin webguy@example2.dom
+ DocumentRoot /www/example2
+</VirtualHost>
+ </highlight>
+
+ <p>Supposons que vous ayez assigné 192.0.2.1 à
+ <code>www.example1.dom</code> et 192.0.2.2 à <code>www.example2.dom</code>. En
+ outre, supposons que <code>example1.dom</code> gère son propre DNS. Avec
+ cette configuration, <code>example1.dom</code> sera en mesure de
+ détourner tout trafic destiné à <code>example2.dom</code>. Pour y
+ parvenir, tout ce qu'ils ont à faire consiste à
+ assigner 192.0.2.2 à
+ <code>www.example1.dom</code>. Comme ils gèrent leur propre DNS, vous ne
pouvez pas les empêcher de faire pointer l'enregistrement
- <code>www.def.dom</code> vers l'adresse qu'ils veulent.</p>
+ <code>www.example1.dom</code> vers l'adresse qu'ils veulent.</p>
- <p>Les requêtes à destination de 192.0.2.1 (y compris toutes celles
+ <p>Les requêtes à destination de 192.0.2.2 (y compris toutes celles
où l'utilisateur à tapé une URL de la forme
- <code>http://www.abc.dom/quelquepart</code>), seront toutes servies
- par le serveur virtuel <code>def.dom</code>. Une meilleur
+ <code>http://www.example2.dom/quelquepart</code>), seront toutes servies
+ par le serveur virtuel <code>example1.dom</code>. Une meilleur
compréhension de la raison pour laquelle ceci peut se produire
nécessite une discussion plus approfondie à propos de la manière
- dont Apache associe les requêtes entrantes aux différents serveurs
+ dont httpd associe les requêtes entrantes aux différents serveurs
virtuels qui vont les servir. Un document de base décrivant ceci <a
href="vhosts/details.html">est disponible</a>.</p>
</section>
<section id="main">
<title>L'adresse du "serveur principal"</title>
- <p>L'addition du <a href="vhosts/name-based.html">support des
- serveurs virtuels à base de nom</a> dans la version 1.1 d'Apache
- oblige ce dernier à connaître la/les adresse(s) IP de l'hôte sur
+ <p><a href="vhosts/name-based.html">Le support des
+ serveurs virtuels à base de nom</a> oblige httpd à
+ connaître la/les adresse(s) IP de l'hôte sur
lequel <program>httpd</program> s'exécute. Pour obtenir cette
adresse, soit il utilise la directive <directive
module="core">ServerName</directive> globale (si elle est présente),
<p>Si votre serveur n'a aucune autre raison d'effectuer des
recherches DNS, vous pouvez définir la variable d'environnement
<code>HOSTRESORDER</code> à "local", et vous serez alors en mesure
- d'exécuter Apache. Tout dépend du système d'exploitation et des
+ d'exécuter httpd. Tout dépend du système d'exploitation et des
bibliothèques de résolution de noms que vous utilisez. Elle affecte
aussi les programmes CGI, à moins que vous n'utilisiez
<module>mod_env</module> pour contrôler l'environnement. Il est
</ul>
</section>
- <section id="appendix">
- <title>Appendice : orientations pour le futur</title>
-
- <p>La situation concernant le DNS apparaît clairement comme non
- souhaitable. Avec Apache 1.2, nous avons fait en sorte que le
- serveur puisse au moins démarrer en cas d'échec de recherche DNS,
- mais ce n'est pas ce que nous pouvons faire de mieux. En tout état
- de cause, le fait de devoir spécifier des adresses IP explicites
- dans les fichiers de configuration est fortement non souhaitable
- avec l'Internet d'aujourd'hui où les changements de numérotation
- sont une nécessité.</p>
-
- <p>Il est possible d'éviter les attaques par usurpation de service
- décrites ci-dessus en effectuant une recherche DNS inverse sur
- l'adresse IP renvoyée par la recherche DNS directe et en comparant
- les deux noms -- en cas de non correspondance, le serveur virtuel
- serait désactivé. Ceci nécessite cependant une configuration
- correcte du DNS inverse (ce avec quoi les administrateurs sont
- familiers à cause de l'utilisation courante des doubles recherches
- DNS inverses par les serveurs FTP et les TCP wrappers).</p>
-
- <p>En tout état de cause, il ne semble pas envisageable de démarrer
- de manière fiable un serveur web avec serveurs virtuels losqu'une
- recherche DNS a échoué, sauf si l'on utilise des adresses IP. Les
- solutions partielles consistant à désactiver des portions de
- configuration pourraient s'avérer pires que ne pas démarrer du tout
- ; tout dépend de ce que le serveur est supposé faire.</p>
-
- <p>Au fur et à mesure du déploiement de HTTP/1.1, et comme les
- navigateurs et les mandataires commencent à générer l'en-tête
- <code>Host</code>, il devient possible d'envisager de se passer
- complètement des serveurs virtuels à base d'adresses IP. Dans ce
- cas, un serveur web n'a besoin d'aucune recherche DNS pendant
- l'interprétation de ses fichiers de configuration. Cependant, au
- mois de mars 1997, ces fonctionnalités n'ont pas été assez largement
- déployées pour être utilisées sur des serveurs web critiques.</p>
- </section>
</manualpage>