Tabla de contenidos 
FTP("File Transfer Protocol")
Figura: El DNS
El DNS es un protocolo estándar con STD 13. Su status es recomendado. Se describe en los RFCs 1034 y 1035. Esta sección explica la implementación del DNS y de los servidores de nombres. Ver "Domain Name System" para una descripción del DNS y su relación con el esquema de direccionamiento IP.
El DNS usa el concepto de espacio de nombres distribuido. Los nombres simbólicos se agrupan en zonas de autoridad, o más comúnmente, zonas. En cada una de estas zonas, uno o más hosts tienen la tarea de mantener una base de datos de nombres simbólicos y direcciones IP y de suministrar la función de servidor para los clientes que deseen traducir nombres simbólicos a direcciones IP. Estos servidores de nombres locales se interconectan lógicamente en una árbol jerárquico de dominios. Cada zona contiene una parte del árbol o subárbol y los nombres de esa zona se administran con independencia de los de otras zonas. La autoridad sobre zonas se delega en los servidores de nombres. Normalmente, los servidores de nombres que tienen autoridad en zona tendrán nombres de dominio de la misma, aunque no es imprescindible. En los puntos en los que un dominio contiene un subárbol que cae en una zona diferente, se dice que el servidor / servidores de nombres con autoridad sobre el dominio superior delegan autoridad al servidor / servidores de nombres con autoridad sobre los subdominios. Los servidores de nombres también pueden delegar autoridad en sí mismos; en este caso, el espacio de nombres sigue dividido en zonas, pero la autoridad para ambas las ejerce el mismo servidor . La división por zonas se realiza utilizando registros de recursos guardados en el DNS:
- Registro SOA("Start of Authority")
- Define el inicio de una zona
- Registro NS("Name Server")
- Marca el fin de una zona iniciada por un SOA y apunta a un servidor de nombres con autoridad sobre la zona siguiente
En este contexto, el comienzo de un dominio está más cerca a la raíz del árbol que a sus terminaciones. En la raíz, no puede haber servidores de nombres superiores para delegar autoridad: la autoridad para la raíz se deposita en un conjunto de servidores de nombres de la raíz. (11)
El resultado de este esquema es:
- En vez de tener un servidor central para la base de datos, el trabajo implicado en mantenerla se reparte entre los hosts a lo largo y ancho del espacio de nombres.
- La autoridad para crear y cambiar nombres simbólicos de hosts y la responsabilidad de mantener una base de datos para ellos le corresponde a la organización propietaria de la zona que los contiene.
- Desde el punto de vista del usuario, hay una sola base de datos que trata la resolución de las direcciones.
Nota: Aunque los dominios dentro del espacio de nombres se mapean con frecuencia a redes y subredes con el mecanismo de direccionamiento IP, este no es un requisito del DNS. Considerar un "router" entre dos subredes: tiene dos direcciones IP, una por cada adaptador, pero normalmente no tiene por qué poseer dos nombres simbólicos.
La resolución de nombres de dominio es un proceso cliente/ servidor . La función del cliente(el "resolver" o "name resolver") es transparente al usuario y la llama una aplicación para mapear nombres de alto nivel a direcciones IP o viceversa. El servidor de nombres(llamado también servidor de nombres de dominio) es una aplicación servidora que traduce los nombres de alto nivel de las máquinas a direcciones IP. El proceso básico se muestra en Figura - Usando un "full resolver" para la resolución de nombres de dominio y Figura - Usando una "stub resolver" para la resolución de nombres de dominio. El primero muestra un programa denominado "full resolver", distinto del programa de usuario , que envía todas las peticiones al servidor de nombres . El servidor de nombres cachea las respuestas para su uso en el futuro; posiblemente será él mismo el que las use. El último muestra un "stub resolver", que es una rutina enlazada con el programa de usuario, que envía las peticiones a un servidor de nombres. El servidor de nombres suele cachear las respuestas, aunque esto depende de la implementación. En UNIX, el "stub resolver" se implementa con dos funciones de librería: gethostbyname() y gethostbyaddr() para convertir nombres de hosts a direcciones IP y viceversa. Otras plataformas tienen rutinas iguales o parecidas. Los "stub resolvers" son mucho más comunes que los "full resolvers".
Figura: Usando una "full resolver" para la resolución de nombres de dominio
Figure: Usando una "stub resolver" para la resolución de nombres de dominio
Las peticiones sobre nombres de dominio pueden ser de dos tipos: recursivas o iterativas (llamadas también no-recursivas). Un bit de flag en la consulta especifica si el cliente desea una consulta recursiva y un bit de flag en la respuesta indica si el servidor soporta peticiones recursivas. La diferencia entre una consulta recursiva y una iterativa aparece cuando el servidor recibe una solicitud a la que por sí mismo no puede dar una respuesta completa. Una consulta recursiva demanda que el servidor lance a su vez una consulta para determinar la información buscada y luego devolvérsela al cliente. Una consulta iterativa implica que el servidor de nombres debería devolver la información de la que disponga además de una lista de servidores adicionales con los que el cliente puede contactar para completar su consulta.
Las respuestas de nombres de dominio pueden ser de dos tipos: autoritativas y no-autoritativas. Un bit de flag en la respuesta indica de qué tipo es la respuesta. Cuando un servidor de nombres recibe una consulta para un dominio en una zona en la que tiene autoridad, devuelve una respuesta con el bit de flag activo. Si no tiene autoridad en esa zona, su reacción depende de si el flag de recursividad está o no activo.
- Si el flag de recursividad está activo y el servidor la soporta, dirigirá su consulta a otro servidor de nombres. Este será un servidor con autoridad sobre el dominio de la consulta, o uno de los servidores de nombres de la raíz. Si el segundo servidor no devuelve una respuesta autoritativa, el proceso se repite.
Cuando un servidor(o un "full resolver") recibe una respuesta, lo cacheará para mejorar el rendimiento de consultas repetidas. La entrada de la cache se almacena con un tiempo máximo especificado en la respuesta en un campo TTL("time to live") de 32 bits. 172,800 segundos(dos días) es un valor típico.
- Si el flag de recursividad no está activo o el servidor no soporta consultas recursivas, devolverá la información que tenga en su caché y una lista de servidores capaces de dar respuestas autoritativas.
Cada servidor de nombres tiene autoridad para cero o más zonas. Hay tres tipos de servidor de nombres:
- primario
- Un servidor de nombres primario carga de disco la información de una zona, y tiene autoridad sobre ella.
- secundario
- Un servidor de nombres secundario tiene autoridad sobre una zona, pero obtiene la información de esa zona de un servidor primario utilizando un proceso llamado transferencia de zona. Para permanecer sincronizado, los servidores de nombres secundarios consultan a los primarios regularmente(típicamente cada tres horas) y reejecutan la transferencia de zona si el primario ha sido actualizado. Un servidor de nombres puede operar como primario o secundario para múltiples dominios, o como primario para unos y secundario para otros. Un servidor primario o secundario realiza todas las funciones de un servidor caché.
- caché
- Un servidor de nombres que no tiene autoridad para ninguna zona se denomina servidor caché. Obtiene todos sus datos de servidores primarios o secundarios. Requiere al menos un registro NS para apuntar a un servidor del que pueda obtener la información inicialmente.
Cuando un dominio se registra en la raíz y se establece una zona de autoridad separada, se aplican las siguientes reglas:
- El dominio se debe registrar en el administrador de la raíz
- Debe haber un administrador identificado para el dominio
- Debe haber al menos dos servidores de nombres con autoridad para la zona que sean accesibles desde fuera y dentro del dominio para evitar cualquier posible punto débil
También se recomienda que los servidores de nombres que delegan autoridad apliquen estas reglas, ya que son responsables del comportamiento de los servidores de nombres delegados.
La base de datos distribuida del DNS se compone de RRs("resource records"). Estos proporcionan una mapeado entre nombres de dominio y objetos de red. Los objetos de red más comunes son las dirección de los hosts, pero el DNS está diseñado para acomodarse a una variada gama de distintos objetos. El formato general del registro de recurso es:
name ttl class type rdata
donde:
- name
- Es el nombre de dominio a definir. El DNS es muy general en las reglas de composición de nombres de dominio. Sin embargo, se recomienda una sintaxis para crearlos que minimiza la probabilidad de que las aplicaciones que usen un "resolver"(es decir, la mayoría de las aplicaciones TCP/IP) los malinterpreten. Un nombre de dominio que siga esta sintaxis consistirá en una serie de etiquetas formadas por caracteres alfanuméricos o guiones, cada etiqueta con una longitud de 1 a 63 caracteres, comenzando con un carácter alfabético. Cada par de etiquetas está separado por un punto en forma legible para el ojo humano, pero no en la misma forma que se usa dentro de los mensajes DNS. Los nombres de dominio no son sensibles a mayúsculas y minúsculas.
- ttl
- Es el "time-to-live" o tiempo en segundos que el registro será válido en la caché de un servidor de nombres. Se almacena en el DNS como un valor de 32 bits sin signo. 86400(un día) es un valor típico para registros que apuntan a una dirección IP.
- class
- Identifica la familia del protocolo. Valores habituales son:
- IN
- Sistema de Internet
- CH
- Sistema Chaos
- type
- Identifica el tipo de recurso del registro.
- Los diferentes tipos se describen en detalle en los RFCs 1034, 1035 y 1706. Cada tipo tienen un nombre y un valor. Valores corrientes incluyen:
- Rdata
- El valor depende del tipo, por ejemplo:
- A
- Un dirección IP de 32 bits(si la clase es IN)
- CNAME
- Un nombre de dominio
- MX
- Un valor por defecto de 16 bits(se prefieren valores bajos) seguido de un nombre de dominio.
- NS
- Un nombre de host.
- PTR
- Un nombre de dominio.
Todos los mensajes del DNS utilizan un único formato. Este formato se muestra en: Figura - Formato del mensaje DNS. El "resolver" envía la trama al servidor de nombres. Sólo la cabecera y la sección "question" se utilizan para la consulta. Las respuestas o retransmisiones de las consultas usan la misma trama, pero llenan más secciones de la misma(las secciones "answer/authority/additional").
Figure: Formato del mensaje DNS
La sección de cabecera siempre ha de aparecer y tiene una longitud fija de 12 bytes. Las otras secciones son de longitud variable.
- ID
- Un identificador de 16 bits asignado por el programa. Este identificador se copia en la respuesta correspondiente del servidor de nombres y se puede usar para diferenciar respuestas cuando concurren múltiples consultas.
- Parameters
- Un valor de 16 bits con el siguiente formato:
- QR
- Flag que indica consulta(0) o respuesta(1)
- Op code
- Campo de 4-bit especificando el tipo de consulta:
- 0
- consulta estándar(QUERY)
- 1
- consulta inversa(IQUERY)
- 2
- solicitud del estado del servidor(STATUS) Se reservan los otros valores para su uso en el futuro
- AA
- Flag de respuesta autoritativa. Si está activo en una respuesta, especifica que el servidor de nombres que responde tiene autoridad para el nombre de dominio enviado en la consulta.
- TC
- Flag de truncado. Activo si el mensaje es más largo de lo que permite el canal.
- RD
- Flag de recursividad. Este bit indica al servidor de nombres que se pide resolución recursiva. El bit se copia en la respuesta.
- RA
- Flag de recursividad disponible. Indica si el servidor de nombres soporta resolución recursiva.
- zero
- 3 bits reservados para uso futuro. Deben ser cero.
- Rcode
- Código de respuesta de 4 bits. Posibles valores son:
- 0
- Ningún error.
- 1
- Error de formato. El servidor fue incapaz de interpretar el mensaje.
- 2
- Fallo en el servidor. El mensaje no fue procesado debido a un problema con el servidor.
- 3
- Error e nombre. El nombre de dominio de la consulta no existe. Sólo válido si el bit AA está activo en la respuesta.
- 4
- No implementado. El tipo solicitado de consulta no está implementado en el servidor de nombres.
- 5
- Rechazado. El servidor rechaza responder por razones políticas. Los demás valores se reservan para su usuario en el futuro.
- QDcount
- Un entero sin signo de 16 bits que especifica el número de entradas en la sección "question".
- ANcount
- Un entero sin signo de 16 bits que especifica el número de RRs en la sección "answer".
- NScount
- Un entero sin signo de 16 bits que especifica el número de RRs en la sección "authority".
- ARcount
- Un entero sin signo de 16 bits que especifica el número de RRs en la sección "additional records".
-
La siguiente sección contiene las consultas al servidor de nombres. Contiene QDcount(generalmente 1) entradas, cada una con el formato mostrado en Figure - Formato del campo "Question".
Figura: Formato del campo "Question" - Todos estos campos están alineados por bytes. La alineación del campo Type a 4 bytes es un ejemplo, y no es obligatoria en el formato.
- length
- Un byte que indica la longitud de la siguiente etiqueta.
- label
- Un elemento del nombre de dominio. El nombre de dominio se almacena como una serie de etiquetas de longitud variable, cada una precedida por un campo "length".
- 00
- X'00' indica el fin del dominio y representa la etiqueta nula del dominio raíz.
- Type
- 2 bytes especificando el tipo de consulta. Puede tener cualquier valor del campo "Type" del registro.
- Class
- 2 bytes especificando la clase de consulta. Para consultas en Internet, será "IN".
Estas tres secciones contienen un número variable de registros de recursos. El número se especifica en el campo correspondiente de la cabecera. Los registros tienen el formato mostrado en Figura - Formato de la sección "Answer".
Figura: Formato de la sección "Answer" - Todos los campos están alineados por bytes. La alineación del campo "Type" a 4 bytes es un ejemplo, y no es obligatoria en el formato.
Los campos que preceden al TTL tienen el mismo significado que en la sección "question" y:
- TTL
- TTL de 32-bit medido en segundos. Define cuánto tiempo se puede considerar válido el recurso.
- RDlength
- Longitud de 16 bits para el campo Rdata.
- Rdata
- Ristra de longitud variable cuya interpretación depende del campo "Type".
Con el fin de reducir el tamaño del mensaje, se utiliza un esquema de compresión para eliminar la repetición de nombres de dominio en los diversos RRs. Cualquier dominio o lista de etiquetas duplicada se sustituye por un puntero a la ocurrencia anterior. El puntero tiene la forma de un campo de 2 bytes:
- Los primeros 2 bits distinguen al puntero de una etiqueta normal, que está restringida a una longitud de 63 bytes además de el byte de longitud(con el valor de <64).
- El campo de "offset especifica un desplazamiento desde el comienzo el mensaje. Un "offset" de cero especifica el primer byte del campo ID de la cabecera.
- Si se usa compresión en un campo en el campo "Rdata" de una sección "answer", "authority" o "additional", el campo "RDlength" precedente contiene, después de haber efectuado la compresión, la longitud real .
Los mensajes DNS se transmiten como datagramas(UDP) o sobre un canal(TCP).
Puerto del servidor: 53 (decimal).
Los mensajes transportados por UDP se restringen a 512 bytes. Los mensajes más largos se truncan y el bit TC de la cabecera se activa. Ya que las tramas UDP se pueden perder, hace falta una estrategia de retransmisión.
Puerto del servidor: 53 (decimal).
En este caso, el mensaje va precedido de un campo de 2 bytes que indica la longitud total de la trama.
El STD 3 - Requerimientos del host requiere que:
- Un "resolver" del DNS o un servidor que envía una consulta que no supone una transferencia de zona debe enviar una consulta UDP primero. Si la sección "answer" de la respuesta está truncada y el solicitante soporta TCP, debería intentarlo de nuevo usando TCP. Se prefiere UDP a TCP para las consultas porque UDP tiene un factor de carga mucho menor, y su uso es esencial para un servidor fuertemente cargado. El truncamiento de mensajes no suele ser un problema dados los contenidos actuales de la base de datos del DNS, ya que típicamente se pueden enviar en un datagrama 15 registros, pero esto podría cambiar a medida que se añaden nuevos tipos de registro al DNS.
- TCP debe usarse para actividades de transferencia de zonas debido a que el límite de 512 bytes de UDP siempre será inadecuado para una transferencia de zona.
- Los servidores de nombres deben soportar ambos tipos de transporte.
Los siguientes RFCs definen el estándar DNS y la información el mismo:
- RFC 1032 - Guía del administrador de dominios
- RFC 1033 - Guía operativa del administrador de dominios
- RFC 1034 - Nombres de dominio - Conceptos y servicios
- RFC 1035 - Nombres de dominio - Implementación y especificación
- RFC 1101 - Codificación DNS de nombres de red y de otros tipos
- RFC 1183 - Nuevas definiciones de RRs de DNS
- RFC 1706 - Registros de recursos DNS NSAP
Muchas implementaciones de DNS proporcionan tres utilidades bastante comunes para consultar a servidores de nombres:
- host
- Obtiene una dirección IP asociada con un nombre de host o un nombre de host asociado con una dirección IP.
- nslookup
- Permite localizar información acerca de los nodos de red, examinar los contenidos de la base de datos de un servidor de nombres y establecer la accesibilidad a servidores de nombres.
- dig("Domain Internet Groper")
- Permite probar los servidores de nombres, reunir grandes volúmenes de información de nombres de dominio y ejecutar simples consultas de nombres de dominio.
Tabla de contenidos 
SMTP ("Simple Mail Transfer Protocol")