¿Debería nuestra pequeña oficina tener servidores DNS internos?


9

Administro una pequeña oficina (<50 personas). Siempre hemos tenido servidores DNS internos en la oficina. Los servidores DNS son bastante sencillos, pero hemos tenido problemas con ellos en el pasado. Tenemos algunos recursos de oficina que solo están disponibles en la oficina, o externamente a través de VPN, y también tenemos algunos recursos de oficina con dirección pública y registro. Esos recursos tienen actualmente el mismo nombre DNS, aunque eso no es necesariamente un requisito, y hay muchos menos de lo que solían ser.

También poseemos el espacio de nombres de la oficina interna, por lo que es posible que pueda llenar mi DNS público con todas las direcciones IP privadas de los recursos de la oficina interna que tenemos y dejar de usar el DNS interno por completo.

¿Es esta una buena idea? Nunca he trabajado en un lugar que no tenga DNS interno de oficina. ¿Cuáles son algunas de las razones por las que aún debemos conservarlo? Alguna vez fue crítico, ahora sigue siendo conveniente, pero los problemas que hemos encontrado ya no lo hacen sentir conveniente.

Razones actuales para mantener:

  • Split DNS nos permite usar el mismo nombre de host para aquellos recursos que están alojados internamente pero también disponibles externamente
  • Tenemos algunos dominios de prueba que no hemos necesitado comprar pero que necesitaríamos si nos deshiciéramos de ellos.
  • ??? Es familiar y reconfortante?

Razones para deshacerse de él:

  • No hay soporte para IPv6 actualmente
  • He tenido varios problemas con la división de DNS, principalmente con la configuración de VPN
  • Mantenimiento en un servidor que puede ser innecesario

Creo que también debe tener en cuenta otras cosas, como la cantidad de servidores que tiene y la estabilidad de la conexión a Internet. si confía en un servidor DNS externo, ¿qué sucede si pierde su conectividad a Internet durante mucho tiempo? (cuando ya no se almacena en caché la información) significa que ninguno de sus servidores podrá comunicarse entre sí, y por lo tanto, todos los servicios estarán inactivos. Es una ventaja tener un servidor DNS local al menos para el almacenamiento en caché y realizar resoluciones locales.
olivierg

1
La razón principal para tener servidores DNS internos, al menos en una red de Windows, es para admitir Active Directory y un dominio de Windows. Si está ejecutando un dominio, no puede deshacerse de su DNS integrado de AD. O, al menos, no deberías de todos modos.
Appleoddity

Tenemos un servidor LDAP interno, no AD. El DNS no está integrado en eso, aunque me pregunto si tiene alguna interdependencia.
Aaron R.

debería tener algunos requisitos de DNS, si hay varios servidores LDAP, AD usa SRVregistros para el descubrimiento de servicios, también lo hace Dir389.
Jacob Evans el

Interesante, bueno saberlo. Aunque no estoy seguro de que deba ser interno en cualquier caso; Me parece que podríamos usar DNS público para eso.
Aaron R.

Respuestas:


5

Leyendo sus comentarios ...

Me quedaría al 100% con DNS. También ampliaría su implementación de LDAP a AD. 50 personas es definitivamente lo suficientemente grande; Implementaría DNS para> 10 usuarios si no son técnicos y tienen múltiples recursos internos a los que necesitan acceder.

En cuanto a los contras:

  • No hay soporte para IPv6 actualmente

¿Qué plataforma usas? Existen múltiples plataformas con soporte para IPv6, a saber, OpenDNS

  • Configuración de VPN que causa problemas

Sin ánimo de ofender, pero tal vez debería averiguar por qué las configuraciones de VPN están rompiendo DNS y resolver eso. Es mejor que la bandaid de "No, el DNS interno es demasiado complicado para trabajar con la VPN".

  • El mantenimiento

Automatizar, automatizar, automatizar: no debería ser demasiado difícil siempre que adopte un enfoque inteligente para las entradas de DNS y la administración del sistema en su conjunto. El DNS no debería tener que cambiarse radicalmente (al menos no con frecuencia).


