DNS, server.prod adreslerimi 127.0.53.53 olarak çözmeye başladı.

Gibi adlandırılmış sunucularım var server.prod.example.comve düzenli olarak bunlara giriş yapıyorum server.prod. Son zamanlarda, bu ana bilgisayar adları 127.0.53.53 olarak çözümlenmeye başladı.

ICANN'in yakın zamanda TLD'yi etkinleştirdiği ortaya çıktı .prod. Ek olarak, .prodad sunucularına giden her istek, NXDOMAIN olarak geri gelmek yerine 127.0.53.53 olarak çözülür ve bu da çözünürlüğün düzgün çalışmasına devam eder. (Bunun arkasındaki noktaya, insanların gerçek bir şeyi çözmeye başlamadan önce eşyalarının daha kötüye gideceğini bilmeleridir.)

Bu gibi her ana bilgisayar için alan adımı girmek zorunda kalmayı nasıl önleyebilirim?

Bu hala ara sıra seni ısırıyor mu? Yeni TLD'lerin bir listesini bulamadım ve eklendiklerinde kendimi bir tane ayarladım: https://twitter.com/newgtldannounce

domain-name-system tld

— wfaulk
kaynak

ICANN tarafından yapılan bu değişiklik, uygulamalarınızın arama yollarını kullanmasına izin vermenin kötü olduğunu da hatırlatır. Bu soru kesinlikle bir kullanıcının girişi bu davranışla sonuçlandığında fayda sağlar, ancak uygulamalarınızın ana bilgisayar dosya girişlerini kullanması veya FQDN'nin nokta eklenmiş olması en iyisidir. Çok az kişi, glibc'nin tanımlanmış her arama sonekini denemeye zaman aşımına uğrayana kadar bir sonraki sunucuya geçmeyeceğini fark etti.

— Andrew B,

Herkese .prodfrakking aptalca bir TLD olduğunu hatırlatmak için biraz zaman alabilir miyim ? :(

— Monica

Sorunuz, soracağım soruyu cevapladı, "ICANN yakın zamanda <whatever> TLD'yi etkinleştirdi" diyerek sordu. LAN’ım için .haus kullanıyorum ve şunları almaya başladım: D Sorduğun / cevapladığın için teşekkürler :)

— Arno Teigseth

@LightnessRacesinOrbit .prod, Google’ın birçok yeni TLD’den biridir. Onları suçla.

— Michael Hampton

@LightnessRacesinOrbit, bu şekilde bakarsanız aptalca olabilir, ancak aynı zamanda, çarpışmalara çarpacağınız için arama listelerine bağımlı olmak veya global olarak kayıtlı olmayan adları kullanmak aynı şekilde değildir.

— Patrick Mevzek,

Yanıtlar:

Dahili etki alanlarını aniden 127.0.53.53çözdüğünüzde bir ad koduna sahip olursunuz ve ICANN size DNS yapılandırmanızı acilen düzeltmeniz gerektiğini söylemeye çalışıyor.
NXDOMAIN'i önerdiğiniz şekilde döndürürse, haklısınız, çalışmaya devam ederdi - şimdilik .

Ayrıca dahili olarak hedeflenen DNS sorgunuzu dış taraflara da sızdırıyor.

Daha da kötüsü, gelecekte birileri kayıt olabilir server.prodve size daha fazla sıkıntıya neden olabilir.

Daha fazla bilgi için buraya bakın https://icann.org/namecollision veya run:

$ dig -t TXT server.prod +short
"Your DNS configuration needs immediate attention see https://icann.org/namecollision"

Bunun nasıl çözüleceğine gelince: Kullanım durumuna bağlı olarak, muhtemelen .ssh/configkısa adlarla ekleyeceğim . Veya FQDN'leri gerçekten kullanmaya başlayın.

— numaracı
kaynak

@MichaelHampton gerçekten değil, bölüm 5.3'ü tavsiye ediyorum Train users and system administrators in using FQDNs:;))

— faker

Evet, çünkü gerçekten günde 20 kere, ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.comyerine yazmak istiyorum ssh db.

— wfaulk

@wfaulk: Neden bir "şaka" olsun ki? Aşırı yazmayı sevmiyorsanız, neden aşırı yazmayı engelleyen bir bilgisayarla etkileşime izin vermek için en iyi mekanizmayı saplantılı olarak kullanıyorsunuz? Bazılarınız Unix inekler sadece kasvetli.

— Monica ile Hafiflik Yarışları,

@Lightness Genel olarak, bodrum konaklarına yönelme eğiliminde olduğumuz için. Şirket genel müdürlerimizin, çalışanlarının, yıllar geçtikçe şirket tarafından yayınlanan cihazlarda Unix çalıştırmalarına izin verme olasılıkları daha düşüktür ve erişim noktamızdan gelen kabuk komut dosyalarına erişim sağlayarak kazanılan saatler, bir GUI'nin ne kadar kolay bir şekilde attığını belirler. . GUI ve metin konsollarının her ikisi de kendileriyle ilişkili kötü alışkanlıklara sahiptir. : P

