Las respuestas FTP

Las respuestas FTP garantizan la sincronización entre el cliente y el servidor FTP. Por lo tanto, por cada comando enviado por el cliente, el servidor eventualmente llevará a cabo una acción y sistemáticamente Las respuestas están compuestas por un código de 3 dígitos que indica la manera en la que el comando enviado por el cliente ha sido procesado. Sin embargo, debido a que el código de 3 dígitos resulta difícil de leer para las personas, está acompañado de texto (cadena de caracteres Telnet separada del código numérico por un espacio).

Los códigos de respuesta están compuestos por 3 números, cuyos significados son los siguientes:

·         El primer número indica el estatuto de la respuesta (exitosa o fallida)

·         El segundo número indica a qué se refiere la respuesta.

·         El tercer número brinda un significado más específico (relacionado con cada segundo dígito).

Primer número
Dígito	Significado	Descripción
1yz	Respuesta positiva preliminar	La acción solicitada está en progreso. Se debe obtener una segunda respuesta antes de enviar un segundo comando.
2yz	Respuesta de finalización positiva	La acción solicitada se ha completado y puede enviarse un nuevo comando.
3yz	Respuesta intermedia positiva	La acción solicita está temporalmente suspendida. Se espera información adicional del cliente.
4yz	Respuesta de finalización negativa	La acción solicitada no se ha realizado debido a que el comando no se ha aceptado temporalmente. Se le solicita al cliente que intente más tarde.
5yz	Respuesta negativa permanente	La acción solicitada no se ha realizado debido a que el comando no ha sido aceptado. Se le solicita al cliente que formule una solicitud diferente.

Segundo número
Dígito	Significado	Descripción
x0z	Sintaxis	La acción tiene un error de sintaxis o sino, es un comando que el servidor no comprende.
x1z	Información	Ésta es una respuesta que envía información (por ejemplo, una respuesta a un comando STAT).
x2z	Conexiones	La respuesta se refiere al canal de datos.
x3z	Autenticación y cuentas	La respuesta se refiere al inicio de sesión (USUARIO/CONTRASEÑA) o a la solicitud para cambiar la cuenta (CPT).
x4z	No utilizado por el protocolo FTP.
x5z	Sistema de archivos	La respuesta se relaciona con el sistema de archivos remoto.

                                  Los comandos FTP

Toda comunicación que se realice en el canal de control sigue las

recomendaciones del protocolo Telnet. Por lo tanto, los comandos

FTP son cadenas de caracteres Telnet (en código NVT-ASCII) que

finalizan con el código de final de línea Telnet (es decir, la secuencia

<CR>+<LF>, Retorno de carro seguido del carácter Avance de línea indicado como <CRLF>).Si el comando FTP tiene un parámetro, éste se separa del comando con un espacio (<SP>).

Los comandos FTP hacen posible especificar:

• El puerto utilizado

• El método de transferencia de datos

• La estructura de datos

• La naturaleza de la acción que se va a realizar (Recuperar,

Enumerar, Almacenar, etc.)

Existen tres tipos de comandos FTP diferentes:

• Comandos de control de acceso

• Comandos de parámetros de transferencia

• Comandos de servicio FTP

Comandos de control de acceso
Comando	Descripción
USER	Cadena de caracteres que permite identificar al usuario. La identificación del usuario es necesaria para establecer la comunicación a través del canal de datos.
PASS	Cadena de caracteres que especifica la contraseña del usuario. Este comando debe ser inmediatamente precedida por el comando USER. El cliente debe decidir si esconder la visualización de este comando por razones de seguridad.
ACCT	Cadena de caracteres que especifica la cuenta del usuario. El comando generalmente no es necesario. Durante la respuesta que acepta la contraseña, si la respuesta es 230, esta etapa no es necesaria; Si la respuesta es 332, sí lo es.
CWD	Change Working Directory (Cambiar el directorio de trabajo): este comando permite cambiar el directorio actual. Este comando requiere la ruta de acceso al directorio para que se complete como un argumento.
CDUP	Change to Parent Directory (Cambiar al directorio principal): este comando permite regresar al directorio principal. Se introdujo para resolver los problemas de denominación del directorio principal según el sistema (generalmente "..").
SMNT	Structure Mount (Montar estructura):
REIN	Reinitialize (Reinicializar):
QUIT	Comando que permite abandonar la sesión actual. Si es necesario, el servidor espera a que finalice la transferencia en progreso y después proporciona una respuesta antes de cerrar la conexión.

