A.gtld-servers.net ha un elenco di tutti i domini .com?


14

Quando lo faccio dig @a.gtld-servers.net example.com, restituisce rapidamente i nameserver per example.come gli indirizzi IP per quei nameserver (record di colla).

Significa a.gtld-servers.net(e *.gtld-servers.net) avere un registro di tutti i .comdomini a livello locale? Rispondono molto rapidamente, quindi non credo che stiano facendo un'altra query da soli. Allo stesso modo, una richiesta per example.comi nameserver non mi reindirizza a domains.starting.with.e.gtld-servers.netnulla.

Mi rendo conto che a.gtld-servers.netprobabilmente sono diverse macchine e che sto per essere indirizzato a quella più vicina a me (attraverso quella nuova tecnologia multi-ip-macchina multipla), ma ciò significherebbe solo che molte altre macchine hanno tutti i .comdomini.

EDIT: Grazie a tutti quelli che hanno risposto! Domanda di follow-up: se qualcuno "inserisce" una di queste macchine, non potrebbe ottenere un elenco di tutti i .comdomini? Sembra un'informazione utile, a meno che non sia già disponibile da qualche parte gratuitamente? Mi rendo conto che le informazioni sul dominio sono pubbliche, ma è ancora difficile ottenere in blocco. Suppongo *.gtld-servers.netche non supportino i trasferimenti di zona (anche se .edui server dei nomi lo hanno fatto, almeno qualche anno fa).

NOTA: mi rendo conto che example.com non è un dominio reale, basta sostituirlo con qualsiasi altro dominio .com sopra (originariamente avevo xyz.com, ma qualcuno lo ha modificato correttamente per evitare di usare un vero nome di dominio).


Domanda di follow-up: sì, potrebbero ottenere l'elenco e per la maggior parte dei domini di livello superiore tale elenco non è pubblicamente disponibile e l'utente è "solo" autorizzato a eseguire query in base al nome. Alcune zone sono ancora pubbliche (attualmente), ad esempio la zona radice o quella svedese.
Vladimír Čunát,

1
@ VladimírČunát per tutti i gTLD i file di zona sono pubblici, vedere czds.icann.org/en Questo è per contratto ICANN. Per i ccTLD, varia, ma la maggior parte non fornisce questo elenco.
Patrick Mevzek,

@PatrickMevzek bello, anche se i gTLD più interessanti apparentemente non ci sono (com, org, ...).
Vladimír Čunát,

@ VladimírČunát per coloro che non ci sono, è necessario contattare il registro gTLD: avranno un processo separato perché sono richiesti dal loro contratto ICANN per consentire l'accesso ai propri file di zona.
Patrick Mevzek,

Risposte:


18

Sì, "x.gtld-servers.net" sono i server autorevoli per il dominio di primo livello "com", quindi hanno tutti i "puntatori" per i domini .com. È possibile visualizzare i nameserver per il TLD eseguendo

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

Con i nomi con etichetta singola, è meglio includere la desinenza .- com., us.- per evitare di aggiungere il nome di dominio predefinito. (Per esempio, durante la risoluzione comall'interno della rete di Contoso Inc, il sistema potrebbe tentare com.contoso.net. prima solo com.)
user1686

4
Non credo digche usi mai il percorso di ricerca; altri "strumenti di debug DNS reali" non dovrebbero neanche. (nslookup lo fa, ma non usarlo per il debug di dns). :-)
Chiedi a Bjørn Hansen il

1
Oh i vecchi modi. : D @ AskBjørnHansen ha ragione. basta usare scavare piuttosto che nslookupin tutti i casi
Dan Bradbury,

quindi hanno tutti i "puntatori" per i domini .com. per essere precisi hanno tutti i nomi di dominio .COM che sono delegati, ovvero con record NS, che non sono assolutamente tutti i nomi di dominio .COM esistenti, c'è qualche differenza percentuale.
Patrick Mevzek,

@grawity il punto finale sarebbe strettamente necessario solo in presenza di ambiguità. -tè facoltativo, puoi fare dig com NSe scavare farà la cosa giusta (ho messo il tipo di record in maiuscolo proprio come una convenzione per la leggibilità ma questo non è obbligatorio). Ma quando vuoi fare una query per qualcosa che potrebbe essere interpretato come un'opzione hai un problema, risolto dal punto.
Patrick Mevzek,

3

Esegui una query per il dominio stesso - dig @a.gtld-servers.net com.- e cerca il flag "risposta autorevole":

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

1

