httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbo...@apache.org
Subject svn commit: r1030181 - in /httpd/httpd/trunk/docs/manual: dns-caveats.html.en dns-caveats.xml
Date Tue, 02 Nov 2010 19:12:54 GMT
Author: rbowen
Date: Tue Nov  2 19:12:53 2010
New Revision: 1030181

URL: http://svn.apache.org/viewvc?rev=1030181&view=rev
Log:
Remove 1998-era stuff that's not true any more.

Modified:
    httpd/httpd/trunk/docs/manual/dns-caveats.html.en
    httpd/httpd/trunk/docs/manual/dns-caveats.xml

Modified: httpd/httpd/trunk/docs/manual/dns-caveats.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/dns-caveats.html.en?rev=1030181&r1=1030180&r2=1030181&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/dns-caveats.html.en (original)
+++ httpd/httpd/trunk/docs/manual/dns-caveats.html.en Tue Nov  2 19:12:53 2010
@@ -29,15 +29,14 @@
     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">
@@ -46,9 +45,9 @@
 
     <div class="example"><p><code>
       # This is a misconfiguration example, do not use on your server <br />
-      &lt;VirtualHost www.abc.dom&gt; <br />
-      ServerAdmin webgirl@abc.dom <br />
-      DocumentRoot /www/abc <br />
+      &lt;VirtualHost www.example.dom&gt; <br />
+      ServerAdmin webgirl@example.dom <br />
+      DocumentRoot /www/example <br />
       &lt;/VirtualHost&gt;
     </code></p></div>
 
@@ -57,21 +56,20 @@
     <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 />
       &lt;VirtualHost 192.0.2.1&gt; <br />
-      ServerAdmin webgirl@abc.dom <br />
-      DocumentRoot /www/abc <br />
+      ServerAdmin webgirl@example.dom <br />
+      DocumentRoot /www/example <br />
       &lt;/VirtualHost&gt;
     </code></p></div>
 
@@ -81,16 +79,16 @@
     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>
       &lt;VirtualHost 192.0.2.1&gt; <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 />
       &lt;/VirtualHost&gt;
     </code></p></div>
   </div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif"
/></a></div>
@@ -98,50 +96,39 @@
 <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>
-      &lt;VirtualHost www.abc.dom&gt;<br />
+      &lt;VirtualHost www.example1.dom&gt;<br />
       <span class="indent">
-        ServerAdmin webgirl@abc.dom<br />
-        DocumentRoot /www/abc<br />
+        ServerAdmin webgirl@example1.dom<br />
+        DocumentRoot /www/example1<br />
       </span>
       &lt;/VirtualHost&gt;<br />
       <br />
-      &lt;VirtualHost www.def.dom&gt;<br />
+      &lt;VirtualHost www.example2.dom&gt;<br />
       <span class="indent">
-        ServerAdmin webguy@def.dom<br />
-        DocumentRoot /www/def<br />
+        ServerAdmin webguy@example2.dom<br />
+        DocumentRoot /www/example2<br />
       </span>
       &lt;/VirtualHost&gt;
     </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>
@@ -200,41 +187,6 @@
       <li>create a <code>&lt;VirtualHost _default_:*&gt;</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">&nbsp;en&nbsp;</a> |

Modified: httpd/httpd/trunk/docs/manual/dns-caveats.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/dns-caveats.xml?rev=1030181&r1=1030180&r2=1030181&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/dns-caveats.xml (original)
+++ httpd/httpd/trunk/docs/manual/dns-caveats.xml Tue Nov  2 19:12:53 2010
@@ -29,9 +29,9 @@
     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">
@@ -39,9 +39,9 @@
 
     <example>
       # This is a misconfiguration example, do not use on your server <br />
-      &lt;VirtualHost www.abc.dom&gt; <br />
-      ServerAdmin webgirl@abc.dom <br />
-      DocumentRoot /www/abc <br />
+      &lt;VirtualHost www.example.dom&gt; <br />
+      ServerAdmin webgirl@example.dom <br />
+      DocumentRoot /www/example <br />
       &lt;/VirtualHost&gt;
     </example>
 
@@ -50,21 +50,20 @@
     <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 />
       &lt;VirtualHost 192.0.2.1&gt; <br />
-      ServerAdmin webgirl@abc.dom <br />
-      DocumentRoot /www/abc <br />
+      ServerAdmin webgirl@example.dom <br />
+      DocumentRoot /www/example <br />
       &lt;/VirtualHost&gt;
     </example>
 
@@ -74,16 +73,16 @@
     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>
       &lt;VirtualHost 192.0.2.1&gt; <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 />
       &lt;/VirtualHost&gt;
     </example>
   </section>
@@ -91,50 +90,39 @@
   <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>
-      &lt;VirtualHost www.abc.dom&gt;<br />
+      &lt;VirtualHost www.example1.dom&gt;<br />
       <indent>
-        ServerAdmin webgirl@abc.dom<br />
-        DocumentRoot /www/abc<br />
+        ServerAdmin webgirl@example1.dom<br />
+        DocumentRoot /www/example1<br />
       </indent>
       &lt;/VirtualHost&gt;<br />
       <br />
-      &lt;VirtualHost www.def.dom&gt;<br />
+      &lt;VirtualHost www.example2.dom&gt;<br />
       <indent>
-        ServerAdmin webguy@def.dom<br />
-        DocumentRoot /www/def<br />
+        ServerAdmin webguy@example2.dom<br />
+        DocumentRoot /www/example2<br />
       </indent>
       &lt;/VirtualHost&gt;
     </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
@@ -196,38 +184,4 @@
     </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>



Mime
View raw message