Qual è il ruolo dei record NS all'apice di un dominio DNS?

$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

Il ruolo di un record NS sotto l'apice di un dominio è ben compreso; esistono per delegare l'autorità per un sottodominio a un altro nameserver. Esempi di questo sopra includono i record NS per sub1e sub2. Ciò consente al nameserver di distribuire riferimenti per parti del dominio per le quali non si ritiene autorevole.

Lo scopo dei record NS all'apice di un dominio, ns1e ns2in questo caso, sembra essere meno compreso da Internet in generale. La mia comprensione (che potrebbe non essere olistica) è la seguente:

1. Non vengono utilizzati memorizzando nella cache i server DNS per determinare i server autorevoli per il dominio. Questo è gestito dalla colla del nameserver , che è definita a livello di registrar. Il registrar non utilizza mai queste informazioni per generare i record di colla.
2. Non vengono utilizzati per delegare l'autorizzazione per l'intero dominio ad altri nameserver. Cercare di farlo con software come ISC BIND non comporterà affatto il comportamento di riferimento "previsto", poiché il nameserver continuerà a considerarsi autorevole per la zona.
3. Non vengono utilizzati dal nameserver per determinare se deve restituire risposte autorevoli ( AAflag set) oppure no; tale comportamento è definito se si dice al software di essere un master o uno slave per la zona. La maggior parte dei software di nameserver servirà piuttosto felicemente i record NS dell'apice in disaccordo con le informazioni contenute nei record di colla a monte, che a loro volta genereranno avvisi per il dominio da parte dei noti siti Web di convalida DNS.

Stando così le cose, cosa ci resta? Perché stiamo definendo queste informazioni se non sembrano essere consumate memorizzando nella cache server DNS su Internet in generale?

Identificazione subordinata

I record NS di livello Apex sono utilizzati da un server master per identificare i suoi subordinati. Quando i dati su un server dei nomi autorevole cambiano, li pubblicizzeranno tramite DNS NOTIFYmessaggi ( RFC 1996 ) a tutti i suoi colleghi in quell'elenco. Questi server a loro volta richiameranno con una richiesta per il SOArecord (che contiene il numero seriale) e decideranno se ritirare una copia più recente di quella zona.

• È possibile inviare questi messaggi a server non elencati nella NSsezione, ma ciò richiede direttive di configurazione specifiche del server (come la also-notifydirettiva ISC BIND ). I record NS dell'apice comprendono l'elenco di base dei server da notificare con una configurazione predefinita.
• Vale la pena notare che i server secondari invieranno anche i messaggi NOTIFY tra loro in base a questi NSrecord, di solito con conseguente rifiuto registrato. Questo può essere disabilitato chiedendo ai server di inviare notifiche solo per le zone per cui sono padroni (BIND:) notify master;o di saltare le NSnotifiche basate interamente a favore delle notifiche esplicitamente definite nella configurazione. (BIND: notify explicit;)

Definizione autorevole

La domanda sopra conteneva un errore:

Non vengono utilizzati memorizzando nella cache i server DNS per determinare i server autorevoli per il dominio. Questo è gestito dalla colla del nameserver, che è definita a livello di registrar. Il registrar non utilizza mai queste informazioni per generare i record di colla.

Questa è una conclusione facile da raggiungere, ma non accurata. I NSdati e i dati dei record di colla (come quelli definiti nel tuo account registrar) non sono autorevoli. È ovvio che non possono essere considerati "più autorevoli" dei dati che risiedono sui server a cui viene delegata l'autorità. Ciò è sottolineato dal fatto che i referral non hanno il aaflag (Risposta autorevole) impostato.

Illustrare:

$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     172800  IN      A       199.43.135.53
a.iana-servers.net.     172800  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172800  IN      A       199.43.133.53
b.iana-servers.net.     172800  IN      AAAA    2001:500:8d::53

Nota la mancanza di aanelle bandiere per la risposta sopra. Il rinvio in sé non è autorevole. D'altra parte, i dati sul server a cui si fa riferimento sono autorevoli.

$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

Detto questo, questa relazione può diventare molto confusa in quanto non è possibile conoscere le versioni autorevoli di questi NSrecord senza i record non autorevoli NSdefiniti sul lato genitore del referral. Cosa succede se non sono d'accordo?

