No se puede negar, las redes de computadoras son un asunto complicado que involucra

muchas tecnologías, capas y protocolos.

Al fin y al cabo, el propósito principal de las redes de computadoras
es que los servicios de red puedan estar disponibles para responder a las solicitudes de
datos de los clientes.
El vasto número y la variedad de cosas que podría comprender un servicio de red
hace que sea imposible que los abarquemos todos.
Pero hay muchas tecnologías y servicios de red
que se usan para que las redes de computadoras sean más fáciles de usar y seguras.
Estos servicios y tecnologías de red
son los que se relacionan directamente con el asunto de las redes en sí,
y es importante comprender cómo funcionan.
Si algo en la red no funciona como se espera,
lo primero que hay que mirar son los servicios que vamos a ver aquí.
Y que te pidan que soluciones cosas que no están funcionando como se espera
será una parte importante de tu tarea como especialista en soporte de TI.
Al final de este módulo, podrás describir por qué la resolución de nombres es
importante,
identificar los diversos pasos involucrados en la búsqueda de DNS
y entender los tipos de registros DNS más comunes.
También podrás explicar por qué DHCP simplifica la administración de la red.
Podrás demostrar cómo las tecnologías de NAT ayudan a mantener la seguridad de las
redes
y a preservar el precioso espacio de direcciones IP.
Por último, podrás describir cómo las VPN
y los proxies ayudan a los usuarios a conectarse y a mantenerse seguros.
Como puedes ver, tenemos mucho para abordar. Empecemos.

Las computadoras se comunican entre sí usando números.

En los niveles más bajos, todo lo que las computadoras realmente entienden son 1 y 0.
Leer números binarios no es lo más fácil para los humanos,
por eso, la mayoría de los números binarios se representan de muchas formas diferentes.
Esto es especialmente cierto en el campo de las redes.
Recuerda que una dirección IP es, en realidad, un número binario de 32 bits,
pero que normalmente se escribe como 4 octetos en forma decimal ya que así es más
fácil de leer para los humanos.
También puedes recordar que las direcciones MAC son solo números binarios de 48 bits
que normalmente se escriben en 6 grupos de 2 dígitos hexadecimales cada uno.
Si bien recordar 192.168.1.100 podría ser más fácil
que recordar una larga cadena de unos y ceros,
tampoco facilita las cosas cuando tienes que recordar algo más que unas pocas
direcciones.
Imagina tener que recordar los cuatro octetos de una dirección IP
para cada sitio web que visites.
No es un talento natural del cerebro humano.
Los humanos somos mucho mejores recordando palabras.
Ahí es donde DNS, o sistema de nombres de dominio, entra en juego.
DNS es un servicio de red global y altamente distribuido
que resuelve strings de letras en una dirección IP para ti.
Supongamos que querías ir a un sitio web sobre el clima para ver cómo iba a estar
la temperatura.
Es mucho más fácil escribir www.weather.com en un navegador web
que recordar que una de las direcciones IP
para este sitio es 184.29.131.121.
La dirección IP para un nombre de dominio también puede cambiar todo el tiempo
por muchas razones diferentes
Un nombre de dominio es solo el término que usamos para algo que el DNS puede
resolver.
En el ejemplo que acabamos de utilizar, www.weather.com sería el nombre de dominio,
y la IP que resuelve aquí podría cambiar dependiendo de una variedad de factores.
Digamos que weather.com estaba moviendo su servidor web a un nuevo centro de
datos.
Tal vez firmaron un nuevo contrato, o el viejo centro de datos estaba cerrando.
Mediante el uso de DNS, una organización puede cambiar a qué IP se resuelve un
nombre de dominio,
y el usuario final nunca lo sabría.
Entonces, el DNS no solo hace más fácil que los humanos podamos recordar cómo
llegar a un sitio web,
también permite que ocurran cambios administrativos detrás de escena
sin que un usuario final deba cambiar su comportamiento.
Intenta imaginar un mundo en el que tengas que recordar cada IP
para cada sitio web que visitas, y además memorizar las nuevas IP si algo cambiara.
Pasaríamos todo nuestro día memorizando números.
No podemos enfatizar lo suficiente la importancia del DNS para el funcionamiento de
Internet.
Las direcciones IP pueden resolver diferentes cosas
según en qué parte del mundo estés.
Mientras que la mayoría de las comunicaciones de Internet viajan a la velocidad de la
luz,
cuanto más lejos tengas que enrutar datos, más lentas serán las cosas.
En casi todas las situaciones, va a ser más rápido transmitir una cierta cantidad de datos
entre lugares que están geográficamente cerca entre sí.
Si eres una empresa web global, querrás que personas de todo el mundo
tengan una gran experiencia al acceder a tu sitio web.
Así que en lugar de mantener todos tus servidores web en un solo lugar,
podrías distribuirlos por centros de datos en todo el mundo.
De esta manera, alguien en Nueva York que visita un sitio web,
podría recibir datos de un servidor web cercano a Nueva York, mientras alguien en
Nueva Delhi
podría recibir datos de un servidor web más cercano a Nueva Delhi.
Nuevamente, DNS permite brindar esta funcionalidad
Debido a su estructura global, DNS permite a las organizaciones decidir,
si estás en la región, resolver el nombre de dominio a esta IP.
Si estás en esta otra región, resolver este dominio a esta otra IP.
DNS cumple muchas funciones y podría ser una de las tecnologías más importantes
que debas comprender como especialista en soporte de TI
para poder solucionar problemas de redes con eficacia.

En su forma más básica, DNS es un sistema que convierte nombres de dominio en

