TL; DR: sì, devono esistere sottodomini intermedi, almeno quando vengono richiesti, per definizione del DNS; tuttavia potrebbero non esistere nel file di zona.
Una possibile confusione da eliminare per prima; Definizione di "Vuoto non terminale"
Potresti confondere due cose, come sembrano anche fare altre risposte. Vale a dire, cosa succede quando si esegue una query per i nomi rispetto a come si configura il server dei nomi e il contenuto del file di zona.
Il DNS è gerarchico. Perché esista un nodo foglia, devono esistere tutti i componenti che lo conducono, nel senso che se vengono richiesti, il nameserver autorevole responsabile dovrebbe rispondere per loro senza errori.
Come spiegato in RFC 8020 (che è solo una ripetizione di quella che era sempre la regola, ma solo alcuni provider DNS avevano bisogno di un promemoria), se per qualsiasi query, un server dei nomi autorevole risponde NXDOMAIN (ovvero: questo record di risorse non esiste), allora significa che nessuna etichetta "sotto" questa risorsa non esiste neanche.
Nel tuo esempio, se una query per intermediate.example.comi rendimenti NXDOMAIN, quindi qualsiasi corretta nameserver ricorsiva risponderemo immediatamente NXDOMAINper leaf.intermediate.example.comquanto questo disco non può esistere se tutte le etichette in esso non esistono come record.
Questo è già stato affermato in passato nella RFC 4592 sui caratteri jolly (che non sono correlati qui):
Lo spazio dei nomi di dominio è una struttura ad albero. I nodi nella struttura
possiedono almeno un RRSet e / o hanno discendenti che possiedono collettivamente
almeno un RRSet. Un nodo può esistere senza RRSet solo se ha
discendenti che lo fanno; questo nodo è un non terminale vuoto.
Un nodo senza discendenti è un nodo foglia. Non esistono nodi foglia vuoti.
Un esempio pratico con i nomi di dominio .US
Facciamo un esempio funzionante da un TLD con molte etichette storicamente, cioè .US. Scegliendo qualsiasi esempio online, usiamolo www.teh.k12.ca.us.
Ovviamente se richiedi questo nome, o anche teh.k12.ca.uspuoi recuperare i Arecord. Niente di conclusivo qui per il nostro scopo (c'è anche un CNAME nel mezzo di esso, ma non ci interessa):
$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86
Cerchiamo ora per k12.ca.us(non sto interrogando il nameserver autorevole di esso, ma questo non cambia il risultato in effetti):
$ dig k12.ca.us A
; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us. IN A
;; AUTHORITY SECTION:
us. 3587 IN SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400
;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE rcvd: 104
Cosa impariamo da questa risposta?
Innanzitutto, è un successo perché lo stato è NOERROR. Se fosse stato qualcos'altro e specificamente NXDOMAINallora teh.k12.ca.us, né www.teh.k12.ca.uspotrebbe esistere.
In secondo luogo, la sezione RISPOSTA è vuota. Non ci sono Arecord per k12.ca.us. Questo non è un errore, questo tipo ( A) non esiste per questo record, ma forse esistono altri tipi di record per questo record o questo record è un ENT, alias "Empty Non Terminal": è vuoto, ma non è un leaf, ci sono cose "sotto" (vedi definizione in RFC 7719 ), come già sappiamo (ma normalmente la risoluzione è dall'alto verso il basso, quindi raggiungeremo questo passaggio prima di passare di un livello sotto e non il contrario come stiamo facendo qui per la dimostrazione scopo).
Questo è il motivo per cui, in realtà, come scorciatoia, diciamo che il codice di stato è NODATA: questo non è un vero codice di stato, significa solo NOERROR+ sezione RISPOSTA vuota, il che significa che non ci sono dati per questo specifico tipo di record ma potrebbero essercene altri.
Puoi ripetere lo stesso esperimento per lo stesso risultato se esegui una query con l'etichetta "up" successiva, questo è il nome ca.us.
Risultati delle query e contenuto del file di zona
Ora da dove può venire la confusione? Credo che possa derivare da una falsa idea che qualsiasi punto in un nome DNS significhi che esiste una delegazione. Questo è falso Detto diversamente, il tuo example.comfile di zona può essere così, ed è totalmente valido e funzionante:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
Con un tale file di zona, interrogando questo nameserver otterrai esattamente il comportamento sopra osservato: una query per intermediate.example.comrestituirà NOERRORuna risposta vuota. Non è necessario crearlo specificamente nel file di zona (se non è necessario per altri motivi), l'autorevole nameserver si occuperà di sintetizzare le risposte "intermedie", perché vede che ha bisogno di questo vuoto non terminale (e qualsiasi altri "nel mezzo" se ci fossero state altre etichette) in quanto vede il nome della foglia leaf.intermediate.example.com.
Si noti che questo è un caso molto diffuso in alcune aree, ma potresti non vederlo perché è destinato a più record "infrastrutturali" a cui le persone non sono esposte:
- in zone inverse come
in-addr.arpo ip6.arpa, e in particolare l'ultima. Avrai record simili 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.e ovviamente non c'è una delegazione in ogni punto, né record di risorse allegati a ciascuna etichetta
- nei
SRVrecord, ad esempio _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., un dominio può avere molti _proto._tcp.example.come _proto._udp.example.com SRVrecord perché in base alla progettazione devono avere questo modulo, ma allo stesso tempo _tcp.example.come _udp.example.comrimarranno vuoti non terminali perché mai utilizzati come record
- hai infatti molti altri casi di costruzione specifica di nomi basati su "etichette di sottolineatura" per vari protocolli come DKIM. DKIM ti impone di avere record DNS simili
whatever._domainkey.example.com, ma ovviamente _domainkey.example.comda solo non verrà mai utilizzato, quindi rimarrà un non terminale vuoto. Questo è lo stesso per il TLSArecord in DANE (es: _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==), o URIrecord (es: _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")
Comportamento del server dei nomi e generazione di risposte intermedie
Perché il nameserver sintetizza automaticamente tali risposte intermedie? L'algoritmo di risoluzione di base per il DNS, come dettagliato nella sezione 4.3.2 di RFC 1034, è il motivo per cui, prendiamolo e riassumiamo nel nostro caso quando interroghiamo il nameserver autorevole sopra per il nome intermediate.example.com(questo è il QNAMEprotocollo in sotto):
- Cerca le zone disponibili per la zona che è l'antenato più vicino a QNAME. Se viene trovata una tale zona, andare al passaggio 3, altrimenti al passaggio 4.
Il nameserver trova la zona example.comcome l'antenato più vicino a QNAME, quindi possiamo andare al passaggio 3.
Ora abbiamo questo:
- Inizia ad abbinare, etichetta per etichetta, nella zona. [..]
un. Se l'intero QNAME è abbinato, abbiamo trovato il nodo. [..]
b. Se una partita ci togliesse dai dati autorevoli, avremmo un rinvio. Questo accade quando incontriamo un nodo con RR RR che segna tagli lungo il fondo di una zona. [..]
c. Se su qualche etichetta, una corrispondenza è impossibile (cioè, l'etichetta corrispondente non esiste), controlla se esiste un'etichetta "*". [..]
Possiamo eliminare i casi bec, perché il nostro file di zona non ha deleghe (quindi non ci sarà mai un riferimento ad altri nameserver, nessun caso b), né caratteri jolly (quindi nessun caso c).
Dobbiamo solo trattare qui il caso a.
Iniziamo ad abbinare, etichetta per etichetta, nella zona. Quindi, anche se avessimo un sub.sub.sub.sub.sub.sub.sub.sub.example.comnome lungo , ad un certo punto, arriviamo al caso a: non abbiamo trovato un referral, né un jolly, ma siamo arrivati al nome finale per cui volevamo un risultato.
Quindi applichiamo il resto del contenuto del caso a:
Se i dati nel nodo sono CNAME
Non nel nostro caso, lo ignoriamo.
Altrimenti, copia tutti i RR che corrispondono a QTYPE nella sezione delle risposte e vai al passaggio 6.
Qualunque sia QTYPE scegliamo ( A, AAAA, NS, etc.) non abbiamo RR per intermediate.example.comquanto non compare nel zone file. Quindi la copia qui è vuota. Ora finiamo al passaggio 6:
Utilizzando solo dati locali, provare ad aggiungere altri RR che potrebbero essere utili alla sezione aggiuntiva della query. Uscita.
Non rilevante per noi qui, quindi finiamo con successo.
Questo spiega esattamente il comportamento osservato: tali query restituiranno NOERRORma non ci sono dati.
Ora, potresti chiederti: "ma se uso un nome qualsiasi, come another.example.comallora con l'algoritmo di cui sopra, dovrei ottenere la stessa risposta (nessun errore)", ma le osservazioni verrebbero invece riportate NXDOMAINin quel caso.
Perché?
Perché l'intero algoritmo come spiegato, inizia con questo:
Il seguente algoritmo presuppone che i RR siano organizzati in diverse strutture ad albero, uno per ciascuna zona e un altro per la cache
Ciò significa che il file di zona sopra è trasformato in questo albero:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
Quindi, seguendo l'algoritmo, dall'alto, puoi davvero trovare un percorso: com > example > intermediate(perché il percorso com > example > intermediate > leafesiste) Ma per another.example.com, dopo com > exampleche non trovi l' anotheretichetta nella struttura, come nodo figlio di example. Quindi cadiamo in parte della scelta c dall'alto:
Se l'etichetta "*" non esiste, controlla se il nome che stiamo cercando è il QNAME originale nella query o un nome che abbiamo seguito a causa di un CNAME. Se il nome è originale, impostare un errore di nome autorevole nella risposta ed uscire. Altrimenti basta uscire.
L'etichetta *non esiste e non abbiamo seguito un CNAME, quindi siamo nel caso: set an authoritative name error in the response and exitaka NXDOMAIN.
Si noti che tutto quanto sopra ha creato confusione in passato. Questo è raccolto in alcuni RFC. Vedi ad esempio questo luogo inaspettato (la gioia delle specifiche DNS è così impenetrabile) che definisce i caratteri jolly: RFC 4592 "Il ruolo dei caratteri jolly nel sistema dei nomi di dominio" e in particolare la sua sezione 2.2 "Regole di esistenza", citata anche in parte all'inizio di la mia risposta ma qui è più completa:
I non terminali vuoti [RFC2136, sezione 7.16] sono nomi di dominio che non possiedono record di risorse ma che hanno sottodomini. Nella sezione 2.2.1,
"_tcp.host1.example." è un esempio di un nome non terminale vuoto.
I non terminali vuoti sono introdotti da questo testo nella sezione 3.1 della RFC 1034:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.
La parentesi "che può essere vuota" specifica che i non
terminali vuoti sono esplicitamente riconosciuti e che i non terminali vuoti
"esistono".
La lettura pedonale del paragrafo precedente può portare a
un'interpretazione dell'esistenza di tutti i possibili domini, fino al
limite suggerito di 255 ottetti per un nome di dominio [RFC1035]. Ad esempio,
www.esempio. può avere un RR, e per quanto riguarda praticamente
, è una foglia dell'albero del dominio. Ma la definizione può essere
intesa come sottotitolo www.esempio. esiste anche, anche se senza dati. Per estensione, esistono tutti i possibili domini, dalla radice in giù.
Poiché RFC 1034 definisce anche "un errore di nome autorevole che indica che il nome non esiste" nella sezione 4.3.1, quindi questo apparentemente non è lo scopo della definizione originale, giustificando la necessità di una definizione aggiornata nella sezione successiva.
E poi la definizione nella prossima sezione è il paragrafo che ho citato all'inizio.
Si noti che RFC 8020 (in NXDOMAINrealtà significa NXDOMAIN, che è se si risponde NXDOMAINper intermediate.example.com, quindi leaf.intermediate.example.comnon può esistere) è stato incaricato in parte perché i vari fornitori di DNS non ha seguito questa interpretazione e che il caos creato, o erano solo gli insetti, si veda ad esempio questo uno risolto nel 2013 in un codice nameserver autorevole opensource: https://github.com/PowerDNS/pdns/issues/127
Le persone dovevano quindi mettere contromisure specifiche solo per loro: ciò non è una cache aggressiva NXDOMAINperché per quei provider se si arriva NXDOMAINa un nodo, può comunque significare che si ottiene qualcos'altro rispetto NXDOMAINa un altro nodo al di sotto di esso.
E questo rendeva impossibile ottenere la minimizzazione di QNAME (RFC 7816) (vedi https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf per dettagli più lunghi) , mentre si voleva aumentare la privacy. L'esistenza di non terminali vuoti in caso di DNSSEC ha anche creato problemi in passato, riguardo alla gestione della non esistenza (vedi https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf se interessati, ma prima hai davvero bisogno di una buona conoscenza di DNSSEC).
I seguenti due messaggi forniscono un esempio dei problemi che un fornitore ha dovuto essere in grado di applicare correttamente questa regola sui vuoti non terminali, fornisce una prospettiva dei problemi e del perché: