웹사이트 검색

DNS 서버 유형 비교: 올바른 DNS 구성을 선택하는 방법

소개

DNS 또는 도메인 이름 시스템은 인터넷에서 시스템이 서로 연결되어 통신하는 데 필수적인 부분입니다. DNS가 없으면 컴퓨터와 이를 사용하는 사람들은 IP 주소로 알려진 숫자 주소만 사용하여 연결해야 합니다.

간단한 작업을 위해 많은 수의 복소수를 기억해야 하는 명백한 문제 외에도 IP 주소를 통한 통신은 몇 가지 추가적인 문제를 야기합니다. 웹 사이트를 다른 호스팅 공급자로 이동하거나 서버를 다른 위치로 이동하려면 모든 클라이언트에게 새 위치를 알려야 합니다.

주소 대신 이름을 사용할 수 있도록 하는 시스템을 함께 구성하는 컴퓨터인 DNS 서버는 다양한 기능을 서버로 제공할 수 있으며, 각 기능은 이름으로 서버에 액세스하는 기능에 기여할 수 있습니다.

이전 가이드에서 우리는 도메인 이름 시스템의 몇 가지 기본 용어와 개념에 대해 논의했습니다. 해당 문서에서 다루는 개념에 어느 정도 익숙하다고 가정하겠습니다. 이 가이드에서는 다양한 유형의 DNS 서버 설정과 각각의 이점, 사용 사례 및 속성에 대해 설명합니다.

DNS 쿼리의 경로

클라이언트 프로그램이 도메인 이름으로 서버에 액세스하려면 도메인 이름을 통신에 사용할 수 있는 실제 라우팅 가능한 주소로 변환하는 방법을 찾아야 합니다. 서버에 정보를 가져오거나 보내려면 이 정보를 알아야 합니다.

대부분의 웹 브라우저를 포함한 일부 애플리케이션은 최근 쿼리의 내부 캐시를 유지합니다. 문제의 도메인의 IP 주소를 찾기 위해 응용 프로그램이 이 기능이 있는지 확인하는 첫 번째 위치입니다. 여기에서 질문에 대한 답을 찾지 못한 경우 시스템 확인자에게 도메인 이름의 주소를 확인하도록 요청합니다.

일반적으로 확인자는 DNS 쿼리에서 클라이언트측 참여자 역할을 하는 모든 구성 요소입니다. 시스템 해석기는 운영 체제가 DNS 쿼리에 대한 응답을 찾는 데 사용하는 해석 라이브러리입니다. 일반적으로 시스템 리졸버는 시스템에서 몇 가지 정적 파일(예: /etc/hosts 파일)을 검색하고 요청을 다른 파일로 전달하는 것 외에는 그다지 복잡하지 않기 때문에 스텁 리졸버로 간주됩니다. 리졸버

따라서 일반적으로 쿼리는 클라이언트 애플리케이션에서 시스템 확인자로 이동한 다음 주소가 있는 DNS 서버로 전달됩니다. 이 DNS 서버를 재귀 DNS 서버라고 합니다. 재귀 서버는 질문에 대한 답을 찾을 때까지 다른 DNS 서버를 쿼리하도록 구성된 DNS 서버입니다. 응답 또는 오류 메시지를 클라이언트(이 경우 시스템 확인자가 클라이언트 응용 프로그램에 전달함)에 반환합니다.

재귀 서버는 일반적으로 캐시도 유지합니다. 쿼리에 대한 답변이 이미 있는지 확인하기 위해 먼저 이 캐시를 확인합니다. 그렇지 않은 경우 상위 수준 도메인 구성 요소를 제어하는 서버에 대한 주소가 있는지 확인합니다. 따라서 요청이 www.example.com에 대한 것이고 캐시에서 해당 호스트 주소를 찾을 수 없는 경우 example.com code에 대한 이름 서버의 주소가 있는지 확인합니다. 및 필요한 경우 com. 그런 다음 더 많은 정보를 쿼리하기 위해 찾을 수 있는 가장 구체적인 도메인 구성 요소의 이름 서버에 쿼리를 보냅니다.

이러한 도메인 구성 요소에 대한 주소를 찾지 못하면 루트 이름 서버를 쿼리하여 계층 구조의 최상위에서 시작해야 합니다. 루트 서버는 .com, .net, .org 에 대한 영역을 제어하는 모든 TLD(최상위 도메인) 이름 서버의 주소를 알고 있습니다. 등. 루트 서버에 www.example.com의 주소를 알고 있는지 묻습니다. 루트 서버는 재귀 서버를 .com TLD의 이름 서버로 참조합니다.