Comandos de parámetros de transferencia
Comando	Descripción
PORT	Cadena de caracteres que permite especificar el número de puerto utilizado.
PASV	Comando que permite indicar al servidor de DTP que permanezca a la espera de una conexión en un puerto específico elegido aleatoriamente entre los puertos disponibles. La respuesta a este comando es la dirección IP del equipo y el puerto.
TYPE	Este comando permite especificar el tipo de formato en el cual se enviarán los datos.
STRU	Carácter Telnet que especifica la estructura de archivos (F de File [Archivo], R de Record [Registro], P de Page [Página]).
MODE	Carácter Telnet que especifica el método de transferencia de datos (S deStream [Flujo], B de Block [Bloque], C de Compressed [Comprimido]).

Comandos de servicio FTP
Comando	Descripción
RETR	Este comando (RETRIEVE [RECUPERAR]) le pide al servidor de DTP una copia del archivo cuya ruta de acceso se da en los parámetros.
STOR	Este comando (store [almacenar]) le pide al servidor de DTP que acepte los datos enviados por el canal de datos y que los almacene en un archivo que lleve el nombre que se da en los parámetros. Si el archivo no existe, el servidor lo crea; de lo contrario, lo sobrescribe.
STOU	Este comando es idéntico al anterior, sólo le pide al servidor que cree un archivo cuyo nombre sea único. El nombre del archivo se envía en la respuesta.
APPE	Gracias a este comando (append [adjuntar]) los datos enviados se concatenan en el archivo que lleva el nombre dado en el parámetro si ya existe; si no es así, se crea.
ALLO	Este comando (allocate [reservar]) le pide al servidor que reserve un espacio de almacenamiento lo suficientemente grande como para recibir el archivo cuyo nombre se da en el argumento.
REST	Este comando (restart [reiniciar]) permite que se reinicie una transferencia desde donde se detuvo. Para hacer esto, el comando envía en el parámetro el marcador que representa la posición en el archivo donde la transferencia se había interrumpido. Después de este comando se debe enviar inmediatamente un comando de transferencia.
RNFR	Este comando (rename from [renombrar desde]) permite volver a nombrar un archivo. En los parámetros indica el nombre del archivo que se va a renombrar y debe estar inmediatamente seguido por el comando RNTO.
RNTO	Este comando (rename from [renombrar a]) permite volver a nombrar un archivo. En los parámetros indica el nombre del archivo que se va a renombrar y debe estar inmediatamente seguido por el comando RNFR.
ABOR	Este comando (abort [cancelar]) le indica al servidor de DTP que abandone todas las transferencias asociadas con el comando previo. Si no hay conexión de datos abierta, el servidor de DTP no realiza ninguna acción; de lo contrario, cierra la conexión. Sin embargo, el canal de control permanece abierto.
DELE	Este comando (delete [borrar]) permite que se borre un archivo, cuyo nombre se da en los parámetros. Este comando es irreversible y la confirmación sólo puede darse a nivel cliente.
RMD	Este comando (remove directory [eliminar directorio]) permite borrar un directorio. El nombre del directorio que se va a borrar se indica en los parámetros.

Por lo tanto, el cliente y el servidor cuentan con dos procesos que permiten la administración de estos dos tipos de información:

·         DTP (Proceso de transferencia de datos) es el proceso encargado de establecer la conexión y de administrar el canal de datos. El DTP del lado del servidor se denomina SERVIDOR DE DTP y el DTP del lado del cliente se denomina USUARIO DE DTP.

