Blanco wrote:
Hi,
Attached to this email, I have included a patch for the
dns-caveats.xml documentation file and its Spanish translation:
manual/dns-caveats.xml.patch
manual/dns-caveats.xml.es
Both files have been reviewed by Daniel Lopez.
I submitted a few days ago another file, env.xml.es but it has not yet
been commited. Please don't forget :)
At the moment we are working on the files listed below, which we will
be submitting soon.
- manual/sections.xml
- manual/mod/mod_rewrite.xml
- manual/mod/mod_actions.xml
Best Regards,
--
Jes�s Blanco www.bitrock.com
<http://www.bitrock.com>
Project Manager
e: blanco @ bitrock.com <http://bitrock.com> t: +34 669 23 43 57
f:+34 954 502 697
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Oooops! I forgot to include the attachements. Here they are.
Regards,
J
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.es.xsl"?>
<!-- English Revision: 151405 -->
<!--
Copyright 2002-2005 The Apache Software Foundation or it licensors,
as applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="dns-caveats.xml.meta">
<title>Asuntos relacionados con Apache y las DNS</title>
<summary>
<p>Este documento puede resumirse en la siguiente frase: no
configure Apache de manera que el análisis sintáctico de
los ficheros de configuración tenga que confiar en
resoluciones DNS. Si Apache necesita de resoluciones DNS para
analizar los ficheros de configuración, entonces su servidor
puede no funcionar correctamente (por ejemplo, podría no
iniciarse), o sufrir ataques de denegación o robo de servicio
(incluyendo que otas web puedan "robar" peticiones de otras
web).</p>
</summary>
<section id="example">
<title>Un ejemplo sencillo</title>
<example>
<VirtualHost www.abc.com> <br />
ServerAdmin [EMAIL PROTECTED] <br />
DocumentRoot /www/abc <br />
</VirtualHost>
</example>
<p>Para que Apache funcione correctamente, es imprescindible
conocer dos aspectos sobre cada host virtual: el valor de la
directiva <directive module="core">ServerName</directive> y al
menos una dirección IP en la que servidor escuchará y
responderá a las peticiones que se produzcan. El ejemplo
mostrado arriba no incluye la direccion IP, de manera que Apache
tiene que usar una resolución DNS para encontrar la
dirección IP correspondiente a <code>www.abc.com</code>. Si
por alguna razón la resolución DNS no está
disponible en el momento en que su servidor está analizando
sintánticamente su fichero de configuración, entonces
este host virtual <strong>no se configurará</strong> y no
será capaz de responder a ninguna de las peticiones que se
hagan a ese host virtual (en las versiones de Apache anteriores a
la 1.2 el servidor ni siquiera se iniciaba).</p>
<p>Suponga que <code>www.abc.com</code> tiene como dirección
IP la 10.0.0.1. Considere la siguiente configuración:</p>
<example>
<VirtualHost 10.0.0.1> <br />
ServerAdmin [EMAIL PROTECTED] <br />
DocumentRoot /www/abc <br />
</VirtualHost>
</example>
<p>Ahora Apache necesita hacer una búsqueda DNS inversa para
encontrar el <code>ServerName</code> de este host virtual. Si esta
búsqueda inversa falla entonces el host virtual se
desactivará parcialmente (en las versiones de Apache
anteriores a la 1.2 el servidor ni siquiera se iniciaba). Si el
host virtual está basado en el nombre, entonces se
desactivará completamente, pero si está basado en la
dirección IP, entonces funcionará para la mayor parte de
las cosas. Sin embargo, si Apache tiene que generar en algún
momento una URL completa que incluya el nombre del servidor, no
será capaz de generar una URL válida.</p>
<p>Aquí tiene una forma de evitar ambos problemas:</p>
<example>
<VirtualHost 10.0.0.1> <br />
ServerName www.abc.com <br />
ServerAdmin [EMAIL PROTECTED] <br />
DocumentRoot /www/abc <br />
</VirtualHost>
</example>
</section>
<section id="denial">
<title>Denegación de servicio</title>
<p>Hay (al menos) dos formas de que ocurra una denegación de
servicio. Si está ejecutando una versión de Apache
anterior a la 1.2, entonces su servidor no se iniciará si una
de las dos búsquedas de DNS mencionadas arriba falla para
cualquiera de sus hosts virtuales. En algunos casos estas
búsquedas DNS puede que no estén bajo su control; por
ejemplo, si <code>abc.com</code> es uno de sus clientes y ellos
controlan su propia DNS, pueden forzar a su servidor (pre-1.2) a
fallar al iniciarse simplemente borrando el registro
<code>www.abc.com</code>.</p>
<p>Otra formas pueden ser bastante más complicadas. Fíjese
en esta configuración:</p>
<example>
<VirtualHost www.abc.com> <br />
  ServerAdmin [EMAIL PROTECTED] <br />
  DocumentRoot /www/abc <br />
