Problèmes DNS avec Apache - Serveur Apache HTTP

Serveur Apache HTTP Version 2.0

Apache > Serveur HTTP > Documentation > Version 2.0

# Problèmes DNS avec Apache

Langues Disponibles: en | es | fr | ja | ko

L'ensemble de cette page pourrait se résumer à la phrase : ne jamais configurer Apache de telle sorte qu'il s'appuie sur des résolutions DNS pour parcourir ses fichiers de configuration. Une telle configuration risque d'engendrer des problèmes de fiabilité (le serveur peut ne pas démarrer), des attaques de type déni et de vol de service (comme par exemple des utilisateurs volant les hits d'autres utilisateurs).

## Un exemple simple

`<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>`

Pour qu'Apache fonctionne correctement, il a absolument besoin de deux informations pour chacun de ses serveurs virtuels : `ServerName` ainsi qu'au moins une adresse IP à laquelle le serveur s'attachera pour répondre. L'exemple ci-dessus ne précise pas l'adresse IP, si bien qu'Apache doit utiliser le DNS pour trouver l'adresse de `www.abc.dom`. Si, pour une raison ou une autre, le DNS ne fonctionne pas au moment où Apache lit ses fichiers de configuration, le serveur virtuel ne sera pas configuré. Il sera incapable de répondre aux requêtes. Jusqu'à la version 1.2, Apache refusait même de démarrer dans ce cas de figure.

Prenons le cas où l'adresse de `www.abc.dom` est 10.0.0.1 et considérons cet extrait de configuration :

`<VirtualHost 10.0.0.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>`

Cette fois, Apache a besoin d'utiliser la résolution DNS inversée pour déterminer le nom `ServerName` de ce serveur virtuel. Si cette résolution n'aboutit pas, le serveur virtuel sera partiellement mis hors service (jusqu'à la version 1.2, Apache refusait même de démarrer dans ce cas de figure). Si le serveur virtuel est un serveur basé sur un nom (name-based), il sera totalement hors service, mais s'il s'agit d'un serveur par IP (IP-based), il fonctionnera correctement. Cependant, dans le cas où Apache doit générer une adresse complète URL en s'appuyant sur le nom du serveur, il échouera à fournir une adresse valide.

Voici un extrait de configuration qui résout ces deux problèmes :

`<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>`

## Déni de Service

Il existe (au moins) deux problèmes possibles de déni de service. Les versions d'Apache antérieures à 1.2 ne démarreront pas si l'une des deux requêtes DNS citées ci-dessus n'aboutissent pas pour un de vos serveurs virtuels. Dans certains cas, les entrées DNS sont hors de contrôle de l'administrateur Web ; par exemple si `abc.dom` appartient à un de vos clients qui a la maîtrise de son propre DNS, celui-ci peut empêcher votre serveur Web (avant la version 1.2) de démarrer, simplement en effaçant l'enregistrement `www.abc.dom` du DNS.

L'autre problème possible est bien plus pernicieux. Dans la configuration suivante :

`<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
<VirtualHost www.def.dom>
ServerAdmin webguy@def.dom
DocumentRoot /www/def
</VirtualHost>`

Supposons que `www.abc.dom` ait l'adresse 10.0.0.1, et que `www.def.dom` ait l'adresse 10.0.0.2. Supposons également que `def.com` ait la main sur son DNS. Cette configuration peut permettre à `def.dom` de détourner vers son serveur tout le trafic destiné à `abc.dom`. Pour ce faire, il doit simplement positionner le champ DNS de `www.def.dom` sur 10.0.0.1, et rien ne peut l'empêcher de faire, puisqu'il a la main sur son DNS.

Les requêtes à destination de 10.0.0.1 (incluant celles dont l'URL contient `http://www.abc.com/tout_et_n_importe_quoi`) seront envoyées au serveur virtuel de `def.dom`. Une bonne compréhension des mécanismes internes d'Apache concernant la gestion des serveur virtuels est requise. Ce document explique ce fonctionnement.

## L'Adresse du "serveur principal"

L'implémentation du support des serveur virtuels par nom depuis Apache 1.1 suppose qu'Apache connaisse la ou les adresse(s) IP sur lesquelles le serveur écoute. Pour déterminer cette adresse, Apache utilise soit la directive globale `ServerName` (si elle est présente), soit un appel à la fonction C `gethostname` (cet appel renvoie le même résultat que la commande "hostname" entrée sur une ligne de commande). Une résolution DNS est alors effectuée sur l'adresse obtenue. Pour l'instant, il n'existe aucun moyen de contourner cette requête DNS.

Pour se prémunir du cas où cette résolution DNS échouerait à cause de la défaillance du serveur DNS, le nom d'hôte peut être ajouté dans `/etc/hosts` (il y est probablement déjà). Assurez vous que votre machine est configurée pour lire ce fichier `/etc/hosts` en cas de défaillance du serveur DNS. Pour cela, selon votre système d'exploitation, il vous faudra configurer `/etc/resolv.conf` ou `/etc/nsswitch.conf`.

Au cas où votre serveur n'a pas besoin de réaliser des requêtes DNS pour d'autres raisons que de démarrer Apache, il est possible que vous puissiez vous en sortir en positionnant la variable d'environnement `HOSTRESORDER` sur "local". Ceci dépend cependant de votre système d'exploitation et des librairies de résolution DNS que vous utilisez. Ceci affecte également le comportement des scripts CGIs, à moins que vous n'utilisiez `mod_env` pour contrôler leur environnement. La meilleure solution est de consulter les pages "man" ou les FAQs spécifiques à votre système d'exploitation.

## Comment éviter ces problèmes

- spécifier les adresses IP dans les `VirtualHost`
- spécifier les adresses IP au moyen de `Listen`
- s'assurer que tous les serveurs virtuels spécifient explicitement leur `ServerName`
- créer un serveur virtuel `<VirtualHost _default_:*>` qui ne sert aucune page

## Appendice: Perspectives futures

Les problèmes liés au DNS sont très indésirables. À partir d'Apache 1.2, nous avons travaillé à ce qu'Apache démarre même dans le cas où les requêtes DNS échouent, mais ce n'est pas forcément la meilleure des solutions. En tous cas, obliger l'administrateur à spécifier explicitement des adresses IP est également très indésirable sur le réseau Internet tel qu'il existe actuellement, où le nombre d'adresses IP commence à manquer.

Une réponse possible au problème de vol de trafic décrit ci-avant pourrait être de réaliser une résolution inverse DNS sur l'adresse IP renvoyée par la première requête, et de comparer les deux noms obtenus -- lorsqu'ils sont différents, le serveur virtuel serait désactivé. Ceci suppose que la configuration pour la résolution inverse DNS soit faite correctement (c'est une chose à laquelle les administrateurs DNS commencent à s'habituer, en raison de l'utilisation de plus en plus répandue des requêtes DNS "double-reverse" par les serveurs FTP et les filtrages "TCP wrappers").

Dans tous les cas de figures, il ne semble pas possible de démarrer de façon fiable un serveur virtuel quand la requête DNS a échoué, à moins de recourir à l'utilisation d'adresses IP fixes. Des solutions partielles, telles que désactiver des portions de la configuration selon les tâches attribuées au serveur Web, risquent d'être pires que ne pas démarrer du tout.

Au fur et à mesure que HTTP/1.1 se répand, et que les navigateurs et les serveurs mandataires envoient l'en-tête `Host`, il devient possible d'éviter complètement l'utilisation de serveurs virtuels par IP. Dans ce cas, les serveurs Web n'ont plus aucun besoin de réaliser des requêtes DNS lors de leur démarrage. Au 1er mars 1997, ces fonctionnalités ne sont pas suffisamment déployées pour que des serveurs Web sensibles les mettent en oeuvre (NdT : cette remarque est aujourd'hui complètement dépassée, HTTP/1.1 est désormais supporté par l'immense majorité des navigateurs et des serveurs mandataires).

Langues Disponibles: en | es | fr | ja | ko