In termini fisici, la delega è molto simile a come un manager delegherà la responsabilità dei compiti al proprio personale. I risultati sono gli stessi, tuttavia più di una persona è stata coinvolta nel processo. Il manager riceve la richiesta di lavoro, passa la responsabilità a un altro membro del personale e il membro del personale o il manager ritorna con i risultati del lavoro. Tutto questo a condizione che il lavoro svolto dallo staff sia effettivamente corretto ed è ciò che il richiedente originale ha richiesto (o che il richiedente ha effettivamente richiesto qualcosa che fosse valido in primo luogo!).
Con la delega DNS, è abbastanza simile. Quando ai com
server dei nomi viene chiesto il posto dove trovare l'autorità della zona example.com
, spesso delegano questo lavoro a server dei nomi separati (in realtà nella stragrande maggioranza dei casi, in realtà delegano la risposta ad altri server dei nomi). Quando registri per la prima volta un dominio, ad esempio il nostro example.com
dominio, ciò viene spesso eseguito tramite una terza parte denominata registrar. È prassi comune dei registrar inserire i propri server dei nomi per la delegazione e servire una zona predefinita da tali server dei nomi. Questa zona di default include i requisiti di base per servire quella zona su internet (i SOA
, NS
e A
record associati a quei record NS).
Ovviamente se tu stesso vuoi prendere il controllo dell'autorità del dominio, devi invece chiedere al registrar di delegare il dominio al tuo nameserver. Diversi registrar si riferiscono a questo processo in vari modi, "cambia server dei nomi", "usa DNS di terze parti", "Aggiungi record di colla" e così via. Il meccanismo sottostante rimane lo stesso. Fornisci, in genere, 2 o più "nomi dei server dei nomi" (ad esempio ns0.example.com
e ns1.example.com
) e gli indirizzi IP a cui ns0
e ns1
sono. Quindi elaborano la richiesta e la delega viene indirizzata dal proprio registrar ai server dei nomi forniti.
In termini tecnici, è a questo punto che devi assicurarti che i tuoi nameserver siano attivi e funzionanti, servendo il dominio example.com
, con un minimo di SOA
(record di inizio autorità), 1 o più NS
record e i A
record (gli IP) che questi record NS sono risolti da:
example.com. IN SOA ns0.example.com. hostmaster.example.com. ( 10 3600 900 604800 7200 )
IN NS ns0.example.com.
IN NS ns1.example.com.
ns0 IN A 192.0.2.8
ns1 IN A 192.0.2.44
(Ho scelto alcuni valori arbitrari condivisi per i valori SOA, i nomi per i record NS e gli IP a cui risolvono i nameserver). Questi dovranno tutti riflettere la zona per cui stai servendo.
Questo servizio DNS deve essere visibile da qualsiasi parte di Internet e non essere protetto da firewall (è necessario consentire la porta 53 udp e tcp inbound). Inoltre, il tuo fornitore di servizi non deve bloccare nemmeno quella porta (che alcuni fornitori bloccano il traffico in entrata destinato a quelle porte).
Dato il mio confronto originale, i com
server dei nomi sono i gestori di DNS, che stanno delegando la zona example.com
ai server dei nomi (i membri dello staff) per fare il lavoro di fornire le informazioni di zona di base ( SOA
, NS
, A
). Puoi anche servire qualsiasi record aggiuntivo come i record del server di posta MX
o può essere un A
record per il tuo www.example.com
indirizzo.
Se quel server dei nomi non esegue il lavoro, restituisce risultati errati o presenta un blocco di terze parti (firewall / ISP) che blocca il lavoro, non si avrà DNS funzionante e la delega si interrompe.
Potrebbe anche essere la pena di notare che il dominio non deve essere delegata al server dei nomi nello stesso dominio, in modo ns0.example.net
e ns0.example.org
potrebbe essere sia valida nameserver che avrebbero potuto example.com
delegato a loro. A condizione che entrambi i server dei nomi offrissero il example.com
dominio.