·         PI (Intérprete de protocolo) interpreta el protocolo y permite que el DTP pueda ser controlado mediante los comandos recibidos a través del canal de control. Esto es diferente en el cliente y el servidor:

·         El SERVIDOR PI es responsable de escuchar los comandos que provienen de un USUARIO PI a través del canal de control en un puerto de datos, de establecer la conexión para el canal de control, de recibir los comandos FTP del USUARIO PI a través de éste, de responderles y de ejecutar el SERVIDOR DE DTP.

·         El USUARIO PI es responsable de establecer la conexión con el servidor FTP, de enviar los comandos FTP, de recibir respuestas del SERVIDOR PI y de controlar al USUARIO DE DTP, si fuera necesario.

Cuando un cliente FTP se conecta con un servidor FTP, el USUARIO PI inicia la conexión con el servidor de acuerdo con el protocolo Telnet. El cliente envía comandos FTP al servidor, el servidor los interpreta, ejecuta su DTP y después envía una respuesta estándar. Una vez que se establece la conexión, el servidor PI proporciona el puerto por el cual se enviarán los datos al Cliente DTP. El cliente DTP escucha el puerto especificado para los datos provenientes del servidor. 

Es importante tener en cuenta que, debido a que los puertos de control y de datos son canales separados, es posible enviar comandos desde un equipo y recibir datos en otro. Entonces, por ejemplo, es posible transferir datos entre dos servidores FTP mediante el paso indirecto por un cliente para enviar instrucciones de control y la transferencia de información entre dos procesos del servidor conectados en el puerto correcto.

En esta configuración, el protocolo indica que los canales de control deben permanecer abiertos durante la transferencia de datos. De este modo, un servidor puede detener una transmisión si el canal de control es interrumpido durante la transmisión

Protocolo de transferencia de archiveros de FTP

El protocolo FTP (Protocolo de transferencia de archivos) es, como su nombre lo indica, un protocolo para transferir archivos. La implementación del FTP se remonta a 1971 cuando se desarrolló un sistema de transferencia de archivos (descrito en RFC141) entre equipos del Instituto Tecnológico de Massachusetts (MIT, Massachusetts Institute of Technology). Desde entonces, diversos documentos de RFC (petición de comentarios) han mejorado el protocolo básico, pero las innovaciones más importantes se llevaron a cabo en julio de 1973.Actualmente, el protocolo FTP está definido por RFC 959 (Protocolo de transferencia de archivos (FTP) - Especificaciones). Protocolo FTP (Protocolo de transferencia de archivos) La función del protocolo FTP El protocolo FTP define la manera en que los datos deben ser transferidos a través de una red TCP/IP. El objetivo del protocolo FTP es: ·         permitir que equipos remotos puedan compartir archivos ·         permitir la independencia entre los sistemas de archivo del equipo del cliente y del equipo del servidor ·         permitir una transferencia de datos eficaz El modelo FTP El protocolo FTP está incluido dentro del modelo cliente-servidor, es decir, un equipo envía órdenes (el cliente) y el otro espera solicitudes para llevar a cabo acciones (el servidor). Durante una conexión FTP, se encuentran abiertos dos canales de transmisión: ·         Un canal de comandos (canal de control) ·         Un canal de datos

Servidores de nombres Dns

Los servidores DNS son conocidos como servidores de nombres(NS), los cuales suelen ser responsables de una o mas zonas. Una zona es un archivo físico que almacena registros de las base de datos de una parte del espacio de nombres de dominio, concretamente de aquellos dominios sobre los que tiene autoridad.

Siempre es necesario que existan dos servidores de nombres:

• Servidor de nombres principal: Obtiene los datos de sus zonas de archivos locales. Todos los cambios en una zona, como añadir más dominios se hacen en este servidor.
• Servidor de nombres secundario: Obtiene los datos de sus zonas de otro servidor de nombres, generalmente el principal. Al proceso de obtención de estos datos se le llama transferencia de zona.

Características del servidor

El servicio de servidor del Sistema de nombres de dominio (DNS) proporciona las siguientes características:

