Estoy intentando establecer un servidor de correo/calendario personal en mi casa (sí, he oído que es difícil, que genera muchos problemas, etc., pero aún así me gustaría intentarlo). Tengo un ISP que no ofrece direcciones IP estáticas, por lo que parece que algún tipo de Servicio de nombres de dominio dinámico (DDNS) es la solución.
Sin embargo, he estado investigando y encontré al menos un par de recursos en línea que explican que usted mismo puede hacer DDNS: necesita tener un script/programa que monitoree su dirección IP periódicamente, y si la dirección cambia , entonces el script/aplicación necesita actualizar cualquier nombre de dominio que esté usando para sus servidores domésticos (resulta que tengo un dominio estacionado con un proveedor de alojamiento solo para esta eventualidad y, según tengo entendido, solo necesito la clave API de la empresa de alojamiento para ajustar los registros de dominio/IP necesarios mediante programación... alguien avíseme si me equivoco en esto y hay una manera más sencilla).
Aquí está la cuestión: cuando actualiza sus registros de nombre de dominio de la manera que describí anteriormente, leí que puede llevar varias horas propagarse por todo el sistema/mundo (todos los servidores DNS deben volver a llenarse con su dirección actualizada). ). Sin embargo, varios proveedores de DDNS pagados que he estado analizando parecen promover su capacidad de hacer que el cambio surta efecto casi instantáneamente (o al menos, más rápido que mi método de bricolaje). ¿Es eso cierto? ¿Hay algo que me he perdido?
Además, tengo otra preocupación: ¿hay algún problema de seguridad que pueda pasar por alto al tener un proveedor de DDNS? ¿No podrán monitorear todo el tráfico que fluye a través del nombre de dominio que proporcionan? ¿Alguien tiene una opinión informada sobre qué método (pago o bricolaje) podría ser mejor?
Aprecio tu tiempo... ¡gracias!
Respuesta1
Estoy intentando establecer un servidor de correo/calendario personal en mi casa (sí, he oído que es difícil, que genera muchos problemas, etc., pero aún así me gustaría intentarlo).
Probablemente no tengas mucha suerte con la parte del correo. Vea la respuesta de @Alex.
necesita tener un script/programa que monitoree su dirección IP periódicamente, y si la dirección cambia, entonces el script/aplicación debe actualizar cualquier nombre de dominio que esté usando para sus servidores domésticos.
Más o menos eso.
Solo necesito la clave API de la empresa de alojamiento para ajustar los registros de dominio/IP necesarios mediante programación.
Sí, aunque si la empresa solo proporciona un servicio genérico de "alojar todo", es posible que no tenga ninguna API de administración de DNS (centrándose en la web y el correo) y es posible que deba mover el dominio a otra parte.
Aquí está la cuestión: cuando actualiza sus registros de nombre de dominio de la manera que describí anteriormente, leí que puede llevar varias horas propagarse por todo el sistema/mundo (todos los servidores DNS deben volver a llenarse con su dirección actualizada). ).
No. Sólo es necesario actualizar los sistemas propios de su proveedor de alojamiento DNS. El resto del mundo no mantiene un registro permanente: simplemente almacena en caché los resultados de búsquedas individuales, durante el tiempo indicado en el campo "TTL" (Tiempo de vida) de cada (sub)dominio.
Sin embargo, varios proveedores de DDNS pagados que he estado analizando parecen promover su capacidad de hacer que el cambio surta efecto casi instantáneamente (o al menos, más rápido que mi método de bricolaje). ¿Es eso cierto? ¿Hay algo que me he perdido?
Supongo que permiten configurar un TTL muy bajo en los dominios dinámicos (hasta unos pocos segundos), lo que significa que saldrá de cualquier caché muy rápidamente, a costa de que el propio proveedor de DDNS reciba muchas más solicitudes (mayor). cargar en sus servidores DNS y bases de datos, y una excusa para cobrarle más). Eso por sí solo no es algo especial y podría implementarse con cualquier método de bricolaje.
¿No podrán monitorear todo el tráfico que fluye a través del nombre de dominio que proporcionan?
No. El servidor DNS sólo le proporciona una dirección (muy parecida a una guía telefónica) y no participa en ninguna comunicación posterior.
(A menos que el proveedor realmente intentedevolver datos falsos, lo que acortaría considerablemente el TTL de la empresa en el momento en que los sitios web de noticias se enteren).
Dicho esto, preste atención a cómo funciona la API; Por supuesto, no puede estar seguro de que el servicio no tenga ninguna vulnerabilidad, pero si (por ejemplo) la API se ejecuta a través de HTTP sin cifrar y transmite la clave API a la vista, entonces no es algo en lo que desee confiar.
Respuesta2
Si no tiene una IP estática, entonces debe olvidarse del servidor de correo si utiliza la solución DDNS, la mayoría de los servidores de correo electrónico rechazarán sus correos electrónicos o etiquetarán los correos electrónicos con el nivel más alto de spam, ya que todas las IP dinámicas están enABPliza. (Puede ver más detalles en la sección PS por qué no es una buena idea tener un servidor de correo electrónico en una IP residencial, pero todavía hay una solución alternativa mediante el uso de VPS (servidor privado virtual) intermedio y económico.)
Con respecto a "DDNS usted mismo", un buen registrador de dominio que proporciona actualización gratuita de IP a través de su API, todo lo que su programa debe hacer es verificar periódicamente la IP pública y, si cambia, enviar una nueva IP al registrador, quien actualizará el registro A (AAAA). Por cierto, la mayoría de los enrutadores actuales ya tienen dicha característica (esté atento a la IP e informe al proveedor de DDNS)
He leído que puede tardar varias horas en propagarse por todo el sistema/mundo.
Depende del proveedor de DNS, los registradores respetuosos permiten establecer TTL (tiempo que les dice a otros con qué frecuencia se puede cambiar la IP) en 5 minutos. No todos reenvían servidores DNS intermedios siguiendo esto para evitar una carga alta, pero generalmente, incluso si no siguen el TTL del propietario del dominio, rara vez duran más de unas pocas horas. La mayoría de los reenviadores actualizarán sus cachés como lo configuraría en el dominio TTL.
¿Hay algún problema de seguridad que pueda pasar por alto al tener un proveedor de DDNS?
Al conectarse, ya es posible que haya un problema de seguridad. Aísle su servidor de la red local para evitar invitados no deseados.
¿Alguien tiene una opinión informada sobre qué método (pago o bricolaje) podría ser mejor?
Tirará su tiempo y dinero al aire si opta por DDNS. Hoy en día, puedes conseguir un VPS (servidor privado virtual) decente por 3 o 4 dólares al mes. Si bien el sitio web (si planea tener uno) se puede alojar directamente en VPS, ya que generalmente no ocupa mucho espacio, el servidor de correo electrónico podría ser problemático si espera ejecutar su servidor durante mucho tiempo o espera un gran volumen de correos electrónicos. Por lo general, 20 GB de espacio son suficientes para pequeñas empresas de hasta 3 a 5 años, incluso sin eliminar correos electrónicos antiguos. Incluso si espera una gran cantidad de correos electrónicos, puede utilizar nginxla función para enviar el tráfico de correo electrónico a su hogar. Por lo tanto, puede alojar el servidor de correo electrónico principal en casa con una IP dinámica y el VPS (que tiene una IP estática) representará el tráfico entrante/saliente a su casa. Puede usar su propio VPS en dicha configuración sin problemas, ya que no hay necesidad de preocuparse por la propagación de DNS, el dominio siempre apuntará a la IP estática del VPS. Aún necesita administrar los informes de los cambios de IP de su hogar al VPS, para que el VPS sepa dónde enviar el tráfico mediante proxy, pero es mucho más fácil, simplemente consulte alguna URL en su VPS y analice los registros de su IP entrante y ajuste nginx, para que siempre sepa Dónde estás.
PD
Puedo ver que este tema es interesante para los superusuarios, por lo que agregaría un poco más de detalles.
ABPLas listas contienen una base de datos de IP que generalmente son IP dinámicas, por lo queABP ayuda mucho a los operadores de servidores de correo electrónico. No es un problema técnico o los ISP son malos al no permitir servidores de correo electrónico en IP dinámicas, el problema es que la mayor parte del tráfico de correo electrónico de IP dinámicas proviene de computadoras infectadas que envían spam o malware en un volumen enorme que puede fácilmenteDDoSservidor receptor si uno es el objetivo. Algunos ISP bloquean las conexiones salientes al puerto 25 para evitar la propagación de malware yDDoS, pero algunos no. Prácticamente todos los servidores de correo electrónico corporativo simplemente desconectan las conexiones que provienen deABPlista que reduce significativamente el spam.
La segunda solución antispam eficaz es eliminar conexiones desde IP que no tienen un registro PTR inverso en DNS y no coinciden con el registro DNS del dominio. Incluso si las conexiones provienen de IP estáticas que no tienen registro PTR, generalmente se trata de una configuración mal configurada o en su mayoría provienen de servidores ejecutados por bandas de spam (podrían existir exclusiones para algunos proveedores grandes (pero descuidados), pero se pueden agregar manualmente en lista blanca). Si bien es cuestión de unos minutos configurar el registro PTR inverso en VPS, no es el caso si las IP estáticas obtenidas del ISP y el proceso para configurar el PTR suele ser un PITA (hay que llamarlos y enviar un ticket después de la verificación). que usted es el propietario original de la IP y espera la misericordia de su administrador de sistemas, que necesita establecer un registro PTR inverso, a veces en unas pocas horas, pero a veces en unos días)
Además, no es crítico, pero... para evitar la falsificación de correo electrónico, la mayoría de los propietarios de servidores de correo electrónico utilizan los llamadosFPS(marco de políticas del remitente) que permite especificar el método de procesamiento de políticas más rápido si se configuran en DNS direcciones IP autorizadas que permiten enviar correos electrónicos en nombre del dominio. (Se pueden especificar servidores autorizados medianteFQDNcomo referencia al registro MX, pero requiere viajes de ida y vuelta adicionales a través de DNS para conectar servidores). Por lo tanto, administrar IP flotante en DNS no sería divertido.
Respuesta3
Tengo un ISP que no ofrece direcciones IP estáticas, por lo que parece que algún tipo de Servicio de nombres de dominio dinámico (DDNS) es la solución.
Esa es una solución. Como ejemplo de otra solución, un túnel IPv6 de HurricaneElectric.net proporciona una dirección estática (IPv6) con un punto final de túnel móvil. Por supuesto, en este momento, sería mejor que IPv4 admitiera dicha funcionalidad entre el público en general, pero si puede encontrar una computadora dispuesta a cooperar, técnicamente también podría hacer algo así con IPv4.
necesita tener un script/programa que monitoree su dirección IP periódicamente, y si la dirección cambia, entonces el script/aplicación debe actualizar cualquier nombre de dominio que esté usando
Esto suena como un plan técnicamente sólido.
Solo necesito la clave API de la empresa de alojamiento para ajustar los registros de dominio/IP necesarios mediante programación... alguien avíseme si me equivoco en esto y hay una manera más sencilla).
Los detalles exactos dependerán de la elección del registrador de nombres de dominio sobre cómo implementar esta característica. Algunos pueden usar una clave API de algún tipo, mientras que otros pueden depender de una interfaz web para actualizaciones automáticas. Antiguamente, algunos ISP proporcionaban este tipo de servicio, pero dependían de cambios manuales en respuesta a las solicitudes. Por lo tanto, depende totalmente de quien le proporcione el servicio.
Aquí está la cuestión: cuando actualiza sus registros de nombre de dominio de la manera que describí anteriormente, leí que puede llevar varias horas propagarse por todo el sistema/mundo (todos los servidores DNS deben volver a llenarse con su dirección actualizada). ).
Bah patraña. Se sabe que la propagación de DNS tarda minutos, horas o días (por ejemplo, 72 horas). Sin embargo, cuando las personas analizaron las cosas en profundidad, descubrieron que gran parte de ese vago tiempo de "propagación" se debía simplemente a que un proveedor de alojamiento DNS tardaba en actualizarse.
En una mejor teoría, sólo debería tener que esperar el valor TTL. Aunque hay un problema con esa teoría...
Sin embargo, varios proveedores de DDNS pagados que he estado analizando parecen promover su capacidad de hacer que el cambio surta efecto casi instantáneamente (o al menos, más rápido que mi método de bricolaje). ¿Es eso cierto? ¿Hay algo que me he perdido?
Bien, esta es la realidad: para que su actualización surta pleno efecto, necesitará que Internet vacíe su caché activo de información antigua.
Según los estándares, los servidores DNS de almacenamiento en caché pueden depender de su caché durante el período de tiempo especificado por un valor TTL que puede configurar.
Sin embargo, la realidad es que se sabe que al menos algunos (¿y tal vez incluso la mayoría?) de ISP muy grandes ejecutan sus propios servidores DNS de almacenamiento en caché que ignoran por completo los valores TTL. Hacen esto porque sienten que si actualizan sus cachés de DNS con menos frecuencia, el efecto general será menos ancho de banda (y tal vez menos tiempo de computación).
Por lo tanto, cualquier servidor de correo electrónico que dependa de dicho servidor DNS puede verse afectado y no poder notar sus actualizaciones hasta que se actualice el servidor DNS. En algunos casos, esto puede llevar uno o dos días (¿o tres?).
Sin embargo, estos efectos se han vuelto cada vez más raros. En la práctica real, la mayoría de los servidores DNS borrarán sus cachés en una o dos horas.
Dado que algunos cachés no se actualizan tan rápido como otros, el efecto es que algunos lugares en Internet funcionarán con la nueva dirección, mientras que otros lugares seguirán intentando usar la dirección anterior. En un par de horas, la mayoría de las computadoras funcionarán bien con la nueva información. (Muchos, muchos de ellos pueden funcionar en cuestión de minutos).
El comportamiento típico del software de correo electrónico es intentar enviar el correo electrónico. Si esto falla, inténtelo de nuevo más tarde. Los servidores de correo electrónico normalmente seguirán intentándolo (tal vez aproximadamente una vez cada hora) durante días antes de darse por vencidos. Entonces, lo que probablemente sucederá es que no perderá el correo electrónico, pero sí se retrasará un poco.
El comentario de Alex "todas las IP dinámicas están en listas PBL" es claramente incorrecto, ya que esta información está descentralizada (por lo que la palabra "todas" es inexacta), pero es cierto que muchas IP dinámicas están en dichas listas, y eso puede significa que algunas computadoras/dispositivos relacionados con el correo electrónico pueden decidir no cooperar con usted.
Además, tengo otra preocupación: ¿hay algún problema de seguridad que pueda pasar por alto al tener un proveedor de DDNS?
La mayor preocupación será si sus actualizaciones se manejan de forma segura.
¿No podrán monitorear todo el tráfico que fluye a través del nombre de dominio que proporcionan?
No. El trabajo del servidor DNS es recibir una solicitud de un nombre de dominio y proporcionar una respuesta. La respuesta típica tradicional es proporcionar una o más direcciones IP. Son posibles otras respuestas, como hacer referencia a otro servidor DNS o nombre de dominio (por ejemplo, con un CNAME) u otros datos (por ejemplo, ayudar a proporcionar seguridad a través del estándar DNSSec más nuevo).
¿Alguien tiene una opinión informada...?
Me gustaría señalar que si realmente desea ejecutar un servidor de correo electrónico serio, puede considerar la posibilidad de cumplir con los estándares de correo electrónico modernos. Eso implica algo más que cumplir con las especificaciones técnicas de SMTP y DNS. Mucha gente utiliza grandes proveedores, y esos grandes proveedores pueden implementar sus propias expectativas.
Por ejemplo, conozco un servidor de correo electrónico que se configuró con Debian y Postgrey hace años. Postgrey es un software que proporciona manejo antispam de "listas grises". Sin embargo, la versión de Postgrey que se utiliza supone que cuando un servidor de correo electrónico reintenta el correo electrónico, el servidor de correo electrónico emisor utilizará la misma dirección IP al hacerlo. Se sabe que los servidores de correo electrónico de Office 365 vuelven a intentar enviar un correo electrónico desde una dirección IP diferente que todavía se encuentra dentro de una subred IPv6/64. A Postgrey no le gusta eso.
A medida que más y más organizaciones han cambiado a Office 365, esto se ha convertido en un problema cada vez mayor para las personas que utilizan ese antiguo servidor de correo electrónico. Se ha lanzado una versión más nueva del software Postgrey, pero la forma más sencilla de instalar dicho software es utilizar el repositorio de software oficial para ese sistema operativo. Entonces, en la práctica, la forma inteligente de actualizar ese software será actualizar el sistema operativo.
Existen otras convenciones, como tener nombres DNS que comiencen con "correo". lo que puede hacer que su configuración se considere más o menos confiable. Esto puede afectar si los dispositivos lo tratan como a un spammer que no cumple con las normas o como un dispositivo con el que vale la pena comunicarse.
Claro, tal vez cuando se habla muy estrictamente de especificaciones técnicas oficiales, organizaciones gigantes están realizando algunas acciones diferentes a los requisitos mínimos exigidos por los documentos RFC que contienen las especificaciones técnicas de los protocolos que se utilizan. Pero si desea comunicarse con la comunidad de Internet en general, existen algunos estándares adicionales que imponen algunos actores importantes o grandes. Esté preparado para cumplir bien con esos estándares o esté preparado para encontrar algunos problemas.
Estoy siendo un poco vago acerca de cuáles son exactamente todos esos estándares, porque pueden cambiar con el tiempo.
Con respecto a ese antiguo servidor de correo electrónico que necesitará actualizar su antiguo sistema operativo Debian, tal vez la gente debería actualizar su sistema operativo con más frecuencia de todos modos. Lo que quiero decir, sin embargo, es que una configuración de software que funcionó perfectamente bien durante años ahora no funciona debido a un comportamiento más nuevo que comúnmente utilizan muchas direcciones de correo electrónico. Si intenta hacer cosas inusuales, como usar DNS dinámico en un proveedor de Internet más lento, es más probable que encuentre algunos problemas adicionales en el camino. Como suena ambicioso, tal vez pueda invertir esfuerzos en eso. Sólo te advierto que te prepares para tener que hacer eso.
... ¿con respecto a qué método (pago o bricolaje) podría ser mejor?
Como otros han señalado, pagar será mucho más fácil y bastante económico para la mayoría de las personas. Es probable que los proveedores grandes proporcionen una dirección IP estable a la que pueda apuntar su registro MX (por lo que el correo electrónico va allí) y pueden proporcionar un ancho de banda notablemente mejor.
El bricolaje es mejor para adquirir experiencia y aprender cómo funcionan las cosas, y para elegir no depender únicamente de implementaciones de grandes corporaciones. Tener más control sobre su implementación también puede permitirle realizar cambios personalizados importantes mucho más rápidamente.
Cuál es "mejor" dependerá de sus objetivos individuales, por lo que dejo esas conclusiones a su criterio.
Respuesta4
Otras respuestas ya han explicado la parte DDNS.
voy a explicarpor quétienes que usar un servidor separado para enviar correo electrónico (ya que la breve explicación de @Alex está incompleta).
Lo más importante es que necesita un registro PTR inverso válido para enviar correo electrónico; muchos servidores de correo electrónico lo comprobarán y rebotarán su correo si el registro DNS inverso para la dirección IP no coincide con el dominio del remitente. Este registro lo proporciona el propietario de la dirección IP, por ejemplo, su ISP.
Ahora imaginemos que de alguna manera ha obtenido un DNS inverso válido y actualizado dinámicamente (ja, ja). Aún tienes que convencer a todos de que tu dominio es legítimo y que tu correo electrónico saliente no es spam.
Como explica @Alex, a los proveedores de alojamiento de correo de poca monta les encanta utilizar spamhaus y otras listas negras en línea. Pero he visto a esos administradores corporativos hacer muchas otras cosas tontas (como bloquear todo el correo electrónico que no proviene de Gmail/Hotmail). En realidad, no se trata sólo de algunos "administradores corporativos": he vistoForja de fuentebloquear el registro desde un dominio de correo electrónico corporativo legítimo, porque "no sabemos por qué, pero nuestro filtro de spam piensa que eres malo". Simplemente ignóralos: no puedes seguir siendo compatible con todos los que están bajo el cielo.
Los grandes proveedores de alojamiento de correo hoy en día no dependen de spamhaus u otros PBL. Ellos mismos rastrean su confiabilidad. La reputación del remitente (al menos la mayor parte) está adjunta a la IP. Esto se debe a que los spammers frecuentemente reciben un arranque de sus proveedores de alojamiento, por lo que se ven obligados a cambiar de IP. Desde el punto de vista de Gmail, su dominio/IP creado recientemente no es diferente del spammer común. Cuando comienzas a enviar correo electrónico, tu reputación es baja (¡te tratan como spammer de forma predeterminada!). La mayor parte de su correo electrónico saliente se marcará como spam. Cuando alguien responde a su correo electrónico o lo marca especialmente como legítimo (presionando el botón correspondiente en la interfaz web de su proveedor de correo electrónico), la confianza hacia usted aumentará ligeramente. Como puede ver, para aumentar la reputación del remitente, tendría que utilizar el mismo dominio en la misma IP durante años. Esto no se puede hacer de manera confiable con IP dinámica.
Una vez que alquiles un VPS a un proveedor de alojamiento, mantener un servidor doméstico con IP dinámica será mucho más fácil. Podrá utilizar ese VPS como su propio servidor DDNS con un TTL extremadamente bajo. Incluso podrías renunciar al DNS y utilizar otros medios (como la redirección HTTP) para gestionar el cambio de IP de tu equipo de inicio. Aún podrá recibir correos electrónicos directamente en su casilla de inicio, opcionalmente con respaldo al VPS, cuando la IP de su hogar no funcione o haya cambiado recientemente.