TL; DR : 예, 최소한 DNS의 정의에 따라 쿼리 할 때 중간 하위 도메인이 있어야합니다. 존 파일에는 존재하지 않을 수도 있습니다.
먼저 제거 할 수있는 혼란. "비 터미널 비우기"의 정의
다른 답변이하는 것처럼 두 가지를 혼란스럽게 할 수 있습니다. 즉, 이름을 쿼리 할 때 발생하는 작업과 이름 서버 및 영역 파일의 내용을 구성하는 방법이 다릅니다.
DNS는 계층 적입니다. 리프 노드가 존재하기 위해서는 그 노드로 이어지는 모든 구성 요소가 존재해야합니다. 이는 요청이있을 경우 책임있는 네임 네임 서버가 오류없이 응답해야한다는 의미입니다.
RFC 8020 (항상 규칙의 반복이지만 일부 DNS 제공 업체 만 미리 알림이 필요함)에 설명 된 바와 같이 쿼리에 대해 권한있는 네임 서버가 NXDOMAIN (즉,이 리소스 레코드가 없음)으로 응답하면, 이는이 자원이 "아래"라는 레이블도 존재하지 않음을 의미합니다.
에 대한 쿼리 경우 예에서, intermediate.example.com반환 NXDOMAIN후 어떤 적절한 재귀 네임 서버가 즉시 회신 해 드리겠습니다 NXDOMAIN을 위해 leaf.intermediate.example.com이 기록이 존재할 수 있기 때문에 모든 라벨은 레코드로 존재하지 않는 경우.
이것은 RFC 4592 에서 과거 에 와일드 카드에 대해 이미 언급되었습니다 (여기서는 관련이 없습니다).
도메인 네임 스페이스는 트리 구조입니다. 트리의 노드는
하나 이상의 RRSet을 소유하거나 하나 이상의 RRSet을 집합 적으로 소유하는 자손을
갖습니다. 하위 노드가있는 경우에만 RRSet이없는 노드가 존재할 수 있습니다
. 이 노드는 비어있는 비 터미널입니다.
자손이없는 노드는 리프 노드입니다. 빈 리프 노드가 없습니다.
미국 도메인 이름을 가진 실제 예
역사적으로 많은 레이블을 가진 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않을 것입니다.
둘째, 답변 섹션이 비어 있습니다. 에 대한 A레코드 가 없습니다 k12.ca.us. 이 오류 A는이 레코드에 대해이 유형 ( )이 존재하지 않지만이 레코드에 대해 다른 레코드 유형이 존재하거나이 레코드가 ENT 일 수 있습니다 ( "비 터미널 비우기"). 비어 있지만 잎이 아닙니다. 우리가 이미 알고 있듯이 "아래"( RFC 7719의 정의 참조) 것들이 있습니다 (그러나 일반적으로 해상도는 하향식이므로 시연을 위해 여기에서 수행하는 것과 반대가 아닌 한 단계 아래로 이동하기 전에이 단계에 도달합니다) 목적).
사실 바로 가기로서 상태 코드는 NODATA다음과 같습니다. 이것은 실제 상태 코드가 아닙니다. NOERROR+ 빈 ANSWER 섹션을 의미합니다. 즉,이 특정 레코드 유형에 대한 데이터는 없지만 다른 것에는 해당 될 수 있습니다.
다음 "위"레이블을 사용하여 쿼리하면 동일한 결과에 대해 동일한 실험을 반복 할 수 있습니다 (이름) 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됩니다. zonefile에서 특별히 생성 할 필요는 없습니다 (다른 이유로 필요하지 않은 경우), 권한이있는 네임 서버는이 빈 비 터미널 (및 모든 leaf name을 보면 다른 레이블이있는 경우 다른 "중간" 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은와 같은 DNS 레코드를 요구
whatever._domainkey.example.com하지만 분명히 _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 단계로 이동할 수 있습니다.
우리는 지금 이것을 가지고 있습니다 :
- 영역에서 레이블별로 레이블을 일치시키기 시작하십시오. [..]
에이. QNAME 전체가 일치하면 노드를 찾았습니다. [..]
비. 일치하는 내용이 권위있는 데이터에서 제외 될 경우 추천이 있습니다. 이는 영역 하단에서 NS RR 표시 컷이있는 노드가 발생할 때 발생합니다. [..]
기음. 일부 레이블에서 일치하는 것이 불가능한 경우 (즉, 해당 레이블이 존재하지 않는 경우) "*"레이블이 있는지 확인하십시오. [..]
존 파일에는 위임이 없기 때문에 (예 : 다른 네임 서버에 대한 참조가 없으며, 케이스 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는 zonefile에 표시되지 않는합니다. 여기 사본이 비어 있습니다. 이제 6 단계에서 마칩니다.
로컬 데이터 만 사용하여 쿼리의 추가 섹션에 유용 할 수있는 다른 RR을 추가하십시오. 출구.
여기서 우리와 관련이 없으므로 성공으로 끝납니다.
이것은 관찰 된 동작을 정확하게 설명합니다 : 이러한 쿼리는 반환 NOERROR하지만 데이터는 없습니다.
이제, 당신은 스스로에게 물을 수도 있습니다 : "그러나 만약 내가 another.example.com위와 같은 알고리즘으로 어떤 이름을 사용한다면 같은 응답을받을 것 NXDOMAIN입니다."
왜?
설명 된대로 전체 알고리즘은 다음과 같이 시작합니다.
다음 알고리즘은 RR이 여러 개의 트리 구조로 구성되어 있다고 가정합니다 (각 영역마다 하나씩, 다른 하나는 캐시 용으로).
이것은 위의 존파일이이 트리로 변환되었음을 의미합니다 :
+-----+
| 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, aka NXDOMAIN.
위의 모든 것은 과거에 혼란을 초래했습니다. 이것은 일부 RFC에서 수집됩니다. 예를 들어이 예상치 못한 장소 (그래서 꿰 뚫을 수있는 DNS 사양의 기쁨) 정의 와일드 카드를 참조하십시오 4592 RFC는 "도메인 이름 시스템에서 와일드 카드의 역할" 의 시작 부분과 특히 자사의 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을 가질 수 있으며, 실제로
는 도메인 트리의 잎이다. 그러나 그 정의는
그 하위 www.example을 의미 할 수 있습니다 . 데이터는 없지만 존재합니다. 또한 루트부터 루트까지 가능한 모든 도메인이 존재합니다.
RFC 1034는 또한 4.3.1 절에서 "이름이 존재하지 않음을 나타내는 신뢰할 수있는 이름 오류"를 정의하므로, 이것은 원래 정의의 의도가 아니기 때문에 다음 섹션에서 업데이트 된 정의의 필요성을 정당화합니다.
그리고 다음 섹션의 정의는 처음에 인용 한 단락입니다.
(에 RFC 8020 점에 유의 NXDOMAIN정말 의미 NXDOMAIN회신 경우이며, NXDOMAIN대한 intermediate.example.com다음, leaf.intermediate.example.com다양한 DNS 제공 업체는이 해석하고 만들어 혼란을 따르지 않았거나 그들은 단지 버그했다, 예를 들어이 하나보기 때문에 존재할 수 없다)이 부분에 위임했다 하나의 오픈 소스 권위있는 네임 서버 코드로 2013 년에 수정되었습니다 : https://github.com/PowerDNS/pdns/issues/127
그런 다음 사람들은 특정 카운터 조치 만 취해야했습니다. 일부 노드에 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에 대해 잘 알고 있어야합니다.
다음 두 메시지는 한 공급자가 비어있는 비 터미널에 대해이 규칙을 올바르게 적용 할 수 있어야하는 문제의 예를 제공하며 문제에 대한 일부 관점과 그 이유를 알려줍니다.