조금 세분화합시다.
TLD 영역의 NS 레코드 (예 : example.com NS ...에서 com)는 위임 레코드입니다.
TLD 영역의 A 및 AAAA 레코드 (예 : ns1.example.com A ...에서 com)는 글루 레코드입니다.
(인 영역 자체에 NS 레코드 example.com NS ...이어 example.com)이다 권한 레코드.
영역 자체 ( ns1.example.com A ...in example.com) 의 A 및 AAAA 레코드는 단순하고 간단한 주소 레코드입니다.
A (재귀) 해결이 영역의 데이터없이 캐시와 (이름 확인 과정을 부트 스트랩하는 데 사용됩니다)에만 루트 영역 캐시로 시작하면 첫째로 이동합니다 .다음 com.. com서버는 응답합니다 권한 섹션 응답 기본적으로 말한다 "나는 모른다, 그러나 알고 있나요 누군가 이쪽을 봐주세요"를위한 서버와 동일 .대해 할 일을 com. 이 쿼리 응답은 신뢰할 수 없으며 채워진 답변 섹션이 포함되어 있지 않습니다. 또한 소위 추가를 포함 할 수 있습니다섹션은 특정 서버가 아는 호스트 이름 (접착 레코드 또는 재귀 해결의 경우 이전에 캐시 된 데이터)에 대한 주소 맵핑을 제공합니다. 확인자는이 위임 응답을 받고 필요한 경우 NS 레코드의 호스트 이름을 확인한 후 권한이 위임 된 DNS 서버를 쿼리합니다. 심층 위임 계층 구조가있는 경우이 프로세스가 여러 번 반복 될 수 있지만 결국 "authoritative answer"플래그가 설정된 쿼리 응답 이 발생합니다 .
리졸버는 (일반적으로, 희망적으로) 해결 될 호스트 이름을 하나씩 분해하려고 시도하지는 않지만 단순히 "알고있는"가장 좋은 서버로 전체를 전송한다는 점에 유의해야합니다. 인터넷의 평균 권한 부여 이름 서버는 대부분의 유효한 DNS 이름에 대해 권한이 없기 때문에 응답은 다른 DNS 서버를 가리키는 권한이없는 위임 응답이됩니다.
이제 영역에 대해 권한을 부여하기 위해 서버를 위임 또는 권한 레코드에서 이름을 지정할 필요가 없습니다. 예를 들어 개인 마스터 서버의 경우를 고려하십시오. 이 경우 영역의 슬레이브 DNS 서버 관리자 만 알고있는 권한있는 DNS 서버가 있습니다. 일부 메커니즘을 통해 해당 영역에 대한 완전하고 정확한 지식이있는 경우 DNS 서버는 영역에 대한 권한을 갖습니다. 예를 들어, 일반적으로 신뢰할 수있는 DNS 서버는 구성된 마스터 서버에 SOA 레코드에서 만료 시간으로 정의 된 시간 내에 도달 할 수없는 경우 신뢰할 수없는 상태가 될 수 있습니다.
정식 답변 만 적절한 쿼리 응답으로 간주해야합니다. 다른 모든 것은 위임 또는 일종의 오류입니다. 권한이없는 서버에 대한 위임을 "라임"위임이라고하며, 해결 프로그램이 한 단계를 역 추적하고 이름이 지정된 다른 DNS 서버를 시도해야 함을 의미합니다. 위임 할 수있는 신뢰할 수있는 이름 서버가 없으면 이름 확인에 실패합니다 (그렇지 않으면 정상보다 느립니다).
신뢰할 수없는 데이터는 캐시하지 않아야 하므로 이는 모두 중요 합니다 . 비인증 서버에 전체 그림이 없기 때문에 어떻게 될 수 있습니까? 따라서 권위있는 서버는 자체적으로 "누가 권위 있고 누가 무엇을해야 하는가?"라는 질문에 대답 할 수 있어야합니다. 이것이 존 내 NS 레코드가 제공하는 정보입니다.
실제로 단일 영역 내부의 여러 호스트 이름 레이블을 중심으로 (특히 동적 IP 범위가 큰 경우 역방향 DNS 영역에서 상당히 일반적 임) 또는 이름 서버 목록이 서로 다를 때 실제로 큰 차이를 만들 수있는 여러 가지 경우가 있습니다. 상위 영역과 해당 영역 (오류 일 가능성이 있지만 의도적으로 수행 할 수도 있음)
dig그리고 +norec(재귀를 요청하지 않음) 및 @서버 지정자 기능을 사용하여 어떻게 작동하는지 좀 더 자세히 볼 수 있습니다 . 다음은 실제 확인 DNS 서버의 작동 방식을 보여줍니다. unix.stackexchange.com예를 들어 a.root-servers.net다음과 같이 시작 하기위한 A 레코드를 조회하십시오 .
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
flags섹션 수와 섹션 수를 자세히 살펴보십시오 . qrQuery Response이며 aa정식 답변입니다. com서버 에만 위임됩니다 . 해당 위임을 수동으로 따릅니다 (실제로 재귀 해결자는 제공된 경우 추가 섹션의 IP 주소를 사용하거나 위임 응답에 IP가 제공되지 않은 경우 명명 된 이름 서버 중 하나의 별도 이름 확인을 시작하지만, 우리는 해당 부분을 건너 뛰고 예제의 간결성을 위해 운영 체제의 일반 리졸버로 넘어갑니다.
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
이제 당신은 stackexchange.com(다른 사람들에게) 위임 된 것을 보았지만 ns1.serverfault.com여전히 권위있는 대답을 얻지 못했습니다. 다시 대표단을 따르십시오.
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
빙고! 우리는 aa플래그가 설정되어 있기 때문에 답을 얻었으며, 원하는대로 IP 주소를 포함합니다. 따로, 적어도이 글을 쓰는 시점에 위임 대상 및 등록 된 권한 이름 서버 목록이 다르므로 두 이름이 동일 할 필요는 없습니다. 위에서 예시 한 것은 기본적으로 모든 리졸버가 수행 한 작업입니다. 실제 리졸버도 경로를 따라 응답을 캐시하므로 매번 루트 서버에 충돌하지 않아도됩니다.
위의 예에서 볼 수 있듯이 위임 및 글루 레코드는 영역 자체의 권한 및 주소 레코드와 다른 용도로 사용됩니다.
캐싱 및 해결 네임 서버는 일반적으로 캐시 포이즈 닝으로부터 보호하기 위해 리턴 된 데이터에 대해 일부 정상 성 검사를 수행합니다. 예를 들어,com 부모 영역에서 이미 위임 된 대상 이 아닌 다른 소스에서 권한있는 서버를 명명하는 응답을 캐시하지 않을 수 있습니다 com. 세부 사항은 서버에 따라 다르지만 인터넷상의 임의 이름 서버가 공식적으로 "관할 구역"에 해당되지 않는 것에 대한 위임 레코드를 무시하도록 허용하는 헛간 문을 열지 않으면 서 가능한 한 많이 캐시하는 것이 목적입니다.