A.gtld-servers.net tüm .com alan adlarının bir listesine sahip mi?

Bunu yaptığımda dig @a.gtld-servers.net example.com, hızlı bir şekilde ad sunucularını example.comve bu ad sunucularının IP adreslerini (tutkal kayıtları) döndürür .

Bu, yerel olarak tüm alan adlarının bir kaydı a.gtld-servers.net(ve *.gtld-servers.net) anlamına mı geliyor .com? Çok hızlı yanıt veriyorlar, bu yüzden kendileri başka bir sorguda bulunduklarını sanmıyorum. Benzer şekilde, example.comad sunucuları için yapılan bir istek beni domains.starting.with.e.gtld-servers.netbaşka bir şeye yönlendirmiyor .

Ben farkında mısın a.gtld-servers.netmuhtemelen birkaç makineleri ve ben (yani yeni bir ip-çoklu-makine teknolojisi aracılığıyla) bana en yakın birine yönlendirilmesini ediyorum, ama bu olurdu sadece ortalama birkaç başka makineler hepsine sahip .cometki.

EDIT: Yanıtlayan herkese teşekkürler! Takip eden soru: Birisi bu makinelerden birine "girerse", tüm .comalan adlarının bir listesini alamadı mı? Zaten ücretsiz bir yerde mevcut değilse, bu yararlı bilgiler gibi mi görünüyor? Alan adı bilgilerinin herkese açık olduğunu, ancak toplu olarak edinilmesinin hala zor olduğunu biliyorum. Sanırım *.gtld-servers.netbölge transferlerini desteklemiyorum ( .eduen azından birkaç yıl önce isim sunucuları yaptı).

NOT: example.com'un gerçek bir alan olmadığını fark ediyorum - sadece yukarıdaki herhangi bir .com alanıyla değiştirin (aslında xyz.com vardı, ancak birisi gerçek bir alan adı kullanmaktan kaçınmak için doğru bir şekilde düzenledi).

dns

— barrycarter
kaynak

Takip eden soru: evet, listeyi alabilirler ve üst düzey alan adlarının çoğu için bu tür liste herkese açık değildir ve her isme göre sorgulamanıza "yalnızca" izin verilir. Bazı bölgeler hala halka açıktır (şu anda), örneğin kök bölge veya İsveç bölgesi.

— Vladimír Čunát

@ VladimírČunát bölge dosyalarının herkese açık olduğu tüm gTLD'ler için bkz. Czds.icann.org/en Bu ICANN sözleşmesine göre yapılır. CcTLD'ler için değişir, ancak çoğu bu listeyi vermemektedir.

— Patrick Mevzek

@PatrickMevzek güzel, ancak en ilginç gTLD'ler görünüşe göre orada değil (com, org, ...).

— Vladimír Čunát

@ VladimírČunát orada olmayanlar için gTLD kayıt defterine başvurmanız gerekir: ayrı bir süreçleri olacaktır çünkü ICANN sözleşmelerinin bölge dosyalarına erişim vermeleri gerekir.

— Patrick Mevzek

Evet, "x.gtld-servers.net" "com" üst düzey etki alanı için yetkili sunuculardır, bu nedenle .com etki alanları için tüm "işaretçiler" e sahiptir. TLD'nin ad sunucularını çalıştırarak görebilirsiniz.

dig -t ns com
dig -t ns us
dig -t ns dk
dig -t ns aero

— Bjørn Hansen adlı kullanıcıdan Ask
kaynak

Tek etiketli adlarda, varsayılan alan adının eklenmesini önlemek için .- com., us.- sonunu eklemek en iyisidir . (Çözümlerken Örneğin, comContoso Inc ağın içindeki sistem deneyebilirsiniz com.contoso.net. önce sadece com.)

— user1686

digHiç arama yolunu kullandığını sanmıyorum ; diğer "gerçek dns hata ayıklama araçları" da olmamalıdır. (nslookup yapar, ancak dns hata ayıklaması için bunu kullanmayın). :-)

— Ask Bjørn Hansen

Ah eski yollar. : D @ AskBjørnHansen çok haklı. nslookupher durumda değil sadece kazı kullanın

— Dan Bradbury