direcciones IP.
Es la forma en que los humanos recordarán y clasificarán las cosas
resuelta en la forma en que las computadoras prefieren pensar las cosas.
Este proceso de utilizar DNS para convertir
un nombre de dominio en una dirección IP se conoce como resolución de nombres.
Veamos cómo funciona esto más de cerca.
Lo primero que es importante saber es que los servidores DNS
son una de las cosas que deben configurarse específicamente en un nodo en una red.
Para que una computadora funcione en una red moderna,
tiene que tener cierta cantidad de cosas configuradas.
Recuerda que las direcciones MAC están hard-coded y vinculadas a piezas específicas
de hardware.
Pero también vimos que la dirección IP, la máscara de subred,
y la puerta de enlace para un host debe estar específicamente configuradas.
Un servidor DNS es la cuarta y última parte de la configuración de la red moderna
estándar.
Estas son casi siempre las cuatro cosas que deben configurarse
para que un host funcione en una red de la forma esperada.
Debo señalar que una computadora puede funcionar bien
sin DNS o sin un servidor DNS configurado,
pero como vimos en el último video,
esto dificulta las cosas para cualquier humano que pueda estar usando esa computadora.
Hay cinco tipos principales de servidores DNS: servidores de almacenamiento en caché
de nombres,
servidores de nombres recursivos, servidores de nombres raíz,
servidores de nombres TLD y servidores de nombres autoritativos.
A medida que los veamos en profundidad,
es importante tomar nota de que un servidor DNS dado puede cumplir muchas de estas
funciones a la vez.
Los servidores de almacenamiento en caché y de nombres recursivos
son proporcionados generalmente por un ISP o tu red local.
Su propósito es almacenar las búsquedas de nombres de dominio durante un cierto
tiempo.
Como verás en un momento,
hay muchos pasos para realizar
una resolución completa de un nombre de dominio.
Con el fin de evitar que esto suceda cada vez
que se establece una nueva conexión TCP,
tu ISP o red local generalmente tendrán un servidor de almacenamiento en caché de
nombres disponible.
La mayoría de estos servidores también son servidores de nombres recursivos.
Los servidores de nombres recursivos son los que realizan solicitudes de resolución de
DNS completas.
En la mayoría de los casos, tu servidor de nombres local realizará las tareas de ambos,
pero definitivamente es posible que un servidor de nombres
sea solo de almacenamiento en caché o solo recursivo.
Vamos a presentar un ejemplo para explicar mejor cómo funciona esto.
Tu amigo y tú están conectados a la misma red
y ambos quieren ir a Facebook.com.
Tu amigo escribe "www.facebook.com" en un navegador web,
lo que significa que su computadora ahora necesita saber la IP
de www.facebook.com para establecer una conexión.
Ambas computadoras están en la misma red, lo que por lo general
implica que ambas fueron configuradas con el mismo servidor de nombres.
La computadora de tu amigo pide al servidor de nombres
la IP de www.facebook.com, pues no la conoce.
Este servidor de nombres ahora realiza una resolución completamente recursiva
para detectar la IP correcta para www.facebook.com.
Esto implica un montón de pasos que veremos en un momento.
Esta IP se entrega a la computadora de tu amigo y se almacena localmente en una
memoria caché.
Unos minutos más tarde, tú escribes "www.facebook.com" en un navegador web.
Nuevamente, tu computadora necesita conocer la IP de este dominio,
así que le pregunta al servidor de nombres local con el que está configurada,
que es el mismo con el que la computadora de tu amigo estuvo en comunicación.
Como recién hubo una búsqueda del nombre de dominio www.facebook.com,
el servidor de nombres local todavía tiene la IP que resolvió almacenar
y puede entregarla a tu computadora sin tener que realizar una búsqueda completa.
Así es como los mismos servidores actúan como servidor de almacenamiento en caché.
Todos los nombres de dominio en el sistema DNS global tienen un TTL o tiempo de
vida.
Este es un valor en segundos
que el propietario de un nombre de dominio puede configurar para indicar cuánto
tiempo se permite
que un servidor de nombres almacene una entrada en la memoria caché
antes de que deba descartarla y volver a realizar una resolución completa.
Hace varios años, era normal que estos TTL fueran realmente largos,
a veces un día completo o más.
Esto se debe a que el ancho de banda general disponible en Internet era mucho menor,
así que los administradores de red no querían desperdiciar el ancho de banda disponible
para realizar búsquedas de DNS completas constantemente.
A medida que Internet fue creciendo y volviéndose más veloz,
estos TTL para la mayoría de los dominios se redujeron a un valor entre unos minutos a
unas horas.
Pero es importante saber que, a veces,
podrías encontrar nombres de dominios con TTL muy largos,
lo que significa que puede llevar la duración completa de un TTL
para que Internet en su totalidad conozca un cambio en el registro de DNS.
Ahora, veamos que sucede
cuando tu servidor recursivo local necesita realizar una resolución recursiva completa.
El primer paso es siempre contactar con un servidor llamado raíz;
hay 13 servidores raíz de nombres en total
y son responsables de dirigir las consultas hacia el servidor de nombres TLD apropiado.
En el pasado, estos 13 servidores raíz se distribuían en regiones geográficas muy
específicas,
pero hoy en día, se distribuyen principalmente en todo el mundo a través de la difusión
por proximidad (Anycast).
Anycast es una técnica que se utiliza para enrutar el tráfico
a diferentes destinos dependiendo de factores como la ubicación,
la congestión o el estado del enlace.
Con Anycast, una computadora puede enviar un datagrama a una IP específica,
pero podría verlo enrutado a uno de los muchos destinos reales diferentes dependiendo
de algunos factores.
Esto también debería dejar claro que, en realidad,
ya no hay solo 13 servidores de nombres de rutas físicas.
Es mejor pensar en ellos como 13 autoridades
que ofrecen las búsquedas de nombre de ruta como un servicio.
Los servidores raíz responderán
a una búsqueda de DNS con el servidor de nombres TLD que se debe consultar.
TLD significa dominio de nivel superior
y representa la parte superior del sistema jerárquico de resolución de nombres DNS.
Un TLD es la última parte de cualquier nombre de dominio:
tomando www.facebook.com como ejemplo otra vez,
la porción ".com" debe considerarse el TLD.
Vamos a entrar en más detalles
sobre los diferentes componentes de un nombre de dominio en una próxima lección.
Para cada TLD en existencia,
hay un servidor de nombres TLD,
pero al igual que con los servidores raíz,
esto no significa que solo haya físicamente un servidor en cuestión.
Es muy probable que sea una distribución global
de servidores Anycast accesibles, responsables de cada TLD.
Los servidores de nombres TLD responderán de nuevo con un redireccionamiento,
esta vez informando a la computadora
que realiza la búsqueda de nombres con qué servidor de nombres autoritativo debe
contactarse.
Los servidores de nombres autoritativos son responsables de las dos últimas partes
de cualquier nombre de dominio, que es la resolución
en la que una sola organización puede ser responsable de las búsquedas de DNS.
Tomando www.weather.com como ejemplo,
el servidor de nombres de TLD apuntaría una búsqueda al servidor autoritativo para
Weather.com,
que probablemente esté controlado por The Weather Channel,
la organización que dirige el sitio.
Por último, la búsqueda de DNS podría redirigirse al servidor autoritativo
para weather.com que, en última instancia, proporcionaría la IP real del servidor en
cuestión.
Esta jerarquía estricta es muy importante para la estabilidad de Internet,
ya que garantiza que todas las resoluciones completas de DNS pasan por una serie
de búsquedas estrictamente reguladas y controladas para obtener las respuestas
correctas,
y es la mejor manera de proteger contra actores maliciosos que redireccionan el tráfico.
Tu computadora enviará ciegamente el tráfico a cualquier IP que se le indique.
Al usar un sistema jerárquico controlado por entidades confiables en la forma en que lo
hace el DNS,
podemos garantizar mejor que las respuestas a las búsquedas de DNS sean precisas.
Ahora que ves cuántos pasos están involucrados, tiene sentido que confiemos
en que nuestros servidores de nombres locales almacenen las búsquedas de DNS en
caché.
Es para no tener que hacer una búsqueda de ruta completa para cada conexión TCP.
De hecho, tu computadora local, desde tu teléfono
a un equipo de escritorio, generalmente también tendrá su propia memoria caché DNS
temporal.
De esa manera, tampoco tiene que molestar
a su servidor de nombres local para cada conexión TCP.

DNS es un gran ejemplo de un servicio de capa de aplicación

que usa UDP para la capa de transporte en lugar de TCP.
Esto se puede desglosar en algunas razones simples.
Recuerda que la mayor diferencia entre TCP y UDP es que UDP no tiene conexión.
Esto significa que no hay configuración ni cierre de una conexión.
En general, se necesita transmitir mucho menos tráfico.
Una sola solicitud de DNS y su respuesta pueden caber dentro de un solo datagrama
UDP,
por lo que es un candidato ideal para un protocolo sin conexión.
También vale la pena señalar que DNS puede generar mucho tráfico.
Es cierto que las copias en caché de las entradas DNS
se guardan en máquinas locales y en servidores de nombres de caché,
pero también es cierto que si se necesita procesar una resolución completa,
estamos hablando de mucho más tráfico.
Veamos qué aspecto tendría una búsqueda de DNS completa a través de TCP.
Primero, el host que se está encargando
de la solicitud de resolución de DNS enviaría un paquete SYN al servidor de nombres
local en el puerto 53,
que es el puerto que escucha DNS.
Este servidor de nombres tendría que responder con un paquete SYN ACK,
lo que significa que el host original debería responder
con un ACK para completar el protocolo de enlace de tres vías.
Ahí tenemos tres paquetes.
Ahora que la conexión se estableció,
el host original tendría que enviar la solicitud real.
"Quisiera saber la dirección IP de food.com, por favor".
Cuando reciba esta solicitud,
el servidor de nombres tendría que responder con otro ACK.
"Tengo tu solicitud de food.com".
Hasta aquí, se enviaron cinco paquetes.
En nuestra situación, el primer servidor de almacenamiento de nombres en caché no
tiene nada en el caché para food.com.
Por lo tanto, debe comunicarse con un servidor de nombres raíz para averiguar quién es
responsable del TLD de .com.
Esto requeriría un protocolo de enlace de tres vías:
la solicitud real, el ACK de la solicitud,
la respuesta, y luego el ACK de la respuesta.
Por último, la conexión tendría que cerrarse a través de un protocolo de enlace de cuatro
vías.
Eso son 11 paquetes más, o 16 en total.
Ahora que el servidor de nombres recursivo tiene el servidor de nombres TLD correcto,
debe repetir todo el proceso para detectar el servidor de nombres autoritativo adecuado.
Eso son 11 paquetes más,
lo que nos lleva a 27 hasta ahora.
Por último, el servidor de nombres recursivo tendría que repetir todo el proceso una vez
más
mientras se comunica
con el servidor de nombres autoritativo para obtener la IP de food.com.
Esto son 11 paquetes más para un total acumulado de 38.
Ahora que el servidor de nombres local finalmente tiene la dirección IP de food.com,
puede finalmente responder a la solicitud inicial.
Una respuesta al agente de resolución de DNS que originalmente hizo la solicitud,
y luego esta computadora envía un ACK de regreso para confirmar que recibió la
respuesta.
Eso son 2 paquetes más,
y llegamos a 40.
Por último, la conexión TCP tendría que cerrarse a través de un protocolo de enlace de
cuatro vías.
Esto nos lleva a un total de 44 paquetes como mínimo
para que una solicitud de DNS completamente recursiva se complete a través de TCP.
44 paquetes no es realmente un gran número en cuanto a la rapidez con la que operan
las redes modernas.
Pero se acumulan rápido, como puedes ver.
Recuerda que el tráfico de DNS es solo un precursor del tráfico real.
Una computadora casi siempre realiza una búsqueda de DNS porque necesita saber
la IP del nombre de dominio para enviar datos adicionales,
no solo porque sea curiosa.
Ahora, vamos a ver cómo sería esto con UDP.
Alerta de spoiler: no ocupa tantos paquetes.
La computadora original envía un paquete UDP a su servidor de nombres local
en el puerto 53 solicitando la IP para food.com, eso es un paquete.
El servidor de nombres local actúa como servidor recursivo y envía un paquete UDP
al servidor raíz que envía una respuesta que contiene
el servidor de nombres TLD adecuado, ahí tenemos tres paquetes.
El servidor de nombres recursivo envía un paquete al servidor de TLD
y recibe una respuesta que contiene el servidor autoritativo correcto.
Ahora estamos en cinco paquetes.
A continuación, el servidor de nombres recursivo envía su solicitud final
al servidor de nombres autoritativo que envía una respuesta que contiene la IP para
food.com.
Eso son siete paquetes.
Por último, el servidor de nombres local responde
al agente de resolución de DNS que realizó la solicitud en primer lugar con la IP de
food.com.
Eso nos lleva a un total final de ocho paquetes.
Mira, mucho menos paquetes.
Ahora puedes ver cuánta sobrecarga requiere TCP realmente.
Y para algo tan simple como DNS, no es necesario.
Es el ejemplo perfecto de por qué existen protocolos como UDP
además de TCP, que es mucho más sólido.
Quizás te preguntes cómo entra en juego la recuperación de errores aquí,
ya que UDP no tiene esa función.
La respuesta es bastante simple.
El agente de resolución de DNS vuelve a preguntar si no recibe una respuesta.
Básicamente, la misma funcionalidad que TCP proporciona
en la capa de transporte es proporcionada por DNS
en la capa de aplicación de la manera más simple.
Un servidor DNS nunca debe preocuparse por otra cosa que responder a las búsquedas
entrantes,
y un agente de resolución de DNS solo debe realizar búsquedas y repetirlas si no tiene
éxito.
Un verdadero modelo de la simplicidad de DNS y UDP.
Debo señalar que, de hecho, DNS sobre TCP existe y también se usa en todas partes.
Como la Web se ha vuelto más compleja,
ya no todas las respuestas de búsqueda de DNS pueden caber en un solo datagrama
UDP.
En estas situaciones, un servidor de nombres DNS
responderá con un paquete que explica que la respuesta es demasiado grande.
El cliente DNS establecerá una conexión TCP para realizar la búsqueda.