Hai già ricevuto una risposta molto tempo fa, ma penso che possiamo essere più precisi e hai una domanda di follow-up, che avrebbe dovuto essere un'altra domanda in effetti.

Quindi torniamo dall'inizio.

Se si esegue una query sui server di root per conoscere la .COMdelega (si noti che tutto quanto segue si applica allo stesso modo .NETpoiché entrambi sono gestiti dallo stesso registro) si ottiene questa risposta:

$ 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.

Quindi in sintesi uno di questi nameserver è autorevole .COM e tutti hanno gli stessi dati (quindi puoi ampliare la tua domanda, non a.gtld-servers.netè in alcun modo speciale, tutto ciò che segue si applicherà a nessuno di questi nameserver).

Quando interrogherai questi nameserver per qualsiasi .COM/.NET nome di dominio, dovranno rispondere in modo autorevole con i server dei nomi autorevoli per il nome di dominio che stai chiedendo.

Quindi, per definizione, "Significa che a.gtld-servers.net (e * .gtld-server.net) hanno un registro di tutti i domini .com localmente?", Ma significa esattamente questo! Con qualche avvertimento intorno a "tutto" che viene affrontato più avanti.

Nota che parli di dischi di colla, questo è un caso specifico e non il più frequente. In genere una richiesta per un dominio in uno dei suddetti nameserver restituirà solo uno o più record NS.

Concediamoci del tempo per affrontare gli altri punti minori del tuo testo:

Rispondono molto rapidamente, quindi non credo che stiano facendo un'altra query da soli.

Un nameserver autorevole, per definizione, ha i dati di cui ha bisogno per rispondere alle query, senza dover fare affidamento su alcuna risorsa esterna, altrimenti non è veramente autorevole.

Per quanto riguarda la velocità, questo è in parte soggettivo e fortemente dipendente da cosa e come test, ma ci sono diversi fattori: per impostazione predefinita DNS utilizza UDP che è più leggero di TCP quindi più veloce, e tali server dei nomi sono trasmessi, il che significa che con un po 'di fortuna tu sempre avere un "vicino" a te.

Mi rendo conto che a.gtld-servers.net è probabilmente diverse macchine

Puoi rimuovere il "probabilmente" :-) Questi server dei nomi ricevono così tante domande che ogni singola casella non sarà mai in grado di resistere.

Se vai su https://stat.ripe.net/192.5.6.30#tabId=routing vedrai molte informazioni che potrebbero essere difficili da digerire ma sostanzialmente, visto che questo singolo IP di a.gtld-servers.net(in effetti il ​​blocco in cui lo è) è annunciato da diversi AS tutti controllati da una società, che è un forte indicatore di qualsiasi trasmissione, che funziona magnificamente per la maggior parte dei DNS.

Se vai su http://www.root-servers.org/ puoi saperne di più. Questo è legato ai nameserver di root, non più .COMquelli, ma tecnicamente è esattamente la stessa cosa. Ad esempio, è possibile scoprire che i 13 server root sono gestiti da 12 diverse organizzazioni in 930 istanze (un'istanza non è solo un server, è una posizione, un "punto di presenza" in cui l'operatore ha un "nodo" che è in genere routing gear, server multipli in bilanciamento del carico / failover sulla configurazione, alcune funzionalità di monitoraggio / mani remote, ecc.). Fper esempio è in 222 posti.

e che vengo indirizzato a quello più vicino a me (attraverso quella nuova tecnologia multi-ip-macchina multipla), ma ciò significherebbe solo che molte altre macchine hanno tutti i domini .com.

Sì, molte macchine hanno l'elenco di tutti .COMi nomi di dominio. Ma prima una precisione: su questi nameserver otterrai l'elenco di tutti i nameserver per tutti i nomi di dominio .COM ... il che significa che per i nomi di dominio non delegati non li troverai qui. Questo può accadere in più casi:

  1. quando registri un nome di dominio, puoi scegliere di non impostare i nameserver o di rimuoverli in un secondo momento.
  2. il tuo registrar, ad esempio a causa di una disputa sul pagamento, potrebbe aggiungere lo stato clientHoldsul tuo nome di dominio, che lo fa scomparire dal DNS
  3. il registro potrebbe attivare il dominio serverHoldper qualsiasi motivo.

(vedi https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-it se vuoi saperne di più su questi stati e altri).

A seconda di come definiresti "tutto" e di cosa faresti con tali dati, potresti non ottenerli davvero tutti.

