Cadena de dominio de nivel superior propuesta para uso privado: ".internal"

Artículo original ↗ Discusión en Hacker News ↗

El plan de ICANN de reservar el dominio de nivel superior “.internal” para redes privadas pretende ofrecer a las organizaciones un sufijo garantizado de nunca ser público para DNS interno, evitando problemas pasados en los que opciones no oficiales como “.dev” o “.local” acabaron chocando con el uso público o con mDNS. Los comentaristas sopesan las ventajas de un TLD privado claro y estandarizado frente a las preocupaciones por su longitud y su soporte TLS limitado (ya que las autoridades de certificación públicas no emitirán certificados para él), y muchos argumentan que usar subdominios de dominios reales de su propiedad junto con nombres reservados existentes como “home.arpa” sigue siendo más práctico en muchas configuraciones.

Dominios de uso especial existentes y conflictos

  • El hilo repasa dominios reservados/de uso especial actuales: .example, .invalid, .localhost, .test, .local, .onion, home.arpa.
  • .localhost tiene un comportamiento de loopback estandarizado; algunos resolutores lo implementan, otros requieren configuración local de DNS.
  • .local es ampliamente criticado por entrar en conflicto con mDNS/Bonjour y zeroconf; hay muchos enlaces e historias sobre descubrimiento de servicios roto y configuraciones heredadas de AD.
  • El procesamiento de .corp, .home, .mail ha sido “pospuesto indefinidamente” por ICANN, lo que se considera más débil que una reserva explícita.

Pros y contras de .internal

  • ICANN/IANA proponen .internal como un TLD de uso privado que “nunca será delegado”.
  • A quienes lo apoyan les gusta la claridad, el alcance más amplio que “home” y la seguridad de la no delegación (sin una sorpresa posterior al estilo .dev).
  • Quienes lo critican lo encuentran demasiado largo y torpe de escribir, especialmente en TVs/interfases de IoT; muchos prefieren opciones cortas como .lan, .intra o incluso .d.
  • A algunos les preocupa la confusión con .int y posibles patrones de apariencia similar/phishing como foo.int/ernal.
  • Existe escepticismo de que ICANN no acabe monetizando más tarde cadenas cortas alternativas; desconfianza general por .dev, .sucks y controversias previas.

Patrones de diseño de DNS interno

  • Un consejo fuerte de varios comentaristas: usar un dominio que realmente controlas (por ejemplo, internal.example.com) en lugar de TLD inventados.
  • Otros señalan problemas con ese enfoque: divulgación por DNSSEC de nombres internos, complejidad de split-DNS, caídas y confusión del usuario sobre qué es interno frente a externo.
  • Muchos despliegues heredados usaron .local o .dev internamente y luego sufrieron cuando estos se volvieron especiales o públicos.
  • Algunos evitan DNS por completo en configuraciones pequeñas/de hogar usando /etc/hosts o DNS local alimentado desde archivos de hosts.

TLS y problemas de certificados

  • Los dominios .internal no pueden obtener certificados de CA públicas; las organizaciones necesitarían CAs privadas o certificados autofirmados.
  • Varios señalan problemas de usabilidad y seguridad cuando los dispositivos se desplazan entre redes y confían en múltiples CAs privadas, lo que permite colisiones en el mismo nombre de host.
  • Ideas planteadas: mejor soporte en navegadores para Name Constraints, registro de dominios de uso interno compatible con Let’s Encrypt (mediante solo DNS-01), y formalizar patrones para HTTPS en redes locales.

Alternativas y usabilidad

  • home.arpa ya está estandarizado para uso residencial; a algunos les gusta su claridad, otros lo encuentran largo y torpe.
  • Opciones ad hoc comunes mencionadas: .lan, .lab, .home, .localnet, .d, nombres de host cortos más dominios de búsqueda, o dominios específicos de routers como fritz.box.
  • Un sector sostiene que cualquier TLD especial terminará siendo usado indebidamente o cooptado; por ello, “usa simplemente un dominio real” sigue siendo una recomendación recurrente.