• La risposta breve è "comportamento incoerente".
• La risposta lunga è che i server dei nomi saranno inizialmente stub tutto fuori del deferimento (e colla) su una cache vuota, ma quelli NS, Ae AAAAregistrazioni possono eventualmente essere sostituiti quando sono aggiornati. Gli aggiornamenti si verificano quando scadono i TTL su tali record temporanei o quando qualcuno richiede esplicitamente la risposta per tali record.
  • Ae i AAAArecord per i dati fuori dalla zona (cioè i comnameserver che definiscono la colla per i dati al di fuori della comzona, simili example.net) finiranno sicuramente per essere aggiornati, poiché è un concetto ben noto che un nameserver non dovrebbe essere considerato una fonte autorevole di tali informazioni . (RFC 2181)
  • Quando i valori dei NSrecord differiscono tra i lati principale e secondario del riferimento (come i server dei nomi inseriti nel pannello di controllo del registrar diversi dai NSrecord che vivono su quegli stessi server), i comportamenti sperimentati saranno incoerenti, fino al figlio compreso NSi record vengono ignorati completamente. Questo perché il comportamento non è ben definito dagli standard e l'implementazione varia tra le diverse implementazioni del server ricorsivo. In altre parole, ci si può aspettare un comportamento coerente su Internet solo se le definizioni dei nameserver per un dominio sono coerenti tra i lati padre e figlio di un riferimento .

In sostanza, i server DNS ricorsivi su Internet torneranno indietro tra le destinazioni se i record definiti nella parte padre del referral non concordano con le versioni autorevoli di tali record. Inizialmente saranno preferiti i dati presenti nel rinvio, solo per essere sostituiti dalle definizioni autorevoli. Poiché le cache vengono costantemente ricostruite da zero su Internet, è impossibile che Internet si assesti su una singola versione della realtà con questa configurazione. Se i record autorevoli stanno facendo qualcosa di illegale secondo gli standard, come il puntamento dei NSrecord agli alias definiti da aCNAME, questo diventa ancora più difficile da risolvere; il dominio si alternerà tra funzionante e non funzionante per il software che rifiuta la violazione. (ad es. ISC BIND / nome)

RFC 2181 §5.4.1 fornisce una tabella di classificazione per l'affidabilità di questi dati e rende esplicito che i dati della cache associati ai riferimenti e alla colla non possono essere restituiti come risposta a una richiesta esplicita per i record a cui si riferiscono.

5.4.1. Ranking data

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

   <snip>

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

L'NS registra la zona delegata che fornisce completezza nella definizione del dominio. Gli stessi server NS si baseranno sul file di zona. Non ci si aspetta che provino a trovarsi eseguendo una query ricorsiva dai server root. I record NS nel file di zona forniscono una serie di altre funzioni.

I server di cache possono aggiornare l'elenco dei server dei nomi eseguendo una query su un server dei nomi dalla sua cache. Finché un server di memorizzazione nella cache conosce l'indirizzo di un server dei nomi, lo utilizzerà anziché cercare in modo ricorsivo un record NS appropriato.

Quando si spostano i server dei nomi, è importante aggiornare i vecchi server dei nomi e i nuovi server dei nomi. Ciò eviterà interruzioni o incongruenze che potrebbero verificarsi quando le definizioni delle due zone non sono sincronizzate. I record aggiornati verranno eventualmente aggiornati da tutti i server che hanno memorizzato nella cache i record NS. Ciò sostituirà l'elenco memorizzato nella cache dei server dei nomi.

I record NS aiutano anche a confermare la correttezza della configurazione DNS. Il software di convalida verifica spesso che le definizioni del server dei nomi della zona delegata corrispondano a quelle fornite dalla zona. Questo controllo può essere eseguito su tutti i server dei nomi. Eventuali disallineamenti possono indicare una configurazione errata.

Avere i record NS consente zone disconnesse (locali). Questi possono essere sottodomini di un dominio registrato o un dominio completamente nuovo (non raccomandato a causa di modifiche al TLD). Gli host che utilizzano i server dei nomi come loro server dei nomi saranno in grado di trovare le zone che non sono raggiungibili ricorrendo ai server principali. Altri server dei nomi possono essere configurati per cercare i server dei nomi per le zone locali.

Nel caso di DNS diviso (interno / esterno), è possibile che si desideri disporre di un diverso set di server DNS. In questo caso, l'elenco NS (e probabilmente altri dati) sarà diverso e i record NS nei file di zona elencheranno l'elenco dei server dei nomi appropriato.