Risoluzione di un dominio NS quando punta allo stesso dominio

Leggere questa domanda mi ha fatto pensare:

Voglio ospitare un server DNS per il mio sito Web di casa da casa mia (che ha un IP statico) che cosa devo fare?

Sono a mio agio con DNS e come funziona, ma questa domanda mi porta su un percorso che non avevo mai considerato prima.

Supponiamo di ospitare un server DNS per il mio dominio ( example.com) su 1.2.3.4e questo server DNS pubblicizza la seguente zona (semplificata):

@   NS ns.domain.com.
@   A  1.2.3.4
ns  A  1.2.3.4

Successivamente mi registro ns.example.comcome example.comserver dei nomi con il mio registrar.

Non possiamo risolvere l'indirizzo ns.example.comsenza prima sapere di chi è responsabile example.com.

Una volta che sappiamo che ns.example.comè il server dei nomi per example.comnon restiamo bloccati? Sicuramente non c'è modo di contattare ns.example.comperché il record A che identifica il loro indirizzo IP è detenuto dallo stesso server ...?

Presumibilmente c'è un passaggio che mi manca nella ricerca ...

Dopo aver letto questo , la mia comprensione è confermata ma sono ancora perplesso ...

Sembra che sia possibile, come google.comsembra essere configurato in questo modo (come indicato nell'articolo collegato).

Non manca un passaggio tra 5 e 6?

Passaggio 5: [...] Il server .com gTLD risponde con un elenco di tutti i record NS di google.com. In questo caso, Google ha quattro server dei nomi, da "ns1.google.com" a "ns4.google.com".

Passaggio 6: Infine, il resolver DNS esegue una query su uno dei server dei nomi di Google per l'IP di "www.google.com".

... sì, ma dobbiamo conoscere l'IP di uno di questi nameserver per interrogarli, scambiando efficacemente una www.google.comquery con una ns1.google.comquery temporanea .

Cosa mi sto perdendo qui?

In questa situazione, la zona padre ha una copia dei record A / AAAA pertinenti - chiamati record di colla - quindi nel 'Passaggio 5' il server li include automaticamente nella risposta e non sono necessarie ulteriori query nidificate.

Qualsiasi risposta che includa i record NS (sia che si trattasse di una query diretta per i record NS, sia che si trattasse di una query ordinaria che genera un riferimento) includerà sempre i corrispondenti record di colla nella sezione "AGGIUNTIVO":

$ dig google.com. A @ c.gtld-servers.net.

;; flag: qr rd; QUERY: 1, RISPOSTA: 0, AUTORITÀ: 4, AGGIUNTIVO: 9

;; SEZIONE AUTORITÀ:
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns2.google.com.
...

;; SEZIONE AGGIUNTIVA:
ns1.google.com. 172800 IN AAAA 2001: 4860: 4802: 32 :: a
ns1.google.com. 172800 IN A 216.239.32.10
ns2.google.com. 172800 IN AAAA 2001: 4860: 4802: 34 :: a
ns2.google.com. 172800 IN A 216.239.34.10
...

(Questa copia viene gestita manualmente: quando il proprietario del dominio configura i nameserver nella zona padre, possono anche specificare gli indirizzi IP insieme ai nomi.)

Come esempio di come sono effettivamente archiviati i record , puoi dare un'occhiata alla zona radice che ha molte di queste delegazioni con record di colla - sono semplicemente posizionate in linea nella zona padre:

lt. 172800 IN NS a.tld.lt.
lt. 172800 IN NS b.tld.lt.
a.tld.lt. 172800 IN A 195.8.218.131
b.tld.lt. 172800 IN A 194.0.20.1
b.tld.lt. 172800 IN AAAA 2001: 678: 19: 0: 0: 0: 0: 1

Come nota finale, i record di colla diventano obbligatori solo per i nameserver dello stesso dominio, ma non sono richiesti quando non si verifica un ciclo - è molto comune per il dominio A utilizzare i nameserver dal dominio B, nel qual caso la zona padre spesso non avrà record di colla e il cliente dovrà effettivamente eseguire ulteriori query da solo.

Il passaggio 5 di quell'articolo dice:

[...] Il server .com gTLD non ha gli indirizzi IP per google.com, ma conosce la posizione dei server dei nomi di google.com. Il server .com gTLD risponde con un elenco di tutti i record NS di google.com.

Se non sbaglio, anche se il server .com gTLD non ha record per gli indirizzi IP per google.com , conoscendo la posizione del server dei nomi di google.com può interrogare gli indirizzi IP e rispondere con essi.

Forse fare un po 'di sperimentazione con l' diguso +tracee +norecursein diversi passaggi può chiarire cosa sta succedendo.