böylece .com alanları için tüm "işaretçiler" vardır. Kesin olarak, tüm .COM etki alanı adlarına sahip oldukları, kesinlikle tüm .COM etki alanı adları olmayan NS kayıtlarına sahip oldukları için, birkaç yüzde fark vardır.

— Patrick Mevzek

@yükseklik son nokta sadece belirsizlik varsa kesinlikle gerekli olacaktır. -tisteğe bağlıdır, sen dig com NSve kazmak doğru olanı yapacak (kayıt türünü okunabilirlik için bir kural olarak büyük harf koymak, ancak bu zorunlu değildir). Ancak bir seçenek olarak yorumlanabilecek bir şey için sorgu yapmak istediğinizde, nokta tarafından çözülen bir sorununuz vardır.

— Patrick Mevzek

Alan adının kendisi için bir sorgu yapın - dig @a.gtld-servers.net com.- ve "yetkili yanıt" bayrağını arayın:

snowflake ~ $ dig @a.gtld-servers.net com | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
             ^^

— user1686
kaynak

Uzun zaman önce bir cevabınız var ama daha kesin olabileceğimizi hissediyorum ve bir takip sorunuz var, bu aslında başka bir soru olmalı.

O halde baştan başlayalım.

.COMTemsilci seçme hakkında bilgi almak için kök sunucuları sorgularsanız (aşağıdaki her şeyin .NETaynı kayıt defteri tarafından işlendiği için aynı şekilde uygulandığını unutmayın ) bu yanıtı alırsınız:

$ dig @a.root-servers.net com. NS +noall +auth

; <<>> DiG 9.12.0 <<>> @a.root-servers.net com. NS +noall +auth
; (1 server found)
;; global options: +cmd
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.

Özetle, bu ad sunucularının herhangi biri için yetkili .COMve hepsi aynı verilere sahiptir (böylece sorunuzu genişletebilirsiniz, a.gtld-servers.nethiçbir şekilde özel değildir, aşağıdaki her şey bu ad sunucularının herhangi biri için geçerli olacaktır).

Bu ad sunucularını herhangi bir .COM/.NETetki alanı adı için sorgulayacağınız zaman, istediğiniz etki alanı adı için yetkili ad sunucularıyla yetkili olarak yanıt vermeleri gerekir.

Bu nedenle, tanımı gereği, "a.gtld-servers.net (ve * .gtld-servers.net) 'in yerel olarak tüm .com alan adlarının bir kaydı olduğu anlamına mı geliyor?" Aşağıda daha ayrıntılı olarak "hepsi" etrafında bazı uyarılarla.

Tutkal kayıtları hakkında konuştuğunuza dikkat edin, bu özel bir durumdur ve en sık görülen durum değildir. Genellikle yukarıdaki ad sunucularından herhangi birinde bir etki alanı isteği yalnızca bir veya daha fazla NS kaydı verir.

Metninizdeki diğer küçük noktaları ele almak için zaman ayıralım:

Çok hızlı yanıt veriyorlar, bu yüzden kendileri başka bir sorguda bulunduklarını sanmıyorum.

Yetkili bir ad sunucusu, tanım gereği, herhangi bir dış kaynağa güvenmek zorunda kalmadan sorguları yanıtlamak için ihtiyaç duyduğu verilere sahiptir, aksi takdirde gerçekten yetkili değildir.

Hız gelince, bu kısmen özneldir ve neyi ve nasıl test ettiğinize bağlıdır, ancak birkaç faktör vardır: varsayılan olarak DNS, TCP'den daha hafif olan UDP kullanır ve bu tür ad sunucuları her zaman şanslıdır; size yakın bir tane var.

A.gtld-servers.net'in muhtemelen birkaç makine olduğunun farkındayım

"Muhtemelen" :-) kaldırabilirsiniz Bu ad sunucuları o kadar çok sorgu alırsınız ki herhangi bir kutu asla dayanamaz.

Eğer giderseniz https://stat.ripe.net/192.5.6.30#tabId=routing görmekte, temelde sindirmek ancak zor olabilir birçok bilgi göreceği bu tek bir IP a.gtld-servers.net(aslında blokta hangi tüm) tek bir şirket tarafından kontrol edilen birkaç AS tarafından ilan edilir, bu da çoğu DNS için güzel çalışan herhangi bir yayının güçlü bir göstergesidir.

