Público, privado, estático e dedicado são propriedades de endereço independentes. Construa um mapa de implantação que também abranja roteamento, firewalls, DNS direto, DNS reverso e TLS, e verifique cada configuração com a parte que a controla.
As propriedades de endereço respondem a perguntas diferentes
Público e privado descrevem onde um endereço deve ser roteado. Estático e dinâmico descrevem como uma atribuição se comporta ao longo do tempo. Dedicado e compartilhado descrevem como um endereço é usado ou alocado dentro de um serviço. Essas 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 implantação: ponto de entrada público, banco de dados interno, rota de gerenciamento ou conexão de saída. Em seguida, identifique quem o atribui e o que pode mudar. Isso 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 é acessível. A acessibilidade também depende de roteamento, firewalls e do listener da aplicação.
O endereçamento privado ainda precisa de roteamento e controle de acesso
A 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. Seus endereços não são destinos públicos globalmente exclusivos. Uma rede pode traduzir endereços privados para conexões de saída ou conectar redes privadas por meio 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 registro DNS não cria essa rota.
O IPv6 tem seus próprios tipos e escopos de endereço, incluindo endereçamento link-local e endereços unicast globalmente roteáveis. Revise-o separadamente em vez de presumir 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 de cada rede relevante e restrinja a administração no limite apropriado.
Nomes estáveis e endereços estáveis estão relacionados
O DHCP aloca configuração de endereço por meio de um protocolo e pode usar concessões. Um endereço atribuído dinamicamente pode permanecer inalterado por algum tempo; isso não torna 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 mudança do provedor em vez de inferi-la da conexão de ontem.
O DNS dinâmico pode atualizar um nome depois que um endereço muda, mas os clientes ainda podem armazenar em cache a resposta anterior. Ele também não consegue superar um listener inacessível, uma rota de entrada ausente ou tradução de endereço de nível de operadora. Use-o quando a rede permitir a conexão e a aplicação tolerar atrasos de atualização. Para uma implantação hospedada, documente o ciclo de vida pretendido do endereço antes de criar listas de permissões ou integrações externas em torno dele.
| Propriedade | O que confirmar | Suposição equivocada comum |
|---|---|---|
| Público ou privado | Escopo de roteamento e caminho de acesso | Um endereço por si só torna um serviço acessível |
| Estático ou dinâmico | Política de atribuição e mudança | Uma concessão inalterada é permanente |
| Dedicado ou compartilhado | Alocação e uso permitido | Um endereço dedicado fornece identidade anônima |
| IPv4 ou IPv6 | Configurações de roteamento e de firewall | As configurações de um protocolo cobrem o outro |
DNS direto e DNS reverso têm proprietários diferentes
O DNS direto mapeia nomes para dados como registros de endereço A e AAAA. O DNS reverso usa um namespace relacionado a endereços e registros 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 reverso para o intervalo de endereços. Obtenha o caminho de configuração correto antes de prometer um nome reverso.
Verifique o registro por meio do resolvedor apropriado e registre o resultado. Para um PTR destinado a identificar um host, verifique também se o registro direto correspondente aponta para o endereço esperado. O DNS reverso pode apoiar a identificação operacional e algumas verificações de sistemas de e-mail, mas não autentica uma aplicação nem garante a entrega de mensagens. O envio de e-mail também precisa de sua própria revisão de domínio, reputação e autenticação.
Um endereço dedicado não é necessário para todo site HTTPS
O roteamento de host HTTP e a extensão Server Name Indication do TLS permitem que clientes e servidores compatíveis selecionem um site ou certificado por nome. Vários sites HTTPS podem, portanto, usar um endereço sem exigir um endereço público por domínio. A configuração real de hospedagem e os clientes necessários determinam se esse arranjo é adequado.
Escolha um endereço extra apenas quando um requisito documentado exigir um, como uma separação de rede compatível 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 certificados, roteamento de hostname e alocação de endereços como verificações separadas. Verifique o certificado servido por meio do hostname que os usuários realmente visitarão.
Use um mapa de implantação antes de alterar registros
Crie um pequeno mapa contendo cada hostname, registro de endereço, listener, caminho de firewall e parte responsável. Inclua administração, backups e quaisquer listas de permissões de saída. Verifique se a configuração do SwissOctet lista a opção de endereço de que você precisa e pergunte sobre o controle de DNS reverso antes de depender dele. 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 configurações de TLS antes de direcionar os usuários para lá. Leve em conta os caches DNS e mantenha um caminho de recuperação viável. Verifique separadamente a resolução direta, a acessibilidade real da aplicação e o nome reverso esperado. O mapa facilita localizar falhas porque um registro errado, uma porta fechada e um certificado incompatível são problemas diferentes com proprietários diferentes.
Sua lista prática.
- Mapeie o papel do endereço, a atribuição e a propriedade.
- Verifique IPv4 e IPv6 separadamente.
- Verifique o roteamento de entrada antes de depender do DNS.
- Identifique quem controla os registros 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. Ele descreve um arranjo de alocação ou uso, não uma identidade nem uma garantia de privacidade. Contas, tráfego e dados de aplicação têm implicações separadas.
Posso definir registros PTR no painel DNS do meu domínio?+
Somente se ele também controlar a zona reversa relevante. O provedor de endereços normalmente controla essa zona ou fornece um processo de solicitação separado.
Cada domínio HTTPS precisa de seu próprio endereço?+
Não necessariamente. Clientes e servidores compatíveis podem usar roteamento baseado em nome e SNI TLS. Verifique os requisitos reais de hospedagem e de cliente.
Vá à fonte.
Estas referências apoiam os conceitos técnicos deste guia. Siga a documentação atual antes de alterar um sistema em 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 do TLS, incluindo Server Name Indication www.rfc-editor.org
Orientação editorial da SwissOctet. Os exemplos são ilustrativos. Especificações de serviço, opções disponíveis e condições contratuais devem ser verificadas separadamente.