Anda sudah mendapat balasan sejak lama tetapi saya merasa kami bisa lebih tepat dan Anda memiliki pertanyaan lanjutan, yang seharusnya menjadi pertanyaan lain sebenarnya.
Jadi mari kita kembali dari awal.
Jika Anda meminta server root untuk mempelajari tentang .COM
delegasi (perhatikan bahwa semua yang di bawah ini berlaku dengan cara yang sama karena .NET
keduanya ditangani oleh registri yang sama) Anda mendapatkan balasan ini:
$ 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.
Jadi, secara ringkas salah satu server nama ini adalah resmi untuk .COM
dan mereka semua memiliki data yang sama (sehingga Anda dapat memperluas pertanyaan Anda, a.gtld-servers.net
sama sekali tidak istimewa, semuanya di bawah ini akan berlaku untuk salah satu server nama ini).
Saat Anda akan meminta server nama ini untuk .COM/.NET
nama domain apa pun, mereka harus membalas secara otoritatif dengan server nama yang otoritatif untuk nama domain yang Anda minta.
Oleh karena itu, menurut definisi, "Apakah itu berarti a.gtld-servers.net (dan * .gtld-servers.net) memiliki catatan semua domain .com secara lokal?", Namun artinya persis seperti itu! Dengan beberapa peringatan di sekitar "semua" yang ditekankan lebih jauh di bawah.
Perhatikan bahwa Anda berbicara tentang rekaman lem, ini adalah kasus khusus, dan bukan yang paling sering. Biasanya permintaan untuk domain di salah satu server nama di atas hanya akan memberikan kembali satu atau lebih catatan NS.
Biarkan kami meluangkan waktu untuk membahas poin-poin kecil lainnya dalam teks Anda:
Mereka merespons dengan sangat cepat, jadi saya tidak berpikir mereka membuat pertanyaan lebih lanjut sendiri.
Nameserver yang otoritatif, menurut definisi, memiliki data yang diperlukan untuk menjawab pertanyaan, tanpa harus bergantung pada sumber daya eksternal, jika tidak itu tidak benar-benar otoritatif.
Adapun kecepatan ini sebagian subjektif dan sangat tergantung pada apa dan bagaimana Anda menguji, tetapi ada beberapa faktor: secara default DNS menggunakan UDP yang lebih ringan dari TCP sehingga lebih cepat, dan nameserver semacam itu disiarkan yang berarti bahwa dengan sedikit keberuntungan Anda selalu punya satu "dekat" Anda.
Saya menyadari a.gtld-servers.net mungkin beberapa mesin
Anda dapat menghapus "mungkin" :-) Server nama ini menerima begitu banyak pertanyaan sehingga setiap kotak tidak akan bisa bertahan.
Jika Anda masuk ke https://stat.ripe.net/192.5.6.30#tabId=routing Anda akan melihat banyak informasi yang mungkin sulit dicerna tetapi pada dasarnya, melihat bahwa IP tunggal ini a.gtld-servers.net
(pada kenyataannya blok di mana itu) diumumkan oleh beberapa SA yang semuanya dikendalikan oleh satu perusahaan, yang merupakan indikator kuat dari siaran apa pun, yang bekerja dengan baik untuk sebagian besar DNS.
Jika Anda mengunjungi http://www.root-servers.org/ Anda dapat mempelajari lebih lanjut. Ini terkait dengan nameserver root, bukan lagi nameserver .COM
, tetapi secara teknis persis sama. Anda dapat menemukan misalnya bahwa 13 server root dikelola oleh 12 organisasi berbeda di 930 instance (sebuah instance bukan hanya satu server, itu adalah lokasi, "titik kehadiran" di mana operator memiliki "node" yang biasanya gigi perutean, beberapa server dalam penyeimbangan beban / kegagalan pengaturan, beberapa kemampuan pemantauan / remote tangan, dll.). F
misalnya ada di 222 tempat.
dan bahwa saya diarahkan ke yang terdekat dengan saya (melalui teknologi satu-ip-banyak-mesin baru), tetapi ini hanya berarti beberapa mesin lain memiliki semua domain .com.
Ya, banyak mesin memiliki daftar semua .COM
nama domain. Tapi pertama-tama ketepatan: pada nameserver ini Anda akan mendapatkan daftar semua nameserver untuk semua nama domain .COM ... yang berarti bahwa untuk nama domain yang tidak didelegasikan Anda tidak akan menemukannya di sini. Ini dapat terjadi dalam banyak kasus:
- ketika Anda mendaftarkan nama domain, Anda dapat memilih untuk tidak mengatur server nama, atau menghapusnya nanti.
- pendaftar Anda, misalnya karena sengketa pembayaran dapat menambahkan status
clientHold
pada nama domain Anda, yang membuatnya hilang dari DNS
- registri dapat menempatkan domain pada
serverHold
alasan apa pun.
(lihat https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en jika Anda ingin mempelajari lebih lanjut tentang status ini dan lainnya).
Bergantung pada bagaimana Anda mendefinisikan "semua" dan apa yang akan Anda lakukan dengan data tersebut, Anda mungkin tidak benar-benar mendapatkan semuanya.
Dalam semua kasus di atas, domain tidak akan muncul di server DNS registri, tetapi akan muncul ketika Anda melakukan permintaan whois. Jadi server whois (sekali lagi, bukan satu kotak) juga akan memiliki ... daftar semua nama domain .COM dan bahkan lebih banyak data daripada pada server nama karena:
- Anda benar-benar memiliki semua nama domain, termasuk yang tidak menyelesaikan dan karenanya bukan pada server nama registri
- whois memberikan informasi yang jauh lebih banyak, seperti data kontak
Dan ini masih hanya layanan registri menghadapi publik yang, dalam beberapa cara atau bagian, daftar (atau bagian dari itu) nama domain.
Adapun tindak lanjut Anda:
Pertanyaan tindak lanjut: jika seseorang "meretas" salah satu mesin ini, tidak bisakah mereka mendapatkan daftar semua domain .com?
Secara teknis, ya. Tapi:
- Ini tentu bukan target termudah yang akan Anda temukan online
- Dan dalam kasus khusus ini data sudah tersedia secara gratis.
.COM
adalah gTLD dan karena itu berdasarkan kontrak dengan ICANN. ICANN mengamanatkan semua pendaftar gTLD untuk menerbitkan zonefile mereka (yang pada dasarnya adalah apa yang digunakan nameserver sendiri, sehingga NS mencatat plus perekat A / AAAA), setidaknya sekali sehari, dan akses gratis untuk siapa saja selama Anda menandatangani perjanjian untuk memastikan bahwa Anda tidak menggunakan kembali data ini untuk tujuan "buruk" (seperti menerbitkan ulang sendiri).
Lihat https://czds.icann.org/en untuk semua detail tentang itu. Ini dapat memberi Anda akses ke ratusan zonefile gTLD.
Perhatikan bahwa jika pertanyaan Anda diperluas ke "jika seseorang meretas ke salah satu mesin ini dan mengubah konten yang menambah atau menghapus nama domain .COM ..." maka kami dapat dengan cepat menjawab dengan:
- perubahan tidak akan terlihat di seluruh dunia, karena Anda meretas hanya satu kotak dan ada banyak server nama, pertama dengan nama kemudian oleh anycasting
- DNSSEC dapat membuat perubahan Anda tampak sebagai kesalahan dan karenanya akan terlihat dengan cepat (selain tentu saja penanggulangan lokal oleh operator itu sendiri).
Singkatnya itu bukan ide terbaik untuk melakukan itu untuk mengacaukan .COM
nama domain, dan ada cara lain.
Saya menyadari informasi domain bersifat publik, tetapi masih sulit diperoleh secara massal.
Lihat di atas untuk program ICANN. Adapun ccTLD situasinya bervariasi tetapi lebih sering mereka tidak memberikan akses ke zonefile mereka, dan tidak secara real time.
Terkadang, Anda dapat mengaksesnya setelah beberapa waktu, misalnya melalui gerakan "data terbuka". Salah satu contoh: https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html untuk .FR
nama domain.
Saya kira * .gtld-servers.net tidak mendukung transfer zona (meskipun nameserver .edu melakukannya, setidaknya beberapa tahun yang lalu).
Mudah diuji:
$ 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.
Tidak, saat ini, tidak ada .COM
server nama otoritatif yang menerima pertanyaan AXFR. Tapi ini belum tentu sama di mana-mana. Jika Anda meminta f.root-servers.net
server nama, Anda bisa melakukan permintaan AXFR untuk menerbitkan semua TLD. Beberapa TLD lain juga memungkinkan itu.
Perhatikan bahwa ada "banyak" rekomendasi yang melarang kueri AXFR publik. Faktanya adalah bahwa mereka adalah jawaban yang sangat besar menurut definisi, dan dapat membebani server jika diulangi, itu benar. Pada dapat berdebat tanpa henti tentang mengapa / jika publik membutuhkan informasi ini. Itu lebih digunakan pada awal DNS untuk menyalin zona antara server nama (ada alternatif yang jauh lebih baik sekarang). Jadi AXFR sering dinonaktifkan ... kecuali jika Anda melakukan DNSSEC secara bersamaan, dalam beberapa cara tertentu (yaitu NSEC dan bukan varian NSEC3), mudah untuk berjalan, melalui kueri DNS standar dan tanpa AXFR, semua dari Anda zona dan merekonstruksi zonefile. Ada alat untuk melakukannya.
Perhatikan juga bahwa berbagai penyedia online akan menjual kepada Anda file zona dan / atau daftar semua nama domain untuk banyak TLD, yang mereka peroleh dengan berbagai cara (satu ide antara lain: Anda mengambil file zona terbuka, seperti .COM
, dan untuk TLD .example
Anda meminta satu per satu semua nama yang Anda temukan .COM
, yang dapat memberi Anda beberapa ide, selain tentu saja kamus berjalan berdasarkan bahasa yang paling banyak digunakan dalam pencarian TLD).