tags: dig dns reconnaissance passive 2zone_transfer


Comando che copre quasi tutti i campi che ci interessano

 
dig +nocmd targetdomain.com any +multiline +noall +answer
 

Server DNS

Per vedere quali sono i server DNS di un determinato dominio ci basta lanciare il seguente comando:

dig ns certifiedhacker.com
 
; <<>> DiG 9.20.2-1-Debian <<>> ns certifiedhacker.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50497
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;certifiedhacker.com.		IN	NS
 
;; ANSWER SECTION:
certifiedhacker.com.	6847	IN	NS	ns1.bluehost.com.
certifiedhacker.com.	6847	IN	NS	ns2.bluehost.com.
 
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Nov 05 18:06:21 CET 2024
;; MSG SIZE  rcvd: 93

Le informazione riguardanti i server DNS del dominio certifiedhacker.com sono nella sezione ANSWER SECTION.

DNS Zone Transfer

Il trasferimento di zona DNS è il processo di trasferimento di una copia del file di zona DNS dal server DNS primario a un server DNS secondario. Nella maggior parte dei casi, il server DNS mantiene un server di riserva o secondario per ridondanza, che contiene tutte le informazioni archiviate nel server principale. Se l’impostazione di trasferimento DNS è abilitata sul server DNS di destinazione, fornirà informazioni DNS; in caso contrario, restituirà un errore che indica che il trasferimento di zona è fallito o rifiutato.

dig @ns1.bluehost.com certifiedhacker.com axfr
;; Connection to 162.159.24.80#53(162.159.24.80) for certifiedhacker.com failed: connection refused.
;; no servers could be reached
;; Connection to 162.159.24.80#53(162.159.24.80) for certifiedhacker.com failed: connection refused.
;; no servers could be reached
;; Connection to 162.159.24.80#53(162.159.24.80) for certifiedhacker.com failed: connection refused.
;; no servers could be reached

Oppure su Parrot questo errore viene espresso così:

L’errore come già detto ci indica che l’opzione Zone Transfer è disabilitata.

SOA (Start of Authority)

dig soa certifiedhacker.com                   
 
; <<>> DiG 9.20.2-1-Debian <<>> soa certifiedhacker.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15718
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;certifiedhacker.com.		IN	SOA
 
;; ANSWER SECTION:
certifiedhacker.com.	86400	IN	SOA	ns1.bluehost.com. dnsadmin.box5331.bluehost.com. 2024110500 86400 7200 3600000 300
 
;; Query time: 108 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Nov 05 18:18:53 CET 2024
;; MSG SIZE  rcvd: 114

Il comando dig soa restituisce informazioni importanti sulla configurazione del dominio, specialmente riguardo al record SOA (Start of Authority). Questo record contiene i dettagli principali dell’autorità per il dominio e include informazioni utili per capire come funziona la gestione del dominio stesso.

Ecco cosa significano i vari campi nell’output:

  1. Server dei Nomi Primario (ns1.bluehost.com.): Questo è il server DNS principale per il dominio certifiedhacker.com. È l’autorità principale che ha il controllo sui record DNS del dominio.

  2. Responsabile del Dominio (dnsadmin.box5331.bluehost.com.): È l’indirizzo email del responsabile o amministratore DNS del dominio, rappresentato con un punto al posto della ”@” (in questo caso, [email protected]).

  3. Numero di Serie (2024110500): È un identificatore unico e incrementale per la versione del record SOA. Ogni volta che c’è una modifica ai record DNS del dominio, questo numero viene incrementato per informare i server secondari che devono aggiornare le informazioni.

  4. Refresh Time (86400 secondi): È il tempo (in secondi) che i server DNS secondari devono attendere prima di interrogare il server principale per vedere se ci sono aggiornamenti. In questo caso, è impostato su 86400 secondi (24 ore).

  5. Retry Time (7200 secondi): Se un server secondario non riesce a contattare il server primario, questo valore indica l’intervallo di tempo (in secondi) prima che il server secondario riprovi a connettersi. Qui è impostato su 7200 secondi (2 ore).

  6. Expire Time (3600000 secondi): Se un server secondario non riesce a contattare il server primario per aggiornare i record DNS per un lungo periodo, dopo questo tempo i dati memorizzati in cache verranno considerati non validi. In questo esempio, è impostato su 3600000 secondi (circa 41 giorni).

  7. TTL Minimo (300 secondi): Indica il tempo minimo (in secondi) che i resolver (come i provider DNS) devono mantenere in cache i record DNS per il dominio prima di richiederli di nuovo. In questo caso, è impostato su 300 secondi (5 minuti).

In breve

Il comando dig soa è utile per ottenere informazioni sulla struttura di gestione del dominio, identificare il server DNS primario, trovare il contatto amministrativo e capire i tempi di aggiornamento tra server DNS primario e secondari. La stessa identica operazione la si può fare tramite nslookup per saperne di più visita la seguente pagina Ns-lookup.