latex2rtf-2.3.17/test/babel_spanish.tex

%% LyX 1.1 created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass{article}
\usepackage[spanish]{babel}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{graphicx}
\setlength\parskip{\medskipamount}
\setlength\parindent{0pt}

\makeatletter

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
\addto\extrasspanish{\bbl@deactivate{~}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
\usepackage{hyperlatex}
\htmltitle{Jorge Leon}
\htmladdress{\xlink{Georg Lehner}{mailto:Jorge.Lehner@gmx.net} - \xlink{homepage}{/\~{}jorge}}
\htmldirectory{html}
\htmlname{dns_intro}

\makeatother
\begin{document}

\title{Domain Name Service}


\date{24 de Febrero del 2002}


\author{Georg Lehner}

\maketitle
\abstract{
El servicio primario para el funcionamiento de INTERNET es el Domain
Name Service. Este documento resume de forma breve su funcionamiento
y da algunas referencias a otra informaci�n
}

\section{Qu� es DNS}

Cada computadora conectada a Internet tiene (al menos) un n�mero de
identificaci�n asociado: su \emph{n�mero IP}. En todo Internet no
se repite un n�mero en diferentes computadoras.

Cada computadora tiene (generalmente) un nombre. Grupos de computadoras
est�n organizados en \emph{dominios} lo que permite que diferentes
computadora tengan el mismo nombre, siempre y cuando se encuentran
en diferentes dominios. El nombre calificado \emph{(fully qualified
domain name~--~fqdn}) \emph{}de una computadora es la concatenaci�n
del nombre con el dominio, mediante un punto '.' de separaci�n, ejemplo:
puma.felinos.net = computadora puma, dominio felinos.net

Existe una base de datos distribuida en Internet, de la cual se puede
obtener el n�mero IP de una computadora de la cual se conoce el fqdn
mediante un \emph{query}; este tipo de query se llama \emph{forward
resolution} (resoluci�n de nombre directo). Teniendo un n�mero IP
se puede obtener el fqdn de la computadora correspondiente mediante
un \emph{reverse query} (resoluci�n inversa).

Es responsabilidad de la administraci�n de un dominio proveer este
servicio de resoluci�n de nombres para las computadoras conectados.
Esto involucra dos tareas: instalaci�n de servidores de nombres y
actualizaci�n constante de los registros de nombres en el dominio
administrado.

Una buena administraci�n del DNS puede hacer m�s fiable y eficiente
el funcionamiento del dominio. Muchas veces esto tambi�n involucra
tareas de configuraci�n de las computadoras clientes del dominio.


\section{Una base de datos distribuida}

En el dibujo \ref{domain_fig} apreciamos la vista a dos dominios
(ficticios) de Internet. Cada computadora tiene un nombre y un n�mero
IP asignado. Por m�s conveniencia, todas las computadoras en una red
f�sica utilizan n�meros de un grupo com�n: 12.206.3.{[}0\ldots{}255{]}
corresponde al dominio felinos.net, 97.3.3.{[}0\ldots{}255{]} a mujeres.org,
y por ende 198.27.37.{[}0\ldots{}255{]} a ispex.com.
\begin{figure}
\label{domain_fig}\resizebox*{0.8\textwidth}{!}{Some missing figure}
\end{figure}
En la figura \ref{dns_fig} observamos de forma esquem�tica la agrupaci�n
de la informaci�n sobre un dominio en una tabla, manejado por una
computadora, el servidor DNS.
\begin{figure}
\label{dns_fig}\resizebox*{0.8\textwidth}{!}{Some other missing figure}
\end{figure}
En vez de crear una tabla completa de todos los n�meros de todas las
computadoras que podr�an estar conectados a Internet y manejar esta
tabla inmensa en todas las computadoras se manejan tablas de los {}``vecinos
cercanos'', que de todas formas se requieren m�s frecuentemente.
Para obtener la informaci�n sobre computadoras remotas se establece
un sistema de b�squeda jer�rquica explicados m�s adelante.

El n�mero de computadoras en un dominio puede ser grande, y con ello
la frecuencia de consultas que se hacen al servidor de base de datos
que maneja la tabla para el dominio. Esto puede causar un retraso
significativo en el acceso a la red. Para aliviar esta situaci�n,
se maneja la informaci�n sobre nombres y n�meros IP en uno o varios
cach�s. El cach� realiza la b�squeda correspondiente a una consulta
hecha por un cliente y entrega el resultado, pero a la vez guarda
el resultado localmente en memoria o en el disco duro. Si se repite
la misma consulta ya no se realiza una b�squeda en las tablas {}``oficiales'',
sino se entrega el resultado guardado. El problema de un cach� es,
que su informaci�n puede hacerse obsoleta: una computadora puede desaparecer,
cambiar su nombre o su n�mero IP. Por esto cada resultado grabado
contiene un tiempo de expiraci�n (TTL - Time To Live), despu�s del
cual est� descartado de la memoria del cach�, una subsiguiente consulta
del dato resulta en una b�squeda en los Servidores DNS y por lo tanto
(ojal�) en una respuesta aut�ntica. El programa cach� puede ser instalado
en todas las computadoras (�ptimo), o puede instalarse solo en alguna(s),
las cuales entonces sirven dentro de un dominio como la fuente de
informaci�n DNS: son los servidores de nombre del dominio, o \emph{nameserver}.


\subsection{Jerarqu�a de la base de datos distribuida}

Una serie de servidores root (por redundancia no es solo uno) manejan
\emph{delegaciones} de dominios, que son listas de cuales Servidores
DNS manejan cual dominio. Estos Servidores pueden delegar a su vez
la resoluci�n de nombres de sub-dominios a Servidores DNS subordinados.


\begin{figure}
\resizebox*{0.8\textwidth}{!}{Another missing figure} \label{root_server}
\end{figure}
En la figura \ref{root_server} solamente se muestra la delegaci�n
de un (1) servidor ra�z (root server) en la parte izquierda arriba,
todas las flechas s�lidas que indican la delegaci�n a los dominios
primarios, tienen que duplicarse en cada uno de los servidores ra�z
(puntos negros conectados con una l�nea punteada). Se puede apreciar
entonces, que el tiempo de respuesta del DNS se mejora, ya que cualquier
consulta a los servidores root en promedio toma la v�a de acceso media
en la red global.

Regresando a la imagen \ref{dns_fig} podemos ver dos v�as que caracterizan
el sistema DNS: La distribuci�n jer�rquica de los servidores DNS que
garantiza (te�ricamente) que todos los datos pueden ser encontrados,
aunque recursivamente (l�neas punteadas), y la jerarqu�a de b�squeda
de los nameserver (cach�s), que forman {}``ventanas restringidas''
pero adaptables a la base de datos completa (l�neas s�lidas). Los
cach�s son cercanos a la computadora cliente, y pueden ascender de
un cach� al siguiente hacia {}``arriba''. Si encuentran la respuesta
en alg�n cach� superior en el camino, no necesitan recurrir al servidor
root.


\section{Escenarios comunes}

La pr�ctica com�n en Internet es configuraci�n minimista, deficiente
y arcaica, por lo que muchos administradores no est�n en conocimiento
de la pr�ctica �ptima (best practice). Software popular de clientes
y servidores DNS se adapta a las pr�cticas deficientes y dificulta
as� el uso eficiente y la divulgaci�n de la pr�ctica �ptima.

Estoy tratando de resumir en esta secci�n \emph{best} \emph{practice}
para algunos casos comunes (NO para todas las situaciones), lo que
no concuerda necesariamente con la experiencia de lectores experimentados
en Internet. En corto: Lo presentado es solo mi punto de vista, nada
mas.

T�rminos usados:

\begin{description}
\item [Cach�~local]un programa que consulta la base de datos DNS a solicitud
de un programa cliente en la computadora local, le retorna el resultado
requerido o una respuesta negativa, y memoriza la respuesta durante
un cierto tiempo para acelerar futuros queries sobre la misma computadora
\item [Cach�~externo]realiza la misma funci�n como un cach� local, pero
tambi�n acepta queries de programas clientes en computadoras remotas.
\item [Servidor~DNS]un programa que maneja una parte de la base de datos
DNS y que acepta queries de clientes locales o remotos, pero solo
contesta queries para los cuales tiene un registro disponible.
\item [Servidor~DNS~local]solo acepta queries desde la computadora local,
normalmente desde un cache local o externo.
\item [Servidor~DNS~externo]acepta queries desde computadoras remotas.
\item [LAN/Red~privada]una red, en la cual se utilizan n�meros IP reservados
para crear dominios en redes aislados. Estos n�meros no se utilizan
en Internet, y pueden re-utilizarse en diferentes redes f�sicas. Estas
redes y los n�meros IP se denominan \emph{redes} \emph{privadas}.
\end{description}

\subsection{Configuraci�n de computadora cliente}

\begin{description}
\item [Sistemas~Operativos~Unix]configurar un cach� local
\item [Otros]utilizan cach�s externos (remotos)
\end{description}
En ambos casos se configura uno o m�s n�meros de cach�s o servidores
remotos (\emph{nameserver}) a los cuales se env�an queries.

En muchos sistemas Unix es com�n seguir tambi�n la segunda pr�ctica.


\subsection{LAN sin conexi�n externa}

\label{LAN_sin_conext}

Configuraci�n de un servidor DNS externo en una o mas computadoras
en la LAN.

Opcional:

Configuraci�n de uno o varios servidores DNS locales y en la misma
computadora un cache externo, que env�a sus queries al servidor local
y a los otros caches externos.


\subsection{LAN con conexi�n externa}

Es como la configuraci�n opcional en \ref{LAN_sin_conext}. Los cach�s
externos adem�s de enviar queries a los servidores de la LAN env�an
queries a cach�s externos.

Este escenario en muchos casos es reducido de tal forma, que todos
los clientes locales de la LAN utilizan uno o varios cach�s externos.


\subsection{Dominio p�blico}

\label{dominio_publico}

Configuraci�n de uno o varios servidores DNS externos. Estos son consultados
por cach�s de dominios remotos sobre registros del dominio.

Configuraci�n de uno o varios caches externos, estos son consultados
por computadoras del mismo dominio.


\subsection{Dominio p�blico asegurado}

La pr�ctica com�n es, seccionar el dominio en una parte con contacto
directo al Internet, incluyendo un gateway (pasarela) que contacta
con una parte {}``interna'' del dominio. El gateway restringe el
acceso de computadoras de dominios remotos a las computadoras {}``internas''
realizando as� la funci�n de un \emph{firewall}.

La configuraci�n del DNS es id�ntico a \ref{dominio_publico}, con
la salvedad que los servidores y uno o m�s cach�s externos est�n detr�s
del firewall en la parte {}``interna''. El firewall permite a todos
los clientes, internos o del Internet remoto acceso a los cach�s externos.


\section{Redundancia}

Hay b�sicamente dos razones por los cuales se introducen servidores
de bases de datos redundantes:

\begin{itemize}
\item Si uno de ellos falla, uno de los servidores redundantes puede asumir
el servicio y
\item Se puede distribuir la carga de solicitudes a dos o m�s servidores
y de esta manera acelerar el acceso de los clientes a la informaci�n
requerida.
\end{itemize}
La parte negativa de la redundancia es, que hay que mantener copias
id�nticas de la informaci�n en todo servidor redundante. Este corresponde
a mayor trabajo administrativo y riesgo adicional de fallas.

La mejor pr�ctica es, utilizar un mecanismo automatizado para la actualiqzaci�n
de un dominio, e incluir en este la duplicaci�n de los datos en los
servidores secundarios con cada cambio realizado.

La transferencia de los archivos necesarios debe hacerse con un programa
que no permite la modificaci�n involuntaria de su contenido - ejemplo:
ssh. Para minimizar la cantidad de informaci�n transferida se puede
usar un programa de compresi�n y/o transferencia diferential, ejemplo:
rsync. En una sola frase:

rsync bajo ssh es actualmente la mejor forma de actualizar datos remotos
de manera confiable.

Tradicionalmente se realiza esta duplicaci�n mediante {}``transferencias
de zonas'' (zone transfer) a trav�s de un protocolo que es parte
del sistema DNS. Este protocolo no es eficiente ni confiable.


\section{BIND, djbdns y otro(s)}

El programa {}``oficial'' para el servicio DNS en Internet es BIND
- Berkeley Internet Name Daemon. BIND combina la funci�n de servidor
y cach� en un solo programa. En toda la historia de su desarrollo
se han visto problemas de seguridad y problemas de fiabilidad.

Dan Bernstein es el autor del paquete de programas djbdns, que son
optimizados en seguridad, velocidad y fiabilidad. djbdns separa las
tareas de servidor DNS y cach� (nameserver) en diferentes programas.
La configuraci�n de djbdns es completamente diferente a la de BIND
y requiere aprendizaje desde cero, una desventaja para administradores
que conocen este primer programa bien.

Existe por lo menos otra alternativa: maradns que provee tambi�n un
servidor DNS dise�ado para seguridad.


\section{Referencias}

Existe una gran cantidad de literatura en papel y en forma electr�nica
sobre DNS. Para la documentaci�n oficial de BIND recomiendo visitar
las p�ginas Web de los servidores sam.uni.edu.ni, magma.com.ni, loghog.uni.edu.ni
y visitar el directorio doc/bind-doc.

La p�gina Web de Daniel Bernstein, que tiene una excelente y compacta
discusi�n de \xlink{DNS, BIND y sus problemas se encuentra en }{http://cr.yp.to/djbdns.html}
junto con mucha otra informaci�n valiosa.

\xlink{Linux-Howtos}{http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html}
(tambi�n en los servidores arriba mencionados en doc/HOWTO/)

\xlink{http://axs.org/\~{}cp/DNS.html}{http://axs.org/\~{}cp/DNS.html}

\xlink{http://www.dns.net/dnsrd/docs/ }{http://www.dns.net/dnsrd/docs/}

\xlink{http://www.psionic.com/}{http://www.psionic.com/}


\section{Copias y Legalidades}

Georg Lehner mantiene los derechos de autor de este documento, bajo
la Licencia Publica de Documentaci�n. Cabe se�alar, que pr�cticamente
toda la informaci�n brindada aqu� es extra�da de fuentes externos,
como los creadores de Internet y las personas que lo siguen desarrollando.
Newton dec�a {}``Si veo lejos es, porque estoy sentado en los hombros
de gigantes.

El documento fue elaborado durante una asesor�a para la Universidad
Nacional de Ingenier�a y el proyecto ICT financiado por SIDA - Suecia,
y forma parte de la documentaci�n elaborado a fin de proveer informaci�n
y formaci�n b�sica a todo el equipo de trabajo y al grupo meta involucrado.

Puede bajarlo en formato \xlink{PDF (Acrobat) aqu�}{dns_intro.pdf},
o en formato html empacado en \xlink{un archivo zip}{dns_intro.zip}.
\end{document}