Pública, privada, estática y dedicada son propiedades de dirección independientes. Construya un mapa de despliegue que también cubra enrutamiento, firewalls, DNS directo, DNS inverso y TLS, y verifique cada configuración con la parte que la controla.
Las propiedades de las direcciones responden a preguntas diferentes
Pública y privada describen dónde se pretende enrutar una dirección. Estática y dinámica describen cómo se comporta una asignación a lo largo del tiempo. Dedicada y compartida describen cómo se usa o asigna una dirección dentro de un servicio. Estas son propiedades separadas: una dirección pública estable puede servir a muchos sitios, y una dirección privada puede asignarse dinámicamente dentro de una red controlada.
Escriba el rol de cada dirección en el despliegue: punto de entrada público, base de datos interna, ruta de administración o conexión saliente. Luego identifique quién la asigna y qué puede cambiar. Esto evita que el trabajo de configuración dependa de una suposición como que dedicada significa permanentemente fija o que pública significa que el servicio es accesible. La accesibilidad también depende del enrutamiento, los firewalls y el listener de la aplicación.
El direccionamiento privado aún necesita enrutamiento y control de acceso
RFC 1918 reserva los rangos IPv4 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16 para redes privadas. Sus direcciones no son destinos públicos únicos a nivel global. Una red puede traducir direcciones privadas para conexiones salientes o conectar redes privadas mediante rutas explícitas. Un servicio entrante detrás de traducción necesita un método de publicación deliberado; cambiar solo un registro DNS no crea esa ruta.
IPv6 tiene sus propios tipos y ámbitos de dirección, incluido el direccionamiento de enlace local y las direcciones unicast enrutables globalmente. Revíselo por separado en lugar de asumir que una regla de firewall o traducción de IPv4 cubre IPv6. Una dirección privada no es un mecanismo de autenticación, y una dirección IPv6 pública no es razón para exponer todos los servicios. Pruebe el acceso desde cada red relevante y restrinja la administración en el límite adecuado.
Los nombres estables y las direcciones estables están relacionados
DHCP asigna la configuración de direcciones mediante un protocolo y puede usar concesiones. Una dirección asignada dinámicamente puede permanecer sin cambios durante algún tiempo; eso no convierte su permanencia en una garantía contractual. Cuando una aplicación depende de una dirección estable, verifique la política de asignación y cambio del proveedor en lugar de inferirla a partir de la conexión de ayer.
El DNS dinámico puede actualizar un nombre después de que cambie una dirección, pero los clientes aún pueden almacenar en caché la respuesta anterior. Tampoco puede superar un listener inaccesible, una ruta entrante faltante o la traducción de direcciones de nivel de operador. Úselo cuando la red permita la conexión y la aplicación tolere retrasos de actualización. Para un despliegue alojado, documente el ciclo de vida previsto de la dirección antes de construir listas de permitidos o integraciones externas en torno a ella.
| Propiedad | Qué confirmar | Suposición errónea común |
|---|---|---|
| Pública o privada | Ámbito de enrutamiento y ruta de acceso | Una dirección por sí sola hace que un servicio sea accesible |
| Estática o dinámica | Política de asignación y cambio | Una concesión sin cambios es permanente |
| Dedicada o compartida | Asignación y uso permitido | Una dirección dedicada proporciona identidad anónima |
| IPv4 o IPv6 | Tanto las configuraciones de enrutamiento como las de firewall | La configuración de un protocolo cubre la del otro |
DNS directo y DNS inverso tienen propietarios diferentes
El DNS directo asigna nombres a datos como los registros de dirección A y AAAA. El DNS inverso usa un espacio de nombres relacionado con direcciones y registros PTR para asociar una dirección con un nombre. La organización que controla la zona DNS directa no es necesariamente la organización que controla el DNS inverso para el rango de direcciones. Obtenga la ruta de configuración correcta antes de prometer un nombre inverso.
Verifique el registro a través del resolutor adecuado y registre el resultado. Para un PTR destinado a identificar un host, verifique también si el registro directo correspondiente apunta a la dirección esperada. El DNS inverso puede respaldar la identificación operativa y algunas comprobaciones de sistemas de correo, pero no autentica una aplicación ni garantiza la entrega de mensajes. El envío de correo también necesita su propia revisión de dominio, reputación y autenticación.
No se requiere una dirección dedicada para cada sitio HTTPS
El enrutamiento de host de HTTP y la extensión Server Name Indication de TLS permiten que los clientes y servidores compatibles seleccionen un sitio o certificado por nombre. Varios sitios HTTPS pueden por lo tanto usar una dirección sin requerir una dirección pública por dominio. La configuración de alojamiento real y los clientes requeridos determinan si ese arreglo es adecuado.
Elija una dirección adicional solo cuando un requisito documentado la exija, como una separación de red admitida o un sistema externo que espere un endpoint distinto. Una dirección no proporciona inmunidad frente a problemas de reputación ni identifica a la persona que opera un servicio. Mantenga los certificados, el enrutamiento por nombre de host y la asignación de direcciones como verificaciones separadas. Verifique el certificado servido a través del nombre de host que los usuarios visitarán realmente.
Use un mapa de despliegue antes de cambiar registros
Cree un mapa pequeño que contenga cada nombre de host, registro de dirección, listener, ruta de firewall y parte responsable. Incluya administración, copias de seguridad y cualquier lista de permitidos saliente. Verifique si la configuración de SwissOctet lista la opción de dirección que necesita y pregunte sobre el control del DNS inverso antes de depender de él. No presente las opciones del catálogo como una asignación activa que ya se ha aprovisionado.
Durante una migración, prepare la aplicación de destino y la configuración de TLS antes de dirigir a los usuarios allí. Tenga en cuenta las cachés de DNS y mantenga una ruta de recuperación viable. Verifique por separado la resolución directa, la accesibilidad real de la aplicación y el nombre inverso esperado. El mapa facilita localizar fallos porque un registro incorrecto, un puerto cerrado y un certificado no coincidente son problemas diferentes con propietarios diferentes.
Su lista de verificación práctica.
- Asigne el rol de la dirección, la asignación y la propiedad.
- Verifique IPv4 y IPv6 por separado.
- Verifique el enrutamiento entrante antes de depender de DNS.
- Identifique quién controla los registros PTR.
- Pruebe el nombre de host, el certificado y la aplicación en conjunto.
Los detalles que importan.
¿Una IP dedicada hace que un servicio sea anónimo?+
No. Describe un arreglo de asignación o uso, no una garantía de identidad o privacidad. Las cuentas, el tráfico y los datos de la aplicación tienen implicaciones separadas.
¿Puedo configurar registros PTR desde el panel DNS de mi dominio?+
Solo si también controla la zona inversa relevante. El proveedor de la dirección comúnmente controla esa zona o proporciona un proceso de solicitud separado.
¿Cada dominio HTTPS necesita su propia dirección?+
No necesariamente. Los clientes y servidores compatibles pueden usar enrutamiento basado en nombres y SNI de TLS. Verifique los requisitos reales de alojamiento y de los clientes.
Vaya a la fuente.
Estas referencias respaldan los conceptos técnicos de esta guía. Consulte la documentación actual antes de cambiar un sistema de producción.
- RFC 1918: Asignación de direcciones para internets privadas www.rfc-editor.org
- RFC 2131: Protocolo de configuración dinámica de host www.rfc-editor.org
- RFC 1035: Implementación y especificación de DNS www.rfc-editor.org
- RFC 4291: Arquitectura de direccionamiento de IPv6 www.rfc-editor.org
- RFC 6066: Extensiones de TLS, incluida Server Name Indication www.rfc-editor.org
Orientación editorial de SwissOctet. Los ejemplos son ilustrativos. Las especificaciones del servicio, las opciones disponibles y las condiciones contractuales deben verificarse por separado.