그런 다음 재귀 서버는 도메인 구성 요소에 대한 책임이 위임된 각 연속 이름 서버에 대한 참조 추적을 따라 전체 응답이 있는 특정 이름 서버에 집중할 수 있습니다. 이후 쿼리를 위해 이 답변을 캐시에 넣은 다음 클라이언트에 반환합니다.

이 예에서 알 수 있듯이 다양한 종류의 서버가 있으며 각각 다른 역할을 합니다. 다양한 유형의 DNS 서버에 대한 세부 사항을 살펴보겠습니다.

기능적 차이

DNS 서버 간의 차이점 중 일부는 순전히 기능적입니다. DNS 구현과 관련된 대부분의 서버는 특정 기능에 특화되어 있습니다. 선택하는 DNS 서버 유형은 사용자의 필요와 해결하려는 문제 유형에 따라 크게 달라집니다.

권한 있는 전용 DNS 서버

권한 있는 전용 DNS 서버는 자신이 담당하는 영역에 대한 쿼리 응답에만 관심이 있는 서버입니다. 외부 영역에 대한 쿼리를 해결하는 데 도움이 되지 않기 때문에 일반적으로 매우 빠르고 많은 요청을 효율적으로 처리할 수 있습니다.

신뢰할 수 있는 전용 서버에는 다음과 같은 속성이 있습니다.

  • 제어하는 영역에 대한 쿼리에 매우 빠르게 응답합니다. 권한만 있는 서버는 자신이 담당하는 도메인에 대한 모든 정보 또는 다른 이름 서버에 위임된 도메인 내의 영역에 대한 참조 정보를 가집니다.
  • 재귀 쿼리에 응답하지 않습니다. 신뢰할 수 있는 전용 서버의 정의는 재귀 요청을 처리하지 않는 서버입니다. 이렇게 하면 DNS 시스템에서 클라이언트가 아닌 서버만 됩니다. 권한 있는 서버에 도달하는 모든 요청은 일반적으로 해당 서버에 대한 참조를 수신한 확인자로부터 옵니다. 즉, 권한 있는 서버만 완전한 응답을 가지거나 새 참조를 이름 서버에 전달할 수 있음을 의미합니다. 책임을 위임받았습니다.
  • 쿼리 결과를 캐시하지 않습니다. 권한만 있는 서버는 요청을 해결하기 위해 다른 서버에 정보를 쿼리하지 않으므로 결과를 캐시할 기회가 없습니다. 알고 있는 모든 정보는 이미 시스템에 있습니다.

캐싱 DNS 서버

캐싱 DNS 서버는 클라이언트의 재귀 요청을 처리하는 서버입니다. 운영 체제의 스텁 확인자가 연결하는 거의 모든 DNS 서버는 캐싱 DNS 서버가 됩니다.

캐싱 서버는 클라이언트의 재귀 요청에 응답할 수 있는 이점이 있습니다. 권한 있는 전용 서버는 특정 영역 정보를 제공하는 데 이상적일 수 있지만 캐싱 DNS 서버는 클라이언트의 관점에서 더 광범위하게 유용합니다. 그것들은 세계의 DNS 시스템이 다소 멍청한 클라이언트 인터페이스에 액세스할 수 있도록 합니다.

재귀 요청을 수신할 때마다 다른 DNS 서버에 여러 반복 요청을 발행하는 성능 저하를 피하기 위해 서버는 결과를 캐시합니다. 이를 통해 최근 요청을 매우 빠르게 처리하면서 광범위한 DNS 정보(전 세계에서 공개적으로 액세스할 수 있는 DNS)에 액세스할 수 있습니다.

캐싱 DNS 서버에는 다음 속성이 있습니다.

  • 공용 DNS 데이터의 전체 범위에 대한 액세스. 전역 위임 트리에 연결된 공개적으로 액세스 가능한 DNS 서버에서 제공하는 모든 영역 데이터는 캐싱 DNS 서버에서 도달할 수 있습니다. 루트 DNS 서버에 대해 알고 있으며 데이터를 수신할 때 추천을 지능적으로 따를 수 있습니다.
  • 멍청한 클라이언트에게 데이터를 떠먹일 수 있는 능력. 거의 모든 최신 운영 체제는 스텁 확인자를 사용하여 DNS 확인을 전용 재귀 서버로 오프로드합니다. 이러한 해결 라이브러리는 단순히 재귀 요청을 발행하고 완전한 답변을 돌려받기를 기대합니다. 캐싱 DNS 서버에는 이러한 클라이언트에 서비스를 제공할 수 있는 정확한 기능이 있습니다. 재귀 쿼리를 수락함으로써 이러한 서버는 응답 또는 DNS 오류 메시지를 반환할 것을 약속합니다.
  • 최근에 요청한 데이터의 캐시를 유지합니다. 클라이언트 요청에 대해 다른 DNS 서버에서 결과를 수집할 때 결과를 캐싱함으로써 캐싱 DNS 서버는 최근 DNS 데이터에 대한 캐시를 구축합니다. 서버를 사용하는 클라이언트 수, 캐시 크기, TTL 데이터가 DNS 레코드 자체에 있는 기간에 따라 대부분의 경우 DNS 확인 속도를 크게 높일 수 있습니다.

