Hola listeros, quizás esta consulta es básica para vosotros, pero estoy en busca de conseguir un alto performance en una red.
El Problema es el siguiente:
Tengo una red conectada a internet por medio de un firewall, cuyo firewall hace la hora de router separando los traficos de la red en varias vlans, estas están dedicadas a varios propósitos, sobre todo a separar la administración de la red, de clientes intrusos como también generando una dmz que es donde ira una granja de varios servicios. Por sentido común, tengo dos NS en la DMZ cuyo objetivo es resolver las consultas realizadas desde internet con el fin de publicar estos servicios al mundo. con el fin de tener el máximo de Performance tengo un NS en la vlan de administración y otro en la vlan de clientes como DNS-Cache
Las preguntas:
1.- es necesario configurar los NS de las vlan's de administración y de los clientes como NS-Locales para que accedan a los servicios alojados en la DMZ de forma que resuelvan por la red local y no estén saliendo a internet para acceder a estos servicios?
2.- a vista de ojos mas expertos y considerando como un ejemplo estas tres vlan's (administración, clientes y dmz) cuantos dns debería de tener en cada red de estas y que tipo de configuración me recomiendan para cada caso?
Espero que tenga buena acogida mi consulta y no estar incomodandolos con estas consultas de novatos.
Saludos
**********************************************Pablo Figueroa Alvarez*
*Movil : (+56-9) 4234 3378*
*Mail : Pabluster@gmail.com Pabluster@gmail.com*
https://linuxcounter.net/user/379917.html
On 10/05/18 08:06, Pabluster wrote: Hola listeros, quizás esta consulta es básica para vosotros, pero estoy en busca de conseguir un alto performance en una red.
El Problema es el siguiente:
Tengo una red conectada a internet por medio de un firewall, cuyo firewall hace la hora de router separando los traficos de la red en varias vlans, estas están dedicadas a varios propósitos, sobre todo a separar la administración de la red, de clientes intrusos como también generando una dmz que es donde ira una granja de varios servicios. Por sentido común, tengo dos NS en la DMZ cuyo objetivo es resolver las consultas realizadas desde internet con el fin de publicar estos servicios al mundo. con el fin de tener el máximo de Performance tengo un NS en la vlan de administración y otro en la vlan de clientes como DNS-Cache
Las preguntas:
1.- es necesario configurar los NS de las vlan's de administración y de los clientes como NS-Locales para que accedan a los servicios alojados en la DMZ de forma que resuelvan por la red local y no estén saliendo a internet para acceder a estos servicios?
2.- a vista de ojos mas expertos y considerando como un ejemplo estas tres vlan's (administración, clientes y dmz) cuantos dns debería de tener en cada red de estas y que tipo de configuración me recomiendan para cada caso?
Hola Pablo,
entiendo que los NS que tenés en las VLAN de administración y clientes son resolvers (es decir, que brindan servicio de resolución de todos los nombres de internet para los usuarios locales y clientes) y los dos NS que tenés en la DMZ son autoritativos (es decir, los que publican la información de tus dominios a toda la internet). Tené en cuenta que, si bien toda la vida llamamos "servidores DNS" a ambas cosas y ambos servicios utilizan el mismo protocolo en el mismo puerto, son conceptualmente distintos y, si bien podrías brindarlos juntos (y de hecho, lo hacíamos casi siempre hace 20 años o más), hoy conviene separarlos.
Suponiendo que efectivamente lo que tenés en las VLAN de administración y clientes son resolvers y los de la DMZ son autoritativos, la cantidad depende de varias cosas.
Con 2 autoritativos en la DMZ te va a alcanzar. Se recomienda utilizar más pero "separarlos" (es decir, podrías contratar un servicio de DNS autoritativo secundario para tener cobertura en distintos puntos del mundo, pero si están topológicamente juntos no tiene sentido tener más de uno o dos).
En general, la percepción de "velocidad" para los usuarios depende de la performance de los resolvers. El hecho de que los resolvers tengan acceso a los autoritativos tuyos a través de internet o por un camino más local no creo que tenga una influencia muy grande ya que en general el resolver obtiene la información del autoritativo una vez y luego la tiene cacheada localmente (hasta que expira) y contesta inmediatamente. Por otra parte, el consumo que hagan tus usuarios de tus propios nombres, probablemente sea relativamente marginal, y la mayor parte del tiempo estén resolviendo nombres públicos sobre los que no tenés control (google, facebook, clientes, proveedores, etc).
Lo que te va a importar para que tus usuarios y clientes tengan buena "performance de DNS" es que tus resolvers sean rápidos y funcionen bien. En general uno debería poder asegurar la disponibilidad del servicio con lo cual sería recomendable tener al menos dos en cada VLAN. Luego de eso, hay que ver las cuestiones de performance.
Cuando uno tiene varios resolvers con cache, a diferencia de lo que pasa con otros servicios (como mail o web), en general es mejor tener todo el tráfico posible en el mismo servidor hasta que se empiece a perder performane (normalmente porque el servidor no puede contestar y dropea consultas) ya que lo que te conviene es tener la cache de ese servidor llena de información para poder contestar instantáneamente sin hacer las consultas autoritativas "hacia afuera".
La gente de PowerDNS tiene un producto que se llama DNSdist que es una especie de "load balancer" de DNS que maneja estos conceptos. Es decir, intenta enviar todas las consultas al mismo resolver hasta que detecta una pérdida de performance.
En cuanto a la cantidad efectiva de resolvers para poner en cuanto a performance, depende muchísimo de la cantidad de usuarios de cada lado. Además, una cosa es una oficina, otra cosa un ISP corporativo y otra un proveedor de servicios a redes celulares.
[NIC Argentina]https://nic.ar
Mariano Absatz Consultor de Tecnología E-mail: mariano@nic.armailto:mariano@nic.ar Dirección Nacional del Registro de Dominios de Internet San Martín 536 1°Piso (C1004AAL), C.A.B.A. +54 (11) 5238-1350 Argentina
Gracias Mariano.... ahora me salta la duda... es necesario que en los resolver cree las zonas para que los administradores resuelvan por ejemplo el servidor de mail de forma interna por la red local ?
El 10-05-2018, a la(s) 09:42, Mariano Absatz mariano@nic.ar escribió:
On 10/05/18 08:06, Pabluster wrote: Hola listeros, quizás esta consulta es básica para vosotros, pero estoy en busca de conseguir un alto performance en una red.
El Problema es el siguiente:
Tengo una red conectada a internet por medio de un firewall, cuyo firewall hace la hora de router separando los traficos de la red en varias vlans, estas están dedicadas a varios propósitos, sobre todo a separar la administración de la red, de clientes intrusos como también generando una dmz que es donde ira una granja de varios servicios. Por sentido común, tengo dos NS en la DMZ cuyo objetivo es resolver las consultas realizadas desde internet con el fin de publicar estos servicios al mundo. con el fin de tener el máximo de Performance tengo un NS en la vlan de administración y otro en la vlan de clientes como DNS-Cache
Las preguntas:
1.- es necesario configurar los NS de las vlan's de administración y de los clientes como NS-Locales para que accedan a los servicios alojados en la DMZ de forma que resuelvan por la red local y no estén saliendo a internet para acceder a estos servicios?
2.- a vista de ojos mas expertos y considerando como un ejemplo estas tres vlan's (administración, clientes y dmz) cuantos dns debería de tener en cada red de estas y que tipo de configuración me recomiendan para cada caso?
Hola Pablo,
entiendo que los NS que tenés en las VLAN de administración y clientes son resolvers (es decir, que brindan servicio de resolución de todos los nombres de internet para los usuarios locales y clientes) y los dos NS que tenés en la DMZ son autoritativos (es decir, los que publican la información de tus dominios a toda la internet). Tené en cuenta que, si bien toda la vida llamamos "servidores DNS" a ambas cosas y ambos servicios utilizan el mismo protocolo en el mismo puerto, son conceptualmente distintos y, si bien podrías brindarlos juntos (y de hecho, lo hacíamos casi siempre hace 20 años o más), hoy conviene separarlos.
Suponiendo que efectivamente lo que tenés en las VLAN de administración y clientes son resolvers y los de la DMZ son autoritativos, la cantidad depende de varias cosas.
Con 2 autoritativos en la DMZ te va a alcanzar. Se recomienda utilizar más pero "separarlos" (es decir, podrías contratar un servicio de DNS autoritativo secundario para tener cobertura en distintos puntos del mundo, pero si están topológicamente juntos no tiene sentido tener más de uno o dos).
En general, la percepción de "velocidad" para los usuarios depende de la performance de los resolvers. El hecho de que los resolvers tengan acceso a los autoritativos tuyos a través de internet o por un camino más local no creo que tenga una influencia muy grande ya que en general el resolver obtiene la información del autoritativo una vez y luego la tiene cacheada localmente (hasta que expira) y contesta inmediatamente. Por otra parte, el consumo que hagan tus usuarios de tus propios nombres, probablemente sea relativamente marginal, y la mayor parte del tiempo estén resolviendo nombres públicos sobre los que no tenés control (google, facebook, clientes, proveedores, etc).
Lo que te va a importar para que tus usuarios y clientes tengan buena "performance de DNS" es que tus resolvers sean rápidos y funcionen bien. En general uno debería poder asegurar la disponibilidad del servicio con lo cual sería recomendable tener al menos dos en cada VLAN. Luego de eso, hay que ver las cuestiones de performance.
Cuando uno tiene varios resolvers con cache, a diferencia de lo que pasa con otros servicios (como mail o web), en general es mejor tener todo el tráfico posible en el mismo servidor hasta que se empiece a perder performane (normalmente porque el servidor no puede contestar y dropea consultas) ya que lo que te conviene es tener la cache de ese servidor llena de información para poder contestar instantáneamente sin hacer las consultas autoritativas "hacia afuera".
La gente de PowerDNS tiene un producto que se llama DNSdist que es una especie de "load balancer" de DNS que maneja estos conceptos. Es decir, intenta enviar todas las consultas al mismo resolver hasta que detecta una pérdida de performance.
En cuanto a la cantidad efectiva de resolvers para poner en cuanto a performance, depende muchísimo de la cantidad de usuarios de cada lado. Además, una cosa es una oficina, otra cosa un ISP corporativo y otra un proveedor de servicios a redes celulares.
<logo_NIC_firma>
Mariano Absatz Consultor de Tecnología E-mail: mariano@nic.ar Dirección Nacional del Registro de Dominios de Internet San Martín 536 1°Piso (C1004AAL), C.A.B.A. +54 (11) 5238-1350 Argentina
dns-esp mailing list dns-esp@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp
On 10/05/18 20:33, Pablo Figueroa wrote:
Gracias Mariano.... ahora me salta la duda... es necesario que en los resolver cree las zonas para que los administradores resuelvan por ejemplo el servidor de mail de forma interna por la red local ?
Ahhh... ya veo por dónde vas :-)
¿Desde la red de administración los servidores se /deben/ ver con direcciones IP distintas a las públicas?
Este es otro problema que tiene varias complejidades. Si desde la red de administración es necesario utilizar direcciones IP distintas para los mismos servicios, hay que conseguir que los mismos nombres se resuelvan de distinto modo según de dónde viene la consulta.
- Si el hecho de que desde la red de administración se /puedan/ ver las
direcciones privadas pero */también/* se puedan utilizar las direcciones IP públicas (que usa cualquiera desde afuera), lo más fácil (aunque quizás no lo más óptimo) es simplemente dejar todo así y que desde la VLAN de admin se utilicen los servicios públicos.
- Si desde la VLAN de admin sólo se puede llegar a los servicios por
direcciones privadas (o, desde el punto de vista de performance, conviene hacerlo) entonces tenés que implementar algo que se llama "split-horizon" (¿horizonte dividido?), en el que, de algún modo, conseguís que la respuesta a la misma consulta dé un resultado distinto según desde donde llegue.
BIND siempre tuvo soporte para "split-horizon", pero es muy fácil configurarlo mal (o "romperlo" después de un tiempo y modificaciones por distintas manos).
Una cosa que tenés que tener en cuenta es que, si un equipo (cliente) tiene configurados varios resolvers (por si alguno no responde o si alguno es más eficiente que el otro), /todos/ los resolvers deberían contestar /lo mismo/ para las mismas consultas. Esto te va a obligar a que /no/ utilices los resolvers para clientes como backup de los de admin y viceversa (o que tengas que configurar con mucho cuidado a todos ellos).
Para mí, en tu caso, lo más simple es configurar uno o dos servidores *autoritativos /internos/* para tu dominio que tengan las zonas configuradas como las tengan que ver desde la VLAN de admin (lo cual posiblemente tenga algunas direcciones IP públicas y otras privadas).
Una vez hecho esto, en los *resolvers* de la VLAN de admin configurás, /sólo para tu dominio/ un "forwarder" que, en lugar de seguir el mecanismo de delegación desde la raíz, haga directamente las consultas a los autoritativos internos.
Tenés que tener en cuenta que, en muchos casos, cuando introduzcas modificaciones en las zonas, vas a tener que configurarlas en el autoritativo master público y en el interno.
La alternativa es que configures el "split-horizon" en los autoritativos públicos y hagas que, si las consultas vienen de una IP de la VLAN admin contesten con una zona distinta. De los servidores open source que usé, el único que soporta esto es BIND (ni NSD, ni PowerDNS ni el viejo djbdns lo soportan, y es más "por diseño" que por pereza). En este caso, /de todos modos/ tenés que modificar dos zonas distintas, sólo que están ambas en el mismo servidor.
Lo mismo lo podrías implementar con dos instancias de autoritativo (aún con NSD u otro) en el mismo equipo, y hacés que la zona interna se conteste en una IP distinta o en un port distinto (si usás un forwarder, en general lo podés configurar para que haga las consultas en un puerto no-estándar).
Suerte.
-
Mariano Absatz -
Mariano Absatz - gmail -
Pablo Figueroa -
Pabluster