TL; DR：はい。少なくともサブクエリを行う場合は、DNSの定義に従って、中間サブドメインが存在する必要があります。ただし、ゾーンファイルには存在しない場合があります。
最初に排除する混乱の可能性。「空の非ターミナル」の定義
他の答えもそうであるように、あなたは2つのことを混乱させるかもしれません。すなわち、ネームサーバーとゾーンファイルのコンテンツをどのように構成するかに対して、名前を照会するときに何が起こるか。
DNSは階層的です。リーフノードが存在するためには、それを導くすべてのコンポーネントが存在しなければなりません。それらが照会された場合、責任のある権威あるネームサーバーはエラーなしでそれらに応答する必要があるという意味です。
RFC 8020で説明されているように（これは常に規則であったことの単なる繰り返しですが、一部のDNSプロバイダーはリマインダーが必要でした）、いずれかのクエリに対して、権威あるネームサーバーがNXDOMAINを応答する場合（つまり、このリソースレコードは存在しません）、それは、このリソースの「下」にあるラベルも存在しないことを意味します。
あなたの例では、クエリがreturnをintermediate.example.com返す場合、NXDOMAIN適切な再帰ネームサーバーはすぐに応答NXDOMAINしますleaf.intermediate.example.comます。これは、その中のすべてのラベルがレコードとして存在しない場合、このレコードは存在できないためです。
これは、ワイルドカードに関するRFC 4592で過去に既に述べられています（ここでは無関係です）：
ドメインネームスペースはツリー構造です。ツリー内のノードは、
少なくとも1つのRRSetを所有するか、少なくとも1つのRRSetを集合的に所有
する子孫を持ちます。ノードには、RRSetsが存在しない場合
があります。このノードは空の非ターミナルです。
子孫のないノードはリーフノードです。空の葉ノードは存在しません。
.USドメイン名の実用的な例
歴史的に多くのラベルを持つTLDから実用的な例を見てみましょう.US。オンラインで例を挙げて、使用しましょうwww.teh.k12.ca.us。
もちろん、この名前を照会する場合、またはレコードteh.k12.ca.usを取得することもできますA。ここで私たちの目的のために決定的なものは何もありません（その中にCNAMEさえありますが、私たちはそれを気にしません）：
$ 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
クエリを実行しますk12.ca.us（権限のあるネームサーバーはクエリしていませんが、実際には結果は変わりません）。
$ 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
この答えから何を学びますか？
まず、ステータスがであるため成功ですNOERROR。それが何か他のものであり、具体的にNXDOMAINはteh.k12.ca.us、www.teh.k12.ca.us存在していなかった場合。
2番目に、ANSWERセクションは空です。のA記録はありませんk12.ca.us。これはエラーでAはなく、このレコードにはこのタイプ（）は存在しませんが、このレコードに他のレコードタイプが存在するか、このレコードがENT（別名「空の非ターミナル」）である可能性があります。 「下」にあるものがあります（RFC 7719の定義を参照してください）既に知って）があります（ただし、通常、解像度はトップダウンであるため、デモのためにここで行っているように、1つ下のレベルに進む前にこのステップに到達します）目的）。
これが、実際に、ショートカットとしてステータスコードを言う理由ですNODATA：これは単なるステータスコードではなく、単にNOERROR空のANSWERセクションを意味します。つまり、この特定のレコードタイプにはデータがありませんが、他のレコードタイプにはあります。
次の「up」ラベル、つまりnameでクエリすると、同じ結果に対して同じ実験を繰り返すことができますca.us。
クエリの結果とゾーンファイルのコンテンツ
混乱がどこから来るのか？DNS名にドットが含まれていると、委任があることを意味するという誤った考えに基づいている可能性があります。これは誤りです。別のexample.com言い方をすれば、ゾーンファイルはそのようなものであり、完全に有効で動作しています。
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
このようなゾーンファイルを使用して、このネームサーバーにクエリを実行するintermediate.example.comと、上記の動作が正確に得られます。クエリNOERRORは空の応答で返されます。ゾーンファイルで特別に作成する必要はありません（他の理由で必要ない場合）、権限のあるネームサーバーは、この空の非ターミナル（および他のラベルがあった場合は「中間」にあります）、リーフ名が表示されleaf.intermediate.example.comます。
これは実際には一部の地域で広まっているケースですが、人々がさらされていないより多くの「インフラストラクチャ」レコードを対象としているため、表示されない場合があります。
in-addr.arpまたはのような逆ゾーンip6.arpa、特に最後のゾーン。のようなレコードが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.あり、各ドットに委任がなく、各ラベルにリソースレコードが添付されていないことは明らかです。- で
SRV、レコードなど_nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr.、ドメインは、多くのことができます_proto._tcp.example.comし、_proto._udp.example.com SRV設計によって、彼らはこのフォームを持っている必要がありますので、しかし、同時に、レコードを_tcp.example.comし、_udp.example.comレコードとして使用されることがないので、空非ターミナルのままになります
- 実際には、DKIMなどのさまざまなプロトコルの「アンダースコアラベル」に基づいた名前の特定の構成の他の多くのケースがあります。DKIM
whatever._domainkey.example.comでは、などのDNSレコードを_domainkey.example.com使用することが義務付けられていますが、明らかにそれ自体は決して使用されないため、空の非ターミナルのままになります。これがために同じであるTLSA（例：DANEのレコード_25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==）、またはURI記録（例：_ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public"）
ネームサーバーの動作と中間応答の生成
なぜネームサーバーは、このような中間的な回答を自動的に合成するのですか？RFC 1034セクション4.3.2で詳述されているDNSのコア解決アルゴリズムがその理由です。上記の権威あるネームサーバーに名前を照会する場合のケースを要約してみましょうintermediate.example.com（これはQNAME以下のプロトコルです）。
- QNAMEに最も近い先祖であるゾーンの利用可能なゾーンを検索します。そのようなゾーンが見つかった場合は、手順3に進み、見つからない場合は手順4に進みます。
ネームサーバーは、ゾーンexample.comをQNAMEの最も近い祖先として検出するため、ステップ3に進むことができます。
これがあります：
- ゾーンで、ラベルごとに照合を開始します。[..]
a。QNAME全体が一致した場合、ノードが見つかりました。[..]
b。一致により信頼できるデータから除外される場合は、紹介があります。これは、ゾーンの下部に沿ってNS RRマークカットがあるノードに遭遇したときに発生します。[..]
c。あるラベルで一致が不可能な場合（つまり、対応するラベルが存在しない場合）、「*」ラベルが存在するかどうかを確認します。[..]
ゾーンファイルには委任がないため（他のネームサーバーへの紹介はなく、ケースbはありません）、ワイルドカード（ケースcはありません）がないため、ケースbとcを削除できます。
ここで対処する必要があるのは、ケースaのみです。
ゾーンで、ラベルごとに照合を開始します。長いsub.sub.sub.sub.sub.sub.sub.sub.example.com名前があったとしても、ある時点でケースaに到達します。紹介もワイルドカードも見つかりませんでしたが、結果を求めた最終的な名前になりました。
次に、ケースaの残りのコンテンツを適用します。
ノードのデータがCNAMEの場合
私たちの場合ではなく、それをスキップします。
それ以外の場合は、QTYPEに一致するすべてのRRを回答セクションにコピーし、手順6に進みます。
どのようなQTYPEは、我々は選択した（A、AAAA、 NS私たちは何のためのRR持っていない、など）intermediate.example.comそれはゾーンファイルには表示されませんように。したがって、ここのコピーは空です。これで、ステップ6で終了します。
ローカルデータのみを使用して、クエリの追加セクションに役立つ可能性のある他のRRを追加しようとします。出口。
ここでは私たちには関係ないので、成功で終わります。
これは、観察された動作を正確に説明しています。このようなクエリは返されますNOERRORが、データも返されません。
さて、あなたは自分自身に問うことがあります。「しかし、私は次のように、任意の名前を使用するならば、another.example.com上記のアルゴリズムによって、私は同じ応答（エラーなし）を取得する必要」が、観測は代わりに報告するNXDOMAINような場合には。
どうして？
アルゴリズム全体が説明されているように、これで始まるので：
次のアルゴリズムは、RRがいくつかのツリー構造で構成されていることを前提としています。1つは各ゾーンに、もう1つはキャッシュに使用されます
これは、上記のゾーンファイルが次のツリーに変換されることを意味します。
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
上から、アルゴリズムを以下のときに、あなたは確かにパスを見つけることができますcom > example > intermediate（パスがあるためcom > example > intermediate > leafに存在する）でものためにanother.example.com、後に com > exampleあなたが見つけていないanother子供がノードとして、ツリーのラベルをexample。したがって、上から選択cの一部に分類されます。
「*」ラベルが存在しない場合、探している名前がクエリ内の元のQNAMEか、CNAMEが原因で従った名前かを確認します。名前が元の場合、応答に信頼できる名前エラーを設定して終了します。それ以外の場合は終了します。
ラベルが*存在しない、と私たちは従わなかったCNAMEので、我々は、ケース内にある、： set an authoritative name error in the response and exit、別名NXDOMAIN。
上記のすべてが過去に混乱を引き起こしたことに注意してください。これはいくつかのRFCで収集されます。たとえば、ワイルドカードを定義するこの予想外の場所（DNS仕様の不透過性）を参照してください。RFC4592「ドメインネームシステムでのワイルドカードの役割」、特にセクション2.2私の答えですが、ここではより完全です：
空の非端末[RFC2136、セクション7.16]は、リソースレコードを所有していないが、サブドメインを所有しているドメイン名です。セクション2.2.1の
「_tcp.host1.example。」空の非端末名の例です。
空の非端末は、RFC 1034のセクション3.1の次のテキストで紹介されています。
# 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.
括弧で囲まれた「空でもよい」は、空の非
端末が明示的に認識され、空の非端末が
「存在する」ことを指定します。
上記の段落を慎重に読むと、
考えられるすべてのドメインが存在するという解釈につながる可能性があります-
ドメイン名に対して推奨される制限である255オクテット[RFC1035]まで。たとえば、
www.example。A RRを持つ場合があり、実際
には、ドメインツリーの葉です。しかし、定義は
sub.www.exampleを意味すると解釈できます。データがなくても存在します。拡張により、ルートから下に、すべての可能なドメインが存在します。
RFC 1034はセクション4.3.1で「名前が存在しないことを示す信頼できる名前エラー」も定義しているため、これは明らかに元の定義の意図ではなく、次のセクションで更新された定義の必要性を正当化します。
そして、次のセクションの定義は、冒頭で引用した段落です。
さまざまなDNSプロバイダーがこの解釈に従わず、大混乱を引き起こしたか、単にバグであったため、RFC 8020（NXDOMAIN実際に意味するNXDOMAIN、つまり、存在しない場合）が一部義務付けられていたことに注意してください2013年に1つのオープンソースの権威あるネームサーバーコードで修正：https : //github.com/PowerDNS/pdns/issues/127NXDOMAINintermediate.example.comleaf.intermediate.example.com
積極的にキャッシュされていません。その後、必要な人々はちょうど彼らのために具体的な対策置くためにNXDOMAINあなたが取得する場合、これらのプロバイダのため、NXDOMAINいくつかのノードで、それはまだあなたがより他の何かを得ることを意味しNXDOMAIN、その下に別のノードでは。
これにより、QNAMEの最小化（RFC 7816）を取得できなくなりました（詳細については、https：//indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdfを参照してください） 、プライバシーを強化したいと考えていました。DNSSECの場合の空の非端末の存在も、過去の非存在の処理に関する問題を引き起こしました（https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647を参照してください） /AFNIC_OARC_Dallas.pdf興味がある場合は、DNSSECを十分に理解する必要があります。
次の2つのメッセージは、1つのプロバイダーが空の非ターミナルに対してこのルールを適切に実施する必要があった問題の例を示しています。