• Servidor DNS compatible con RFC
  
  DNS es un protocolo abierto y estandarizado por un conjunto de Solicitudes de comentarios (RFC). Microsoft es compatible con estas especificaciones estándar.
  
  Para obtener más información, vea RFC de DNS.
  
• Interoperabilidad con otras implementaciones del servidor DNS
  
  Como el servicio de Servidor DNS es compatible con RFC y puede utilizar formatos de registro de recursos y de archivo de datos DNS estándar, puede trabajar satisfactoriamente con la mayoría de las implementaciones del servidor DNS, como las que utilizan el software Berkeley Internet Name Domain (BIND).
  
  Para obtener más información, vea Problemas de interoperabilidad.
  
• Compatibilidad con Active Directory
  
  Se necesita DNS para compatibilizar el servicio de directorios Active Directory®. Si instala Active Directory en un servidor, puede instalar y configurar automáticamente un servidor DNS si no puede localizarse un servidor DNS que cumpla los requisitos de Active Directory.
  
  En primer lugar, en el Asistente para instalación de Active Directory, especifique el nombre DNS del dominio de Active Directory en el que promueve al servidor a controlador de dominio. Después, en el proceso de instalación, el asistente comprobará lo siguiente:
  
  
  1. Basándose en su configuración de cliente TCP/IP, comprueba si hay un servidor DNS preferido configurado para ser utilizado.
     
  2. Si está disponible un servidor DNS preferido, hará consultas para encontrar el servidor autorizado principal para el nombre DNS del dominio de Active Directory que especificó en el asistente.
     
  3. A continuación, comprueba si el servidor principal autorizado admite y puede aceptar actualizaciones dinámicas, como se describe en el protocolo de actualización dinámica (RFC 2136).
     
  4. Si, en este punto del proceso, no se encuentra un servidor DNS que acepte actualizaciones del nombre de dominio DNS especificado que está utilizando con Active Directory, puede instalar el servicio de Servidor DNS localmente.
     
  5. Si decide instalar el servicio de Servidor DNS localmente, se utiliza la dirección IP para el servidor DNS preferido actual para configurar un reenviador en el servidor DNS local. Esta configuración mantiene cualquier resolución existente con un Proveedor de servicios Internet (ISP, <i>Internet Service Provider</i>).
     
  En general, es muy recomendable utilizar el servicio del Servidor DNS de Windows Server 2003 para conseguir la mejor integración y compatibilidad posibles de Active Directory y características de servidor DNS mejoradas. Sin embargo, puede utilizar otro tipo de servidor DNS para la compatibilidad con la distribución de Active Directory.

Tipos de servidores Dns

Debe haber un conjunto de servidores de nombres que atiendan peticiones. Este tipo de servidores se denominan autoritativos porque son los que tienen la información real y veraz de la zona pueden ser de dos 

* Primario: Es el servidor principal, a veces llamado master, de la zona.

Es el servidor en el que el administrador del DNS efectúa las operaciones de alta y baja de nombres.

* Secundarios o esclavo: Son el resto de servidores de la zona. Contienen una copia de la zona, habitualmente obtenida del servidor primario tan solo tienen una copia de los datos originales.

Para cada zona deberemos tener, un servidor primario y uno o más secundarios.

Existen otros tipos de servidores DNS:

* Reenviador: Denominados forwarders en ingles, es un servidor DNS que recibe las peticiones de todos los servidores DNS de mi red. Se configura para minimizar las consultas DNS al exterior en una red corporativa en la que existan varios servidores DNS.

* Caché: Es un tipo de servidor DNS que no es autoritativo (ni primario ni secundario) de ninguna zona en especial. Se suele usar para que el trafico DNS al exterior disminuya. También se puede usar para no sobrecargar los servidores autoritativos de una zona. Un ISP puede definir que el servidor DNS que usan sus clientes no sea uno de los servidores de su zona sino que puede configurar un servidor caché que solo sirve para atender las peticiones de estos clientes.