포워딩 DNS 서버

클라이언트 컴퓨터용 캐시를 개발하는 또 다른 방법은 전달 DNS 서버를 사용하는 것입니다. 이 접근 방식은 캐싱 DNS 서버와 같은 재귀 기능이 있는 다른 DNS 서버에 모든 요청을 단순히 전달하는 전달 서버를 구현하여 DNS 확인 체인에 추가 링크를 추가합니다.

이 시스템의 장점은 재귀 작업(추가 네트워크 트래픽이 발생하고 트래픽이 많은 서버에서 상당한 리소스를 차지할 수 있음)을 수행하지 않고도 로컬에서 액세스할 수 있는 캐시의 이점을 제공할 수 있다는 것입니다. 이는 또한 다른 서버로 전달하여 개인 및 공용 트래픽을 분할하는 흥미로운 유연성을 제공할 수 있습니다.

전달 DNS 서버에는 다음과 같은 속성이 있습니다.

  • 재귀 자체를 수행하지 않고 재귀 요청을 처리하는 기능. 전달 DNS 서버의 가장 기본적인 속성은 확인을 위해 다른 에이전트에 요청을 전달한다는 것입니다. 포워딩 서버는 최소한의 리소스를 가질 수 있으며 캐시를 활용하여 여전히 큰 가치를 제공합니다.
  • 가까운 네트워크 위치에 로컬 캐시를 제공합니다. 특히 완전한 재귀 DNS 솔루션을 구축, 유지 및 보호하는 데 자신이 없는 경우 포워딩 서버는 공용 재귀 DNS 서버를 사용할 수 있습니다. 기본 캐싱 위치를 클라이언트 시스템에 매우 가깝게 이동하면서 이러한 서버를 활용할 수 있습니다. 응답 시간을 줄일 수 있습니다.
  • 로컬 도메인 공간을 정의할 때 유연성을 높입니다. 조건부로 다른 서버에 요청을 전달함으로써 포워딩 서버는 외부 요청이 퍼블릭 DNS를 사용하는 동안 내부 요청이 프라이빗 서버에서 처리되도록 할 수 있습니다.

조합 솔루션

위의 솔루션은 매우 특정한 목적을 염두에 두고 구축되었지만 각각의 장점을 결합하도록 DNS 서버를 설정하는 것이 종종 바람직합니다.

DNS 서버는 다른 클라이언트의 반복적이고 신뢰할 수 있는 요청에만 응답하면서 선택한 수의 로컬 클라이언트에 대해 재귀 캐싱 서버 역할을 하도록 구성할 수 있습니다. 이것은 도메인에 대한 글로벌 요청에 응답할 수 있게 해주는 동시에 로컬 클라이언트가 재귀 확인을 위해 서버를 활용할 수 있도록 하기 때문에 일반적인 구성입니다.

특정 DNS 소프트웨어는 하나의 특정 역할을 수행하도록 특별히 설계되었지만 Bind와 같은 애플리케이션은 매우 유연하며 하이브리드 솔루션으로 사용할 수 있습니다. 어떤 경우에는 단일 서버에서 너무 많은 서비스를 제공하려고 시도하면 성능 저하가 발생할 수 있지만 많은 경우, 특히 소규모 인프라의 경우 단일 올인원 솔루션을 유지하는 것이 가장 합리적입니다.

관계적 차이

DNS 서버 구성 간의 가장 분명한 차이점은 아마도 기능적이지만 관계적 차이점도 매우 중요합니다.

기본 및 보조 서버

서비스와 전체 네트워크에 액세스할 수 있도록 하는 DNS의 중요성을 감안할 때 영역에 대해 권한이 있는 대부분의 DNS 서버에는 기본 제공 중복성이 있습니다. 이러한 서버 간의 관계에 대한 다양한 용어가 있지만 일반적으로 서버는 해당 구성에서 기본 또는 보조가 될 수 있습니다.

