Público, privado, estático e dedicado são propriedades de endereço independentes. Construa um mapa de implementação que abranja também o encaminhamento, as firewalls, o DNS direto, o DNS inverso e o TLS, e verifique cada definição com a parte que a controla.
As propriedades dos endereços respondem a perguntas diferentes
Público e privado descrevem onde um endereço se destina a ser encaminhado. Estático e dinâmico descrevem como uma atribuição se comporta ao longo do tempo. Dedicado e partilhado descrevem como um endereço é utilizado ou alocado dentro de um serviço. São propriedades separadas: um endereço público estável pode servir muitos sites, e um endereço privado pode ser atribuído dinamicamente dentro de uma rede controlada.
Escreva o papel de cada endereço na implementação: ponto de entrada público, base de dados interna, rota de gestão ou ligação de saída. Em seguida, identifique quem o atribui e o que pode mudar. Isto evita que o trabalho de configuração dependa de uma suposição como dedicado significa permanentemente fixo ou público significa que o serviço é alcançável. A alcançabilidade também depende do encaminhamento, das firewalls e do listener da aplicação.
O endereçamento privado continua a precisar de encaminhamento e controlo de acesso
O RFC 1918 reserva os intervalos IPv4 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 para redes privadas. Os seus endereços não são destinos públicos globalmente únicos. Uma rede pode traduzir endereços privados para ligações de saída ou ligar redes privadas através de rotas explícitas. Um serviço de entrada atrás de tradução precisa de um método de publicação deliberado; alterar apenas um registo DNS não cria essa rota.
O IPv6 tem os seus próprios tipos e âmbitos de endereço, incluindo endereçamento link-local e endereços unicast globalmente encaminháveis. Reveja-o separadamente, em vez de assumir que uma regra de firewall ou tradução IPv4 cobre o IPv6. Um endereço privado não é um mecanismo de autenticação, e um endereço IPv6 público não é motivo para expor todos os serviços. Teste o acesso a partir de cada rede relevante e restrinja a administração no limite adequado.
Nomes estáveis e endereços estáveis estão relacionados
O DHCP aloca configuração de endereço através de um protocolo e pode utilizar concessões. Um endereço atribuído dinamicamente pode permanecer inalterado durante algum tempo; isso não torna a sua permanência uma garantia contratual. Quando uma aplicação depende de um endereço estável, verifique a política de atribuição e alteração do fornecedor, em vez de a inferir a partir da ligação de ontem.
O DNS dinâmico pode atualizar um nome após uma alteração de endereço, mas os clientes podem continuar a colocar em cache a resposta anterior. Também não consegue superar um listener inalcançável, uma rota de entrada em falta ou tradução de endereços de nível de operadora. Utilize-o quando a rede permite a ligação e a aplicação tolera atrasos de atualização. Para uma implementação alojada, documente o ciclo de vida do endereço pretendido antes de construir listas de permissões ou integrações externas em torno dele.
| Propriedade | O que confirmar | Suposição errada comum |
|---|---|---|
| Público ou privado | Âmbito de encaminhamento e caminho de acesso | Um endereço por si só torna um serviço alcançável |
| Estático ou dinâmico | Política de atribuição e alteração | Uma concessão inalterada é permanente |
| Dedicado ou partilhado | Alocação e utilização permitida | Um endereço dedicado fornece identidade anónima |
| IPv4 ou IPv6 | Configurações de encaminhamento e de firewall | As definições de um protocolo cobrem o outro |
O DNS direto e o DNS inverso têm proprietários diferentes
O DNS direto mapeia nomes para dados como registos de endereço A e AAAA. O DNS inverso utiliza um espaço de nomes relacionado com endereços e registos PTR para associar um endereço a um nome. A organização que controla a zona DNS direta não é necessariamente a organização que controla o DNS inverso para o intervalo de endereços. Obtenha o caminho de configuração correto antes de prometer um nome inverso.
Verifique o registo através do resolver adequado e registe o resultado. Para um PTR destinado a identificar um host, verifique também se o registo direto correspondente aponta para o endereço esperado. O DNS inverso pode apoiar a identificação operacional e algumas verificações de sistemas de correio, mas não autentica uma aplicação nem garante a entrega de mensagens. O envio de correio também precisa da sua própria revisão de domínio, reputação e autenticação.
Não é necessário um endereço dedicado para cada site HTTPS
O encaminhamento de host HTTP e a extensão Server Name Indication do TLS permitem que clientes e servidores suportados selecionem um site ou certificado por nome. Vários sites HTTPS podem, portanto, utilizar um endereço sem exigir um endereço público por domínio. A configuração real de alojamento e os clientes necessários determinam se essa disposição é adequada.
Escolha um endereço adicional apenas quando um requisito documentado o exigir, como uma separação de rede suportada ou um sistema externo que espera um endpoint distinto. Um endereço não fornece imunidade a problemas de reputação nem identifica a pessoa que opera um serviço. Mantenha os certificados, o encaminhamento de hostname e a alocação de endereços como verificações separadas. Verifique o certificado servido através do hostname que os utilizadores irão realmente visitar.
Utilize um mapa de implementação antes de alterar registos
Crie um pequeno mapa que contenha cada hostname, registo de endereço, listener, caminho de firewall e parte responsável. Inclua administração, cópias de segurança e quaisquer listas de permissões de saída. Verifique se a configuração SwissOctet lista a opção de endereço de que necessita e pergunte sobre o controlo do DNS inverso antes de confiar nele. Não apresente opções de catálogo como uma atribuição ativa que já foi provisionada.
Durante uma migração, prepare a aplicação de destino e as definições TLS antes de direcionar os utilizadores para lá. Tenha em conta as caches DNS e mantenha um caminho de recuperação viável. Verifique separadamente a resolução direta, a alcançabilidade real da aplicação e o nome inverso esperado. O mapa torna as falhas mais fáceis de localizar, porque um registo errado, uma porta fechada e um certificado incompatível são problemas diferentes com proprietários diferentes.
A sua lista de verificação prática.
- Mapeie o papel do endereço, a atribuição e a propriedade.
- Verifique IPv4 e IPv6 separadamente.
- Verifique o encaminhamento de entrada antes de confiar no DNS.
- Identifique quem controla os registos PTR.
- Teste o hostname, o certificado e a aplicação em conjunto.
Os detalhes que importam.
Um IP dedicado torna um serviço anónimo?+
Não. Descreve uma disposição de alocação ou utilização, não uma identidade ou garantia de privacidade. Contas, tráfego e dados de aplicação têm implicações separadas.
Posso definir registos PTR a partir do painel DNS do meu domínio?+
Apenas se este também controlar a zona inversa relevante. O fornecedor do endereço controla habitualmente essa zona ou fornece um processo de pedido separado.
Cada domínio HTTPS precisa do seu próprio endereço?+
Não necessariamente. Clientes e servidores suportados podem utilizar encaminhamento baseado em nome e TLS SNI. Verifique os requisitos reais de alojamento e de cliente.
Vá à fonte.
Estas referências sustentam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema de produção.
- RFC 1918: Alocação de endereços para internets privadas www.rfc-editor.org
- RFC 2131: Dynamic Host Configuration Protocol www.rfc-editor.org
- RFC 1035: Implementação e especificação do DNS www.rfc-editor.org
- RFC 4291: Arquitetura de endereçamento IPv6 www.rfc-editor.org
- RFC 6066: Extensões TLS, incluindo Server Name Indication www.rfc-editor.org
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. As especificações de serviço, as opções disponíveis e as condições contratuais devem ser verificadas separadamente.