재귀 DNS 조회에서 실제로 누가“재귀”합니까?

반복 및 재귀 DNS 조회의 차이점을 이해하려고합니다. 기본적으로, 반복적 인 것은 제품을 찾는 백화점에 전화하는 것과 같다고 생각합니다. 제품이 없을 때는 전화를 걸 수있는 다른 지점 중 하나의 번호를 제공 한 다음 다른 지점에 직접 전화를 겁니다. 백화점을 호출 같고, 그들은 당신이 계신이 없을 때, 재귀, 대 그들이 제품을 찾는 대신에 다른 분기를 호출합니다. DNS에 관해서는 이것에 대해 상충되는 견해를 얻고 있습니다. 재귀를 생각할 때 다음과 같은 것을 생각합니다. 대체 텍스트

그러나 웹에서 기사를 읽고 DNS 재귀에 대한 Google 이미지 검색을 수행하는 동안 다음과 같은 예가 훨씬 더 많습니다. 대체 텍스트

나에게이 두 번째 예는 재귀보다 반복적 인 것으로 보인다. 왜냐하면 각각의 "다른 DNS 서버"는 "선호하는 DNS 서버"에게 선호하는 대신 찾아 보지 않고 다음 머신의 주소를 알려주기 때문이다. DNS 서버. 내가 볼 수있는 유일한 재귀 요소는 기본 설정 DNS 서버가 DNS 클라이언트 대신 조회를 수행한다는 것입니다. 그러나 여기서부터는 반복적으로 보입니다.

따라서 제 질문은 "재귀"DNS 조회가 클라이언트를 대신하여 선호하는 DNS 서버가 무언가를 수행한다는 의미에서 재귀를 의미하지만 실제로 여기서부터 반복적입니까? Google 이미지 검색 에서 볼 수있는 결과의 대부분은 이 질문을 믿게 만드는이 글의 첫 번째 이미지가 잘못되었다고 생각합니다.

domain-name-system

— 브라이스 토마스
소스

Ask Mr DNS 팟 캐스트, 재미 있고 유익한 정보 및 1989 년부터 DNS를 관리해 왔으며 모든 O'Reily DNS 서적 등을 작성 또는 공동 작성했습니다. ask-mrdns.com 알고 싶었던 것보다 더 많은 것을 배우십시오.

— Ronald Pottol

답변:

마지막 단락이 맞습니다.

DNS 요청 헤더 (RFC 1035 참조)에서 클라이언트가 보낸 "Recursion Desired"(RD) 플래그는 서버에게 "이 질문에 대한 완전한 답을 알려주십시오"라고 묻습니다.

해당 서버는 반복적 으로 이름 서버 체인에 정답을 요구합니다. 이러한 쿼리 자체에는 RD 비트 세트가 없어야합니다.

궁극적으로 재귀 서버의 응답에는 "RA (Recursion Available)"플래그가 설정되어 응답이 실제로 완전히 응답되었음을 나타냅니다. 반대로 권한있는 서버는 RA 플래그를 설정하지 않습니다.

IMHO, 용어를 잘못 선택했습니다.

가치가있는 것으로, 당신이 찾은 첫 번째 다이어그램은 근본적으로 잘못되었습니다. 루트 서버는 다른 서버에 대한 쿼리를 수행 하지 않으며 다른 서버에 대한 조회 만 발행합니다.

— 알 니탁
소스

내가 이해하는 한, "재귀 적 조회"는 전적으로 원래 질의 자의 관점에서 온 것입니다. 따라서 DNS 서버에 요청하여 완전히 해결 된 답변을 받으면 "재귀 쿼리"입니다. 서버가 재귀 적이거나 반복적 인 조회를하는 경우, 원래 질의자가 신경 써야 할 것이 아닙니다.

— 질
소스

귀하의 질문에있는 두 다이어그램 중 첫 번째 다이어그램이 잘못되었습니다. 루트 서버는 다른 서버로 쿼리를 보내지 않습니다. 루트 서버가 실제로 해당 다이어그램에 표시된 것처럼 쿼리를 전달한 경우 DNS 시스템은 실제보다 DoS 공격에 훨씬 더 취약합니다.

두 번째 다이어그램은 대부분 정확하지만 너무 단순하여 조회의 재귀 특성을 보여줍니다. 다이어그램은 여전히 상세하지만 재귀가 발생하는 곳을 지적 할 수 있습니다.

12표시된 번호 옆의 DNS 서버 Preferred DNS server는 재귀가 발생하는 위치입니다. 기본 설정 DNS 서버 라는 용어 는 표준 용어가 아닙니다. 이 서버는 일반적으로 캐싱 DNS 되풀이 또는 그 약어라고합니다.

