Apa yang terjadi dengan g.root-servers.net.?

Saya baru tahu bahwa 192.112.36.4( g.root-servers.net.) tidak menanggapi permintaan, atau menanggapi ping.

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

Saya memeriksa http://www.internic.net/domain/named.root , yang merupakan daftar up2date dari server root dan alamat IP sudah benar. Saya selalu mendapat kesan bahwa server root itu berlebihan sampai pada titik di mana tidak mungkin ada downtime. Menurut http://root-servers.org ada enam lokasi di seluruh dunia di mana server berada, jadi saya akan menganggap saya benar dengan asumsi itu.

Pertanyaan saya adalah apakah g.root-servers.net.dengan cara apa pun berbeda dari yang lain, atau istimewa,
dan jika saya seharusnya tidak mendapatkan respons DNS darinya karena alasan apa pun?

domain-name-system

— Daniel
sumber

G-root dijalankan oleh militer AS.

— Michael Hampton

Jadi hanya militer AS yang memiliki akses ke sana, atau apa yang ingin Anda sampaikan kepada saya?

— Daniel

Anda bertanya apa yang berbeda atau istimewa tentang itu.

— Michael Hampton

neither responds to requests, nor responds to pings- Ping hanya alat yang berguna kapan dan jika Anda tahu bahwa Anda harus mendapatkan respons dari target. Anda pernyataan bahwa itu tidak menanggapi ping menyiratkan bahwa Anda berpikir bahwa Anda harus mendapatkan respons. Sekarang ternyata, semua root server lain merespons ping jadi itu asumsi yang cukup aman bahwa g.root-servers.net juga harus, tetapi itu tetap sebuah asumsi. Hanya gunakan ping saat Anda benar-benar tahu bahwa target harus merespons, jika tidak, Anda membuang waktu untuk memiringkan kincir angin.

— joeqwerty

FWIW, server g.root itu menanggapi DNS lebih permintaan TCP selama pemadaman - itu hanya untuk UDP bahwa itu tidak tersedia.

— Alnitak

Jawaban:

Saya selalu mendapat kesan bahwa server root itu berlebihan sampai pada titik di mana tidak mungkin ada downtime. Menurut http://root-servers.org ada enam lokasi di seluruh dunia di mana server berada, jadi saya akan menganggap saya benar dengan asumsi itu.

Bahkan jika tidak ada pemadaman bergilir untuk G, itu asumsi yang salah:

Alamat IP Anycast dapat mewakili beberapa situs fisik, tetapi tidak diinginkan untuk peristiwa penyalahgunaan di satu wilayah yang menyebabkan kegagalan di wilayah lain . Jika situs tertekuk, lalu lintas itu tidak akan dialihkan ke yang lain.
Tautan jaringan bersama di mana penyalahgunaan diarahkan pada server root ada mungkin sangat tercekik sebelum infrastruktur lebih dekat ke server root.

Terakhir, kita memiliki unsur manusia. G turun di papan , tetapi belum ada alasan resmi diungkapkan mengapa saat ini. Kegagalan yang meluas dari tipe ini biasanya menunjuk pada tindakan yang disengaja atau kegagalan bencana dalam administrasi pusat.

Karena pengguna Serverfault tidak mewakili administrator dari server root, taruhan terbaik Anda adalah mengawasi pernyataan resmi . Sementara itu, tautan di atas cukup untuk menunjukkan bahwa ada pemadaman total untuk G. Internet terus beroperasi karena satu root turun tidak memiliki dampak yang signifikan dalam gambar yang lebih besar.

Pembaruan dari DoD NIC:

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
sumber

Saya bersama seseorang dari Ripe dalam rapat kemarin sore, dan kesan pertama saya setelah dia menunjukkan kepada saya masalahnya adalah bahwa rootservers menderita kesalahan konfigurasi di firewall.

Hal-hal yang saya perhatikan:

Respons TCP bekerja dengan baik. ( 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 = keduanya & dnsmon.isTcp = true )
Tanggung jawab UDP sudah mati.
Semua probe Atlas Ripe melaporkan masalah yang sama. Masalahnya tidak spesifik untuk satu wilayah.
Routing BGP menuju jaringan baik-baik saja. Tidak ada masalah di sana.

Fakta bahwa UDP tidak berfungsi dan TCP berhasil menunjukkan bahwa seseorang mencoba memblokir paket UDP di atas ukuran tertentu atau sesuatu seperti itu.

Selama pemadaman listrik saya telah melakukan beberapa tes dan semua tes UDP gagal, tidak hanya tes dengan ukuran jawaban lebih besar dari 512 byte.

— jan hugo prins
sumber