☰

특정 도메인에 대해 사용자 정의 DNS 서버를 사용하도록 시스템을 구성하려면 어떻게 해야 합니까?

tag-icon • tag-icon dns
특정 도메인에 대해 사용자 정의 DNS 서버를 사용하도록 시스템을 구성하려면 어떻게 해야 합니까?

이 hosts파일을 사용하면 전체 DNS 서버 시스템을 재정의하고 특정 DNS 이름을 특정 IP 주소로 확인하도록 시스템을 구성할 수 있습니다. 하지만 이 목적으로 특정 DNS 서버를 사용하고 싶다면 어떻게 해야 할까요?

답변1

이것은 ... 불리운다분할 지평선 DNS 서비스이를 수행하는 방법에는 네 가지가 있습니다. 예를 들어 분할 지평선 unix.stackexchange.com.(물론 그 아래 도메인 이름 트리의 모든 부분)을 구성한다고 가정해 보겠습니다. 이를 수행하는 방법은 로컬에서 실행하도록 선택한 항목에 따라 다릅니다.

  1. 당신은 지역을 운영정방향 프록시 DNS 서버. 이는 로컬 캐싱이 필요하지만 로컬 시스템이 공용 인터넷에서 방화벽으로 보호되어 있거나 이러한 시스템에 대한 쿼리 확인이 LAN의 한 위치에서 중앙에서 쿼리를 실행하는 것에 비해 상대적으로 비용이 많이 드는 일반적인 상황입니다.

    unix.stackexchange.com.다른 서버로 전달하라고 지시합니다 . unix.stackexchange.com.하위 도메인에 대한 쿼리를 해결하는 방법을 알고 있는 두 번째(원격) 프록시 DNS 서버를 설정해야 합니다 . 또한 해당 도메인과 해당 하위 도메인에 대한 실제 대체 데이터를 제공 unix.stackexchange.com.하고 두 번째 프록시 DNS 서버가 인식하고 사용하도록 구성된 비공개 콘텐츠 DNS 서버를 설정해야 합니다 .

    당신은 할 수있다이미 가지고 있다후자의 두 가지는 특히 대규모 조직인 경우 더욱 그렇습니다. 실제로 쿼리 확인 작업을 수행하는 중앙 컴퓨터로 확인 프록시 DNS 서버가 이미 있을 수 있습니다. 다양한 내부 트래픽이 조직 외부로 "유출"되는 것을 방지하기 위해 공개 콘텐츠 DNS 서버를 로컬로 미러링하는 비공개 콘텐츠 DNS 서버가 이미 있을 수 있으며 여기에 데이터를 .추가하기만 하면 됩니다 .unix.stackexchange.com.

    로컬 정방향 프록시 DNS 서버 구성:

    • Bernstein dnscache( FORWARDONLY모드) 과 같은 서버의 경우 servers/unix.stackexchange.com프록시 DNS 서버의 IP 주소 구성 파일(서버의 루트/작업 디렉터리에 있음)을 사용하여 쿼리를 서버에 전달하고 서버를 다시 시작할 수 있습니다.
    • ~을 위한분할된DNS 서버는 Microsoft의 DNS 서버 및 ISC의 BIND와 같습니다.포워딩 지역unix.stackexchange.com.서버를 다시 로드/다시 시작합니다 .

    두 번째(원격) 프록시 DNS 서버는 아래 옵션 #2에 표시된 대로 구성됩니다. 옵션 #2는 머신의 DNS 클라이언트 라이브러리가 지정된 경우에도 적용됩니다(예 /etc/resolv.conf: ).곧장정방향 프록시 DNS 서버를 중개자로 사용하는 대신 (로컬/원격) 프록시 DNS 서버에서 해결합니다.

  2. 당신은 지역을 운영프록시 DNS 서버 확인. 1980년대 도메인 이름 시스템(Domain Name System)이 등장한 이후 Unices 및 Linux와 같은 멀티태스킹 운영 체제는 과거처럼 모든 컴퓨터에서 확인 프록시 DNS 서버를 실행하는 것을 주저하지 않았습니다. 그러나 옵션 #1에서 설명한 것처럼 "로컬"은 단일 컴퓨터의 로컬이 아닌 LAN의 로컬일 수 있습니다.

    unix.stackexchange.com.쿼리 해결은 공용 DNS 데이터베이스에 게시된 것과 다른 DNS 서버에서 시작되어야 한다고 알려줍니다 . unix.stackexchange.com.하위 도메인에 대한 실제 대체 데이터를 제공 하려면 개인 콘텐츠 DNS 서버를 설정해야 합니다 .

    로컬 확인 프록시 DNS 서버를 구성합니다.

    • Bernstein과 같은 서버 dnscache(비 FORWARDONLY모드) 의 경우 servers/unix.stackexchange.com콘텐츠 DNS 서버의 IP 주소 구성 파일(서버의 루트/작업 디렉터리에 있음)을 사용하여 쿼리 확인을 시작하고 서버를 다시 시작할 수 있습니다.
    • ~을 위한분할된DNS 서버는 Microsoft의 DNS 서버 및 ISC의 BIND와 같습니다.스텁 영역unix.stackexchange.com.서버를 다시 로드/다시 시작합니다 .

  3. 공개 콘텐츠 DNS 서버는 쿼리를 보내는 사람을 기반으로 대체 데이터를 제공할 수 있습니다. 드물지만 이 작업을 수행하는 소프트웨어가 있는 경우 구조적으로 설정하기가 가장 쉽습니다.

    프록시 DNS 서버를 조작할 필요가 전혀 없으며 두 번째 개인 콘텐츠 DNS 서버를 설정할 필요도 없습니다. 어떤 클라이언트 클래스가 어떤 클래스에 속하는지 공개 콘텐츠 DNS 서버에 알리고 서비스할 레이블이 지정된 다양한 데이터 세트 unix.stackexchange.com.와 해당 하위 도메인을 서버에 제공합니다. 무슨 일이 있어도 모든 사람이 어떤 방법으로든 공개 콘텐츠 DNS 서버에 도달했습니다.

    • Bernstein과 같은 서버의 tinydns경우위치 코드작동하고 모든 "귀하의" 프록시 DNS 서버(백엔드 클라이언트 IP 주소)를 하나의 위치 코드로 구성하고 나머지 인터넷을 다른 위치 코드로 구성합니다. 첫 번째 위치 코드를 사용하여 프록시 DNS 서버에 표시되는 데이터베이스의 모든 데이터와 나머지 인터넷에 표시되는 모든 데이터(또는 위치 코드가 전혀 없음)를 표시할 수 있습니다.
      %시:10
