Que se passe-t-il avec g.root-servers.net.?

Je viens de découvrir que 192.112.36.4( g.root-servers.net.) ne répond ni aux requêtes, ni aux pings.

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

J'ai vérifié http://www.internic.net/domain/named.root , qui est une liste up2date de serveurs racine et l'adresse IP est correcte. J'ai toujours eu l'impression que ces serveurs racine sont redondants au point où il est impossible qu'il y ait des temps d'arrêt. Selon http://root-servers.org, il y a dans le monde six emplacements où se trouvent des serveurs, donc je suppose que je suis d'accord avec cette hypothèse.

Ma question est de savoir si g.root-servers.net.est en quelque sorte différent de tous les autres, ou spécial,
et si je suis censé ne pas obtenir de réponse DNS pour quelque raison que ce soit?

domain-name-system

— Daniel
source

G-root est géré par l'armée américaine.

— Michael Hampton

Donc, seuls les militaires américains y ont accès, ou que voulez-vous me dire?

— Daniel

Vous avez demandé ce qui est différent ou spécial à ce sujet.

— Michael Hampton

neither responds to requests, nor responds to pings- Ping n'est qu'un outil utile quand et si vous savez que vous devriez obtenir une réponse de la cible. Votre déclaration selon laquelle il ne répond pas aux pings implique que vous pensez que vous devriez obtenir une réponse. Maintenant, il s'avère que tous les autres serveurs racine répondent aux pings, c'est donc une hypothèse assez sûre que g.root-servers.net devrait également, mais c'est une hypothèse néanmoins. N'utilisez ping que lorsque vous savez absolument que la cible doit répondre, sinon vous perdez votre temps à vous pencher sur les moulins à vent.

— joeqwerty

FWIW, le serveur g.root a répond aux DNS sur les demandes TCP au cours de la panne - il était seulement pour UDP qu'il était indisponible.

— Alnitak

Réponses:

J'ai toujours eu l'impression que ces serveurs racine sont redondants au point où il est impossible qu'il y ait des temps d'arrêt. Selon http://root-servers.org, il y a dans le monde six emplacements où se trouvent des serveurs, donc je suppose que je suis d'accord avec cette hypothèse.

Même s'il n'y avait pas eu de panne non documentée pour G, c'est une hypothèse incorrecte:

Les adresses IP Anycast peuvent représenter plusieurs sites physiques, mais il n'est pas souhaitable que les événements d'abus dans une région se transforment en échecs dans d'autres . Si un site boucle, ce trafic ne sera pas transféré dans un autre.
Les liens réseau partagés où des abus dirigés contre un serveur racine sont présents peuvent très bien s'étouffer avant que l'infrastructure plus proche d'un serveur racine ne le fasse.

Enfin, nous avons l'élément humain. G est en baisse dans tous les domaines , mais il n'y a aucune raison officiellement divulguée pourquoi à ce moment. Une défaillance généralisée de ce type indique généralement une action délibérée ou une défaillance catastrophique de l'administration centrale.

Comme les utilisateurs de Serverfault ne représentent pas les administrateurs des serveurs racine, votre meilleur pari est de surveiller une déclaration officielle . En attendant, le lien ci-dessus est suffisant pour démontrer qu'il y a eu une panne totale pour G. L'Internet a continué de fonctionner car une racine en panne n'a pas d'impact significatif dans l'ensemble.

Mise à jour à partir de la carte réseau 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
source

J'étais avec quelqu'un de Ripe lors d'une réunion hier après-midi, et ma première impression après qu'elle m'ait montré les problèmes était que les serveurs racine avaient souffert d'une mauvaise configuration dans le pare-feu.

Les choses que j'ai remarquées:

Les réponses TCP ont bien fonctionné. ( 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 )
Les responces de l'UDP étaient morts.
Toutes les sondes Ripe Atlas ont signalé le même problème. Le problème n'était pas spécifique à une région.
Le routage BGP vers le réseau était très bien. Aucun problème là-bas.

Le fait que UDP n'a pas fonctionné et que TCP ait fonctionné suggère que quelqu'un a essayé de bloquer les paquets UDP au-dessus d'une certaine taille ou quelque chose comme ça.

Pendant la panne, j'ai fait plusieurs tests et tous les tests UDP ont échoué, pas seulement les tests avec une taille de réponse supérieure à 512 octets.

— jan hugo prins
source