TL; DR: sim, subdomínios intermediários precisam existir, pelo menos quando consultados, por definição do DNS; eles podem não existir no arquivo de zona embora.
Uma possível confusão para eliminar primeiro; Definição de "Não Terminal Não Vazio"
Você pode estar confundindo duas coisas, como outras respostas também parecem fazer. A saber, o que acontece ao consultar nomes versus como você configura seu servidor de nomes e o conteúdo do arquivo de zona.
O DNS é hierárquico. Para que qualquer nó folha exista, todos os componentes que o conduzem DEVEM existir, no sentido de que, se forem consultados, o servidor de nomes autoritativo responsável deve responder por eles sem erro.
Conforme explicado na RFC 8020 (que é apenas uma repetição do que sempre foi a regra, mas apenas alguns provedores de DNS precisavam de um lembrete), para qualquer consulta, uma resposta oficial do servidor de nomes NXDOMAIN (ou seja: esse registro de recurso não existe), significa que qualquer etiqueta "abaixo" deste recurso também não existe.
No seu exemplo, se uma consulta de intermediate.example.comretorno NXDOMAIN, então qualquer servidor de nomes recursiva adequada irá imediatamente responder NXDOMAINpor leaf.intermediate.example.comporque este registro não pode existir se todas as etiquetas em que não existem como registros.
Isso já foi afirmado no passado na RFC 4592 sobre caracteres curinga (que não são relacionados aqui):
O espaço para nome de domínio é uma estrutura em árvore. Os nós da árvore
possuem pelo menos um RRSet e / ou descendentes que coletivamente possuem
pelo menos um RRSet. Um nó pode existir sem RRSets apenas se houver
descendentes; este nó é um não terminal vazio.
Um nó sem descendentes é um nó folha. Nós de folha vazios não existem.
Um exemplo prático com nomes de domínio .US
Vamos dar um exemplo de trabalho de um TLD com muitos rótulos historicamente, isto é .US. Escolhendo qualquer exemplo online, vamos usar www.teh.k12.ca.us.
Obviamente, se você consultar esse nome, ou mesmo teh.k12.ca.usrecuperar os Aregistros. Nada conclusivo aqui para o nosso propósito (existe até um CNAME no meio dele, mas não nos importamos com isso):
$ 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
Vamos pesquisar agora k12.ca.us(não estou consultando o servidor de nomes autoritativo, mas isso não altera o resultado):
$ 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
O que aprendemos dessa resposta?
Primeiro, é um sucesso porque o status é NOERROR. Se tivesse sido qualquer outra coisa e especificamente NXDOMAINentão teh.k12.ca.us, nem www.teh.k12.ca.uspoderia existir.
Segundo, a seção RESPOSTA está vazia. Não há Aregistros para k12.ca.us. Isso não é um erro, esse tipo ( A) não existe para este registro, mas talvez existam outros tipos de registro para esse registro ou esse registro é um ENT, também conhecido como "Empty Non Terminal": está vazio, mas não é uma folha, existem coisas "abaixo" (veja a definição na RFC 7719 ), como já sabemos (mas normalmente a resolução é de cima para baixo, portanto, alcançaremos essa etapa antes de descer um nível abaixo e não o contrário, como estamos fazendo aqui para demonstração finalidade).
É por isso que, na verdade, como atalho, dizemos que o código de status é NODATA: este não é um código de status real, apenas significa NOERROR+ seção ANSWER vazia, o que significa que não há dados para esse tipo de registro específico, mas pode haver para outros.
Você pode repetir a mesma experiência para o mesmo resultado se consultar com o próximo rótulo "up", que é o nome ca.us.
Resultados das consultas versus conteúdo do arquivo de zona
Agora, de onde a confusão pode vir? Acredito que possa resultar de alguma idéia falsa que qualquer ponto em um nome DNS significa que há uma delegação. Isto é falso. Dito de forma diferente, seu example.comarquivo de zona pode ser assim, e é totalmente válido e funcionando:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
Com esse arquivo de zona, ao consultar este servidor de nomes, você obterá exatamente o comportamento observado acima: uma consulta para intermediate.example.comretornará NOERRORcom uma resposta vazia. Você não precisa criá-lo especificamente no arquivo de zona (se você não precisar dele por outros motivos), o servidor de nomes autoritário cuidará de sintetizar as respostas "intermediárias", porque ele precisa desse terminal não terminal vazio (e qualquer outros "no meio", se houvesse outros rótulos) como ele vê o nome da folha leaf.intermediate.example.com.
Observe que esse é um caso amplamente difundido em algumas áreas, mas você pode não vê-lo porque tem como alvo mais registros de "infraestrutura" aos quais as pessoas não estão expostas:
- em zonas reversas como
in-addr.arpou ip6.arpa, e especificamente a última. Você terá registros como 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 obviamente não há uma delegação em cada ponto, nem registros de recursos anexados em cada rótulo
- em
SRVregistros, como _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., um domínio pode ter muitos _proto._tcp.example.come _proto._udp.example.com SRVregistros, porque pelo projeto que deve ter esta forma, mas, ao mesmo tempo _tcp.example.come _udp.example.comvai permanecer vazio Não-terminais, porque nunca usei como registros
- de fato, existem muitos outros casos de construção específica de nomes com base em "rótulos de sublinhado" para vários protocolos, como o DKIM. O DKIM exige que você tenha registros DNS como esse
whatever._domainkey.example.com, mas obviamente _domainkey.example.comnunca será usado por si só, portanto continuará sendo um não terminal vazio. Esta é a mesma para TLSAregistos em DANE (ex: _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==), ou URIregistos (ex: _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")
Comportamento do servidor de nomes e geração de respostas intermediárias
Por que o servidor de nomes sintetiza automaticamente essas respostas intermediárias? O algoritmo de resolução principal para o DNS, conforme detalhado na seção 4.3.2 da RFC 1034, é a razão disso, vamos tomá-lo e resumir em nosso caso ao consultar o servidor de nomes autoritativo acima para o nome intermediate.example.com(este é o QNAMEprotocolo abaixo):
- Pesquise nas zonas disponíveis a zona que é o ancestral mais próximo de QNAME. Se essa zona for encontrada, vá para a etapa 3, caso contrário, etapa 4.
O servidor de nomes encontra a zona example.comcomo o ancestral mais próximo de QNAME, para que possamos ir para a etapa 3.
Temos agora isso:
- Comece a corresponder para baixo, etiqueta por etiqueta, na zona. [..]
uma. Se todo o QNAME for correspondido, encontramos o nó. [..]
b. Se uma correspondência nos tirar dos dados oficiais, temos uma referência. Isso acontece quando encontramos um nó com cortes de marcação NS RRs na parte inferior de uma zona. [..]
c. Se em algum rótulo, uma correspondência é impossível (ou seja, o rótulo correspondente não existe), verifique se existe um rótulo "*". [..]
Podemos eliminar os casos bec, porque nosso arquivo de zona não tem delegação (portanto, nunca haverá uma referência a outros servidores de nomes, nenhum caso b), nem curingas (portanto, nenhum caso c).
Nós só temos que lidar aqui com o caso a.
Começamos a corresponder, etiqueta por etiqueta, na zona. Portanto, mesmo se tivéssemos um sub.sub.sub.sub.sub.sub.sub.sub.example.comnome longo , em algum momento chegamos ao caso a: não encontramos uma referência nem um curinga, mas acabamos no nome final para o qual desejávamos um resultado.
Em seguida, aplicamos o restante do conteúdo do caso a:
Se os dados no nó forem um CNAME
Não é o nosso caso, ignoramos isso.
Caso contrário, copie todos os RRs que correspondem a QTYPE na seção de respostas e vá para a etapa 6.
Seja qual for QTYPE nós escolhemos ( A, AAAA, NS, etc.) não temos RRS para intermediate.example.comque ele não aparece na zonefile. Portanto, a cópia aqui está vazia. Agora terminamos na etapa 6:
Usando apenas dados locais, tente adicionar outros RRs que possam ser úteis para a seção adicional da consulta. Saída.
Não é relevante para nós aqui, por isso terminamos com sucesso.
Isso explica exatamente o comportamento observado: essas consultas retornarão, NOERRORmas também nenhum dado.
Agora, você pode se perguntar: "mas se eu usar qualquer nome, como another.example.comno algoritmo acima, eu deveria receber a mesma resposta (sem erro)", mas as observações serão relatadas NXDOMAINnesse caso.
Por quê?
Como todo o algoritmo, conforme explicado, começa com isso:
O algoritmo a seguir assume que os RRs estão organizados em várias estruturas em árvore, uma para cada zona e outra para o cache
Isso significa que o arquivo de zona acima é transformado nessa árvore:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
Portanto, ao seguir o algoritmo, de cima, você pode realmente encontrar um caminho: com > example > intermediate(porque o caminho com > example > intermediate > leafexiste). Mas another.example.com, depois de com > examplenão encontrar o anotherrótulo na árvore, como nó filho de example. Portanto, caímos na parte da escolha c de cima:
Se o rótulo "*" não existir, verifique se o nome que estamos procurando é o QNAME original na consulta ou um nome que seguimos devido a um CNAME. Se o nome for original, defina um erro de nome com autoridade na resposta e saia. Caso contrário, basta sair.
O rótulo *não existe e não seguimos a CNAME, portanto, estamos no caso set an authoritative name error in the response and exit:, aka NXDOMAIN.
Observe que todas as opções acima criaram confusão no passado. Isso é coletado em alguns RFCs. Veja, por exemplo, este lugar inesperado (a alegria das especificações de DNS serem tão impenetráveis) definindo caracteres curinga: RFC 4592 "O papel dos caracteres curinga no sistema de nomes de domínio" e notavelmente sua seção 2.2 "Regras de existência", também citada em parte no início de minha resposta, mas aqui está mais completa:
Os não-terminais vazios [RFC2136, seção 7.16] são nomes de domínio que não possuem registros de recursos, mas possuem subdomínios. Na seção 2.2.1,
"_tcp.host1.example". é um exemplo de um nome não terminal vazio.
Os não-terminais vazios são introduzidos por este texto na seção 3.1 da 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.
O parênteses "que pode estar vazio" especifica que os não
terminais vazios são explicitamente reconhecidos e que os não terminais vazios
"existem".
A leitura pedantica do parágrafo acima pode levar a uma
interpretação de que todos os domínios possíveis existem - até o
limite sugerido de 255 octetos para um nome de domínio [RFC1035]. Por exemplo,
www.example. pode ter um A RR e, na prática
, é uma folha da árvore do domínio. Mas a definição pode ser
entendida como o sub.www.example. também existe, embora sem dados. Por extensão, todos os domínios possíveis existem, da raiz em diante.
Como o RFC 1034 também define "um erro autoritário de nome indicando que o nome não existe" na seção 4.3.1, essa aparentemente não é a intenção da definição original, justificando a necessidade de uma definição atualizada na próxima seção.
E então a definição na próxima seção é o parágrafo que citei no começo.
Note-se que RFC 8020 (na NXDOMAINverdade significa NXDOMAIN, isto é, se você responder NXDOMAINpara intermediate.example.com, em seguida, leaf.intermediate.example.comnão pode existir) foi mandatada em parte porque vários provedores de DNS não seguiu esta interpretação e que o caos criado, ou eles eram apenas erros, ver, por exemplo um presente corrigido em 2013 em um código de servidor de nomes autoritário de código aberto: https://github.com/PowerDNS/pdns/issues/127
As pessoas precisavam, então, colocar contra-medidas específicas apenas para elas: isso não é um cache agressivo, NXDOMAINporque para esses provedores, se você chegar NXDOMAINa algum nó, ainda pode significar que você obtém algo mais do que NXDOMAINem outro nó abaixo dele.
E isso estava impossibilitando a minimização do QNAME (RFC 7816) (consulte https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf para obter mais detalhes) , enquanto se queria aumentar a privacidade. A existência de não terminais vazios no caso do DNSSEC também criou problemas no passado, em torno do manuseio da inexistência (consulte https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf, se estiver interessado, mas você realmente precisa de um bom entendimento do DNSSEC antes).
As duas mensagens a seguir dão um exemplo de problemas que um provedor precisava para aplicar adequadamente essa regra em Terminais Não Terminais Vazios, fornece uma perspectiva dos problemas e por que estamos lá: