From d5db0117f213f31c19bee8e78bb373ffe708abb8 Mon Sep 17 00:00:00 2001 From: Rich Bowen Date: Tue, 2 Nov 2010 19:12:53 +0000 Subject: [PATCH] Remove 1998-era stuff that's not true any more. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1030181 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/dns-caveats.html.en | 112 +++++++++----------------------- docs/manual/dns-caveats.xml | 110 +++++++++---------------------- 2 files changed, 64 insertions(+), 158 deletions(-) diff --git a/docs/manual/dns-caveats.html.en b/docs/manual/dns-caveats.html.en index 3b6e5332bf..596a5c5fda 100644 --- a/docs/manual/dns-caveats.html.en +++ b/docs/manual/dns-caveats.html.en @@ -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).

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

top
@@ -46,9 +45,9 @@

# This is a misconfiguration example, do not use on your server
- <VirtualHost www.abc.dom>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ <VirtualHost www.example.dom>
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost>

@@ -57,21 +56,20 @@ ServerName 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 www.abc.dom. If for some + to find the address of www.example.dom. If for some reason DNS is not available at the time your server is parsing its config file, then this virtual host will not be configured. 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).

+ to this virtual host.

-

Suppose that www.abc.dom has address 192.0.2.1. +

Suppose that www.example.dom has address 192.0.2.1. Then consider this configuration snippet:

# This is a misconfiguration example, do not use on your server
<VirtualHost 192.0.2.1>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost>

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

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

Here is a snippet that avoids both of these problems:

<VirtualHost 192.0.2.1>
- ServerName www.abc.dom
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerName www.example.dom
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost>

top
@@ -98,50 +96,39 @@

Denial of Service

-

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 abc.dom 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 - www.abc.dom record.

- -

Another form is far more insidious. Consider this - configuration snippet:

+

Consider this configuration snippet:

- <VirtualHost www.abc.dom>
+ <VirtualHost www.example1.dom>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerAdmin webgirl@example1.dom
+ DocumentRoot /www/example1
 </VirtualHost>

- <VirtualHost www.def.dom>
+ <VirtualHost www.example2.dom>
- ServerAdmin webguy@def.dom
- DocumentRoot /www/def
+ ServerAdmin webguy@example2.dom
+ DocumentRoot /www/example2
 </VirtualHost>

Suppose that you've assigned 192.0.2.1 to - www.abc.dom and 192.0.2.2 to - www.def.dom. Furthermore, suppose that - def.dom has control of their own DNS. With this - config you have put def.dom into a position where - they can steal all traffic destined to abc.dom. To - do so, all they have to do is set www.def.dom to + www.example1.dom and 192.0.2.2 to + www.example2.dom. Furthermore, suppose that + example2.dom has control of their own DNS. With this + config you have put example2.dom into a position where + they can steal all traffic destined to example1.dom. To + do so, all they have to do is set www.example2.dom to 192.0.2.1. Since they control their own DNS you can't stop them - from pointing the www.def.dom record wherever they + from pointing the www.example2.dom record wherever they wish.

Requests coming in to 192.0.2.1 (including all those where users typed in URLs of the form - http://www.abc.dom/whatever) will all be served by - the def.dom virtual host. To better understand why + http://www.example1.dom/whatever) will all be served by + the example2.dom 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 is available.

@@ -200,41 +187,6 @@
  • create a <VirtualHost _default_:*> server that has no pages to serve
    • -
    top
    -
    -

    Appendix: Future Directions

    - - -

    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.

    - -

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

    - -

    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.

    - -

    As HTTP/1.1 is deployed and browsers and proxies start - issuing the Host 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.

    Available Languages:  en  | diff --git a/docs/manual/dns-caveats.xml b/docs/manual/dns-caveats.xml index 56d8d02319..69357d390b 100644 --- a/docs/manual/dns-caveats.xml +++ b/docs/manual/dns-caveats.xml @@ -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).

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

    @@ -39,9 +39,9 @@ # This is a misconfiguration example, do not use on your server
    - <VirtualHost www.abc.dom>
    - ServerAdmin webgirl@abc.dom
    - DocumentRoot /www/abc
    + <VirtualHost www.example.dom>
    + ServerAdmin webgirl@example.dom
    + DocumentRoot /www/example
    </VirtualHost>     @@ -50,21 +50,20 @@ ServerName 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 www.abc.dom. If for some + to find the address of www.example.dom. If for some reason DNS is not available at the time your server is parsing its config file, then this virtual host will not be configured. 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).

    + to this virtual host.

    -

    Suppose that www.abc.dom has address 192.0.2.1. +

    Suppose that www.example.dom has address 192.0.2.1. Then consider this configuration snippet:

    # This is a misconfiguration example, do not use on your server
    <VirtualHost 192.0.2.1>
    - ServerAdmin webgirl@abc.dom
    - DocumentRoot /www/abc
    + ServerAdmin webgirl@example.dom
    + DocumentRoot /www/example
    </VirtualHost>     @@ -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.

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

    Here is a snippet that avoids both of these problems:

    <VirtualHost 192.0.2.1>
    - ServerName www.abc.dom
    - ServerAdmin webgirl@abc.dom
    - DocumentRoot /www/abc
    + ServerName www.example.dom
    + ServerAdmin webgirl@example.dom
    + DocumentRoot /www/example
    </VirtualHost>
    @@ -91,50 +90,39 @@
    Denial of Service -

    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 abc.dom 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 - www.abc.dom record.

    - -

    Another form is far more insidious. Consider this - configuration snippet:

    +

    Consider this configuration snippet:

    - <VirtualHost www.abc.dom>
    + <VirtualHost www.example1.dom>
    - ServerAdmin webgirl@abc.dom
    - DocumentRoot /www/abc
    + ServerAdmin webgirl@example1.dom
    + DocumentRoot /www/example1
     </VirtualHost>

    - <VirtualHost www.def.dom>
    + <VirtualHost www.example2.dom>
    - ServerAdmin webguy@def.dom
    - DocumentRoot /www/def
    + ServerAdmin webguy@example2.dom
    + DocumentRoot /www/example2
     </VirtualHost>

    Suppose that you've assigned 192.0.2.1 to - www.abc.dom and 192.0.2.2 to - www.def.dom. Furthermore, suppose that - def.dom has control of their own DNS. With this - config you have put def.dom into a position where - they can steal all traffic destined to abc.dom. To - do so, all they have to do is set www.def.dom to + www.example1.dom and 192.0.2.2 to + www.example2.dom. Furthermore, suppose that + example2.dom has control of their own DNS. With this + config you have put example2.dom into a position where + they can steal all traffic destined to example1.dom. To + do so, all they have to do is set www.example2.dom to 192.0.2.1. Since they control their own DNS you can't stop them - from pointing the www.def.dom record wherever they + from pointing the www.example2.dom record wherever they wish.

    Requests coming in to 192.0.2.1 (including all those where users typed in URLs of the form - http://www.abc.dom/whatever) will all be served by - the def.dom virtual host. To better understand why + http://www.example1.dom/whatever) will all be served by + the example2.dom 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

    -
    - Appendix: Future Directions - -

    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.

    - -

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

    - -

    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.

    - -

    As HTTP/1.1 is deployed and browsers and proxies start - issuing the Host 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.

    -
    -- 2.40.0