네트워크 트래픽을 볼 때 실제로 반복적으로 보입니다. 재귀는 전적으로 DNS 재귀 내부에 있습니다. DNS recursor의 구현을 살펴보면 요청이 처리되는 방식에서 일부 재귀 구조를 찾을 수 있습니다.

구현에서 요청 당 스레드를 사용하고 재귀 함수 호출을 사용하여 조회를 구현하면 재귀를 쉽게 파악할 수 있습니다. 그러나보다 효율적인 설계는 요청 당 스레드를 사용하지 않으며 대신 DNS 리 커서가 사용하는 데이터 구조 내에서 재귀를 찾을 수 있습니다.

재귀가 필요한 이유는 신뢰할 수있는 DNS 서버 간의 참조가 구현되는 방식 때문입니다. 이것은 예제와 함께 가장 잘 설명됩니다. 다이어그램에는의 권한있는 DNS 서버를 microsoft.com가리키는 권한있는 DNS 서버가 표시 example.microsoft.com됩니다. 이것은 NS호스트 이름을 가리키는 레코드를 사용하여 수행됩니다 . 그래서 예에 대한 권한이있는 서버 microsoft.com는 DNS recursor 말할 수 ms.example.net에 대한 권한을 example.microsoft.com.

이 시점에서 DNS recursor는 해결 ms.example.net을 진행하기 전에 해결 해야합니다 example.microsoft.com.

하나의 호스트 이름을 확인하려면 먼저 다른 호스트 이름을 확인해야합니다. 그것은 재귀입니다. 이로 인해 무한 재귀가 발생하지 않도록 DNS에는 NS특정 경우 레코드 와 함께 전송되는 글루 레코드가 있습니다 .

— 카스퍼 드
소스

여기에는 많은 오류가 있습니다. "재귀"라는 용어의 사용은 "재귀 함수 호출"의 사용 여부와는 아무 관련이 없습니다. Vatine의 답변이 더 가깝습니다. 재귀는 클라이언트가 서버에 완전한 해결 된 답변 을 요청할 때 사용되는 (잘못 선택된) 이름입니다 . 소위 "재귀 서버"에서 사용하는 메커니즘을 실제로 반복 이라고 합니다. 또한 "무한한 재귀"를 방지하기 위해 레코드를 붙입니다. 이러한 서버가 위임 된 도메인의 공간 내에있는 경우 네임 서버의 주소를 찾는 방법의 "치킨 앤 에그"문제를 방지 할 수 있습니다.

— Alnitak

@Alnitak DNS 확인은 본질적으로 재귀 적입니다. 실행 스택을 다른 데이터 구조로 바꾸면 모든 재귀 알고리즘을 반복적 인 것으로 바꿀 수 있습니다. 그 가능성은 이미 내 대답에 언급되어 있습니다. 그리고 당신이 언급하는 순환 의존성 문제는 무한 재귀와 다르지 않습니다. 두 사람은 정말 같습니다. 기본 작업이 주기적 종속성을 겪고 있음을 알지 못하고 순진 재귀 알고리즘을 적용하면 결과는 무한 재귀가됩니다.

— kasperd

@Alnitak 재귀 스택을 제거하고 한 번에 일정한 수의 DNS 이름 만 추적하여 반복적으로 DNS 확인을 수행 할 수 없습니다. 다르게 보이는 데이터 구조로 재귀 스택을 나타낼 수 있지만 본질적으로 재귀 적입니다. 재귀 수준을 하나만 유지하는 방식으로 도메인 이름을 구성 할 수 있습니다. 그러나 모든 도메인 이름이 그런 식으로 구성되는 것은 아닙니다.

— kasperd

RFC 1034- ""인용 이 문제를 처리하는 두 가지 일반적인 접근 방식은 "재귀 적"이며, 첫 번째 서버는 다른 서버에서 클라이언트에 대한 쿼리를 수행하고 "반복적"으로 서버가 클라이언트를 다른 서버를 참조합니다. 서버와 클라이언트가 쿼리를 추구 할 수 있습니다 . ""그것은이없는 것도 스택 "또는"데이터 구조 "와 함께 할"을.

— Alnitak

@Alnitak 그 단락은 내 대답과 다른 종류의 재귀를 나타냅니다. 내 대답에 언급 된 재귀는 하나의 특정 DNS 서버 내부에 있습니다 (내 대답에 명확하게 명시되어 있음). 실제로 DNS 재귀를 완전히 반복적 인 방식으로 구현하려고 시도하면 작동하지 않습니다. 연결된 글루가없는 NS 레코드로 회신을 받으면 원래 해상도를 계속하기 전에 해당 NS 레코드가 가리키는 호스트 이름의 IP 주소를 찾아야합니다.

— kasperd