Cuando estás trabajando en TI, trabajas con un montón de sistemas diferentes.

Podrían ser servidores,
bases de datos, una diversidad de sistemas operativos.
Y luego, como ingeniero de redes, debes saber cómo funcionan todas esas cosas juntas.
Pienso en mi caso: cuando era niño,
tenía un desorden cognitivo, así que nunca sentí que lo académico fuera una de mis
fortalezas.
Sentía que todos querían dedicarse a las computadoras
o a programación o redes y ser genios,
entender matemáticas y ciencias,
obtener las mejores notas.
En mi caso, me di cuenta de que no se trataba de una inteligencia promedio.
Tiene que ver más con tu pasión y tu motivación para aprender.
No tienes que ser un genio,
solo tienes que estar motivado y ser capaz de aprender cosas por ti mismo y avanzar.
El mejor consejo que recibí de un mentor fue "maximiza tu potencial".
Y creo que se puede aplicar en todas las áreas de la vida, pero especialmente en TI,
en cualquier carrera en tecnología,
porque probablemente nunca serás la persona más inteligente en la sala.
Tendrá que ver con tu orientación y tu carrera,
solo preocúpate por ellas y por tu potencial para eso.
No creo que se necesite educación formal para un puesto en TI.
Hay muchos caminos para llegar y muchas personas diferentes toman caminos
diferentes.
Si alguien está nervioso por no tener un título universitario de cuatro años
o ciertas credenciales, está bien.
TI es un lugar donde si conoces la información,
conoces tus fundamentos,
podrás lograr el éxito profesional que deseas.
Creo que cuando miras el papel que juega la tecnología en nuestra vida diaria,
simplemente tiene sentido,

me encanta resolver problemas,

me gustan los desafíos.
Y la tecnología te da todos esos desafíos y esos rompecabezas para resolver.
Por lo tanto, siempre le digo a la gente que dedicarse a la TI
como punto de partida es la base de lo que todos los demás harán a continuación.
Es una amplitud de tecnologías y puedes probar un montón de cosas diferentes
y luego, lentamente, comienzas a especializarte si así lo deseas.

1.

Pregunta 1

¿Por lo general, qué protocolo de capa de transporte usa el DNS?

1 / 1 punto

ICMP

IP

UDP

TCP

Correcto

¡Buen trabajo! Aunque existe el concepto de DNS sobre TCP, el protocolo UDP es el
más común.

2.

Pregunta 2

¿Qué determina un TTL de DNS?

1 / 1 punto

Cuánto tiempo se permite que una entrada de DNS se almacene en caché

Cuántas resoluciones de DNS pueden ocurrir antes de que la IP tenga que cambiar

Qué tan lejos puede estar un DNS de ti

Cuántos pasos hay en el proceso de resolución

Correcto

¡Increíble! TTL significa tiempo de vida y determina cuánto tiempo puede estar una
entrada de DNS en caché.

3.

Pregunta 3

¿Cuántos servidores raíz hay?

1 / 1 punto

16

17

13

Correcto

¡Acertaste! Hay 13 servidores de nombres raíz.

Recuerda: DNS es una de las tecnologías más importantes

que un especialista en soporte de TI debe conocer para solucionar problemas de red.
Por lo tanto, vamos a lo esencial del asunto.
En la práctica, DNS trabaja con un conjunto de tipos de registro de recursos definidos.
Esto permite que se realicen diferentes tipos de resoluciones de DNS.
Hay docenas de diferentes tipos de registros de recursos definidos,
pero muchos de ellos solo cumplen funciones muy especializadas.
Veremos los más comunes aquí.
El registro de recursos más común se conoce como "registro A".
Un registro A se utiliza para apuntar un cierto nombre de dominio a una cierta dirección
IPv4.
En nuestros análisis anteriores sobre DNS,
supusimos que
el agente de resolución de DNS solicitaba el registro A para un nombre de dominio.
En su uso más básico,
se configura un solo registro A para un solo nombre de dominio.
Pero, un solo nombre de dominio también puede tener varios registros A.
Esto da cuenta de una técnica
conocida como round robin de DNS que se utiliza para equilibrar el tráfico entre
múltiples IP.
Round robin es un concepto que consiste en iterar
una lista de artículos uno por uno de forma ordenada.
Se espera que esto garantice
un equilibrio bastante similar de cada entrada en la lista seleccionada.
Supongamos que estamos a cargo de un nombre de dominio: www.microsoft.com.
Microsoft es una empresa grande y es probable que su sitio web vea mucho tráfico.
Para ayudar a equilibrar este tráfico entre múltiples servidores,
configuramos cuatro registros A para www.microsoft.com
en el servidor de nombres autoritativo para el dominio microsoft.com.
Usaremos las IP 10.1.1.1,
10.1.1.2, 10.1.1.3 y 10.1.1.4.
Cuando el agente de resolución de DNS realiza una búsqueda de www.microsoft.com,
las cuatro direcciones IP se devolverán en el orden en que se las configuró por primera
vez: 10.1 1.1,
seguida por 10.1.1.2, seguida por 10.1.1.3, y finalmente, 10.1.1.4.
La computadora de resolución de DNS sabrá que debe intentar usar la primera entrada,
10.1.1.1, pero conoce las cuatro en caso de que una conexión a 10.1.1.1 falle.
La siguiente computadora que realice una búsqueda
www.microsoft.com también recibirá las cuatro IP en la respuesta,
pero el ordenamiento habrá cambiado.
La primera entrada sería 10.1.1.2, seguida de 10.1.1.3,
10.1.1.4, y al final,
10.1.1.1 sería la última en esa lista.
Este patrón continuará para cada intento de resolución de DNS,
pasando por todos los registros A configurados
y equilibrando el tráfico a través de estas IP.
Ese es el fundamento del funcionamiento de la lógica del round robin de DNS.
Otro tipo de registro de recursos cada vez más y más popular es el registro Quad A.
Un registro Quad A es muy similar a un registro A,
salvo por que devuelve una dirección IPv6 en lugar de una dirección IPv4.
Veremos los detalles de IPv6 en un futuro módulo.
El registro CNAME también es muy común.
Un registro CNAME se usa para redirigir el tráfico de un dominio a otro.
Supongamos que Microsoft ejecuta sus servidores web en www.microsoft.com.
También quiere asegurarse de que cualquiera que escriba
solo "microsoft.com" en su navegador web será redirigido correctamente.
Al configurar un registro CNAME para microsoft.com que resuelve en
www.microsoft.com,
el cliente de resolución sabrá entonces realizar
otro intento de resolución, esta vez para www.microsoft.com,
y luego usar la IP devuelta por ese segundo intento.
Los CNAME son realmente útiles porque te garantizan
que apenas debes cambiar la dirección IP canónica de un servidor en un solo lugar.
De hecho, CNAME es una abreviatura de "nombre canónico".
Si volvemos a mirar nuestro ejemplo original de asegurarnos de que los visitantes
a los sitios microsoft.com y www.microsoft.com lleguen al mismo lugar,
podríamos hacerlo de dos maneras.
Podríamos configurar registros A idénticos para ambos nombres de dominio,
microsoft.com y www.microsoft.com,
y funcionaría bien.
Pero si la dirección IP subyacente cambia,
necesitamos cambiarla en dos lugares:
los registros A para microsoft.com y www.microsoft.com.
Al configurar un CNAME
que apunta microsoft.com hacia www.microsoft.com,
solo tendrías que cambiar el registro A para www.microsoft.com
y sabrías que los clientes que apuntan a cualquiera de los dominios obtendrían la nueva
dirección IP.
Esto puede no parecer un gran problema con solo dos registros para preocuparse,
pero las grandes empresas con presencias complejas en la Web
pueden tener docenas de este tipo de redireccionamientos.
Siempre es más fácil tener una sola fuente de información.
Otro tipo de registro de recursos importante es el registro MX.
MX significa intercambio de correo
y este registro de recursos se usa para entregar el correo electrónico al servidor correcto.
Muchas compañías ejecutan sus servidores web y de correo en diferentes máquinas con
diferentes IP,
por lo que el registro MX hace que sea fácil garantizar
que el correo electrónico se entregue al servidor de correo de una empresa
mientras que otro tipo de tráfico como el tráfico web se entregará a su servidor web.
Un tipo de registro muy similar al registro MX es el registro SRV.
SRV significa registro de servicio,
y se usa para definir la ubicación de varios servicios específicos.
Cumple la misma función que el tipo de registro de recursos MX, excepto por una cosa:
mientras que MX es solo para servicios de correo,
un registro SRV se puede definir para que devuelva los detalles de muchos tipos de
servicios diferentes.
Por ejemplo, los registros SRV se usan a menudo para devolver los registros de
servicios como CalDAV,
que cuenta con un servicio de calendario y programación.
El tipo de registro de texto es interesante.
TXT significa texto y originalmente su uso previsto era solamente
para asociar algún texto descriptivo con un nombre de dominio para consumo humano.
La idea era que
podrías dejar notas o mensajes que los humanos pudieran detectar
y leer para obtener más información sobre los detalles arbitrarios de tu red.
Pero con el correr de los años, a medida que Internet
y los servicios que se ejecutan allí se volvieron cada vez más complejos,
el registro de texto se usa cada vez más para transmitir
datos adicionales para que otras computadoras los procesen.
Como el registro de texto tiene un campo cuyo formato es completamente libre,
ingenieros inteligentes han descubierto maneras de usarlo para comunicar datos
que originalmente no se suponía que fueran comunicados por un sistema como DNS.
Es bastante inteligente, ¿verdad? Este registro de texto se utiliza a menudo para
comunicar
preferencias de configuración sobre los servicios de red
cuyo manejo confías a otras organizaciones para tu dominio.
Por ejemplo, es común que el registro de texto se use para transmitir
información adicional a un proveedor de correo electrónico como servicio,
que es una empresa que se encarga de la entrega de tu correo electrónico por ti.
Hay muchos otros tipos de registros de recursos DNS en uso común,
como los registros NS o SOA que se usan para definir la información de autoridad sobre
las zonas DNS.
Hablaremos de las zonas DNS con más detalle en un futuro video. No te lo pierdas.