Eğer giderseniz http://www.root-servers.org/ daha fazla bilgi edinebilirsiniz. Bu kök ad sunucularıyla ilgilidir, artıkkilerle değil, .COMteknik olarak aynı şeydir. Örneğin, 13 kök sunucunun 930 örnek arasında 12 farklı kuruluş tarafından yönetildiğini keşfedebilirsiniz (örnek yalnızca bir sunucu değil, bir konumdur, operatörün tipik olarak bir "düğümü" olduğu bir "varlık noktası" dır. yönlendirme donanımı, yük dengeleme / kurulumda başarısız sunucular, bazı izleme / uzak eller yetenekleri, vb.). Förneğin 222 yerde.

ve bana en yakın olana yönlendirildiğimi (bu yeni bir ip-çoklu-makine teknolojisi aracılığıyla), ancak bu sadece birkaç makinenin tüm .com alanlarına sahip olduğu anlamına gelir.

Evet, birçok makine tüm .COMalan adlarının listesine sahiptir . Ama önce bir doğruluk: bu ad sunucularında, tüm .COM alan adları için tüm ad sunucularının listesini alacaksınız ... bu, yetki verilmeyen alan adları için onları burada bulamayacağınız anlamına gelir. Bu birden fazla durumda olabilir:

bir alan adı kaydettirdiğinizde, ad sunucularını ayarlamamayı veya daha sonra kaldırmamayı seçebilirsiniz.
Örneğin, bir ödeme anlaşmazlığı nedeniyle kayıt kuruluşunuz clientHoldalan adınıza durum ekleyebilir ve bu da DNS'den kaybolmasını sağlar
kayıt defteri serverHoldherhangi bir nedenle alan adını açabilir .

( bu durumlar ve diğerleri hakkında daha fazla bilgi edinmek için bkz. https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en ).

"Tümünü" nasıl tanımladığınıza ve bu tür verilerle ne yapacağınıza bağlı olarak, bunların hepsini kesinlikle alamayabilirsiniz.

Yukarıdaki tüm durumlarda, etki alanı kayıt defteri DNS sunucularında görünmez, ancak whois sorgusu yaptığınızda görünür. Yani whois sunucuları (yine tek bir kutu değil) ... tüm .COM alan adlarının listesini ve ad sunucularına göre daha fazla veriyi içerecektir, çünkü:

çözümlenmeyenler ve dolayısıyla kayıt defteri ad sunucularında olmayanlar da dahil olmak üzere gerçekten tüm etki alanı adlarına sahipsiniz
whois iletişim verileri gibi çok daha fazla bilgi sağlar

Ve bunlar hala sadece bir şekilde veya bir kısmında alan adları listesi (veya bir kısmı) bulunan halka açık kayıt hizmetleri.

İzleminize gelince:

Takip eden soru: Birisi bu makinelerden birine "girerse" tüm .com alan adlarının bir listesini alamadı mı?

Teknik olarak, evet. Fakat:

Bu kesinlikle çevrimiçi olarak bulabileceğiniz en kolay hedef değil
Ve bu özel durumda veriler zaten ücretsiz olarak mevcuttur.

.COMbir gTLD'dir ve bu nedenle ICANN ile sözleşme yapmaktadır. ICANN, tüm gTLD kayıtlarını bölge dosyalarını (temel olarak ad sunucularının kendilerinin kullandığı şeydir, bu nedenle NS kayıtları artı A / AAAA tutkalları) günde en az bir kez yayınlamak için zorunludur ve bir anlaşma imzaladığınız sürece herkes için erişim ücretsizdir Bu verileri "kötü" amaçlarla (kendi başınıza yeniden yayınlamak gibi) tekrar kullanmadığınızdan emin olmak için.

Bununla ilgili tüm ayrıntılar için https://czds.icann.org/en adresine bakın . Bu, yüzlerce gTLD bölge dosyasına erişmenizi sağlayabilir.

Sorunuz "Birisi bu makinelerden birine girerse ve .COM alan adları ekleyen veya silen içeriği değiştirirse " olarak genişletilirse , hızlı bir şekilde aşağıdakileri yanıtlayabiliriz:

