G.root-servers.net. İle neler oluyor?

Ben sadece 192.112.36.4( g.root-servers.net.) ne isteklerine cevap ne de pinglere cevap verdiğini öğrendim .

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

Http://www.internic.net/domain/named.root dosyasını kontrol ettim , bu kök sunucuların up2date listesi ve IP adresi doğru. Ben her zaman bu kök sunucuların arıza süresinin imkansız olduğu noktaya yedekli olduğu izlenimi altında kaldım. Göre http://root-servers.org orada sunucuların bulunduğu altı yerleri dünya çapında vardır, bu yüzden ben varsayımıyla doğru duyuyorum varsayılabilir.

Sorum şu g.root-servers.net., herhangi bir şekilde diğerlerinden farklı mı, özel mi,
ve herhangi bir nedenden bir DNS yanıtı alamamın gerekip gerekmediği?

domain-name-system

— Daniel
kaynak

G-root ABD ordusu tarafından yönetiliyor.

— Michael Hampton

Öyleyse sadece ABD ordusunun erişimi var ya da bana ne söylemek istiyorsun?

— Daniel,

Neyin farklı veya özel olduğunu sordunuz.

— Michael Hampton,

neither responds to requests, nor responds to pings- Ping, yalnızca hedeften bir yanıt almanız gerektiğini bildiğiniz zaman ve bilmeniz durumunda yararlı bir araçtır. Ping'lere cevap vermediğini ifade edersiniz, bir yanıt almanız gerektiğini düşündüğünüz anlamına gelir. Şimdi ortaya çıktığı gibi, diğer kök sunucuların tümü ping'lere yanıt veriyor, bu nedenle g.root-servers.net'in de yapması gereken oldukça güvenli bir varsayım, ancak yine de bu bir varsayım. Ping özelliğini yalnızca hedefin yanıt vermesi gerektiğini bildiğiniz zaman kullanın, aksi takdirde yel değirmenlerinde eğilerek zamanınızı boşa harcıyorsunuzdur.

— joeqwerty

FWIW, g.root sunucusu , kesinti sırasında TCP istekleri üzerinden DNS'ye cevap veriyordu - yalnızca UDP için kullanılamıyordu.

— Alnitak

Yanıtlar:

Ben her zaman bu kök sunucuların arıza süresinin imkansız olduğu noktaya yedekli olduğu izlenimi altında kaldım. Göre http://root-servers.org orada sunucuların bulunduğu altı yerleri dünya çapında vardır, bu yüzden ben varsayımıyla doğru duyuyorum varsayılabilir.

G için belgelenmemiş bir kesinti olmasa bile, bu yanlış bir varsayımdı:

Anycast IP adresleri birden fazla fiziksel siteyi temsil edebilir, ancak bir bölgedeki kötüye kullanım olaylarının diğerlerinde başarısızlığa neden olması istenmeyen bir durumdur . Bir site kilitlenirse, bu trafik başka bir bölgeye kaymayacak.
Bir kök sunucuya yönlendirilen kötüye kullanımın mevcut olduğu paylaşılan ağ bağlantıları, bir kök sunucuya daha yakın altyapı yapmadan önce çok iyi boğulabilir.

Son olarak, insan unsuruna sahibiz. G yönetim kurulunun aşağısındaydı , ancak bu nedenle neden resmen açıklanmış bir nedeni yoktu. Bu türden yaygın bir başarısızlık tipik olarak kasıtlı bir eyleme ya da merkezi yönetimde yıkıcı bir olaya işaret etmektedir.

Serverfault kullanıcıları kök sunucu yöneticilerini temsil etmediğinden, en iyi bahis, resmi bir açıklama izlemektir . Bu arada, yukarıdaki bağlantı G için toplam bir kesinti olduğunu göstermek için yeterlidir. İnternet çalışmaya devam etti çünkü bir kökün aşağı inmesi büyük resimde önemli bir etkiye sahip değildir.

DoD NIC’den güncelleme:

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
kaynak

Dün öğleden sonra bir toplantıda Ripe'dan biriyle birlikteydim ve bana sorunları gösterdikten sonra ilk izlenimim, kökçülerin güvenlik duvarındaki yanlış bir yapılandırmadan muzdarip olduğu idi.

Fark ettiğim şeyler:

TCP yanıtları iyi çalıştı. ( 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.112.112) .36.4 & dnsmon.zone = root & dnsmon.startTime = 1460573400 & dnsmon.endTime = 1460649600 & dnsmon.ipVersion = her ikisi de & dnsmon.isTcp = true )
UDP cevapları ölmüştü.
Tüm Olgun Atlas probları aynı sorunu bildirdi. Sorun bir bölgeye özgü değildi.
BGP ağa yönlendirme gayet güzeldi. Orada sorun yok.

UDP'nin çalışmadığı ve TCP'nin işe yaradığı gerçeği, birinin UDP paketlerini belirli bir boyutta veya benzer bir şey üzerinde engellemeye çalıştığını gösteriyor.

Kesinti sırasında birkaç test yaptım ve tüm UDP testleri başarısız oldu, sadece 512 bayttan büyük bir cevap boyutuna sahip testler değil.

— jan hugo prins
kaynak