diff options
author | Colm MacCarthaigh <colm@apache.org> | 2010-01-08 11:45:43 +0000 |
---|---|---|
committer | Colm MacCarthaigh <colm@apache.org> | 2010-01-08 11:45:43 +0000 |
commit | 396931c93e46f5d130f0df7044a9c0e63fd12ebd (patch) | |
tree | 9ff5247f604985caa9581ebe4bfa6aa5164db5ce /APACHE_1_3_42/htdocs/manual/dns-caveats.html.fr | |
parent | 7d344b579813528064a6711a91f675b7f47e4926 (diff) | |
download | httpd-1.3.tar.gz |
Tag 1.3.421.3
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/tags/1.3@897175 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'APACHE_1_3_42/htdocs/manual/dns-caveats.html.fr')
-rw-r--r-- | APACHE_1_3_42/htdocs/manual/dns-caveats.html.fr | 269 |
1 files changed, 269 insertions, 0 deletions
diff --git a/APACHE_1_3_42/htdocs/manual/dns-caveats.html.fr b/APACHE_1_3_42/htdocs/manual/dns-caveats.html.fr new file mode 100644 index 0000000000..2def7c59d7 --- /dev/null +++ b/APACHE_1_3_42/htdocs/manual/dns-caveats.html.fr @@ -0,0 +1,269 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<!--Traduction anglais 1.4 --> + +<html xmlns="http://www.w3.org/1999/xhtml"> + <head> + <meta name="generator" content="HTML Tidy, see www.w3.org" /> + <meta http-equiv="Content-Type" + content="text/html; charset=iso-8859-1" /> + + <title>Apache et le DNS</title> + </head> + <!-- Background white, links blue (unvisited), navy (visited), red (active) --> + + <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" + vlink="#000080" alink="#FF0000"> + <!--#include virtual="header.html" --> + + <h1 align="CENTER">Apache et le DNS</h1> + + <p>Cette page aurait pu être résumée par la + phrase : <i>ne demandez pas à Apache d'utiliser le DNS + pour la lecture des fichiers de configuration</i>. Si Apache + doit utiliser le DNS pour récupérer ses fichiers + de configuration, alors votre serveur peut être sujet + à des problèmes de fiabilité (il peut tout + simplement ne pas démarrer), ou s'ouvrir à des + attaques et des vols d'information (y compris des utilisateurs + qui pourraient "voler" des hits d'autres utilisateurs).</p> + + <h3>Un exemple simple</h3> + Considérez ce court extrait de code de configuration : + + <blockquote> +<pre> + <VirtualHost www.abc.dom> + ServerAdmin webgirl@abc.dom + DocumentRoot /www/abc + </VirtualHost> +</pre> + </blockquote> + + <p>Pour qu'Apache fonctionne correctement, il a absolument + besoin d'au moins deux informations pour chaque hôte + virtuel : le <a + href="mod/core.html#servername"><code>ServerName</code></a> et + au moins une adresse IP à laquelle ce serveur doit + répondre. Cet exemple ne fait pas apparaître + d'adresse IP ; Apache doit donc utiliser le DNS pour trouver + l'adresse correspondant à <code>www.abc.dom</code>. Si + pour telle ou telle raison, le service de noms de domaines + n'est pas accessible au moment ou le serveur interprète + ses fichiers de configuration, alors cet hôte virtuel + <b>ne pourra pas être configuré</b>. Il ne pourra + donc pas répondre aux requêtes émises vers + cet hôte virtuel (les versions d'Apache + antérieures à la 1.2 n'auraient même pas pu + démarrer).</p> + + <p>Supposons que le doamine <code>www.abc.dom</code> ait pour + adresse 10.0.0.1. Considérez alors ce nouvel extrait de + code de configuration :</p> + + <blockquote> +<pre> + <VirtualHost 10.0.0.1> + ServerAdmin webgirl@abc.dom + DocumentRoot /www/abc + </VirtualHost> +</pre> + </blockquote> + + <p>Apache doit alors effectuer une résolution DNS + inverse pour trouver le nom <code>ServerName</code> pour cet + hôte virtuel. Si cette résolution échoue, + alors il devra partiellement désactiver cet hôte + virtuel (les versions d'Apache antérieures à la + 1.2 n'auraient même pas démarré). Si + l'hôte virtuel est basé sur un nom de domaine + alors il sera totalement inhibé, si par contre il se + base sur une adresse IP, alors il tournera probablement. + Cependant, si Apache devait générer une URL + complète pour ce serveur, incluant le nom de domaine, + l'URL produite ne pourrait être correctement + constituée.</p> + + <p>Voici un extrait qui élimine ces deux + problèmes.</p> + + <blockquote> +<pre> + <VirtualHost 10.0.0.1> + ServerName www.abc.dom + ServerAdmin webgirl@abc.dom + DocumentRoot /www/abc + </VirtualHost> +</pre> + </blockquote> + + <h3>Refus de service</h3> + + <p>Il existe (au moins) deux situations où Apache refuse + de fournir le service. Si vous exécutez une version + antérieure à la version 1.2 d'Apache, votre + serveur ne démarrera même pas si l'une des deux + résolutions DNS mentionnées ci-avant + échoue pour au moins un hôte virtuel. Dans + certains cas, cette résolution peut ne même pas + être sous votre contrôle. Par exemple, si + <code>abc.dom</code> est l'un de vos clients, lequel + contrôle son propre serveur DNS, ce dernier peut forcer + votre serveur Apache (en version antérieure à + 1.2) à s'arrêter au démarrage en supprimant + simplement l'enregistrement du nom + <code>www.abc.dom</code>.</p> + + <p>Une autre situation est beaucoup plus pernicieuse. + Considérez cet extrait de code de configuration :</p> + + <blockquote> +<pre> + <VirtualHost www.abc.dom> + ServerAdmin webgirl@abc.dom + DocumentRoot /www/abc + </VirtualHost> +</pre> + </blockquote> + + <blockquote> +<pre> + <VirtualHost www.def.dom> + ServerAdmin webguy@def.dom + DocumentRoot /www/def + </VirtualHost> +</pre> + </blockquote> + + <p>Supposez que vous avez assigné 10.0.0.1 au domaine + <code>www.abc.dom</code> et 10.0.0.2 au domaine + <code>www.def.dom</code>. De plus, supposez que + <code>def.com</code> contrôle son propre service DNS. + Avec la précédente configuration, vous permettez + à <code>def.com</code> de "voler" tout le trafic + destiné à <code>abc.com</code>. Tout ce qu'ils + auraient à faire pour y parvenir est d'assigner + <code>www.def.dom</code> à l'adresse 10.0.0.1. Dans la + mesure où ils contrôlent leur propre DNS, vous ne + pouvez les empêcher de piéger leur enregistrement + de <code>www.def.com</code>.</p> + + <p>Les requêtes arrivant pour 10.0.0.1 (y compris toutes + celles où les utilisateurs auront tapé une URL de + la forme <code>http://www.abc.dom/qqchose</code>) seront toutes + servies par l'hôte virtuel <code>def.com</code>. Mieux + comprendre comment cela est possible demande une discussion + plus détaillée sur la manière dont Apache + traite des requêtes arrivant pour des hôtes + virtuels. Un premier document descrivant ceci est <a + href="vhosts/details.html">disponible</a>.</p> + + <h3>L'adresse du "serveur principal"</h3> + + <p>L'addition du <a href="vhosts/name-based.html">support + d'hôtes virtuels basés sur les noms</a> dans + Apache 1.1 nécessite qu'Apache connaisse les adresses IP + de l'hôte sur lequel est exécuté httpd. + Pour obtenir cette adresse, il utilise soit le + <code>ServerName</code> global (si défini) ou appelle la + fonction C <code>gethostname</code> (qui renvoie une + information similaire à celle donnée par la + commande interactive "hostname"). Puis il procède + à une résolution DNS pour cette adresse. + Jusqu'à présent, il n'y a aucun moyen + d'éviter cette résolution.</p> + + <p>Si vous craignez que cette résolution échoue + parceque votre serveur DNS est arrêté, alors vous + popuvez ajouter le nom d'hôte dans le fichier + <code>/etc/hosts</code> (où il devrait normalement + déjà figurer, ne serait-ce que pour assurer un + démarrage correct de la machine). Vous devrez en outre + vous assurer que votre machine est configurée pour + exploiter le fichier <code>/etc/hosts</code> en cas + d'échec d'une résolution dynamique. Suivant l'OS + que vous utilisez, ceci peut être fait en éditant + le code <code>/etc/resolv.conf</code>, ou peut être + <code>/etc/nsswitch.conf</code>.</p> + + <p>Si votre machine n'a pas de résolution DNS à + effectuer pour toute autre raison (par exemple parce qu'elle + est isolée), alors vous pourrez néanmoins faire + tourner Apache en initialisant la variable d'environnement + <code>HOSTRESORDER</code> à "local". Tout ceci + dépend de l'OS et des librairies de résolveur que + vous utilisez. Les CGI sont également affectés + sauf si vous utilisez la fonctionnalité <a + href="mod/mod_env.html"><code>mod_env</code></a> pour + contrôler l'environnement. Il est prudent de consulter + les pages de manuel ou les FAQ spécifiques à + votre OS.</p> + + <h3><a id="tips" name="tips">Astuces pour éviter ces + problèmes</a></h3> + + <ul> + <li>utilisez des adresses IP dans les sections + <code><VirtualHost></code></li> + + <li>utilisez des adresses IP dans la clause + <code>Listen</code></li> + + <li>utilisez des adresses IP dans la clause + <code>BindAddress</code></li> + + <li>assurez vous que tous les hôtes virtuels on un + <code>ServerName</code></li> + + <li>créez un serveur <code><VirtualHost + _default_:*></code> qui ne sert aucune page.</li> + </ul> + + <h3>Annexe: Directions futures</h3> + + <p>Cette situation vis-à-vis du DNS est largement + insatisfaisante. Pour Apache 1.2, nous avons travaillé + pour que le serveur puisse continuer à démarrer + dans le cas de l'échec d'une résolution DNS, mais + il est possible que nous puissions en faire plus. Toute + écriture nécessitant l'usage d'adresses IP + explicites dans le fichier de configuration n'est pas + souhaitable dans le contexte Internet actuel où la <a + href="http://www.ietf.org/html.charters/pier-charter.html">rotation + d'adresses</a> est une nécessité.</p> + + <p>Une parade au vol de service serait d'effectuer une + résolution DNS inverse sur l'adresse IP renvoyée + par la résolution directe, et comparer les deux noms. En + cas de non concordance, cet hôte virtuel serait + désactivé. Ceci impliquerait que la + résolution DNS inverse soit correctement + configurée (ce qui reste assez connu des administrateurs + du fait de l'usage commun de la résolution inverse + double par les serveurs FTP et les transposeurs TCP).</p> + + <p>Dans tous les cas, il ne semble pas possible de garantir la + fiabilité du démarrage d'un serveur web + gérant des hôtes virtuels lorsque la + résolution DNS a échoué, sauf si la + définition de ces hôtes utilise des adresses IP + explicites. Une solution partielle consistant à ignorer + certaines portions du fichier de configuration serait encore + pire que ne pas démarrer du tout, dans certains cas + d'exploitation.</p> + + <p>Par l'extension de l'usage de HTTP/1.1, les navigateurs et + proxies fournissent de plus en plus souvent l'en-tête + <code>Host</code>, et il deviendra possible d'éviter + totalement la définition d'hôtes virtuels + basés sur des adresses IP. Dans ce cas, un serveur Web + n'aura plus de résolution DNS à effectuer pendant + la configuration. Mais à la date de Mars 1997, ces + fonctionnalités n'ont pas été suffisament + largement déployées pour pouvoir être + exploitées par des serveurs en situation critique. + <!--#include virtual="footer.html" --> + </p> + </body> +</html> + |