yalnızca bir kutuyu hacklediğinizden ve önce adla sonra herhangi bir yayınla sayısız ad sunucusu bulunduğundan, değişiklikler dünya çapında görülmeyecek
DNSSEC, değişikliklerinizi hata olarak gösterebilir ve bu nedenle hızlı bir şekilde tespit edilir (elbette operatörün kendisi tarafından yapılan yerel önlemlerin yanı sıra).

Kısacası, .COMalan adları ile uğraşmak için bunu yapmak en iyi fikir değildir ve başka yollar da vardır.

Alan adı bilgilerinin herkese açık olduğunu, ancak toplu olarak edinilmesinin hala zor olduğunu biliyorum.

ICANN programı için yukarıya bakın. CcTLD'ye gelince durum değişir, ancak daha sıklıkla gerçek zamanlı olarak değil, bölge dosyalarına erişim vermezler.

Bazen bir süre sonra, örneğin "açık veri" hareketleri ile erişebilirsiniz. Bir örnek: alan adları için https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html.FR .

Sanırım * .gtld-servers.net bölge transferlerini desteklemiyor (gerçi .edu'nun isim sunucuları en az birkaç yıl önce yaptı).

Test edilmesi kolay:

$ for ns in $(dig NS . +noall +ans | grep 'IN NS' | awk '{print $5}') ; do echo $ns ; dig @$ns com. AXFR; done
c.root-servers.net.

; <<>> DiG 9.12.0 <<>> @c.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
m.root-servers.net.

; <<>> DiG 9.12.0 <<>> @m.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
i.root-servers.net.

; <<>> DiG 9.12.0 <<>> @i.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
e.root-servers.net.

; <<>> DiG 9.12.0 <<>> @e.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
j.root-servers.net.

; <<>> DiG 9.12.0 <<>> @j.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
l.root-servers.net.

; <<>> DiG 9.12.0 <<>> @l.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
g.root-servers.net.

; <<>> DiG 9.12.0 <<>> @g.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
k.root-servers.net.

; <<>> DiG 9.12.0 <<>> @k.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
b.root-servers.net.

; <<>> DiG 9.12.0 <<>> @b.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
h.root-servers.net.

; <<>> DiG 9.12.0 <<>> @h.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
d.root-servers.net.

; <<>> DiG 9.12.0 <<>> @d.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; connection timed out; no servers could be reached
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
a.root-servers.net.

; <<>> DiG 9.12.0 <<>> @a.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
f.root-servers.net.

; <<>> DiG 9.12.0 <<>> @f.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.

Hayır, şu anda hiçbir .COMyetkili ad sunucusu AXFR sorgularını kabul etmiyor . Ancak bu her yerde aynı olmayabilir. Eğer sorgulamak durumunda f.root-servers.netnameserver Eğer yayınlanan tüm TLD'leri almak için AXFR sorgusu yapabilirsiniz. Diğer bazı TLD'ler de buna izin verebilir.

Genel AXFR sorgularına izin verilmesine karşı "çok" tavsiyenin bulunduğunu unutmayın. Gerçekler, tanımlarına göre büyük cevaplar oldukları ve tekrarlanırsa bir sunucuyu zorlayabildikleri, doğrudur. Açık, halkın bu bilgilere niçin ihtiyaç duyup duymadığı konusunda durmadan tartışabilir. DNS'nin başında, ad sunucuları arasındaki bölgeleri kopyalamak için daha çok kullanıldı (şimdi çok daha iyi alternatifler var). Bu nedenle AXFR genellikle devre dışıdır ... ancak DNSSEC'yi aynı anda belirli bir şekilde (NSEC ve NSEC3 varyantı değil) yaparsanız, standart DNS sorguları ve AXFR olmadan yürümek kolaydır. ve bölge dosyasını yeniden yapılandırın. Bunu yapmak için araçlar var.

Ayrıca, çeşitli çevrimiçi sağlayıcıların size çeşitli yollarla edindikleri birçok TLD için bölge dosyaları ve / veya tüm alan adları listesini satacağını unutmayın (diğerleri arasında bir fikir: açık bölge dosyalarını alırsınız, .COMTLD için .exampletek tek sorgulayabilirsiniz .COMaradığınız TLD'de en çok kullanılan dillere dayalı sözlük yürüyüşünün yanı sıra, size bazı fikirler verebilecek, bulduğunuz tüm adlar).

— Patrick Mevzek
kaynak