Problèmes DNS avec Apache

Un exemple simple

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 :

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 :

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 :

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).