<-
Apache > Serveur HTTP > Documentation > Version 2.4

Problèmes liés au DNS avec le serveur HTTP Apache

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

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 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 l'attribution de requêtes à un serveur virtuel autre que le serveur virtuel voulu).

top

Un exemple simple

# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
# de configuration
<VirtualHost www.example.dom>
  ServerAdmin [email protected]
  DocumentRoot /www/example
</VirtualHost>
    

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 ServerName, 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 que httpd devra utiliser le DNS pour trouver l'adresse IP de www.example.dom. 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 ne sera pas pris en compte dans la configuration. Il sera incapable de répondre à toute requête pour ce serveur virtuel.

Supposons que l'adresse de www.example.dom soit 192.0.2.1, et examinons cet extrait de configuration :

# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
# de configuration
<VirtualHost 192.0.2.1>
  ServerAdmin [email protected]
  DocumentRoot /www/example
</VirtualHost>
    

Cette fois, httpd doit effectuer une recherche DNS inverse pour trouver le nom ServerName de ce serveur virtuel. Si cette recherche inverse échoue, le serveur virtuel sera 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, 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).

Voici un extrait de configuration qui permet d'éviter ces deux types de problèmes :

<VirtualHost 192.0.2.1>
  ServerName www.example.dom
  ServerAdmin [email protected]
  DocumentRoot /www/example
</VirtualHost>
    
top

Déni de service

Considérons cet extrait de configuration :

<VirtualHost www.example1.dom>
  ServerAdmin [email protected]
  DocumentRoot /www/example1
</VirtualHost>
<VirtualHost www.example2.dom>
  ServerAdmin [email protected]
  DocumentRoot /www/example2
</VirtualHost>
    

Supposons que vous ayez assigné 192.0.2.1 à www.example1.dom et 192.0.2.2 à www.example2.dom. En outre, supposons que example1.dom gère son propre DNS. Avec cette configuration, example1.dom sera en mesure de détourner tout trafic destiné à example2.dom. Pour y parvenir, tout ce qu'ils ont à faire consiste à assigner 192.0.2.2 à www.example1.dom. Comme ils gèrent leur propre DNS, vous ne pouvez pas les empêcher de faire pointer l'enregistrement www.example1.dom vers l'adresse qu'ils veulent.

Les requêtes à destination de 192.0.2.2 (y compris toutes celles où l'utilisateur à tapé une URL de la forme http://www.example2.dom/quelquepart), seront toutes servies par le serveur virtuel example1.dom. 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 httpd associe les requêtes entrantes aux différents serveurs virtuels qui vont les servir. Un document de base décrivant ceci est disponible.

top

L'adresse du "serveur principal"

Le support des serveurs virtuels à base de nom oblige httpd à connaître la/les adresse(s) IP de l'hôte sur lequel httpd s'exécute. Pour obtenir cette adresse, soit il utilise la directive ServerName globale (si elle est présente), soit il fait appel à la fonction C gethostname (qui doit renvoyer le même nom que la commande shell "hostname"). Il effectue ensuite une recherche DNS sur cette adresse. Pour le moment, il n'existe aucun moyen d'éviter cette recherche DNS.

Si vous craignez que cette recherche DNS échoue parce que votre serveur DNS est arrêté, vous pouvez insérer le nom d'hôte dans le fichier /etc/hosts (où il est probablement déjà enregistré afin que la machine démarre correctement). Assurez-vous ensuite que la machine est configurée pour utiliser /etc/hosts dans le cas où la recherche DNS échoue. Suivant le système d'exploitation que vous utilisez, vous y parviendrez en éditant /etc/resolv.conf, ou /etc/nsswitch.conf.

Si votre serveur n'a aucune autre raison d'effectuer des recherches DNS, vous pouvez définir la variable d'environnement HOSTRESORDER à "local", et vous serez alors en mesure 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 mod_env pour contrôler l'environnement. Il est conseillé de consulter les pages de manuel ou les FAQs de votre système d'exploitation.

top

Conseils pour éviter ce genre de problème

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

top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.