기본 서버와 보조 서버는 모두 처리하는 영역에 대해 권한이 있습니다. 기본은 보조보다 영역에 대해 더 이상 권한이 없습니다. 기본 서버와 보조 서버 간의 유일한 차이점은 영역 파일을 읽는 위치입니다.

기본 서버는 시스템 디스크의 파일에서 영역 파일을 읽습니다. 이들은 일반적으로 영역 관리자가 원본 영역 파일을 추가, 편집 또는 전송하는 위치입니다.

보조 서버는 영역의 기본 서버 중 하나에서 영역 전송을 통해 권한이 있는 영역을 받습니다. 이러한 영역이 있으면 캐시에 배치합니다. 다시 시작해야 하는 경우 먼저 캐시를 확인하여 내부 영역이 최신인지 확인합니다. 그렇지 않은 경우 기본 서버에서 업데이트된 정보를 요청합니다.

서버는 처리하는 모든 영역에 대해 기본 또는 보조 서버로만 강등되지 않습니다. 기본 또는 보조 상태는 영역별로 지정되므로 서버가 일부 영역에서는 기본이 되고 다른 영역에서는 보조가 될 수 있습니다.

DNS 영역에는 일반적으로 이름 서버가 두 개 이상 있습니다. 인터넷 라우팅 가능 영역을 담당하는 모든 영역에는 반드시 두 개 이상의 이름 서버가 있어야 합니다. 부하를 분산시키고 중복성을 높이기 위해 더 많은 이름 서버가 유지되는 경우가 많습니다.

공용 서버와 개인 서버

종종 조직은 외부 및 내부적으로 DNS를 사용합니다. 그러나 이 두 영역에서 사용할 수 있어야 하는 정보는 종종 크게 다릅니다.

조직은 처리하는 도메인 및 영역에 대한 퍼블릭 DNS 쿼리를 처리하기 위해 외부에서 사용 가능한 신뢰할 수 있는 전용 DNS 서버를 유지 관리할 수 있습니다. 내부 사용자의 경우 조직은 공용 DNS가 제공하는 신뢰할 수 있는 정보와 내부 호스트 및 서비스에 대한 추가 정보가 포함된 별도의 DNS 서버를 사용할 수 있습니다. 내부 클라이언트를 위한 재귀 및 캐싱과 같은 추가 기능을 제공할 수도 있습니다.

위의 "조합\ 서버에서 단일 서버가 이러한 모든 작업을 처리하는 기능을 언급했지만 워크로드를 분할하면 확실한 이점이 있습니다. 보안의 관점에서 볼 때 특히 중요한 것은 공용 서버에 사설 서버의 레코드가 없다는 것입니다. 이는 공용 영역 파일에 NS 레코드가 있는 사설 이름 서버를 나열하지 않음을 의미합니다.

명심해야 할 몇 가지 추가 고려 사항이 있습니다. 공용 서버와 개인 서버가 기존의 1차-2차 관계에서 공통으로 가지고 있는 영역 데이터를 공유하는 것이 더 쉬울 수 있지만 이렇게 하면 개인 인프라에 대한 정보가 외부로 유출될 수 있습니다.

개인 서버를 영역 파일 자체(본질적으로 공개 검색 가능한 엔터티) 외부에 두는 것 외에도 일반적으로 공용 서버의 구성 파일에서 개인 서버에 대한 참조를 제거하는 것이 좋습니다. 즉, 공용 서버가 손상되더라도 내부 이름 서버가 갑자기 노출되지 않도록 전송, 알림 및 기본 구성 세부 정보를 제거해야 합니다.

이는 각각에 대해 별도의 영역 파일을 유지 관리하는 것을 의미하며 이는 추가 작업이 될 수 있습니다. 그러나 이는 절대적인 분리와 보안을 위해 필요할 수 있습니다.

결론

이 단계에서 DNS 구성을 선택하는 데 상당한 유연성이 있음을 알고 계실 것입니다.

귀하의 선택은 주로 조직의 요구 사항과 주요 우선순위가 선택한 클라이언트(캐싱 또는 전달)에 대해 더 빠른 DNS 확인을 제공하는 것인지 아니면 대규모 인터넷에 도메인 및 영역을 제공하는 것인지(권한 있는 서버)에 따라 달라집니다. 조합 접근 방식이 일반적이며 결국 해결 프로세스의 양쪽 측면을 모두 고려해야 합니다.

다음 가이드에서는 이러한 구성 중 일부를 시작하는 방법을 시연합니다. 권한 있는 전용 DNS 서버 한 쌍을 설정하는 것으로 시작하겠습니다.