%si:192.168
%lo：127
…
=unix.stackexchange.com:127.0.0.1:::lo
=unix.stackexchange.com:192.168.72.3:::si
=unix.stackexchange.com:151.101.1.69:::
    • Microsoft의 DNS 서버의 경우 사용에 조금 더 문제가 있습니다.지리적 범위체계. DNS 클라이언트의 소스 IP 주소를 표시하는 대신 서버 자체 수신 인터페이스의 IP 주소를 표시하여 작동합니다. Microsoft의 PowerShell 예를 적용했습니다.
      추가-DnsServerQueryResolutionPolicy -이름 "SplitHorizonZonePolicy" -작업 허용 -ServerInterface "eq,10.0.0.56" -ZoneScope "internal,1" -ZoneName "stackexchange.com"
추가-DnsServerResourceRecord -ZoneName "stackexchange.com" -A -이름 "unix" -IPv4Address "151.101.1.69"
추가-DnsServerResourceRecord -ZoneName "stackexchange.com" -A - 이름 "unix" -IPv4Address "10.0.0.69" -ZoneScope "내부"
    • ISC의 BIND의 경우 이를 사용하는 것이 확실히 더 번거로울 것입니다.의견체계.

    공개 DNS 콘텐츠를 제공하기 위해 외부 회사에 의존하는 경우가능한불행히도 이러한 아이디어가 주류에 들어간 지 수년이 지난 오늘날에도 마찬가지입니다. 이러한 DNS 서버 소프트웨어 중 하나를 사용하더라도 고객에게 이 기능을 제공하는 회사는 거의 없습니다.

    tinydns그러나 자신의 공용 OpenBSD 시스템에 자신의 데이터를 게시하는 경우 이러한 방식으로 분할 수평 DNS 서비스를 제공하는 것은 매우 간단합니다. ☺

  4. 정교한 DNS 클라이언트 소프트웨어를 사용합니다. 일반적으로 DNS 클라이언트는 시스템의 응용 프로그램 소프트웨어에 연결된 C 라이브러리의 코드입니다. 하지만 때로는 그렇지 않을 때도 있습니다.

    응용 프로그램 소프트웨어는 systemd와 통신하는 데스크탑 버스 시스템과 같은 것을 사용할 수 있습니다 systemd-resolved. 프록시 DNS 서버에서는 DNS 프로토콜을 사용하지 않습니다. (systemd 사람들은 응용 프로그램 소프트웨어 작성자가 이 작업을 중단하도록 권장합니다.) 대신에 그들은 이를 수행하기 위해 특수하고 비표준적인 데스크탑 버스 프로토콜을 사용합니다 systemd-resolved. systemd-resolved결과적으로 현재 네트워크 구성을 기반으로 실제 방향을 결정하는 복잡한 시스템을 갖습니다. 어떤 DNS 서버가 DNS 프로토콜 쿼리를 보내는지.

    이 로컬 DNS 서비스는 systemd-resolvedlibc NSS 또는 [데스크톱] 버스 API만큼 모든 기능을 갖추고 있지는 않습니다. [...] 따라서 모든 애플리케이션은 libc NSS API 또는 기본 systemd-resolved[데스크톱] 버스 API를 사용하는 것이 좋습니다 .
    —레나트 포틀린, 2016-06-25

    이를 조작하는 것은 이와 같은 일반적인 범위 질문과 답변의 범위를 훨씬 뛰어넘습니다.

Microsoft의 DNS 서버, ISC의 BIND 등과 같은 실행 후 잊어버리는 DNS 서버 소프트웨어의 경우 dnsmasq옵션 #1, #2 및 #3이 혼합된 것처럼 보이는 몇 가지 복잡한 시나리오가 있습니다.정말 복잡하다버전 #2를 선택하세요. 그러나 거의 20년 동안 모든 것을 한꺼번에 유지하려는 헛된 시도는 많은 DNS 세계에서 나쁜 생각으로 간주되었습니다. (Microsoft DNS 서버 세계에서도 약 10년 동안 지속되었습니다.) DNS 서버는 콘텐츠 DNS 서버와 프록시 DNS 서버가 하나로 통합되어서는 안 됩니다. (그런 사람도 있구나오픈리졸버 프로젝트이를 위해 사람들의 공용 DNS 서버를 적극적으로 조사하십시오. ) 이미 SMTP 및 HTTP 서비스에 대해 수행한 것처럼 서비스 유형을 여러 서버로 적절하게 분리하면 선택이 위 중 하나로 단순화됩니다.

추가 읽기

답변2

bind한 가지 해결책은 직접 제어하려는 도메인에 대한 영역 파일을 설치( )하고 설정하는 것입니다 .named

이를 수행하기 위한 간단한 튜토리얼이 많이 있지만 특히 마음에 듭니다.https://www.digitalocean.com/예를 들어이것.

관련 정보