Estou tentando estabelecer um servidor de correio/calendário pessoal em minha casa (sim, ouvi dizer que é difícil, dá muitos problemas e assim por diante, mas ainda gostaria de tentar). Eu tenho um ISP que não oferece endereços IP estáticos, então parece que algum tipo de Serviço de Nome de Domínio Dinâmico (DDNS) é a solução.
No entanto, tenho feito pesquisas e encontrei pelo menos alguns recursos on-line que explicam que você mesmo pode fazer DDNS: você precisa ter um script/programa que monitore seu endereço IP periodicamente e, se o endereço mudar , então o script/aplicativo precisa atualizar qualquer nome de domínio que você esteja usando para seus servidores domésticos (acontece que tenho um domínio estacionado em um provedor de hospedagem apenas para essa eventualidade e, pelo que entendi, só preciso da chave API de a empresa de hospedagem para ajustar programaticamente os registros de domínio/IP necessários...alguém me avise se estou errado nisso e há uma maneira mais simples).
O problema é o seguinte: quando você atualiza seus registros de nome de domínio da maneira que descrevi acima, li que pode levar várias horas para se propagar por todo o sistema/mundo (todos os servidores DNS devem ser repovoados com seu endereço atualizado ). No entanto, vários provedores de DDNS pagos que tenho procurado parecem promover sua capacidade de fazer com que a mudança entre em vigor quase instantaneamente (ou pelo menos mais rápido que meu método DIY). Isso é verdade? Há algo que eu perdi?
Além disso, tenho outra preocupação: há algum problema de segurança que eu possa estar ignorando ao ter um provedor de DDNS? Eles não conseguirão monitorar todo o tráfego que flui através do nome de domínio que fornecem? Alguém tem uma opinião informada sobre qual método (pago vs. DIY) pode ser melhor?
Agradeço seu tempo... obrigado!
Responder1
Estou tentando estabelecer um servidor de correio/calendário pessoal em minha casa (sim, ouvi dizer que é difícil, dá muitos problemas e assim por diante, mas ainda gostaria de tentar).
Você provavelmente não terá muita sorte com a parte do correio. Veja a resposta de @Alex.
você precisa ter um script/programa que monitore seu endereço IP periodicamente e, se o endereço mudar, o script/aplicativo precisará atualizar qualquer nome de domínio que você esteja usando para seus servidores domésticos
Praticamente isso.
Eu só preciso da chave API da empresa de hospedagem para ajustar programaticamente os registros de domínio/IP necessários
Sim, embora se a empresa fornecer apenas um serviço genérico de "hospedar tudo", ela poderá não ter nenhuma API de gerenciamento de DNS (concentrando-se na Web e no correio) e talvez seja necessário mover o domínio para outro lugar.
O problema é o seguinte: quando você atualiza seus registros de nome de domínio da maneira que descrevi acima, li que pode levar várias horas para se propagar por todo o sistema/mundo (todos os servidores DNS devem ser repovoados com seu endereço atualizado ).
Não. Apenas os sistemas do seu provedor de hospedagem DNS precisam ser atualizados. O resto do mundo não mantém um registro permanente – ele apenas armazena em cache os resultados de pesquisas individuais, pela duração indicada no campo "TTL" (Time To Live) de cada (sub)domínio.
No entanto, vários provedores de DDNS pagos que tenho procurado parecem promover sua capacidade de fazer com que a mudança entre em vigor quase instantaneamente (ou pelo menos mais rápido que meu método DIY). Isso é verdade? Há algo que eu perdi?
Eu acho que eles permitem configurar um TTL muito baixo nos domínios dinâmicos (até alguns segundos), o que significa que ele sairá de qualquer cache muito rapidamente, ao custo do próprio provedor de DDNS receber muito mais solicitações (maior carga em seus servidores DNS e bancos de dados e uma desculpa para cobrar mais). Isso por si só não é algo especial e pode ser implementado com qualquer método DIY.
Eles não conseguirão monitorar todo o tráfego que flui através do nome de domínio que fornecem?
Não. O servidor DNS fornece apenas um endereço (como uma lista telefônica) e não está envolvido em nenhuma comunicação posterior.
(A menos que o provedor realmente tenteretornar dados falsos, o que reduziria consideravelmente o TTL da empresa no momento em que os sites de notícias tomassem conhecimento dela.)
Dito isto, preste atenção em como a API funciona; é claro que você não pode ter certeza de que o serviço não possui vulnerabilidades, mas se (por exemplo) a API for executada em HTTP não criptografado e transmitir a chave da API à vista de todos, então isso não é algo em que você queira confiar.
Responder2
Se você não tiver um IP estático, então você deve esquecer o servidor de e-mail. Se você optar pela solução DDNS, a maioria dos servidores de e-mail rejeitaria seus e-mails ou marcaria os e-mails com o nível de spam mais alto, já que todos os IPs dinâmicos estão emPBLlistas. (Você pode ver mais detalhes na seção PS porque não é uma boa ideia ter um servidor de e-mail em IP residencial, mas ainda há uma solução alternativa usando VPS intermediário barato (servidor virtual privado))
Em relação ao "DDNS você mesmo" - um bom registrador de domínio que fornece atualização gratuita de IP por meio de sua API, tudo o que seu programa precisa fazer é verificar periodicamente o IP público e, se ele for alterado, enviar um novo IP ao registrador que atualizará o registro A (AAAA). Aliás, a maioria dos roteadores atuais já possui esse recurso (observe o IP e reporte ao provedor DDNS)
Eu li que pode levar várias horas para se propagar por todo o sistema/mundo
Depende do provedor de DNS, registradores respeitosos permitem definir o TTL (tempo que informa aos outros com que frequência o IP pode ser alterado) igual a 5 minutos. Nem todos os servidores DNS intermediários de encaminhamento seguem isso para evitar carga elevada, mas geralmente, mesmo que não sigam o TTL do proprietário do domínio, isso raramente dura mais do que algumas horas. A maioria dos encaminhadores atualizará seus caches conforme você definiria no TTL do domínio.
há algum problema de segurança que eu possa estar ignorando ao ter um provedor de DDNS?
Ficar online já é um possível problema de segurança. Isole seu servidor da rede local para evitar convidados indesejados.
Alguém tem uma opinião informada sobre qual método (pago vs. DIY) pode ser melhor?
Você gastará seu tempo e dinheiro se optar pelo DDNS. Hoje em dia você pode obter um VPS (servidor virtual privado) decente por 3-4 dólares por mês. Embora o site (se você planeja ter um) possa ser hospedado diretamente no VPS, já que normalmente não ocupa muito espaço, o servidor de e-mail pode ser problemático se você espera executar o servidor por um longo tempo ou espera um grande volume de e-mails. Normalmente, 20 GB de espaço são suficientes para pequenas empresas de 3 a 5 anos, mesmo sem excluir e-mails antigos. Mesmo se você espera uma grande quantidade de e-mails, pode usar nginxo recurso para proxy do tráfego de e-mail para sua casa. Assim, você pode hospedar o servidor de e-mail primário em casa em IP dinâmico e o VPS (que possui IP estático) fará proxy do tráfego de entrada/saída para sua casa. Você pode usar seu próprio VPS nessa configuração sem problemas, pois não há necessidade de se preocupar com a propagação do DNS, o domínio estará sempre apontando para o IP estático do VPS. Você ainda precisa gerenciar o relatório das alterações de IP de sua casa para o VPS, para que o VPS saiba onde fazer o proxy do tráfego, mas é muito mais fácil, basta consultar algum URL no seu VPS e analisar nos registros seu IP de entrada e ajustar o nginx, para que ele sempre saiba onde você está.
PS
Percebo que este tópico é interessante para superusuários, então acrescentaria mais alguns detalhes.
PBLlistas contém banco de dados de IPs que geralmente são IPs dinâmicos, entãoPBL ajuda muito aos operadores de servidores de e-mail. Não é um problema técnico ou o ISP é um vilão não permitir servidores de e-mail em IPs dinâmicos, o problema é que a maior parte do tráfego de e-mail de IPs dinâmicos vem de computadores infectados que enviam spam ou malware em grandes volumes que podem facilmenteDDoSservidor receptor se um for um alvo. Alguns ISPs bloqueiam conexões de saída para a porta 25 para evitar a propagação de malware eDDoS, mas alguns não. Praticamente todos os servidores de e-mail corporativo simplesmente descartam conexões provenientesPBLlista que reduz significativamente o spam.
A segunda solução antispam eficaz é eliminar conexões de IPs que não possuem registro PTR reverso no DNS e não correspondem ao registro DNS do domínio. Mesmo que as conexões venham de IP estático que não tenham registro PTR, geralmente é uma configuração mal configurada ou vem principalmente de servidores executados por gangues de spam (pode haver exclusões para alguns provedores grandes (mas descuidados), mas eles podem ser adicionados manualmente na lista branca). Embora seja uma questão de alguns minutos para definir o registro PTR reverso no VPS, não é o caso se os IPs estáticos obtidos do ISP e o processo para definir o PTR forem geralmente um PITA (é necessário ligar para eles, enviar um ticket após verificação que você é o proprietário original do IP e espera pela misericórdia de seu administrador de sistema que precisa definir o registro PTR reverso, às vezes em algumas horas, mas às vezes em dias)
Além disso, não é crítico, mas... para evitar falsificação de e-mail, a maioria dos proprietários de servidores de e-mail usam os chamadosFPS(estrutura de política do remetente) que permite especificar o método de processamento de política mais rápido se for definido no DNS endereços IP autorizados que permitem o envio de e-mails em nome do domínio. (pode-se especificar servidores autorizados porFQDNcomo referência ao registro MX, mas faz viagens extras pelo DNS para conectar servidores). Portanto, gerenciar IP flutuante no DNS não seria divertido.
Responder3
Eu tenho um ISP que não oferece endereços IP estáticos, então parece que algum tipo de Serviço de Nome de Domínio Dinâmico (DDNS) é a solução.
Essa é uma solução. Como exemplo de outra solução, um túnel HurricaneElectric.net IPv6 fornece um endereço estático (IPv6) com um terminal de túnel móvel. É verdade que, neste momento, o IPv4 seria mais agradável para suportar tal funcionalidade com o público em geral, mas se você puder encontrar um computador cooperativo disposto, você poderia tecnicamente fazer isso com o IPv4 também.
você precisa ter um script/programa que monitore seu endereço IP periodicamente e, se o endereço mudar, o script/aplicativo precisará atualizar qualquer nome de domínio que você esteja usando
Parece um plano tecnicamente sólido.
Eu só preciso da chave API da empresa de hospedagem para ajustar programaticamente os registros de domínio/IP necessários... alguém me avise se estiver errado nisso e há uma maneira mais simples).
Os detalhes exatos dependeriam da escolha do registrador de nomes de domínio sobre como implementar esse recurso. Alguns podem usar algum tipo de chave de API, enquanto outros podem contar com uma interface da web para atualizações automáticas. Antigamente, alguns ISPs forneciam esse serviço, mas dependiam de alterações manuais em resposta às solicitações. Portanto, depende inteiramente de quem lhe fornece o serviço.
O problema é o seguinte: quando você atualiza seus registros de nome de domínio da maneira que descrevi acima, li que pode levar várias horas para se propagar por todo o sistema/mundo (todos os servidores DNS devem ser repovoados com seu endereço atualizado ).
Bah farsa. Sabe-se que a propagação do DNS leva minutos, horas ou dias (por exemplo, 72 horas). No entanto, quando as pessoas analisaram profundamente as coisas, descobriram que grande parte desse vago tempo de "propagação" era simplesmente devido à lentidão da atualização de um provedor de hospedagem DNS.
Em teoria melhor, você só precisa esperar pelo valor TTL. Embora haja um problema com essa teoria ...
No entanto, vários provedores de DDNS pagos que tenho procurado parecem promover sua capacidade de fazer com que a mudança entre em vigor quase instantaneamente (ou pelo menos mais rápido que meu método DIY). Isso é verdade? Há algo que eu perdi?
Ok, a realidade é a seguinte: para que sua atualização tenha efeito total, você precisará que a Internet libere seu cache ativo de informações antigas.
De acordo com os padrões, o cache dos servidores DNS pode depender de seu cache pelo período de tempo especificado por um valor TTL que você pode configurar.
No entanto, a realidade é que pelo menos alguns (e talvez até a maioria?) ISPs muito grandes executam seus próprios servidores DNS de cache, que ignoram completamente os valores TTL. Eles fazem isso porque sentem que, se atualizarem seus caches DNS com menos frequência, o efeito geral será menos largura de banda (e talvez menos tempo de computação).
Portanto, qualquer servidor de e-mail que dependa desse servidor DNS pode ser afetado e não conseguir perceber suas atualizações até que o servidor DNS seja atualizado. Em alguns casos, isso pode levar um ou dois dias (ou três?).
No entanto, tais efeitos tornaram-se cada vez mais raros. Na prática, a maioria dos servidores DNS terá seus caches liberados dentro de uma ou duas horas.
Como alguns caches não serão atualizados tão rapidamente quanto outros, o efeito é que alguns locais na Internet funcionarão com o novo endereço, enquanto outros ainda tentarão usar o endereço antigo. Dentro de algumas horas, a maioria dos computadores funcionará perfeitamente com as novas informações. (Muitos, muitos deles podem funcionar em minutos.)
O comportamento típico do software de E-Mail é tentar enviar o E-Mail. Se isso falhar, tente novamente mais tarde. Os servidores de e-mail normalmente continuarão tentando novamente (talvez uma vez por hora) durante dias antes de desistirem. Então o que provavelmente acontecerá é que você não perderá o e-mail, mas ele atrasará um pouco.
O comentário de Alex "todos os IPs dinâmicos estão em listas PBL" está claramente errado, pois esta informação é descentralizada (portanto a palavra "todos" é imprecisa), mas é verdade que muitos IPs dinâmicos estão nessas listas, e então isso pode significa que alguns computadores/dispositivos relacionados ao e-mail podem decidir não cooperar com você.
Além disso, tenho outra preocupação: há algum problema de segurança que eu possa estar ignorando ao ter um provedor de DDNS?
A maior preocupação será se suas atualizações serão tratadas de forma segura.
Eles não conseguirão monitorar todo o tráfego que flui através do nome de domínio que fornecem?
Não. A função do servidor DNS é receber uma solicitação de nome de domínio e fornecer uma resposta. A resposta típica tradicional é fornecer um ou mais endereços IP. Outras respostas são possíveis, como referir-se a outro servidor DNS ou nome de domínio (por exemplo, com um CNAME), ou outros dados (por exemplo, ajudar a fornecer segurança através do padrão DNSSec mais recente).
Alguém tem uma opinião informada ...
Gostaria de salientar que se você realmente deseja executar um servidor de e-mail sério, considere estar em conformidade com os padrões modernos de e-mail. Isso envolve mais do que apenas estar em conformidade com as especificações técnicas de SMTP e DNS. Muitas pessoas usam grandes provedores, e esses grandes provedores podem implementar suas próprias expectativas.
Por exemplo, conheço um servidor de e-mail que foi configurado com Debian e Postgrey anos atrás. Postgrey é um software que fornece tratamento anti-spam de "lista cinza". No entanto, a versão do Postgrey usada pressupõe que quando um servidor de e-mail tenta enviar novamente o e-mail, o servidor de e-mail remetente usará o mesmo endereço IP ao fazê-lo. Sabe-se que os servidores de email do Office 365 tentam enviar novamente um email de um endereço IP diferente que ainda está dentro de uma sub-rede IPv6/64. Postgrey não gosta disso.
À medida que mais e mais organizações migraram para o Office 365, isso se tornou um problema cada vez maior para as pessoas que usam o antigo servidor de e-mail. Uma versão mais recente do software Postgrey foi lançada, mas a maneira mais fácil de instalar esse software é usar o repositório de software oficial desse sistema operacional. Então, na prática, a maneira inteligente de atualizar esse software será atualizar o sistema operacional.
Existem outras convenções, como nomes DNS que começam com “mail”. o que pode fazer com que sua configuração seja considerada mais ou menos confiável. Isso pode afetar se os dispositivos tratam você como um spammer incompatível ou como um dispositivo com o qual vale a pena se comunicar.
Claro, talvez ao falar muito estritamente sobre especificações técnicas oficiais, organizações gigantes estejam realizando algumas ações diferentes dos requisitos mínimos exigidos pelos documentos RFC que contêm as especificações técnicas dos protocolos utilizados. Mas se você quiser se comunicar com a comunidade mais ampla da Internet, existem alguns padrões adicionais que são impostos por alguns participantes significativos/grandes. Esteja preparado para atender bem a esses padrões ou para encontrar alguns problemas.
Estou sendo um pouco vago sobre o que exatamente são todos esses padrões, porque eles podem mudar com o tempo.
Em relação ao antigo servidor de e-mail que precisará atualizar seu antigo sistema operacional Debian, talvez as pessoas devessem atualizar seu sistema operacional com mais frequência de qualquer maneira. O que quero dizer, porém, é que uma configuração de software que funcionou perfeitamente bem durante anos agora está quebrada, devido ao comportamento mais recente que é comumente usado por muitos endereços de e-mail. Se você tentar fazer coisas incomuns, como usar DNS dinâmico em um provedor de Internet mais lento, é mais provável que você encontre alguns problemas extras ao longo do caminho. Como você parece ambicioso, talvez possa investir esforços nisso. Só estou avisando para você se preparar para fazer isso.
... em relação a qual método (pago vs. DIY) pode ser melhor?
Como outros apontaram, pagar será muito mais fácil e bastante econômico para a maioria das pessoas. É provável que grandes fornecedores forneçam um endereço IP estável para o qual seu registro MX possa apontar (para que o e-mail vá para lá) e possam fornecer largura de banda notavelmente melhor.
DIY é melhor para ganhar experiência e aprender como as coisas funcionam, e optar por não depender apenas de implementações de grandes corporações. Ter mais controle sobre sua implementação também pode permitir que você faça alterações personalizadas significativas com muito mais rapidez.
O que é “melhor” dependerá de seus objetivos individuais, por isso deixo essas conclusões para você.
Responder4
Outras respostas já explicaram a parte do DDNS.
eu vou explicarpor quevocê precisa usar um servidor separado para enviar e-mail (já que a breve explicação de @Alex está incompleta).
Mais importante ainda, você precisa de um registro PTR reverso válido para enviar e-mail – muitos servidores de e-mail irão verificá-lo e devolver seu e-mail, se o registro DNS reverso para o endereço IP não corresponder ao domínio do remetente. Este registro é fornecido pelo proprietário do endereço IP – por exemplo, pelo seu ISP.
Agora vamos imaginar que você de alguma forma obteve um DNS reverso válido e atualizado dinamicamente (ha-ha). Você ainda precisa convencer a todos de que seu domínio é legítimo e que seu e-mail enviado não é spam.
Conforme explicado por @Alex, os pequenos hosters de e-mail adoram usar spamhaus e outras listas negras online. Mas tenho visto esses administradores corporativos fazerem muitas outras coisas estúpidas (como bloquear todos os e-mails que não venham do Gmail/Hotmail). Na verdade, não são apenas alguns "administradores corporativos" - já viFonteforjabloquear o registro de um domínio de e-mail corporativo legítimo, porque "não sabemos por que, mas nosso filtro de spam pensa que você é mau". Apenas ignore-os – você não pode permanecer compatível com todos no céu.
Hoje em dia, grandes hosters de e-mail não dependem de spamhaus ou outros PBL. Eles próprios rastreiam sua confiabilidade. A reputação do remetente (pelo menos a maior parte) está ligada ao IP. Isso ocorre porque os spammers frequentemente são expulsos de seus hosters, então eles são forçados a pular IPs. Do ponto de vista do Gmail, seu domínio/IP recentemente criado não é diferente do spammer comum. Quando você começa a enviar e-mails, sua reputação é baixa (você é tratado como spammer por padrão!). A maior parte dos seus e-mails enviados será marcada como spam. Quando alguém responde ao seu e-mail ou o marca especialmente como legítimo (pressionando o botão correspondente na interface web do provedor de e-mail), a confiança em você aumentará ligeiramente. Como você pode ver, para aumentar a reputação do remetente, você teria que usar o mesmo domínio no mesmo IP ao longo dos anos. Isso não pode ser feito de forma confiável com IP dinâmico.
Depois de alugar um VPS do hoster, manter um servidor doméstico em IP dinâmico se tornará muito mais fácil. Você poderá usar esse VPS como seu próprio servidor DDNS com TTL extremamente baixo. Você pode até mesmo renunciar ao DNS e usar outros meios (como o redirecionamento HTTP) para lidar com a alteração do IP da sua caixa inicial. Você ainda poderá receber e-mails diretamente em sua caixa inicial – opcionalmente com fallback para o VPS, quando seu IP residencial estiver inativo ou alterado recentemente.