configure Apache HTTP Server in such a way that it relies on DNS resolution
for parsing of the configuration files. If httpd requires DNS
resolution to parse the configuration files then your server
- may be subject to reliability problems (ie. it might not boot),
- or denial and theft of service attacks (including users able
- to steal hits from other users).</p>
+ may be subject to reliability problems (ie. it might not start up),
+ or denial and theft of service attacks (including virtual hosts able
+ to steal hits from other virtual hosts).</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="./images/down.gif" /> <a href="#example">A Simple Example</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#denial">Denial of Service</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#main">The "main server" Address</a></li>
<li><img alt="" src="./images/down.gif" /> <a href="#tips">Tips to Avoid These Problems</a></li>
-<li><img alt="" src="./images/down.gif" /> <a href="#appendix">Appendix: Future Directions</a></li>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<div class="example"><p><code>
# This is a misconfiguration example, do not use on your server <br />
- <VirtualHost www.abc.dom> <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
+ <VirtualHost www.example.dom> <br />
+ ServerAdmin webgirl@example.dom <br />
+ DocumentRoot /www/example <br />
</VirtualHost>
</code></p></div>
<code class="directive"><a href="./mod/core.html#servername">ServerName</a></code> and at least one
IP address that the server will bind and respond to. The above
example does not include the IP address, so httpd must use DNS
- to find the address of <code>www.abc.dom</code>. If for some
+ to find the address of <code>www.example.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 httpd version 1.2 the server
- would not even boot).</p>
+ to this virtual host.</p>
- <p>Suppose that <code>www.abc.dom</code> has address 192.0.2.1.
+ <p>Suppose that <code>www.example.dom</code> has address 192.0.2.1.
Then consider this configuration snippet:</p>
<div class="example"><p><code>
# This is a misconfiguration example, do not use on your server <br />
<VirtualHost 192.0.2.1> <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
+ ServerAdmin webgirl@example.dom <br />
+ DocumentRoot /www/example <br />
</VirtualHost>
</code></p></div>
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 httpd 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>
+ URL for the server which includes the server name (such as when a
+ Redirect is issued), then it will fail to generate a valid URL.</p>
<p>Here is a snippet that avoids both of these problems:</p>
<div class="example"><p><code>
<VirtualHost 192.0.2.1> <br />
- ServerName www.abc.dom <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
+ ServerName www.example.dom <br />
+ ServerAdmin webgirl@example.dom <br />
+ DocumentRoot /www/example <br />
</VirtualHost>
</code></p></div>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<h2><a name="denial" id="denial">Denial of Service</a></h2>
- <p>There are (at least) two forms that denial of service
- can come in. If you are running a version of httpd 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, they can force your
- (pre-1.2) server to fail while booting simply by deleting the
- <code>www.abc.dom</code> record.</p>
-
- <p>Another form is far more insidious. Consider this
- configuration snippet:</p>
+ <p>Consider this configuration snippet:</p>
<div class="example"><p><code>
- <VirtualHost www.abc.dom><br />
+ <VirtualHost www.example1.dom><br />
<span class="indent">
- ServerAdmin webgirl@abc.dom<br />
- DocumentRoot /www/abc<br />
+ ServerAdmin webgirl@example1.dom<br />
+ DocumentRoot /www/example1<br />
</span>
</VirtualHost><br />
<br />
- <VirtualHost www.def.dom><br />
+ <VirtualHost www.example2.dom><br />
<span class="indent">
- ServerAdmin webguy@def.dom<br />
- DocumentRoot /www/def<br />
+ ServerAdmin webguy@example2.dom<br />
+ DocumentRoot /www/example2<br />
</span>
</VirtualHost>
</code></p></div>
<p>Suppose that you've assigned 192.0.2.1 to
- <code>www.abc.dom</code> and 192.0.2.2 to
- <code>www.def.dom</code>. Furthermore, suppose that
- <code>def.dom</code> has control of their own DNS. With this
- config you have put <code>def.dom</code> into a position where
- they can steal all traffic destined to <code>abc.dom</code>. To
- do so, all they have to do is set <code>www.def.dom</code> to
+ <code>www.example1.dom</code> and 192.0.2.2 to
+ <code>www.example2.dom</code>. Furthermore, suppose that
+ <code>example2.dom</code> has control of their own DNS. With this
+ config you have put <code>example2.dom</code> into a position where
+ they can steal all traffic destined to <code>example1.dom</code>. To
+ do so, all they have to do is set <code>www.example2.dom</code> to
192.0.2.1. Since they control their own DNS you can't stop them
- from pointing the <code>www.def.dom</code> record wherever they
+ from pointing the <code>www.example2.dom</code> record wherever they
wish.</p>
<p>Requests coming in to 192.0.2.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.dom</code> virtual host. To better understand why
+ <code>http://www.example1.dom/whatever</code>) will all be served by
+ the <code>example2.dom</code> virtual host. To better understand why
this happens requires a more in-depth discussion of how httpd
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>.</p>
<li>create a <code><VirtualHost _default_:*></code>
server that has no pages to serve</li>
</ul>
- </div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="appendix" id="appendix">Appendix: Future Directions</a></h2>
-
-
- <p>The situation regarding DNS is highly undesirable. Although
- we've attempted to make the server at least continue
- booting in the event of failed DNS, 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 renumbering is a necessity.</p>
-
- <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>
-
- <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>
-
- <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 case,
- 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.</p>
</div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="./en/dns-caveats.html" title="English"> en </a> |
configure Apache HTTP Server in such a way that it relies on DNS resolution
for parsing of the configuration files. If httpd requires DNS
resolution to parse the configuration files then your server
- may be subject to reliability problems (ie. it might not boot),
- or denial and theft of service attacks (including users able
- to steal hits from other users).</p>
+ may be subject to reliability problems (ie. it might not start up),
+ or denial and theft of service attacks (including virtual hosts able
+ to steal hits from other virtual hosts).</p>
</summary>
<section id="example">
<example>
# This is a misconfiguration example, do not use on your server <br />
- <VirtualHost www.abc.dom> <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
+ <VirtualHost www.example.dom> <br />
+ ServerAdmin webgirl@example.dom <br />
+ DocumentRoot /www/example <br />
</VirtualHost>
</example>
<directive module="core">ServerName</directive> and at least one
IP address that the server will bind and respond to. The above
example does not include the IP address, so httpd must use DNS
- to find the address of <code>www.abc.dom</code>. If for some
+ to find the address of <code>www.example.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 httpd version 1.2 the server
- would not even boot).</p>
+ to this virtual host.</p>
- <p>Suppose that <code>www.abc.dom</code> has address 192.0.2.1.
+ <p>Suppose that <code>www.example.dom</code> has address 192.0.2.1.
Then consider this configuration snippet:</p>
<example>
# This is a misconfiguration example, do not use on your server <br />
<VirtualHost 192.0.2.1> <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
+ ServerAdmin webgirl@example.dom <br />
+ DocumentRoot /www/example <br />
</VirtualHost>
</example>
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 httpd 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>
+ URL for the server which includes the server name (such as when a
+ Redirect is issued), then it will fail to generate a valid URL.</p>
<p>Here is a snippet that avoids both of these problems:</p>
<example>
<VirtualHost 192.0.2.1> <br />
- ServerName www.abc.dom <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
+ ServerName www.example.dom <br />
+ ServerAdmin webgirl@example.dom <br />
+ DocumentRoot /www/example <br />
</VirtualHost>
</example>
</section>
<section id="denial">
<title>Denial of Service</title>
- <p>There are (at least) two forms that denial of service
- can come in. If you are running a version of httpd 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, they can force your
- (pre-1.2) server to fail while booting simply by deleting the
- <code>www.abc.dom</code> record.</p>
-
- <p>Another form is far more insidious. Consider this
- configuration snippet:</p>
+ <p>Consider this configuration snippet:</p>
<example>
- <VirtualHost www.abc.dom><br />
+ <VirtualHost www.example1.dom><br />
<indent>
- ServerAdmin webgirl@abc.dom<br />
- DocumentRoot /www/abc<br />
+ ServerAdmin webgirl@example1.dom<br />
+ DocumentRoot /www/example1<br />
</indent>
</VirtualHost><br />
<br />
- <VirtualHost www.def.dom><br />
+ <VirtualHost www.example2.dom><br />
<indent>
- ServerAdmin webguy@def.dom<br />
- DocumentRoot /www/def<br />
+ ServerAdmin webguy@example2.dom<br />
+ DocumentRoot /www/example2<br />
</indent>
</VirtualHost>
</example>
<p>Suppose that you've assigned 192.0.2.1 to
- <code>www.abc.dom</code> and 192.0.2.2 to
- <code>www.def.dom</code>. Furthermore, suppose that
- <code>def.dom</code> has control of their own DNS. With this
- config you have put <code>def.dom</code> into a position where
- they can steal all traffic destined to <code>abc.dom</code>. To
- do so, all they have to do is set <code>www.def.dom</code> to
+ <code>www.example1.dom</code> and 192.0.2.2 to
+ <code>www.example2.dom</code>. Furthermore, suppose that
+ <code>example2.dom</code> has control of their own DNS. With this
+ config you have put <code>example2.dom</code> into a position where
+ they can steal all traffic destined to <code>example1.dom</code>. To
+ do so, all they have to do is set <code>www.example2.dom</code> to
192.0.2.1. Since they control their own DNS you can't stop them
- from pointing the <code>www.def.dom</code> record wherever they
+ from pointing the <code>www.example2.dom</code> record wherever they
wish.</p>
<p>Requests coming in to 192.0.2.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.dom</code> virtual host. To better understand why
+ <code>http://www.example1.dom/whatever</code>) will all be served by
+ the <code>example2.dom</code> virtual host. To better understand why
this happens requires a more in-depth discussion of how httpd
matches up incoming requests with the virtual host that will
serve it. A rough document describing this <a
</ul>
</section>
- <section id="appendix">
- <title>Appendix: Future Directions</title>
-
- <p>The situation regarding DNS is highly undesirable. Although
- we've attempted to make the server at least continue
- booting in the event of failed DNS, 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 renumbering is a necessity.</p>
-
- <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>
-
- <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>
-
- <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 case,
- 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.</p>
- </section>
</manualpage>
projects / apache / commitdiff