In tutti i casi precedenti, il dominio non verrà visualizzato sui server DNS del registro, ma verrà visualizzato quando si esegue una query whois. Quindi i server whois (di nuovo, non una singola casella) avranno anche ... l'elenco di tutti i nomi di dominio .COM e anche più dati rispetto ai server dei nomi perché:

  1. hai davvero tutti i nomi di dominio, compresi quelli che non si risolvono e quindi non sui nameserver del registro
  2. whois fornisce molte più informazioni, come i dati di contatto

E questi sono ancora solo servizi di registro pubblici che hanno, in qualche modo o in parte, l'elenco (o parte di esso) di nomi di dominio.

Per quanto riguarda il tuo follow-up:

Domanda di follow-up: se qualcuno "inserisce" una di queste macchine, non potrebbe ottenere un elenco di tutti i domini .com?

Tecnicamente si. Ma:

  1. Questo non è certamente l'obiettivo più semplice che troverai online
  2. E in questo caso specifico i dati sono già disponibili gratuitamente.

.COMè un gTLD e come tale è sotto contratto con ICANN. L'ICANN impone a tutti i registri gTLD di pubblicare i propri file di zona (che è sostanzialmente quello che usano i nameserver stessi, quindi i record NS più le colle A / AAAA), almeno una volta al giorno, e l'accesso è gratuito per chiunque fintanto che firmi un accordo al fine di assicurarsi di non riutilizzare questi dati per scopi "errati" (come ripubblicarli da soli).

Vedi https://czds.icann.org/en per tutti i dettagli a riguardo. Questo può darti accesso a centinaia di file di zona gTLD.

Tieni presente che se la tua domanda viene estesa a "se qualcuno esegue un hacking in una di queste macchine e cambia il contenuto che viene aggiunto o rimosso. Nomi di dominio .COM ...", possiamo rispondere rapidamente con:

  1. le modifiche non saranno visibili in tutto il mondo, dal momento che si hackera solo una scatola e ci sono numerosi nameserver, prima per nome e poi per ogni trasmissione
  2. DNSSEC può far apparire le tue modifiche come errori e quindi saranno individuate rapidamente (oltre a eventuali contromisure locali da parte dell'operatore stesso ovviamente).

In breve, non è la migliore idea per farlo per scherzare con .COMi nomi di dominio, e ci sono altri modi.

Mi rendo conto che le informazioni sul dominio sono pubbliche, ma è ancora difficile ottenere in blocco.

Vedi sopra per il programma ICANN. Per quanto riguarda ccTLD, la situazione varia ma più spesso non danno accesso al proprio file di zona e non in tempo reale.

A volte, è possibile accedervi dopo qualche tempo, ad esempio tramite movimenti di "dati aperti". Un esempio: https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html per .FRi nomi di dominio.

Suppongo che * .gtld-server.net non supporti i trasferimenti di zona (sebbene i server dei nomi .edu lo facessero, almeno qualche anno fa).

Facile da testare:

$ 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.

No, in questo momento, nessun .COMnameserver autorevole accetta query AXFR. Ma questo non è necessariamente lo stesso ovunque. Se si f.root-servers.netesegue una query sul nameserver, è possibile eseguire una query AXFR per pubblicare tutti i TLD. Alcuni altri TLD potrebbero anche consentirlo.

Si noti che ci sono "molte" raccomandazioni contro l'ammissione di query AXFR pubbliche. I fatti sono che si tratta di risposte enormi per definizione e che, se ripetute, potrebbero forzare un server, è vero. On può discutere all'infinito sul perché / se il pubblico ha bisogno di queste informazioni. È stato più utilizzato all'inizio del DNS per copiare le zone tra i nameserver (ora ci sono alternative molto migliori). Quindi AXFR è spesso disabilitato ... tranne per il fatto che se si fa DNSSEC contemporaneamente, in qualche modo specifico (ovvero la variante NSEC e non NSEC3), è facile passare attraverso query DNS standard e senza AXFR, tutti i tuoi zona e ricostruire il file di zona. Esistono strumenti per farlo.

Nota anche che vari fornitori online venderanno file di zona e / o un elenco di tutti i nomi di dominio per molti TLD, che hanno acquisito con vari mezzi (un'idea tra l'altro: prendi i file di zona aperti, come .COM, e per TLD esegui .exampleuna query uno per uno tutto il nome che hai trovato .COM, che potrebbe darti alcune idee, oltre ovviamente alla camminata del dizionario in base alle lingue più utilizzate nel TLD cercato).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.