— Andrew B

Burası GUI ile CLI tartışmasının yapıldığı yer değil. Bir çözüm önerdim, herkes için en iyisi olmayabilir ve söylenebilecek tek şey bu.

— faker

İçinde nokta olmayan bir ana bilgisayar adı yazarsanız, DNS çözümleyicileri, önce yapılandırılmış arama etki alanlarını ekleyerek bu ana bilgisayar adını aramaya çalışır.

Çoğu çözümleyici için, içinde en az bir noktaya sahip bir ana bilgisayar adı kullanırsanız, çözümleyici önce ana makine adını kendi başına dener ve yapılandırılmış arama etki alanlarını eklemeye geri döner.

Birçok çözümleyici, davranışlarını değiştirme yeteneğine sahiptir, böylece noktalara sahip ana bilgisayar adları için arama alanlarını eklerler. Bu, genellikle ndotsçözümleyiciye, ana bilgisayar adını kendi başına aramaya çalışmadan önce ana bilgisayar adının kaç noktaya sahip olması gerektiğini söyleyen bir seçenek aracılığıyla yapılır . İş yapmak server.prodiçin bu satırı şu adrese ekleyin resolv.conf:

options ndots:2

Server.subzone.prod dosyasını da çözmek istiyorsanız, seçeneği 3 vb. Olarak ayarlamanız gerekir.

Birisi bunun MacOS X'te nasıl çalışacağını bilen varsa, lütfen bana bildirin; Değişimin /etc/resolv.confişe yaramayacağı belgelenmiştir (ve yapmamaktadır) ve doğru scutilteşvikleri çözemiyorum.

(Not: Buraya bahislerimi muhtemelen garanti edilenden daha fazla koruma sağlıyorum. Bu ndotsseçeneğin (MacOSX dışı) Unix sistemlerinin% 99'unda çalışacağına inanıyorum .)

— wfaulk
kaynak

İşletim sistemi çözümleyici kütüphanesini BIND ile karıştırıyorsunuz. /etc/resolv.confişletim sistemi tarafından aittir. :)

— Andrew B

Hepsi olmasa da çoğu, Unix OS çözümleyicileri doğrudan kullanılmazsa doğrudan BIND'in çözümleyici kitaplıklarından sökülür. BIND'i çağırmaktaki amacım, "ndots" seçeneğine cevap vermeyecek farklı bir şey kullanan bir işletim sistemi var olabilir.

— wfaulk

Böyle bir ifadenin, C standart kütüphanesinin uyguladığı çözücünün ISC tarafından sağlanan kütüphanelere bağımlı olduğunu düşünerek insanları yanlış yönlendirmesi daha olasıdır. Glibc durumunda, kesinlikle olmaz .

— Andrew B

Yeterince adil. BIND atıfta bulunmadığı zaman çalışmayabilir dahil etmek denemek için düzeltildi.

— wfaulk

Diğer cevaplar size sorunun teknik çözümünü verdi. Ancak hiç kimse size cevap vermedi:

Yeni TLD'lerin listesini bulamadım ve ne zaman eklendiklerini

İşte burada.

Çeşitli yolların var.

IANA web sitesine gidin: https://www.iana.org/domains/root/db ; Geçerli delegasyonlu TLD'lerin listesini görürsünüz, ki bunlar çözülür ve kök bölgededir. Onlardan herhangi birini tıklarsanız, en altta göründüğünde size bildiren bir tarih alırsınız
Tam olarak aynı verilerin erişilebilir whoisolması durumunda whois -h whois.iana.org prod | grep created, örneğin sizin durumunuzda sizecreated: 2014-08-23
Twitter / Mastodon'da, IANA içeriği değiştiğinde yayın yapan çeşitli botlar var; örneğin, https://twitter.com/ianawhois veya https://twitter.com/rootchanges adresini ziyaret edin.
IANA verileri güncellemede biraz geride kalabilir, bu nedenle gTLD'ler için kanonik veritabanı ve bunların hangi aşamada olduklarını görmek için (şimdi 2012 ICANN'in yeni gTLD'lerin tanıtılması turundan bu yana biraz daha fazla, ancak yeni turlar gelmesi), işte: https://gtldresult.icann.org/application-result/applicationstatus ; TLD ile arama yapabilirsiniz. Tüm gTLD'lere belirli bir başlangıç dönemi de zorunludur, bu nedenle burada verileri bulacaksınız: https://newgtlds.icann.org/en/program-status/sunrise-claims-periods tüm verileri verebilirsiniz.
ICANN verilerini JSON'da da kullanabilirsiniz: https://www.icann.org/resources/registries/gtlds/v2/gtlds.json

— Patrick Mevzek
kaynak