| Current Path : /compat/linux/proc/self/root/usr/local/share/doc/apache/ |
FreeBSD hs32.drive.ne.jp 9.1-RELEASE FreeBSD 9.1-RELEASE #1: Wed Jan 14 12:18:08 JST 2015 root@hs32.drive.ne.jp:/sys/amd64/compile/hs32 amd64 |
| Current File : //compat/linux/proc/self/root/usr/local/share/doc/apache/dns-caveats.html.fr |
<!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">
<div align="CENTER">
<img src="images/sub.gif" alt="[APACHE DOCUMENTATION]" />
<h3>Apache HTTP Server Version 1.3</h3>
<p><small><em>Is this the version you want? For more recent
versions, check our <a href="/docs/">documentation
index</a>.</em></small></p>
</div>
<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.
<hr />
<h3 align="CENTER">Apache HTTP Server</h3>
<a href="./"><img src="images/index.gif" alt="Index" /></a>
</p>
</body>
</html>