☰

BIND-DNS 전달자를 구성할 수 있는 위치

tag-icon • tag-icon dns bind forwarding
BIND-DNS 전달자를 구성할 수 있는 위치

BIND의 구성을 조사하고 있지만 권한 있는 서버가 아닌 일부 도메인을 요청하기 위해 다음 네임서버를 어떻게 아는지 알 수 없습니다.

예를 들어 기본 도메인은 "workgroup.lan"
조회 입니다.dig www.google.com

답변

;;질문 섹션:
;www.google.com. 안에

;;답변 부분:

[...]

;;신뢰할 수 있는 부분:
google.com. NS ns1.google.com의 87465.

[...]

;;쿼리 시간: 4밀리초
;;서버: 127.0.0.1#53(127.0.0.1)
;;시간: 2012년 8월 28일 화요일 15:56:08
;;MSG 크기 rcvd: 220

그런데 누가/무엇이 그에게 다른 이름 서버에 물어보라고 말했습니까? 아니면 이것이 기본 동작입니까?

루트 네임서버 IP가 포함된 "."(루트) 영역을 담당하는 "root.hint" 파일과 관련이 있을 수 있습니까?

답변1

DNS 서버 구성을 살펴봐야 하지만 전달자 설정이나 그와 유사한 것이 없다고 가정하면 실제로 정확합니다. 루트 힌트 파일입니다.

DNS는 트리로 구성됩니다(일종: 중복성을 위해 노드가 복제됩니다. 예를 들어 루트 노드가 여러 개 있습니다). 루트 힌트 파일은 루트 이름 서버 중 하나를 찾을 수 있는 위치를 서버에 알려줍니다(일단 발견되면 실제로 발견된 루트 이름 서버에서 루트 이름 서버의 현재 목록을 가져옵니다).

그런 다음 루트 이름 서버 중 하나에서 com 영역에 대해 권한이 있는 이름 서버 목록을 조회합니다. 그 중 하나에서 google.com 영역에 대한 권한 있는 이름 서버 목록을 찾습니다. 마지막으로 그 중 하나에서 www.google.com에 대한 주소(A) 레코드를 가져옵니다. [실제로 www.google.com은 CNAME이지만 동일한 영역에 있으며 Google 이름 서버는 확실히 두 레코드를 모두 반환합니다.]

이 프로세스는 분명히 시간이 많이 걸리므로 많은 캐싱을 사용합니다. 아마도 www.google.com의 주소를 이미 알고 있고 캐시에서 해당 주소를 반환할 가능성이 큽니다. 그렇지 않다면 아마도 ns1.google.com에 문의하는 방법을 이미 알고 있거나, 실패할 경우 com의 하위 도메인에 문의할 위치를 거의 확실히 알고 있을 것입니다.

이 dnstracer프로그램을 사용하여 다음을 볼 수 있습니다.

anthony@Zia:~$ dnstracer -4 -o -s . www.google.com
Tracing to www.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ e.gtld-servers.net [com] (192.12.94.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer [received type is cname] 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer [received type is cname] 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer [received type is cname] 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer [received type is cname] 
⋮

DNS에 대해, 특히 BIND 사용법을 더 알고 싶다면,DNS 및 바인딩, 현재 5판이 나온 이 책은 좋은 책입니다. O'Reilly에서 직접 전자책을 구할 수도 있습니다.

관련 정보