Un nombre de dominio dado tiene tres partes principales

y todas ellas cumplen funciones específicas.
Tomemos el nombre de dominio www.google.com. Deberíamos poder detectar
fácilmente
las tres partes aquí ya que están separadas entre sí por un punto.
Son "www", "google" y "com".
A la última parte de un nombre de dominio se la conoce como TLD o dominio de nivel
superior.
En este caso es la parte ".com" del nombre de dominio.
Sólo hay un cierto número restringido de TLD definidos disponibles,
aunque ese número creció mucho en los últimos años.
Los TLD más comunes son aquellos con los que probablemente ya estás
familiarizado: .com, .net,
.edu y así sucesivamente.
Probablemente también has visto algunos TLD específicos de países, como .de para
Alemania
o .cn para China.
Debido al crecimiento de Internet,
muchos de los TLD que se definieron originalmente se volvieron muy concurridos.
Así que hoy, hay una serie de TLD personalizados disponibles,
desde ".museum" hasta ".pizza".
La administración y definición de los TLD la maneja una organización sin fines de lucro
conocida como ICANN, o Corporación de Internet
para la Asignación de Nombres y Números, y puedo contarte qué hace.
La ICANN es una organización asociada de la IANA y juntas ayudan a definir
y controlar los espacios IP globales junto con el sistema DNS global.
Un dominio es el nombre que se usa comúnmente para referirse a la segunda parte de un
nombre de dominio,
lo que sería "google" en nuestro ejemplo.
Los dominios se utilizan para demarcar dónde el control se mueve desde un servidor de
nombres TLD
a un servidor de nombres autoritativo.
Esto queda típicamente bajo el control de una organización independiente
o de alguien fuera de la ICANN.
Los dominios pueden ser registrados y elegidos por cualquier individuo o empresa,
pero todos deben terminar en uno de los TLD predefinidos.
La porción que contiene el "www" se conoce como subdominio,
a veces llamada nombre de host si se asignó a un solo host.
Al combinar todas estas partes,
tienes lo que se conoce como nombre de dominio completo o FQDN.
Si bien cuesta dinero registrar oficialmente un dominio con un registrador,
los subdominios pueden ser elegidos y asignados
libremente por cualquiera que controle dicho dominio registrado.
Un registrador es solo una empresa
que tiene un acuerdo con la ICANN para vender nombres de dominio no registrados.
Hablaremos más sobre tratar con registradores en un futuro módulo.
Técnicamente, puedes tener muchos nombres de subdominios,
por ejemplo, host.sub.sub.subdomain.domain.com puede ser completamente valido,
aunque rara vez verás nombres de dominio completos con tantos niveles.
DNS puede admitir técnicamente hasta 127 niveles
de dominio en total para un solo nombre de dominio completo.
Hay ciertas otras restricciones vigentes sobre cómo puedes especificar tu nombre de
dominio.
Cada sección individual solo puede tener 63 caracteres de largo
y un FQDN completo se limita a un total de 255 caracteres.
Hemos visto cómo los servidores de nombres autoritativos son responsables
de responder a las solicitudes de resolución de nombres para dominios específicos,
pero hacen más que eso.
Un servidor de nombres autoritativo es en verdad responsable de una zona DNS
específica.
Las zonas DNS son un concepto jerárquico.
Los servidores de nombres raíz que vimos anteriormente son responsables de la zona
raíz.
Cada servidor de nombres TLD es responsable de la zona que cubre su TLD específico,
y lo que llamamos servidores de nombres autoritativos
son responsables de algunas zonas subyacentes aún más detalladas.
Los servidores de nombres raíz y TLD también son en realidad servidores de nombres
autoritativos.
Es solo que las zonas para las que están acreditados son casos especiales.
Debo señalar que las zonas no se superponen.
Por ejemplo, la autoridad administrativa del servidor de nombres TLD
para el TLD ".com" no abarca el dominio google.com.
En cambio, finaliza en el servidor autoritativo responsable de google.com.
El propósito de las zonas DNS es permitir un control más sencillo sobre múltiples
niveles de un dominio.
A medida que aumenta el número de registros de recursos en un solo dominio,
se vuelve un dolor de cabeza administrarlos a todos.
Los administradores de red pueden aliviar este dolor
dividiendo sus configuraciones en múltiples zonas.
Imaginemos una gran empresa propietaria del dominio largecompany.com.
Esta empresa tiene oficinas en Los Ángeles,
París y Shanghái, muy cosmopolita.
Digamos que cada oficina tiene alrededor de 200 personas
con su propio equipo de escritorio con un nombre único.
Estos serían 600 registros A para rastrear si todo estuviera configurado como una sola
zona.
Lo que la empresa podría hacer, en cambio,
es dividir cada oficina en su propia zona.
Ahora, podríamos tener la.largecompany.com,
pa.largecompany.com y sh.largecompany.com como subdominios,
cada uno con sus propias zonas DNS.
Ahora se necesitaría un total de cuatro servidores de nombres autoritativos para la
configuración,
uno para largecompany.com y uno para cada uno de los subdominios.
Las zonas se configuran a través de lo que se conoce como archivos de zona,
archivos de configuración simple que declaran todos los registros de recursos para una
zona en particular.
Así que un archivo de zona tiene que contener una SOA,
o declaración de registro de recursos de inicio de autoridad.
Este registro SOA declara la zona
y el nombre del servidor de nombres que tiene autoridad en ella.
Junto con el registro SOA,
por lo general encontrarás registros NS que indican
otros servidores de nombres que también pueden ser responsables de esta zona.
Para simplificar, nos hemos referido a "servidor" en singular
al analizar lo que es responsable de su zona, ya sea a nivel de raíz,
TLD o dominio,
pero a menudo van a haber
múltiples servidores físicos con sus propios FQDN y direcciones IP involucradas.
Tener varios servidores implementados para algo tan importante como DNS es bastante
común.
¿Por qué? Bueno, si un servidor tuviera un problema o sufriera una falla de hardware,
siempre puede confiar en uno de los otros para entregar el tráfico DNS.
Además de los registros SOA y NS,
también encontrarás algunos o todos
los demás tipos de registro de recursos que ya hemos visto, como A,
Quad A y CNAME, junto con configuraciones
como valores TTL predeterminados para los registros entregados por esta zona.
Así como los subdominios pueden tener muchas, muchas capas de profundidad,
las zonas también se pueden configurar para hacer esto,
pero al igual que con los subdominios,
es raro ver zonas que vayan más allá de unos pocos niveles.
A veces, también verás lo que se conoce como archivos de zona de búsqueda inversa.
Estos permiten a los agentes de resolución de DNS solicitar una IP
y obtener el FQDN asociado a ella.
Estos archivos son los mismos que los archivos de zona,
salvo que en lugar de los registros A y Quad A,
que resuelven nombres a direcciones IP,
encontrarás principalmente declaraciones de registro de recursos de puntero.
Como supones, un PTR
o registro de puntero, resuelve una IP a un nombre.
A continuación, un cuestionario dinámico para ti,
antes de una nueva lección dinámica sobre el Protocolo de configuración dinámica de
host. Nos vemos.

