| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| <HTML><HEAD> |
| <TITLE>Issues Regarding DNS and Apache</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">Issues Regarding DNS and Apache</H1> |
| |
| <P>This page could be summarized with the statement: <EM>don't require |
| Apache to use DNS for any parsing of the configuration files</EM>. |
| If Apache has to use DNS to parse the configuration files then your |
| server may be subject to reliability problems (it might not boot), or |
| denial and theft of service attacks (including users able to steal hits |
| from other users). |
| |
| <H3>A Simple Example</H3> |
| |
| Consider this configuration snippet: |
| |
| <BLOCKQUOTE><PRE> |
| <VirtualHost www.abc.dom> |
| ServerAdmin webgirl@abc.dom |
| DocumentRoot /www/abc |
| </VirtualHost> |
| </PRE></BLOCKQUOTE> |
| |
| <P>In order for Apache to function properly it absolutely needs |
| to have two pieces of information about each virtual host: the |
| <A HREF="mod/core.html#servername"><CODE>ServerName</CODE></A> |
| and at least one IP address that the server |
| responds to. This example does not include the IP address, so Apache |
| must use DNS to find the address of <CODE>www.abc.dom</CODE>. If for |
| some reason DNS is not available at the time your server is parsing its |
| config file, then this virtual host <STRONG>will not be configured</STRONG>. It |
| won't be able to respond to any hits to this virtual host (prior to |
| Apache version 1.2 the server would not even boot). |
| |
| <P>Suppose that <CODE>www.abc.dom</CODE> has address 10.0.0.1. Then |
| consider this configuration snippet: |
| |
| <BLOCKQUOTE><PRE> |
| <VirtualHost 10.0.0.1> |
| ServerAdmin webgirl@abc.dom |
| DocumentRoot /www/abc |
| </VirtualHost> |
| </PRE></BLOCKQUOTE> |
| |
| <P>Now Apache needs to use reverse DNS to find the <CODE>ServerName</CODE> |
| for this virtualhost. If that reverse lookup fails then it will partially |
| disable the virtualhost (prior to Apache version 1.2 the server would not |
| even boot). If the virtual host is name-based then it will effectively |
| be totally disabled, but if it is IP-based then it will mostly work. |
| However if Apache should ever have to generate a full URL for the server |
| which includes the server name then it will fail to generate a valid URL. |
| |
| <P>Here is a snippet that avoids both of these problems. |
| |
| <BLOCKQUOTE><PRE> |
| <VirtualHost 10.0.0.1> |
| ServerName www.abc.dom |
| ServerAdmin webgirl@abc.dom |
| DocumentRoot /www/abc |
| </VirtualHost> |
| </PRE></BLOCKQUOTE> |
| |
| <H3>Denial of Service</H3> |
| |
| <P>There are (at least) two forms that denial of service can come in. |
| If you are running a version of Apache prior to version 1.2 then your |
| server will not even boot if one of the two DNS lookups mentioned above |
| fails for any of your virtual hosts. In some cases this DNS lookup may |
| not even be under your control. For example, if <CODE>abc.dom</CODE> |
| is one of your customers and they control their own DNS then they |
| can force your (pre-1.2) server to fail while booting simply by deleting the |
| <CODE>www.abc.dom</CODE> record. |
| |
| <P>Another form is far more insidious. Consider this configuration |
| snippet: |
| |
| <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>Suppose that you've assigned 10.0.0.1 to <CODE>www.abc.dom</CODE> and |
| 10.0.0.2 to <CODE>www.def.dom</CODE>. Furthermore, suppose that |
| <CODE>def.com</CODE> has control of their own DNS. With this config |
| you have put <CODE>def.com</CODE> into a position where they can steal |
| all traffic destined to <CODE>abc.com</CODE>. To do so, all they have to |
| do is set <CODE>www.def.dom</CODE> to 10.0.0.1. |
| Since they control their own DNS you can't stop them from pointing the |
| <CODE>www.def.com</CODE> record wherever they wish. |
| |
| <P>Requests coming in to 10.0.0.1 (including all those where users typed |
| in URLs of the form <CODE>http://www.abc.dom/whatever</CODE>) will all be |
| served by the <CODE>def.com</CODE> virtual host. To better understand why |
| this happens requires a more in-depth discussion of how Apache matches |
| up incoming requests with the virtual host that will serve it. A rough |
| document describing this <A HREF="vhosts/details.html"> is available</A>. |
| |
| <H3>The "main server" Address</H3> |
| |
| <P>The addition of <A HREF="vhosts/name-based.html">name-based virtual host |
| support</A> in Apache 1.1 requires Apache to know the IP address(es) of |
| the host that httpd is running on. To get this address it uses either |
| the global <CODE>ServerName</CODE> (if present) or calls the C function |
| <CODE>gethostname</CODE> (which should return the same as typing |
| "hostname" at the command prompt). Then it performs a DNS lookup on |
| this address. At present there is no way to avoid this lookup. |
| |
| <P>If you fear that this lookup might fail because your DNS server is down |
| then you can insert the hostname in <CODE>/etc/hosts</CODE> (where you |
| probably already have it so that the machine can boot properly). Then |
| ensure that your machine is configured to use <CODE>/etc/hosts</CODE> |
| in the event that DNS fails. Depending on what OS you are using this |
| might be accomplished by editing <CODE>/etc/resolv.conf</CODE>, or maybe |
| <CODE>/etc/nsswitch.conf</CODE>. |
| |
| <P>If your server doesn't have to perform DNS for any other reason |
| then you might be able to get away with running Apache with the |
| <CODE>HOSTRESORDER</CODE> environment variable set to "local". This all |
| depends on what OS and resolver libraries you are using. It also affects |
| CGIs unless you use <A HREF="mod/mod_env.html"><CODE>mod_env</CODE></A> |
| to control the environment. It's best to consult the man pages or FAQs |
| for your OS. |
| |
| <H3><A NAME="tips">Tips to Avoid these problems</A></H3> |
| |
| <UL> |
| <LI> use IP addresses in <CODE><VirtualHost></CODE> |
| <LI> use IP addresses in <CODE>Listen</CODE> |
| <LI> use IP addresses in <CODE>BindAddress</CODE> |
| <LI> ensure all virtual hosts have an explicit <CODE>ServerName</CODE> |
| <LI> create a <CODE><VirtualHost _default_:*></CODE> server that |
| has no pages to serve |
| </UL> |
| |
| <H3>Appendix: Future Directions</H3> |
| |
| <P>The situation regarding DNS is highly undesirable. For Apache |
| 1.2 we've attempted to make the server at least continue booting |
| in the event of failed DNS, but it might not be the best we |
| can do. In any event requiring the use of explicit IP addresses in |
| configuration files is highly undesirable in today's Internet where <A |
| HREF="http://www.ietf.org/html.charters/pier-charter.html">renumbering |
| </A> is a necessity. |
| |
| <P>A possible work around to the theft of service attack described above |
| would be to perform a reverse DNS lookup on the ip address returned by |
| the forward lookup and compare the two names. In the event of a mismatch |
| the virtualhost would be disabled. This would require reverse DNS to be |
| configured properly (which is something that most admins are familiar with |
| because of the common use of "double-reverse" DNS lookups by FTP servers |
| and TCP wrappers). |
| |
| <P>In any event it doesn't seem possible to reliably boot a virtual-hosted |
| web server when DNS has failed unless IP addresses are used. Partial |
| solutions such as disabling portions of the configuration might be worse |
| than not booting at all depending on what the webserver is supposed |
| to accomplish. |
| |
| <P>As HTTP/1.1 is deployed and browsers and proxies start issuing the |
| <CODE>Host</CODE> header it will become possible to avoid the use of |
| IP-based virtual hosts entirely. In this event a webserver has no requirement |
| to do DNS lookups during configuration. But as of March 1997 these |
| features have not been deployed widely enough to be put into use on |
| critical webservers. |
| |
| <!--#include virtual="footer.html" --> |
| </BODY> |
| </HTML> |
| |