네임 서버 간접 지정에 공식적인 제한이 있습니까?

도메인과 이름 서버가 TLD를 공유하지 않는 경우 일반적으로 접착제 레코드를 사용할 수 없으며 동일한 2 차 도메인을 공유하지 않는 경우 기술적으로 필요 하지 않으므로 도메인을 해결하는 추가 단계가 발생할 수 있습니다. 확인자는 먼저 도메인의 주소를 찾기 전에 이름 서버의 주소를 찾아야합니다. 그러나 이론적으로 그 두 단계보다 더 많은 단계를 추가 할 수 있습니다.

여기서 문제는 체인이 얼마나 오래 허용 됩니까?

만약 xyz.com사용 네임 ns1.xyz.info,
및 xyz.info네임 서버 용도 ns1.xyz.co,
그리고 xyz.co사용하는 네임 서버 ns1.xyz.cc,
및 xyz.cc용도 네임 ns1.xyz.co.uk, ... 등등

... 리졸버가 원래 원하는 이름을 확인하기 전에 풀어야 할 매우 긴 체인으로 끝날 수 있습니다.

아마도 실질적인 한계가있을 것입니다. BIND는 너무 많은 링크를 순회해야하는데, 그렇지 않으면 서비스 거부의 가능성이 있습니다. 그러나 공식적인 제한이 있습니까? 리졸버가 공식적으로 진행할 필요가없는 몇 가지 단계가 있습니까?

if xyz.com uses nameserver ns1.xyz.info,

이 경우 로컬 리졸버는 먼저 .comxyz.com 도메인의 이름 서버를 찾을 위치를 서버에 요청합니다 (예 : a.gtld-servers.net). .com 도메인 서버는 일반적으로 xyz.com 도메인에 대한 이름 서버의 IP 주소에 대한 글루 레코드를 제공합니다.

예 :

$ dig  gmail.com @a.gtld-servers.net 

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> gmail.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46893
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available

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

;; AUTHORITY SECTION:
gmail.com.      172800  IN  NS  ns2.google.com.
gmail.com.      172800  IN  NS  ns1.google.com.
gmail.com.      172800  IN  NS  ns3.google.com.
gmail.com.      172800  IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     172800  IN  A   216.239.34.10
ns1.google.com.     172800  IN  A   216.239.32.10
ns3.google.com.     172800  IN  A   216.239.36.10
ns4.google.com.     172800  IN  A   216.239.38.10

;; Query time: 375 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Thu Jul 10 01:10:57 EST 2014
;; MSG SIZE  rcvd: 181

내 경험상 "도메인과 해당 네임 서버가 TLD를 공유하지 않는 경우 일반적으로 접착제 레코드를 사용할 수 없습니다"라는 말은 사실이 아닙니다. 그러나 도메인 등록 기관에서 제공 한 데이터에 따라 다르며 정책은 다양합니다. 일부는 IP를 지정해야합니다. 일부는 도메인 소유자에게 맡깁니다. 나는 호주에서 그들을 지원하지 않는 것을 기억합니다. 해당 국가의 도메인을 다루는 등록 기관의 수가 적 으면 도메인 공간의 해당 부분에 해당하는 것일 수도 있지만 전체적으로는 전체적으로 비정형입니다.

도메인 소유자는 Glue 레코드를 제공하는 것이 좋습니다. 그러나 때때로 IP를 쓰러 뜨리지 않고 이름으로 DNS 서버를 지정하는 기능은 유연성을 제공하는 것으로 보이며, 많은 도메인 소유자는 이것이 생성하는 성능 문제를 이해하지 못합니다.

DNS보고 도구를 제공하는 경우 실제로 잘못된 구성에 대한 절대적인 제한입니까? 누락 된 접착제 레코드 문제 중 하나라도 표시되는 경우 누락 된 접착제 레코드를 경고로보고하는 것이 더 중요합니다. 당신이 제공 한 것과 같은 최소한 몇 가지 간접 지시를 추적하고 (그리고 누락 된 아교 기록을보고하고 싶을 수도 있지만)이를 얼마나 멀리 따라야하는지에 대한 제한이 있어야합니다. 도메인에 글루 레코드를 추가하거나 도메인의 DNS 공급자를보다 유능한 도메인으로 전환하는 데 관심이 있기 때문에 DNS보고 도구가 처음 3 개 정도를 경고 한 경우 매우 기쁩니다.

BIND가 이름 서버의 위치에 대해 수집 한 정보를 캐시하므로 BIND에 대한 제안 된 DOS 접근 방식이 의심 스럽다. 공격자는 풀없이 많은 도메인을 설정 한 다음 이에 대해 많은 쿼리를해야합니다. 사용 후 등록 기관에 의해 취소 될 수있는 도메인 설정 비용으로 인해 공격자에게 호소력이 생길 수 있습니다.