Resolución de nombres en la práctica

Puntos totales 4

1.

Pregunta 1

¿Qué contiene un registro A?

1 / 1 punto

Un CNAME

Una dirección IPv4

Una dirección IPv6

Un nombre de dominio completamente calificado

Correcto

¡Sí! Un registro A contiene una dirección IPv4.

2.

Pregunta 2

Selecciona todas las opciones que sean verdaderas.

1 / 1 punto

Un nombre de dominio puede apuntar a una dirección IP.

Correcto

¡Acertaste! Esta es una configuración de DNS válida.

Un nombre de dominio puede apuntar a muchas direcciones IP.

Correcto

¡Acertaste! Esta es una configuración de DNS válida.

Muchos nombres de dominio pueden apuntar a la misma dirección IP.

Correcto

¡Acertaste! Esta es una configuración de DNS válida.

3.

Pregunta 3

MX significa ______.

1 / 1 punto

micro extremo

micro intercambio

intercambio de correo

intercambio de meta

Correcto

¡Correcto! Un registro MX almacena la dirección IP de un servidor de correo.

4.

Pregunta 4

¿Cuántos caracteres puede contener un nombre de dominio completo?

1 / 1 punto

63

64

127

255

Correcto

¡Lo lograste! Un FQDN está limitado a una longitud total de 255 caracteres.

La gestión de hosts en una red puede ser una tarea desalentadora y lenta.
Cada computadora en una red moderna basada en TCP/IP
necesita tener al menos cuatro cosas configuradas específicamente.
Una dirección IP, la máscara de subred
para la red local, una puerta de enlace principal y un servidor de nombres.
Por sí solas, estas cuatro cosas no parecen ser mucho, pero cuando las tienes que
configurar
en cientos de maquinas, se vuelve super tedioso.
De estas cuatro cosas, tres son probablemente lo mismo en casi todos los nodos en la
red:
la máscara de subred, la puerta de enlace principal y el servidor DNS.
Pero el último elemento, una dirección IP,
debe ser diferente en cada nodo único en la red.
Eso podría requerir gran cantidad de trabajo de configuración complicado;
es aquí donde DHCP, o Protocolo de configuración dinámica de hosts, entra en juego.
Pon atención porque es crucial que un especialista de soporte de TI conozca DHCP
cuando se trata de solucionar problemas de redes.
DHCP es un protocolo de capa de aplicación
que automatiza el proceso de configuración de hosts en una red.
Con DHCP, una máquina puede consultar un servidor DHCP cuando la computadora
se conecta a la red y recibe toda la configuración de la red de una sola vez.
DHCP no solo reduce la sobrecarga administrativa
de tener que configurar muchos dispositivos de red en una sola red, también permite
abordar
el problema de tener que elegir qué IP asignar a qué máquina.
Cada computadora en una red requiere una IP para comunicaciones,
pero muy pocas de ellas requieren una IP comúnmente conocida.
Para los servidores o equipos de red en tu red,
como tu router de puerta de enlace, una dirección IP estática y conocida, es bastante
importante.
Por ejemplo, los dispositivos en una red necesitan conocer la IP de su puerta de enlace
todo el tiempo.
Si el servidor DNS local funcionara mal, los administradores de red
aun así necesitarían una forma de conectarse a algunos de estos dispositivos a través de
su IP.
Sin una IP estática configurada para un servidor DNS,
sería difícil conectarse a él para diagnosticar cualquier problema en caso de mal
funcionamiento.
Pero para un montón de dispositivos cliente como equipos de escritorio o laptops,
o incluso teléfonos móviles, solo importa que tengan una IP en la red correcta.
Importa mucho menos exactamente cuál es esa IP.
Con DHCP, puedes configurar un rango de direcciones IP que están reservadas
para estos dispositivos cliente.
Esto asegura que cualquiera de estos dispositivos pueda obtener una dirección IP
cuando la necesite,
y resuelve el problema de tener que mantener una lista
de cada nodo en la red y su correspondiente IP.
DHCP puede operar en unas pocas formas estándar.
La asignación dinámica de DHCP es la más común
y funciona como la acabamos de describir.
Se reserva un rango de direcciones IP para dispositivos cliente
y una de estas IP se libera a estos dispositivos cuando lo solicitan.
Bajo una asignación dinámica, la IP de una computadora podría ser diferente
casi todas las veces que se conecta a la red.
La asignación automática es muy similar a la asignación dinámica
en cuanto a que se reserva un rango de direcciones IP a fines de asignación.
La principal diferencia aquí es que al servidor DHCP
se le pide que rastree qué direcciones IP se asignaron a ciertos dispositivos en el pasado.
Con esta información,
el servidor DHCP asignará la misma IP a la misma máquina cada vez, si es posible.
Por último, está lo que se conoce como asignación fija.
La asignación fija requiere una lista manualmente especificada de direcciones MAC
y sus direcciones IP correspondientes.
Cuando una computadora solicita una IP, el servidor DHCP busca
su dirección MAC en una tabla y asigna la IP que corresponde a esa dirección MAC.
Si no se encuentra la dirección MAC, el servidor DHCP puede recurrir a la asignación
dinámica o automática, o se podría negar a asignar una IP por completo.
Esto puede usarse como medida de seguridad para asegurar que sólo los dispositivos
cuyas direcciones MAC se configuraron específicamente en el servidor DHCP
puedan obtener una dirección IP y comunicarse en la red.
Vale la pena decir que la detección DHCP
puede usarse para configurar muchas cosas más allá de lo que mencionamos aquí.
Junto con cosas como la dirección IP
y la puerta de enlace primaria, también puedes usar DHCP para asignar cosas como
servidores NTP.
NTP significa Protocolo de tiempo de red
y se usa para mantener todas las computadoras en una red sincronizadas en tiempo.
Lo veremos en más detalle en cursos posteriores.
Pero por ahora, solo vale la pena señalar que DHCP puede usarse
para mucho más que solo IP, máscara de subred, puerta de enlace y servidor DNS.

DHCP es un protocolo de capa de aplicación, lo que significa que se basa en las capas
de transporte,
red, enlace de datos y capas físicas para funcionar.
Pero te habrás dado cuenta de que la finalidad de DHCP
es ayudar a configurar la capa de red en sí.
Veamos exactamente cómo funciona DHCP
y cómo logra las comunicaciones sin una configuración de capa de red implementada.
Advertencia, se avecinan cosas de cerebritos.
El proceso por el cual un cliente configurado para usar DHCP
intenta obtener información de la configuración de red se conoce como detección
DHCP.
El proceso de detección DHCP tiene cuatro pasos.
Primero, tenemos el paso de detección del servidor.
Los clientes DHCP envían lo que se conoce como un mensaje de detección DHCP
a la red.
Como la máquina no tiene una IP y no conoce la IP del servidor DHCP,
se forma, en su lugar, un mensaje de difusión especialmente diseñado.
DHCP escucha en el puerto UDP 67
y los mensajes de detección DHCP siempre se envían desde el puerto UDP 68.
Así que el mensaje DHCPDISCOVER se encapsula en un datagrama UDP
con un puerto de destino de 67 y un puerto de origen de 68.
Esto, luego, se encapsula dentro de un datagrama IP
con una IP de destino de 255.255.255.255,
y una IP de origen de 0.0.0.0.
Este mensaje de difusión se entregará a cada nodo en la red de área local.
Y si hay un servidor DHCP presente, recibirá este mensaje.
A continuación, el servidor DHCP examinará su propia configuración
y tomará una decisión sobre qué dirección IP ofrecer al cliente, si es que hay alguna.
Esto dependerá de si está configurado para funcionar con asignación de direcciones
dinámica, automática o fija.
La respuesta se enviará como un mensaje DHCPOFFER con un puerto de destino de 68,
un puerto fuente de 67, una IP de difusión de destino
de 255.255.255.255 y su IP real como la fuente.
Como DHCPOFFER es también una difusión,
llegará a cada máquina en la red.
El cliente original reconocerá que este mensaje estaba destinado a sí mismo.
Esto es porque DHCPOFFER tiene el campo que especifica la dirección MAC del
cliente
que envió el mensaje DHCPDISCOVER.
La máquina cliente ahora procesará este DHCPOFFER
para ver qué dirección IP se le ofrece.
Técnicamente, un cliente DHCP podría rechazar esta oferta.
Es totalmente posible
que múltiples servidores DHCP se ejecuten en la misma red y que un cliente DHCP
esté configurado solo para responder a una oferta de un IP dentro de un cierto rango.
Pero esto no es frecuente.
Más a menudo, el cliente DHCP responderá
al mensaje DHCPOFFER con un mensaje DHCPREQUEST.
Este mensaje dice esencialmente: "Sí,
me gustaría tener una de las IP que me ofreces".
Como la IP no se asignó todavía,
esto se envía de nuevo desde una IP de 0.0.0.0
a la IP de difusión 255.255.255.255.
Por último, el servidor DHCP recibe el mensaje DHCPREQUEST
y responde con un DHCPACK o mensaje de acuse de recibo de DHCP.
Este mensaje se envía de nuevo a una IP de difusión 255.255.255.255,
y con una IP de origen correspondiente a la IP real del servidor DHCP.
Una vez más, el cliente DHCP reconocerá que este mensaje estaba destinado
a sí mismo porque tenía incluida su dirección MAC en uno de los campos.
Ahora, la pila de redes en la computadora cliente
puede usar la información de configuración que el servidor DHCP le presentó
para establecer su propia configuración de capa de red.
En este punto,
la computadora que actúa como cliente DHCP debería tener toda la información
que necesita para funcionar por completo en la red a la que está conectada.
Toda esta configuración se conoce como concesión DHCP ya que incluye un tiempo de
expiración.
Una concesión DHCP puede durar días o solo un corto período de tiempo.
Una vez que la concesión expire, el cliente DHCP tendrá que negociar una nueva.
Para ello, debe volver a realizar todo el proceso de detección DHCP.
Un cliente también puede liberar su concesión al servidor DHCP,
lo que hará cuando se desconecte de la red.
Esto permitirá que el servidor DHCP devuelva la dirección IP
que había sido asignada a su conjunto de direcciones IP disponibles.
Ya viste DHCP en acción. Ahora, tenemos un breve cuestionario para ti.
Cuando hayas terminado, será momento de aprender los fundamentos de NAT.