</VirtualHost> <br />
<br />
<VirtualHost www.def.com> <br />
  ServerAdmin [EMAIL PROTECTED] <br />
  DocumentRoot /www/def <br />
</VirtualHost>
</example>
<p>Suponga que ha asignado la dirección 10.0.0.1 a
<code>www.abc.com</code> y 10.0.0.2 a
<code>www.def.com</code>. Todavía más, suponga que
<code>def.com</code> tiene el control de sus propias DNS. Con esta
configuración ha puesto <code>def.com</code> en una
posición en la que puede robar todo el trafico destinado a
<code>abc.com</code>. Para conseguirlo, todo lo que tiene que
hacer es asignarle a <code>www.def.com</code> la dirección
10.0.0.1. Como ellos controlan sus propias DNS no puede evitar que
apunten el registro <code>www.def.com</code> a donde quieran.</p>
<p>Las peticiones dirigidas a la dirección 10.0.0.1
(incluídas aquellas en las los usuarios escriben URLs de tipo
<code>http://www.abc.com/whatever</code>) serán todas
servidas por el host virtual <code>def.com</code>. Comprender por
qué ocurre esto requiere una discusión más profunda
acerca de como Apache asigna las peticiones que recibe a los hosts
virtuales que las servirán. Puede consultar <a
href="vhosts/details.html">aquí</a> un documento que trata el
tema.</p>
</section>
<section id="main">
<title>La dirección del "servidor principal"</title>
<p>El que Apache soporte <a href="vhosts/name-based.html">hosting
virtual basado en nombres</a> desde la version 1.1 hace que sea
necesario que el servidor conozca la dirección (o
direcciones) IP del host que <program>httpd</program> está
ejecutando. Para tener acceso a esta dirección puede usar la
directiva global <directive module="core">ServerName</directive>
(si está presente) o llamar a la función de C
<code>gethostname</code> (la cuál debe devolver el mismo
resultado que devuelve ejecutar por línea de comandos
"hostname"). Entonces se produce una búsqueda DNS de esa
dirección. Actualmente, no hay forma de evitar que se
produzca esta búsqueda.</p>
<p>Si teme que esta búsqueda pueda fallar porque su servidor
DNS está desactivado entonces puede insertar el nombre de
host en <code>/etc/hosts</code> (donde probablemente ya lo tiene
para que la máquina pueda arrancar
correctamente). Asegúrese de que su máquina está
configurada para usar <code>/etc/hosts</code> en caso de que esa
búsqueda DNS falle. En función del sistema operativo que
use, puede conseguir esto editando <code>/etc/resolv.conf</code>,
o puede que <code>/etc/nsswitch.conf</code>.</p>
<p>Si su servidor no tiene que ejecutar búsquedas DNS por
ninguna otra razón entonces considere ejecutar Apache
especificando el valor "local" en la variable de entorno
<code>HOSTRESORDER</code>. Todo esto depende del sistema operativo
y de las librerías de resolución que use. Esto
también afecta a los CGIs a menos que use
<module>mod_env</module> para controlar el entorno. Por favor,
consulte las páginas de ayuda o la sección de Preguntas
Más Frecuentes de su sistema operativo.</p>
</section>
<section id="tips">
<title>Consejos para evitar problemas</title>
<ul>
<li>
use direcciones IP en
<directive module="core">VirtualHost</directive>
</li>
<li>
use direcciones IP en
<directive module="mpm_common">Listen</directive>
</li>
<li>
asegúrese de que todos los host virtuales tienen
explícitamente especificados una directiva <directive
module="core">ServerName</directive>
</li>
<li>cree un servidor <code><VirtualHost _default_:*></code>
que no tenga páginas que servir.</li>
</ul>
</section>
<section id="appendix">
<title>Apéndice: Líneas de evolución de Apache</title>
<p>La situación actual respecto a las búsquedas DNS
está lejos de ser la deseable. En Apache 1.2 se intentó
hacer que el servidor al menos se iniciara a pesar de que fallara
la búsqueda DNS, pero puede que esa no sea la mejor
solución. En cualquier caso, requerir el uso de direcciones
IP explícitas en los ficheros de configuración no es ni
mucho menos una solución deseable con la situación
actual de Internet, donde la renumeración es una
necesidad.</p>
<p>Una posible solución a los ataques de robo de servicio
descritos más arriba, sería hacer una búsqueda DNS
inversa de la dirección IP devuelta por la búsqueda
previa y comparar los dos nombres -- en caso de que sean
diferentes, el host virtual se desactivaría. Esto
requeriría configurar correctamente DNS inverso (una tarea
con la que suelen estar familiarizados la mayoría de los
administradores de sistemas).</p>
<p>En cualquier caso, no parece posible iniciar en las condiciones
apropiadas un servidor web alojado virtualmente cuando DNS ha
fallado a no ser que se usen direcciones IP. Soluciones parciales
tales como desactivar partes de la configuración podrían
ser incluso peores que no iniciar el servidor en absoluto,
dependiendo de las funciones que se espera que realice el servidor
web.</p>
<p>Como HTTP/1.1 está ampliamente extendido y los navegadores
y los servidores proxy empiezan a usar la cabecera
<code>Host</code>, en el futuro será posible evitar el uso de
hosting virtual basado en direcciones IP completamente. En ese
caso, un servidor web no tiene ninguna necesidad de hacer
búsquedas de DNS durante la configuración. Sin embargo,
en Marzo de 1997 esas funcionalidades no estaban lo
suficientemente implantadas como para ponerlas en uso en
servidores web que realizaban tareas de importancia
crítica.</p>
</section>
</manualpage>
Index: dns-caveats.xml
===================================================================
--- dns-caveats.xml (revision 168559)
+++ dns-caveats.xml (working copy)
@@ -38,8 +38,8 @@
<title>A Simple Example</title>
<example>
- <VirtualHost www.abc.dom> <br />
- ServerAdmin [EMAIL PROTECTED] <br />
+ <VirtualHost www.abc.com> <br />
+ ServerAdmin [EMAIL PROTECTED] <br />
DocumentRoot /www/abc <br />
</VirtualHost>
</example>
@@ -49,19 +49,19 @@
<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 Apache must use DNS
- to find the address of <code>www.abc.dom</code>. If for some
+ to find the address of <code>www.abc.com</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>
- <p>Suppose that <code>www.abc.dom</code> has address 10.0.0.1.
+ <p>Suppose that <code>www.abc.com</code> has address 10.0.0.1.
Then consider this configuration snippet:</p>
<example>
<VirtualHost 10.0.0.1> <br />
- ServerAdmin [EMAIL PROTECTED] <br />
+ ServerAdmin [EMAIL PROTECTED] <br />
DocumentRoot /www/abc <br />
</VirtualHost>
</example>
@@ -80,8 +80,8 @@
<example>
<VirtualHost 10.0.0.1> <br />
- ServerName www.abc.dom <br />
- ServerAdmin [EMAIL PROTECTED] <br />
+ ServerName www.abc.com <br />
+ ServerAdmin [EMAIL PROTECTED] <br />
DocumentRoot /www/abc <br />
</VirtualHost>
</example>
@@ -95,41 +95,41 @@
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
+ control; for example, if <code>abc.com</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>
+ <code>www.abc.com</code> record.</p>
<p>Another form is far more insidious. Consider this
configuration snippet:</p>
<example>
- <VirtualHost www.abc.dom> <br />
- ServerAdmin [EMAIL PROTECTED] <br />
+ <VirtualHost www.abc.com> <br />
+ ServerAdmin [EMAIL PROTECTED] <br />
DocumentRoot /www/abc <br />
</VirtualHost> <br />
<br />
- <VirtualHost www.def.dom> <br />
- ServerAdmin [EMAIL PROTECTED] <br />
+ <VirtualHost www.def.com> <br />
+ ServerAdmin [EMAIL PROTECTED] <br />
DocumentRoot /www/def <br />
</VirtualHost>
</example>
<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.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.abc.com</code> and 10.0.0.2 to
+ <code>www.def.com</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.com</code> to
10.0.0.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.def.com</code> record wherever they
wish.</p>
<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.dom</code> virtual host. To better understand why
+ <code>http://www.abc.com/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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
