¿Qué está pasando con g.root-servers.net.?

Me acabo de enterar de que 192.112.36.4( g.root-servers.net.) no responde a las solicitudes, ni responde a los pings.

.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4

Verifiqué http://www.internic.net/domain/named.root , que es una lista actualizada de servidores raíz y la dirección IP es correcta. Siempre tuve la impresión de que esos servidores raíz son redundantes hasta el punto de que es imposible que haya tiempo de inactividad. De acuerdo con http://root-servers.org hay seis ubicaciones en todo el mundo donde se encuentran los servidores, por lo que supongo que estoy en lo cierto con esa suposición.

Mi pregunta es si g.root-servers.net.es de alguna manera diferente de todos los demás, o especial,
y si se supone que no debo obtener una respuesta de DNS por algún motivo.

domain-name-system

— Daniel
fuente

G-root está dirigido por el ejército de los EE. UU.

— Michael Hampton

Entonces, solo el ejército de los EE. UU. Tiene acceso, ¿o qué quieres decirme?

— Daniel

Usted preguntó qué es diferente o especial al respecto.

— Michael Hampton

neither responds to requests, nor responds to pings- Ping es solo una herramienta útil cuando y si sabes que debes obtener una respuesta del objetivo. Su afirmación de que no responde a los pings implica que cree que debería obtener una respuesta. Ahora resulta que todos los demás servidores raíz responden a pings, por lo que es una suposición bastante segura que g.root-servers.net también debería hacerlo, pero de todos modos es una suposición. Solo use ping cuando sepa absolutamente que el objetivo debe responder, de lo contrario está perdiendo el tiempo inclinando los molinos de viento.

— joeqwerty

FWIW, el servidor g.root estaba respondiendo a las solicitudes de DNS a través de TCP durante la interrupción; fue solo para UDP que no estaba disponible.

— Alnitak

Respuestas:

Siempre tuve la impresión de que esos servidores raíz son redundantes hasta el punto de que es imposible que haya tiempo de inactividad. De acuerdo con http://root-servers.org hay seis ubicaciones en todo el mundo donde se encuentran los servidores, por lo que supongo que estoy en lo cierto con esa suposición.

Incluso si no hubiera un corte indocumentado para G, esa es una suposición incorrecta:

Las direcciones IP de Anycast pueden representar múltiples sitios físicos, pero no es deseable que los eventos de abuso en una región se conviertan en fallas en otras . Si un sitio se dobla, ese tráfico no se cambiará a otro.
Los enlaces de red compartidos donde el abuso dirigido a un servidor raíz está presente pueden ahogarse antes de que lo haga la infraestructura más cercana a un servidor raíz.

Por último, tenemos el elemento humano. G estaba abajo en todos los ámbitos , pero no se ha revelado oficialmente por qué en este momento. Una falla generalizada de este tipo generalmente apunta a una acción deliberada o una falla catastrófica en la administración central.

Como los usuarios de Serverfault no representan a los administradores de los servidores raíz, su mejor opción es estar atento a una declaración oficial . Mientras tanto, el enlace de arriba es suficiente para demostrar que hubo una interrupción total de la conexión a Internet. G. Internet continuó funcionando porque una raíz que no funciona no tiene un impacto significativo en el panorama general.

Actualización de la NIC del DoD:

Regarding yesterday's G-root outage:

Like many outages, this one resulted from a series of unfortunate events.
These unfortunate events were operational errors;  steps have been taken to
prevent any reoccurrence, and to provide better service in the future.

https://lists.dns-oarc.net/pipermail/dns-operations/2016-April/014765.html

— Andrew B
fuente

Estuve con alguien de Ripe en una reunión ayer por la tarde, y mi primera impresión después de que ella me mostró los problemas fue que los servidores de raíces sufrieron una mala configuración en el firewall.

Las cosas que noté:

TCP responde funcionó bien. ( https://atlas.ripe.net/dnsmon/group/root?dnsmon.session.color_range_pls=0-66-66-99-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112 .36.4 & dnsmon.zone = root & dnsmon.startTime = 1460573400 & dnsmon.endTime = 1460649600 & dnsmon.ipVersion = both & dnsmon.isTcp = true )
Las respuestas UDP estaban muertas.
Todas las sondas de Ripe Atlas informaron el mismo problema. El problema no era específico de una región.
El enrutamiento BGP hacia la red estuvo bien. No hay problemas allí.

El hecho de que UDP no funcionó y TCP funcionó sugiere que alguien intentó bloquear los paquetes UDP por encima de un cierto tamaño o algo así.

Durante la interrupción, he realizado varias pruebas y todas las pruebas UDP fallaron, no solo las pruebas con un tamaño de respuesta superior a 512 bytes.

— Jan hugo prins
fuente