Hola de nuevo. ¿Todo listo para meternos de lleno en esto?

A diferencia de los protocolos como DNS y DHCP,
la traducción de direcciones de red, o NAT, es más una técnica que un estándar
definido.
Esto significa que algo de lo que analizaremos
en esta lección puede tener un nivel superior que algunos de nuestros otros temas.
Diferentes sistemas operativos
y diferentes proveedores de hardware de red han implementado los detalles de NAT de
diferentes maneras.
Pero los conceptos de lo que logra son bastante constantes.
La traducción de direcciones de red hace más o menos lo que parece.
Toma una dirección IP y la traduce en otra.
Hay muchas razones por las que querríamos hacer esto.
Van desde salvaguardas de seguridad
a preservar las cantidades limitadas de espacio disponible de IPV4.
Vamos a discutir las implicaciones de NAT
y la IP antes del espacio de direcciones más adelante en esta lección.
Pero por ahora vamos a concentrarnos en cómo funciona NAT en sí
y cómo puede proporcionar medidas de seguridad adicionales a una red.
En su nivel más básico,
NAT es una tecnología que permite que una puerta de enlace, por lo general un router o
un firewall,
reescriban la IP de origen de un datagrama IP saliente
al tiempo que mantienen la IP original para reescribirla en la respuesta.
Para explicar esto mejor,
veamos un ejemplo simple de NAT.
Supongamos que tenemos dos redes,
la red A consiste en el espacio de direcciones 10.1.1.0/24
y la red B consiste
en el espacio de direcciones 192.168.1.0/24.
Entre estas redes hay un router
que tiene una interfaz en la red A
cuya IP es 10.1.1.1 y una interfaz en la red B cuya IP es 192.168.1.1.
Ahora pongamos dos computadoras en estas redes.
La computadora 1 está en la red A,
y tiene una IP de 10.1.1.100; la computadora 2
está en la red B y tiene una IP de 192.168.1.100.
La computadora 1 quiere comunicarse con un servidor web en la computadora 2.
Entonces crea el paquete apropiado en todas las capas y lo envía a su puerta de enlace
principal:
el router ubicado entre las dos redes.
Hasta aquí, esto es muy parecido a muchos de nuestros ejemplos anteriores,
pero en este caso, el router está configurado para realizar NAT para cualquier paquete
saliente.
Normalmente, un router inspeccionará el contenido de un datagrama IP,
disminuirá el TTL en 1,
recalculará la suma de verificación
y reenviará el resto de los datos en la capa de red sin tocarlos.
Pero con NAT, el router también reescribirá la dirección IP de origen,
que en este caso se convierte en la IP del router en la red B
o 192.168. 1.1. Cuando el datagrama llega a la computadora 2,
parecerá que se originó en el router, no en la computadora 1.
Ahora la computadora 2 elabora su respuesta y la envía de regreso al router.
El router, a sabiendas de que este tráfico está realmente destinado a la computadora 1,
reescribe el campo IP de destino antes de reenviarlo.
Lo que hace NAT en este ejemplo es ocultarle a la computadora 2 la IP de la
computadora 1.
Esto se conoce como enmascaramiento de IP.
El enmascaramiento de IP es un importante concepto de seguridad.
El concepto más básico en juego aquí
es que nadie puede establecer una conexión
con tu computadora si no sabe qué dirección IP tiene.
Al usar NAT en la forma que acabamos de describir,
de hecho, podríamos tener cientos de computadoras en la red A,
con todas sus direcciones IP traducidas por el router a su propia IP.
Para el mundo exterior,
todo el espacio de direcciones de la red A está protegido y es invisible.
Esto se conoce como "NAT uno a muchos",
y lo verás en uso en muchas LAN en la actualidad.

NAT en la capa de red es bastante fácil de entender.

Un dispositivo, generalmente un router, traduce una dirección IP en otra.
Pero en la capa de transporte, las cosas se complican un poco más
y varias técnicas adicionales entran en juego para asegurarse de que todo funcione
correctamente.
En NAT uno a muchos
hablamos de cómo cientos, incluso miles de computadoras pueden tener
su tráfico saliente traducido mediante NAT a una sola IP.
Esto es bastante fácil de entender cuando el tráfico es saliente,
pero un poco más complicado cuando involucra al tráfico de retorno.
Ahora tenemos, potencialmente, cientos de respuestas dirigidas
a la misma IP, y el router en esta IP
necesita determinar qué respuestas van a qué computadora.
La forma más sencilla de hacer esto
es a través de la conservación de puertos.
La conservación de puertos es una técnica en la que el puerto de origen elegido por un
cliente
es el mismo puerto que usa el router.
Recuerda que las conexiones salientes eligen un puerto de origen al azar
de entre los puertos efímeros o los puertos en el rango de 49,152 a 65,535.
En la configuración más sencilla,
una configuración de router para tráfico saliente NAT,
solo controlaremos qué puerto de origen es este
y lo usaremos para dirigir el tráfico de regreso a la computadora correcta.
Imaginemos un dispositivo con una IP de 10.1.1.100.
Quiere establecer una conexión saliente y la pila de redes del SO
elige el puerto 51,300 para esta conexión.
Una vez que esta conexión saliente llega al router,
realiza la traducción de direcciones de red
y coloca su propia IP en el campo de dirección de origen del datagrama IP,
pero no cambia el puerto de origen en el datagrama TCP
y almacena estos datos internamente en una tabla.
Ahora, cuando el tráfico regresa al router y al puerto 51,300,
sabe que este tráfico debe reenviarse a la IP 10.1.1.100.
A pesar del tamaño del conjunto de puertos efímeros,
todavía es posible que dos computadoras diferentes en una red
elijan el mismo puerto de origen al mismo tiempo.
Cuando esto sucede, por lo general el router selecciona un puerto no utilizado al azar
para usar en su lugar.
Otro concepto importante sobre NAT y la capa de transporte es la redirección de
puertos.
La redirección de puertos es una técnica
en la que puertos específicos de destino se pueden configurar para que siempre se
entreguen a nodos específicos.
Esta técnica permite un enmascaramiento completo de IP
sin dejar de tener servicios que puedan responder al tráfico entrante.
Usemos nuestra red 10.1.1.0/24 nuevamente para demostrar esto.
Supongamos que hay un servidor web configurado con una IP de 10.1.1.5.
Con la redirección de puertos, nadie tendría que conocerla.
Los posibles clientes web solo tendrían que conocer la IP externa del enrutador.
Supongamos que es 192.168.1.1.
Cualquier tráfico dirigido al puerto 80 en 192.168.1.1
se reenviaría automáticamente a 10.1.1.5.
El tráfico de respuesta tendría la IP de origen reescrita
para que se parezca a la IP externa del router.
Esta técnica no solo permite el enmascaramiento IP,
sino también simplifica la interacción de los usuarios externos
con una gran cantidad de servicios ejecutados por la misma organización.
Imaginemos una empresa con un servidor web y un servidor de correo;
ambos necesitan ser accesibles al mundo exterior,
pero se ejecutan en diferentes servidores con diferentes IP.
Una vez más, digamos que el servidor web tiene una IP de 10.1.1.5,
y el servidor de correo tiene una IP de 10.1.1.6.
Con la redirección de puertos, el tráfico para cualquiera de estos servicios podría
dirigirse
a la misma IP externa y, por lo tanto, al mismo nombre DNS,
pero se entregaría
a servidores internos completamente diferentes debido a sus diferentes puertos de
destino.