1
Solo alrededor de un tercio de la oficina usa Windows, por lo que no estoy realmente interesado en agregar más infraestructura para implementar un controlador de dominio. Estoy usando Bind en este momento, que ciertamente es compatible con IPv6 pero no se ha habilitado y eso requeriría tiempo y esfuerzo de mi parte; ese es el impulso principal, de verdad; ¿Me estoy arriesgando a eliminar este recurso y usar solo DNS público? ¿Me estoy preparando para más trabajo más tarde debido a alguna función de oficina futura que necesita DNS, etc.
Aaron R.

Lo siento, asumí que todos estaban en un dispositivo Windows (aunque AD funciona bien con Linux e imagino que también hay algunas opciones maduras para OS X). Esas son decisiones de diseño que debe considerar y actuar. Si piensas crecimiento y especificaciones futuras. podría necesitar más de un dominio controlado con DNS interno para recursos internos, luego manténgalo disponible o, como mínimo, tenga listo para arrancar si cree que podría necesitarlo. De lo contrario, eres el capitán de tu propio barco, ¿sabes? Este tipo de cosas siempre es una compensación entre el esfuerzo y las recompensas anticipadas. ¡Buena suerte! :)
kilrainebc

4

Mantenga el DNS interno, si es necesario, haga que sea redundante.

  • SplitBrain DNS es un desastre, pero generalmente tiene (muchos) más registros internos que externos. Además, puede dividir su tráfico: interna utiliza IP internas, externamente usa externas.
  • AD se basa 100% en DNS
  • No depende del DNS de su ISP, porque su DNS podría usar la recursividad.
  • No desea que todos puedan buscar su recurso interno
  • No desea proporcionarle recursos internos a su ISP (DNS)

No necesita tener su propio DNS, cuando todo el mundo está usando Internet y no tiene que administrar sus propios servidores. VPN me parece como servicios internos, jst kepp internos.

  • No hay soporte para IPv6 actualmente

¿Todavía hay servidores DNS sin v6 por ahí? Ponte al día aquí.

  • He tenido varios problemas con la división de DNS, principalmente con la configuración de VPN

Los problemas de configuración no desaparecerán si un servicio desaparece. Aún tendrá que configurar su VPN correctamente, que ahora incluye reglas de ruptura para el tráfico DNS externo.

  • Mantenimiento en un servidor que puede ser innecesario

El DNS generalmente es pequeño y no necesita una caja propia. Simplemente configure uno en uno de sus servidores confiables (como archivo o correo).


1
Sacas una de las preguntas reales que tenía, tal vez una que sería mejor como una nueva pregunta, pero ¿podrías explicar más a qué te refieres cuando dices "No quieres que todos puedan buscar tus recursos internos". " Agregar direcciones IP privadas en DNS públicos es poco común, pero ¿hay algo realmente malo en ello? ¿Por qué me importaría si los piratas informáticos pueden buscar las direcciones IP privadas de mi empresa? Todavía no son enrutables.
Aaron R.

3
No desea darle a un hacker ninguna pista sobre su red interna en caso de que se viole su seguridad. La filtración de su DNS interno da pistas sobre la estructura de la red interna, posibles objetivos jugosos ("¡Ajá!" ¡HRserver está en 192.168.99.72! ¡Gracias! Puedo ir directamente a eso "), etc.
Brandon Xavier

1
¿Es eso realmente una preocupación? Sé que existe un sentimiento general en la comunidad profesional de que es mejor proteger cada fragmento de información posible, pero no estoy seguro de cuán crítico es. Todos nuestros DNS no públicos podrían consultarse y obtendrían esos datos en 10 minutos. Entonces, ¿tal vez estamos ahorrando 10 minutos de tiempo de pirateo? Eso no me parece muy valioso.
Aaron R.

Su DNS no público no debe estar abierto a consultas ... Por lo tanto, "no público" ...
kilrainebc

2
Técnicamente, puede poner sus partes privadas en público, pero técnicamente también podría no usar pantalones en público (o solo en este lugar de trabajo). Por lo tanto, es posible , nadie quiere que hagas eso, por lo que ningún profesional de TI lo haría.
bjoster
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.