Nota: Este artículo fue publicado originalmente en 2013. Algunos pasos, comandos o versiones de software pueden haber cambiado. Consulta la documentación actual de Infrastructure para la información más reciente.
¿Qué es 1e100.net? ¿Es un virus?
La respuesta corta es: No, 1e100.net no es un virus, ni malware, ni software espía. Es un dominio oficial y legítimo que pertenece y es operado por Google.
“1e100” es la notación científica para $1 \times 10^{100}$, que es un 1 seguido de 100 ceros. Este número masivo se conoce matemáticamente como un Gúgol (Googol), que es de donde Google obtuvo su nombre.
Google usa 1e100.net como el nombre de host de DNS inverso (reverse DNS) principal para su vasta infraestructura de servidores en todo el mundo. En lugar de asignar un dominio único a cada dirección IP utilizada por YouTube, Gmail, Búsqueda de Google, Google Drive y Google Analytics, la empresa unificó su red bajo este único nombre de dominio en 2009.
¿Por qué aparece 1e100.net en los logs de mi firewall o proxy?
Si eres un administrador de sistemas que monitorea un firewall corporativo (como Fortinet, Palo Alto o pfSense) o utilizas herramientas de análisis de red como Wireshark, verás conexiones frecuentes a dominios como oa-in-f95.1e100.net.
Cuando tu computadora se comunica con cualquier servicio de Google (lo que ocurre casi constantemente hoy en día, incluso si solo navegas en un sitio web de terceros que usa Google Analytics o fuentes de Google Fonts), el tráfico se dirige a una dirección IP de Google. Cuando el software de tu firewall o proxy realiza una búsqueda de Reverse DNS (rDNS) en esa dirección IP para averiguar qué es, los servidores DNS de Google responden devolviendo un nombre de host 1e100.net.
Problema común: El certificado del servidor SSL no coincide
A menudo, los administradores de red notan por primera vez la existencia de 1e100.net cuando su firewall bloquea la conexión. Por ejemplo:
| Campo | Valor |
|---|---|
| Tipo de Log: | Web Proxy (Forward) |
| Estado: | 12227 El nombre del certificado de servidor SSL provisto por un servidor de destino no coincide con el nombre de host solicitado. |
| Destino: | oa-in-f95.1e100.net (173.194.64.95:443) |
| Protocolo: | https-inspect |
¿Por qué sucede esto?
La conexión se bloqueó porque el certificado SSL que presenta el servidor al que nos comunicamos (probablemente un certificado para *.google.com o *.youtube.com) no coincide matemáticamente con el nombre de host que tu firewall parseó a través del DNS Inverso (oa-in-f95.1e100.net).
Si estás ejecutando un proxy con inspección profunda de SSL (Deep Packet Inspection), deberás configurarlo de manera que reconozca que 1e100.net es un Subject Alternative Name (SAN) válido para los servicios de Google, o bien, agregar los rangos conocidos de direcciones IP de Google a la lista blanca (whitelist).
Prueba: Verificando a quién le pertenece el dominio
Si ejecutas una resolución WHOIS de registro en cualquier dirección IP de Google que se resuelva a 1e100.net (por ejemplo, en la IP 173.194.64.95), la base de datos oficial confirma que está asignada directamente a Google Inc.:
NetRange: 173.194.0.0 - 173.194.255.255
CIDR: 173.194.0.0/16
Organization: Google LLC (GOGL)
RegDate: 2009-08-17
Updated: 2012-02-24Explicación Oficial de Google
Para eliminar cualquier duda y evitar preocupaciones por ataques de cross-site scripting (XSS) o rastreos ocultos, Google se dirigió oficialmente a este asunto en su portal de soporte, explicando:
“1e100.net es un nombre de dominio que pertenece a Google y se utiliza para identificar servidores distribuidos en nuestra red. Siguiendo las recomendaciones y costumbres habituales, hemos garantizado que a cada dirección IP le corresponda su título en el equipo host. En el año 2009 empezamos a utilizar un dominio único para señalar en los productos a nuestros servidores en Google. La principal función es poder identificar todos nuestros servidores a partir de un simple título y que de este modo estén todos englobados bajo el mismo paraguas y no desperdigados. Tomamos esta iniciativa por dos razones: en primer lugar, es más simple, y, en segundo lugar, evitamos complicaciones proactivas que impliquen riesgos de falsificaciones (como los denominados cross-site scripting attacks)“