La IANA ha estado a cargo de distribuir direcciones IP desde 1988.

Desde entonces, Internet se ha expandido a un ritmo increíble.
Se predijo que los 4,200 millones de direcciones IPv4 posibles se agotarán
en el largo plazo y ya casi están agotadas.
Desde hace algún tiempo, la IANA ha sido la principal responsable de asignar bloques
de direcciones
a cinco registros regionales de Internet, o RIR.
Los cinco RIR son AFRINIC, que sirve al continente africano,
ARIN que sirve a los Estados Unidos, Canadá y partes del Caribe.
APNIC, que es responsable
de la mayor parte de Asia, Australia, Nueva Zelanda y las naciones isleñas del Pacífico.
LACNIC que abarca América Central y del Sur
y las partes del Caribe fuera de la cobertura de ARIN.
Y finalmente RIPE, que sirve a Europa, Rusia,
Oriente Medio y porciones de Asia Central.
Estos cinco RIR han sido responsables de asignar bloques de direcciones IP
a organizaciones dentro de sus áreas geográficas, y la mayoría ya se agotaron.
La IANA asignó los últimos dos bloques de direcciones de red /8 no asignados
a varias RIR el 3 de febrero de 2011.
Luego, en abril de 2011, APNIC se quedó sin direcciones.
RIPE fue la siguiente, en septiembre de 2012.
LACNIC se quedó sin direcciones para asignar en junio de 2014.
Y a ARIN le ocurrió lo mismo en septiembre de 2015.
Solo a AFNIC le quedan algunas IP, pero se prevé que se agotarán en 2018.
Wikipedia tiene un gran artículo sobre el agotamiento de IPv4
y los plazos correspondientes.
Agregué un enlace a él en la lectura que viene justo después de este video.
Esto es, por supuesto, una gran crisis para Internet.
Con el tiempo, IPv6 resolverá estos problemas.
Vamos a verlo con más detalle más adelante en este curso.
Pero la implementación de IPv6 en todo el mundo va a llevar algún tiempo
Por ahora, queríamos seguir creciendo y queremos que más personas y dispositivos
se conecten a Internet, pero sin direcciones IP para asignar, se necesita una solución.
Alerta de spoiler: ya conoces los componentes principales de esta solución:
NAT y el espacio de direcciones no enrutables.
Recuerda que el espacio de direcciones no enrutables se definió en RFC 1918
y consta de varios rangos IP diferentes que cualquiera puede usar.
Y un número ilimitado de redes puede usar el espacio de direcciones no enrutables
internamente
porque los routers de Internet no le reenviarán tráfico.
Esto significa que nunca hay colisión global de direcciones IP
cuando la gente usa esos espacios de direcciones.
Hoy, el espacio de direcciones no enrutables es utilizable en gran medida
gracias a tecnologías como NAT.
Con NAT,
puedes tener cientos, incluso miles de máquinas que utilicen el espacio de direcciones
no enrutables.
Sin embargo, con una sola IP pública,
todas esas computadoras pueden seguir enviando y recibiendo tráfico de Internet.
Todo lo que necesitas es una sola dirección IPv4 y, mediante NAT,
un router con esa IP puede representar muchísimas computadoras detrás de sí.
No es una solución perfecta, pero hasta que IPv6 se vuelva más disponible a nivel
global,
nos alcanzará con el espacio de direcciones no enrutables y NAT.

1.

Pregunta 1

Las direcciones NAT se ocupan de la disminución de espacio de direcciones direcciones

IPv4 al ___________________.

1 / 1 punto

permitir que las redes usen menos direcciones IP en general.

permitir que los usuarios cambien a IPv6 cuando quieran.

permitir que las computadoras que usan un espacio de direcciones no enrutables se

comuniquen con Internet.

realizar enmascaramiento de IP.

Correcto

¡Buen trabajo! NAT permite a las redes utilizar un espacio de direcciones no enrutables
para sus dispositivos internos.

3.

Pregunta 3

El número total aproximado de direcciones IPv4 es:

1 / 1 punto

4.2 millones

4,200 millones

4.2 billones

Incontable

Correcto

¡Correcto! Hay aproximadamente 4,200 millones de direcciones IPv4. ¡Increíble!

2.

Pregunta 2
¿Qué técnica permite el tráfico entrante a través de una NAT?

1 / 1 punto

Conservación de puertos

Redirección de puertos

Autoridad portuaria

Puertos efímeros

Correcto

¡Exacto! La redirección de puertos es una técnica que permite el tráfico entrante a través
de un enrutador configurado con NAT.

Las empresas tienen muchas razones para querer mantener la seguridad de su red.
Y lo hacen aplicando algunas de las tecnologías que ya analizamos.
Firewalls, NAT, el uso de espacio de direcciones no enrutables, cosas como esas.
Las organizaciones a menudo tienen información patentada que necesita mantenerse
segura.
Servicios de red que solo están destinados al acceso de los empleados y otras cosas.
Una de las maneras más fáciles de mantener las redes seguras es usar varias tecnologías
de seguridad,
para que solo los dispositivos conectados físicamente a tu red de área local
puedan acceder a estos recursos.
Pero los empleados no siempre están en la oficina.
Podrían estar trabajando desde su casa
o en un viaje de negocios
y es posible que aun así necesiten acceso a estos recursos para hacer su trabajo.
Ahí es donde entran las VPN.
Las redes privadas virtuales, o VPN,
son una tecnología que permite ampliar una red privada o local
a un host que podría no funcionar en esa misma red local.
Las VPN son muy variadas y logran muchas cosas diferentes.
Pero el ejemplo más común de cómo se usan las VPN
es para que los empleados accedan a su red empresarial cuando no están en la oficina.
Las VPN son un protocolo de túneles.
Eso significa que proporcionan acceso a algo que no está disponible localmente.
Al establecer una conexión VPN,
también podría decirse que se estableció un túnel VPN.
Volvamos al ejemplo de un empleado que necesita
acceder a los recursos de la empresa mientras no está en la oficina.
El empleado podría usar un cliente VPN para establecer un túnel VPN a la red de su
compañía.
Esto le proporcionaría a su computadora lo que se conoce como una interfaz virtual,
con una IP que coincide
con el espacio de direcciones de la red que con la que estableció una conexión VPN.
Al enviar datos fuera de esta interfaz virtual,
la computadora podría acceder a recursos internos
al igual que si estuviera físicamente conectada a la red privada.
La mayoría de las VPN funcionan usando la sección de carga útil de la capa de
transporte
para llevar una carga útil cifrada que contiene un segundo conjunto completo de
paquetes:
las capas de red, transporte
y aplicación de un paquete destinado a atravesar la red remota.
Básicamente, esta carga útil se lleva al punto terminal de las VPN
donde todas las otras capas se eliminan y se desechan.
Entonces, se quita el cifrado a la carga útil
y el servidor VPN queda con las tres capas superiores de un nuevo paquete.
Esto se encapsula con la información adecuada de la capa de enlace de datos
y se envía por la red.
Este proceso se completa a la inversa,
en la dirección opuesta.
Las VPN, por lo general, exigen procedimientos de autenticación estrictos para
garantizar
que solo computadoras y usuarios autorizados puedan conectarse a ellas.
De hecho, las VPN fueron
una de las primeras tecnologías en las que se hizo común la autenticación de dos
factores.
La autenticación de dos factores es una técnica
que requiere más que un nombre de usuario y una contraseña para autenticar.
Por lo general, el usuario genera un token numérico
de corta duración por medio de un hardware o software especializado.
Las VPN también se pueden utilizar para establecer la conectividad de sitio a sitio.
Conceptualmente, no hay mucha diferencia
entre cómo funciona esto en comparación con una situación de empleado remoto.
Aquí, simplemente el router,
o a veces un dispositivo VPN especializado en una red,
establece el túnel VPN al router o dispositivo VPN en otra red.
De esta manera, dos oficinas físicamente separadas podrían actuar
como una red y acceder a los recursos de la red a través del túnel.
Es importante señalar que al igual que NAT,
VPN es un concepto general de tecnología,
no es un protocolo estrictamente definido.
Hay muchas implementaciones exclusivas de VPN
y los detalles de cómo funcionan pueden diferir muchísimo.
Lo más importante es que las VPN son una tecnología que utiliza
túneles cifrados para permitir que una computadora o red remota
actúen como si estuvieran conectadas a una red a la que no están conectadas
físicamente.

Un servicio proxy es un servidor que actúa en nombre de un cliente

con el fin de acceder a otro servicio.
Los proxies se ubican entre los clientes
y otros servidores, y proporcionan ciertos beneficios adicionales: anonimato,
seguridad, filtrado de contenidos, mayor desempeño, un par de otras cosas.
Si algo de esto suena familiar, eso es bueno.
Ya hemos visto algunos ejemplos específicos de proxies, como routers de puerta de
enlace.
No escucharás que los mencionen de esta manera,
pero una puerta de enlace definitivamente cumple con la definición y el funcionamiento
de un proxy.
El concepto de proxy es solo eso, un concepto o una abstracción.
No se refiere a ninguna implementación específica.
Los proxies existen en casi todas las capas de nuestro modelo de red.
Hay docenas y docenas de ejemplos de proxies que podrías encontrar en tu carrera,
pero aquí vamos a ver sólo algunos de los más comunes.
Muy a menudo, oirás el término proxy, que se utiliza para referirse a proxies web.
Como podrás imaginar, estos son proxies específicamente construidos para el tráfico
web.
Un proxy web puede cumplir con muchas funciones.
Hace muchos años, cuando la mayoría de las conexiones de Internet eran mucho más
lentas
de lo que son hoy, muchas organizaciones usaban proxies web para mayor desempeño.
Con un proxy web,
una organización dirigiría todo el tráfico web a través de él, lo que le permite en sí
recuperar realmente los datos de la página web desde Internet.
Luego, almacenará estos datos en caché.
De esta manera, si alguien más solicita la misma página web, simplemente podría
devolver
los datos guardados en el caché en lugar de tener que recuperar una copia nueva cada
vez.
Este tipo de proxy es bastante antiguo y no sueles encontrarlos en uso hoy en día. ¿Por
qué?
Bueno, en primer lugar, la mayoría de las organizaciones ahora tienen conexiones
suficientemente rápidas, por lo que guardar páginas web individuales en caché no ofrece
gran beneficio.
Además, la web se volvió mucho más dinámica.
Ir a www.twitter.com va a ser diferente para cada persona
con su propia cuenta de Twitter, por lo que almacenar en caché estos datos no sirve de
mucho.
Un uso más común de un proxy web hoy en día
podría ser para evitar que alguien acceda por completo a sitios como Twitter.
Una empresa podría decidir que acceder a Twitter durante las horas de trabajo
reduce la productividad.
Con un proxy web, puede dirigir todo el tráfico web a él,
permitir que el proxy inspeccione qué datos se solicitan, y luego permitir
o rechazar esta solicitud según el sitio al que se quiera acceder.
Otro ejemplo de proxy es un proxy inverso.
Un proxy inverso es un servicio que a los clientes externos
puede parecerles un solo servidor, pero en realidad representa a muchos servidores
detrás de él.
Un buen ejemplo de esto es la arquitectura de muchos de los sitios web populares de
hoy.
Sitios web muy populares, como Twitter, reciben tanto tráfico
que no hay forma en que un solo servidor web pueda posiblemente manejarlo todo.
Un sitio web así de popular podría necesitar muchos,
muchos servidores web para no atrasarse con el procesamiento de todas las solicitudes
entrantes.
Un proxy inverso, en esta situación, podría actuar como un único frontend
para muchos servidores web ubicados detrás de él.
Desde la perspectiva de los clientes,
parece que todos están conectados al mismo servidor.
Pero detrás de escena, este servidor proxy inverso, en realidad,
está distribuyendo estas solicitudes entrantes a muchos servidores físicos diferentes.
Al igual que en el concepto de round robin de DNS, esta es una forma de equilibrio de
carga.
Otra forma en que los sitios web populares usan comúnmente los proxies inversos
es manejar la desencriptación.
Más de la mitad de todo el tráfico en la web ahora está encriptado, y encriptar
y desencriptar datos es un proceso que puede requerir mucha potencia de
procesamiento.
Aprenderás mucho más sobre la encriptación
y cómo funciona en otro curso en este programa.
Los proxies inversos ahora se implementan para utilizar
hardware compilado específicamente para criptografía con el objeto de hacer tareas de
encriptación y desencriptación.
Así, los servidores web están libres para entregar contenido.
Hay gran variedad de proxies, son demasiados para que los veamos todos aquí.
Pero lo más importante es entender que un servidor proxy es cualquier servidor
que actúe como intermediario entre un cliente y otro servidor.
Buen trabajo, hemos visto muchos temas.
Descansa un poco antes de pasar al cuestionario
y al proyecto que preparamos para ti.
Cuando termines con todo, toma otro descanso y luego nos encontramos aquí
para el siguiente módulo, en el que hablaremos de la historia de las conexiones a
Internet. a congestión o la salud del enlacede forma

2.

Pregunta 2

DNS significa ______.

1 / 1 punto
no señalizar

sistema de nombres de dominio

servidor de nombres dinámico

sistema de nomenclatura diversificada

Correcto

¡SÍ! DNS significa sistema de nombres de dominio.

3.

Pregunta 3

Hay 13 servidores de nombres _____.

1 / 1 punto

raíz

recursivos

autoritativos

TLD

Correcto

¡Acertaste! Hay 13 servidores de nombres raíz.

4.

Pregunta 4

Una técnica que se utiliza para enrutar el tráfico a diferentes destinos, dependiendo de
factores tales como la ubicación, la congestión o la salud del enlace, se conoce como
_____.

1 / 1 punto

unidifusión

anycast

multidifusión

difusión

Correcto

¡Acertaste! Anycast te permite enrutar el tráfico en función de muchos factores.

5.

Pregunta 5

TLD significa ______.

1 / 1 punto

destino de marea bloqueado

dominio de nivel de tipo

dominio de nivel superior

dominio de aspecto típico

Correcto

¡Buen trabajo! Un TLD es la última parte de un FQDN.

6.

Pregunta 6

Un concepto que implica iterar una lista de elementos, uno por uno de forma ordenada,
se conoce como _______.

1 / 1 punto

round robin

recursividad

búsqueda autoritativa

multiplexación

Correcto

¡Buen trabajo! Round robin asegura una distribución bastante equitativa entre sus
miembros.

7.

Pregunta 7

Un registro DNS que se utiliza para redirigir el tráfico de un nombre de dominio a otro
se conoce como registro _______.

1 / 1 punto
SOA

CNAME

NS

Quad A

Correcto

¡Correcto! Un CNAME redirige un intento de resolución de DNS de un nombre de

dominio a otro.

8.

Pregunta 8

La administración y la definición de los TLD están a cargo de una organización sin

fines de lucro conocida como ______.

1 / 1 punto

ICANN

FQDN

DHCP

CNAME

Correcto
¡Muy bien! ICANN es responsable de mantener el sistema global de nombres de
dominio.

9.

Pregunta 9

Un registro _______ es responsable de resolver una dirección IP a un nombre de

dominio.

1 / 1 punto

CNAME

PTR

NTP

TXT

Correcto

¡Lo lograste! Los registros PTR operan como el inverso de un registro A.

10.

Pregunta 10

Junto con una dirección IP, una máscara de subred y un servidor de nombres, la otra
cosa que se requiere para que una computadora funcione en una red es un(a) _______.

1 / 1 punto

proxy

puerta de enlace
servidor NTP

FQDN

Correcto

¡Increíble! Cada dispositivo en red necesita una puerta de enlace para saber dónde
enviar datos destinados al exterior del segmento de la red local.

11.

Pregunta 11

El proceso en el que se reserva un rango de direcciones IP para dispositivos cliente y

una de dichas direcciones IP se asigna estos dispositivos cuando la solicitan se conoce
como asignación _______.

1 / 1 punto

automática

dinámica

fija

Correcto

¡Buen trabajo! El DHCP de asignación dinámica asigna una dirección IP aleatoria de

una reserva de direcciones IP a un dispositivo que la necesite.

12.

Pregunta 12

El paso final del proceso de detección DHCP se conoce como ______.

1 / 1 punto
DHCPACK

DHCPOFFER

DHCPDISCOVER

DHCPREQUEST

Correcto

¡Acertaste! Un DHCPACK es el paso final en el proceso de detección DHCP.

13.

Pregunta 13

NAT significa ______.

1 / 1 punto

traducción académica nacional

equipo de la asociación de redes

traducción de direcciones de red

guía de reconocimiento de red

Correcto
¡Bien hecho! NAT, o traducción de direcciones de red, permite que un dispositivo
reescriba la dirección IP de origen en un paquete.

14.

Pregunta 14

Cuando NAT oculta la IP de origen de un dispositivo de origen, esto se conoce como

________.

1 / 1 punto

enrutamiento de puerto

enrutamiento

conmutación

enmascaramiento de IP

Correcto

¡Correcto! Enmascaramiento de IP significa que el destino nunca conocerá la dirección

IP real del origen.

15.

Pregunta 15

Un servicio que puede parecer un solo servidor para clientes externos, pero que en
realidad representa a muchos servidores que residen detrás de él, se conoce como
_______.

1 / 1 punto

VPN
multiplexor

proxy inverso

proxy

Correcto

¡Buen trabajo! Un proxy inverso permite que un solo servidor parezca ser el punto final
para muchos servidores detrás de él.

16.

Pregunta 16

VPN significa ______.

1 / 1 punto

red muy personal

red privada virtual

red pública virtual

red de proxy virtual

Correcto

¡Así es! Una VPN permite que un dispositivo establezca un túnel encriptado hacia otra
red.