웹사이트 검색

Ubuntu 14.04에서 바인딩을 신뢰할 수 있는 전용 DNS 서버로 구성하는 방법

소개

DNS(도메인 이름 시스템)는 종종 웹 사이트 및 서버 구성 방법을 배울 때 올바르게 이해하기 어려운 구성 요소입니다. 대부분의 사람들은 아마도 호스팅 회사나 도메인 등록 기관에서 제공하는 DNS 서버를 사용하기로 선택할 것이지만 자체 DNS 서버를 만들면 몇 가지 이점이 있습니다.

이 가이드에서는 Ubuntu 14.04 시스템에서 Bind9 DNS 서버를 신뢰할 수 있는 전용 DNS 서버로 설치하고 구성하는 방법에 대해 설명합니다. 기본-보조 구성에서 도메인에 대해 두 개의 바인딩 서버를 설정합니다.

전제 조건 및 목표

이 가이드를 완료하려면 먼저 몇 가지 일반적인 DNS 용어에 익숙해져야 합니다. 이 가이드에서 구현할 개념에 대해 알아보려면 이 가이드를 확인하세요.

또한 최소한 두 대의 서버가 필요합니다. 하나는 도메인의 영역 파일이 생성되는 "기본\ DNS 서버용이고 다른 하나는 전송을 통해 영역 데이터를 수신하고 다른 서버가 다운되는 경우 사용할 수 있는 "보조\ 서버입니다. . 이렇게 하면 DNS 서버에 단일 실패 지점이 생기는 위험을 피할 수 있습니다.

캐싱 또는 전달 DNS 서버 또는 다목적 DNS 서버와 달리 권한 있는 서버만 권한 있는 영역에 대한 반복 쿼리에만 응답합니다. 즉, 서버가 답을 모르면 클라이언트(일반적으로 DNS 서버를 확인하는 일종)에게 답을 모른다고 알리고 더 많이 알 수 있는 서버에 대한 참조를 제공합니다.

권한 있는 전용 DNS 서버는 클라이언트의 재귀 쿼리를 해결하는 오버헤드가 없기 때문에 고성능을 위한 좋은 구성인 경우가 많습니다. 그들은 서비스를 제공하도록 설계된 영역에만 관심이 있습니다.

이 가이드의 목적을 위해 실제로 세 개의 서버를 참조할 것입니다. 위에서 언급한 두 개의 이름 서버와 영역 내에서 호스트로 구성하려는 웹 서버.

이 가이드에서는 더미 도메인 example.com을 사용합니다. 구성 중인 도메인으로 교체해야 합니다. 구성할 머신의 세부 정보는 다음과 같습니다.

Purpose DNS FQDN IP Address
Primary name server ns1.example.com. 192.0.2.1
Secondary name server ns2.example.com. 192.0.2.2
Web Server www.example.com. 192.0.2.3

이 가이드를 완료한 후에는 도메인 영역에 대해 두 개의 신뢰할 수 있는 이름 서버가 구성되어 있어야 합니다. 위 표의 가운데 열에 있는 이름은 다양한 호스트에 도달하는 데 사용될 수 있습니다. 이 구성을 사용하면 재귀 DNS 서버가 도메인에 대한 데이터를 클라이언트에 반환할 수 있습니다.

이름 서버에서 호스트 이름 설정

이름 서버를 구성하기 전에 기본 및 보조 DNS 서버 모두에서 호스트 이름이 올바르게 구성되었는지 확인해야 합니다.

/etc/hosts 파일을 조사하여 시작하십시오. 텍스트 편집기에서 sudo 권한으로 파일을 엽니다.

sudo nano /etc/hosts

각 서버의 호스트 이름과 FQDN을 올바르게 식별하도록 구성해야 합니다. 기본 이름 서버의 경우 파일은 처음에 다음과 같이 표시됩니다.

127.0.0.1       localhost
127.0.1.1       ns1 ns1
. . .

특정 호스트 및 도메인 조합을 참조하도록 두 번째 줄을 수정하고 이를 공개 정적 IP 주소로 지정해야 합니다. 그런 다음 정규화되지 않은 이름을 끝에 별칭으로 추가할 수 있습니다. 이 예에서 기본 서버의 경우 두 번째 줄을 다음과 같이 변경합니다.

127.0.0.1       localhost
192.0.2.1       ns1.example.com ns1
. . .

완료되면 파일을 저장하고 닫습니다.

또한 정규화되지 않은 호스트 이름을 포함하도록 /etc/hostname 파일을 수정해야 합니다.

sudo nano /etc/hostname

ns1

다음을 입력하여 현재 실행 중인 시스템으로 이 값을 읽을 수 있습니다.

sudo hostname -F /etc/hostname

보조 서버에서 동일한 절차를 완료하려고 합니다.

/etc/hosts 파일로 시작합니다.

sudo nano /etc/hosts

127.0.0.1       localhost
192.0.2.2       ns2.example.com ns2

완료되면 파일을 저장하고 닫습니다.

그런 다음 /etc/hostname 파일을 수정합니다. 이 파일에 대해 실제 호스트(이 예에서는 ns2만)만 사용해야 함을 기억하십시오.

sudo nano /etc/hostname

ns2

다시 파일을 읽어 현재 시스템을 수정합니다.

sudo hostname -F /etc/hostname

이제 서버에 호스트 정의가 올바르게 설정되어 있어야 합니다.

두 네임서버 모두에 바인드 설치

이제 각 이름 서버에 우리가 사용할 DNS 서버인 Bind를 설치할 수 있습니다.

Bind 소프트웨어는 Ubuntu의 기본 리포지토리 내에서 사용할 수 있으므로 로컬 패키지 인덱스를 업데이트하고 apt를 사용하여 소프트웨어를 설치하기만 하면 됩니다. 또한 설명서와 몇 가지 일반적인 유틸리티도 포함됩니다.

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

기본 및 보조 DNS 서버에서 이 설치 명령을 실행하여 적절한 파일을 얻습니다.

기본 바인드 서버 구성

이제 소프트웨어가 설치되었으므로 기본 서버에서 DNS 서버를 구성하여 시작할 수 있습니다.

옵션 파일 구성

시작하기 위해 가장 먼저 구성할 것은 named.conf.options 파일입니다.

Bind DNS 서버는 named라고도 합니다. 기본 구성 파일은 /etc/bind/named.conf에 있습니다. 이 파일은 실제로 구성할 다른 파일을 호출합니다.

편집기에서 sudo 권한으로 옵션 파일을 엽니다.

sudo nano /etc/bind/named.conf.options

아래에서는 간결함을 위해 대부분의 주석이 달린 줄을 제거했지만 일반적으로 설치 후 파일은 다음과 같아야 합니다.

options {
        directory "/var/cache/bind";

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

이 파일에서 구성해야 하는 주요 항목은 재귀입니다. 신뢰할 수 있는 전용 서버를 설정하려고 하므로 이 서버에서 재귀를 사용하지 않으려고 합니다. options 블록 내에서 이 기능을 끌 수 있습니다.

또한 이전을 허용하지 않도록 기본 설정됩니다. 나중에 개별 영역 사양에서 이를 재정의합니다.

options {
        directory "/var/cache/bind";
        recursion no;
        allow-transfer { none; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

완료되면 파일을 저장하고 닫습니다.

로컬 파일 구성

우리가 취해야 할 다음 단계는 이 서버를 제어하려는 영역을 지정하는 것입니다. 영역은 다른 서버에 하위 위임되지 않은 이름 서버에 관리를 위해 위임된 도메인의 일부입니다.

우리는 example.com 도메인을 구성하고 있으며 도메인의 일부에 대한 책임을 다른 서버에 하위 위임하지 않을 것입니다. 따라서 영역은 전체 도메인을 포함합니다.

영역을 구성하려면 sudo 권한으로 /etc/bind/named.conf.local 파일을 열어야 합니다.

sudo nano /etc/bind/named.conf.local

이 파일은 처음에는 주석 외에는 비어 있습니다. 일반적인 관리를 위해 우리 서버가 알고 있는 다른 영역이 있지만 named.conf.default-zones 파일에 지정되어 있습니다.

시작하려면 example.com 도메인에 대한 전달 영역을 구성해야 합니다. 정방향 영역은 DNS에 대해 논의할 때 우리 대부분이 생각하는 기존의 이름-IP 해상도입니다. 구성하려는 도메인 영역을 정의하는 구성 블록을 만듭니다.

zone "example.com" {
};

참고: 많은 DNS 도구, 해당 구성 파일 및 문서는 "마스터\ 및 "슬레이브\라는 용어를 사용하는 반면 DigitalOcean은 일반적으로 대체 설명자를 선호합니다. 혼동을 피하기 위해 서버 간의 관계를 나타내는 데 "기본\ 및 "보조\라는 용어를 사용하고 구성 지시문에서 요구하는 경우에만 "마스터\ 또는 "슬레이브\를 사용하도록 선택했습니다.

이 블록 내부에 이 영역에 대한 관리 정보를 추가합니다. 이 DNS 서버와 영역의 관계를 지정합니다. 이 컴퓨터를 모든 영역에 대한 기본 이름 서버로 구성하고 있으므로 다음 영역 예제에서 type master;입니다. 또한 Bind는 영역을 정의하는 실제 리소스 레코드를 보유하는 파일을 가리킵니다.

Bind 구성 디렉토리 내의 zones라는 하위 디렉토리에 기본 영역 파일을 보관할 것입니다. Bind 디렉토리의 다른 영역 파일에서 규칙을 차용하기 위해 db.example.com 파일을 호출합니다. 우리 블록은 이제 다음과 같이 보일 것입니다.

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
};

이 영역을 보조 서버로 전송하려면 다음과 같은 줄을 추가해야 합니다.

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 192.0.2.2; };
};

다음으로 도메인의 리버스 영역을 정의합니다.

리버스 존에 대한 정보

IP 주소를 제공한 조직이 네트워크 범위를 제공하지 않고 해당 범위에 대한 책임을 위임하지 않은 경우 역방향 영역 파일은 참조되지 않으며 조직 자체에서 처리합니다.

호스팅 제공업체의 경우 역방향 매핑은 일반적으로 회사 자체에서 처리합니다. 예를 들어 DigitalOcean을 사용하면 제어판에서 시스템의 FQDN을 서버 이름으로 사용하는 경우 서버에 대한 역방향 매핑이 자동으로 생성됩니다. 예를 들어, 이 자습서의 역방향 매핑은 다음과 같이 서버 이름을 지정하여 만들 수 있습니다.

이와 같은 경우 관리할 주소 덩어리가 할당되지 않았으므로 이 전략을 사용해야 합니다. 아래에 설명된 전략은 완전성과 연속 주소의 더 큰 그룹에 대한 제어 권한을 위임받은 경우 적용할 수 있도록 다룹니다.

역방향 영역은 IP 주소를 도메인 이름에 다시 연결하는 데 사용됩니다. 그러나 도메인 이름 시스템은 원래 순방향 매핑을 위해 설계되었으므로 역방향 매핑을 허용하도록 이를 조정하는 데 약간의 생각이 필요합니다.

역 매핑을 이해하기 위해 염두에 두어야 할 정보는 다음과 같습니다.

  • 도메인에서 주소의 가장 구체적인 부분은 왼쪽에 있습니다. IP 주소의 경우 가장 구체적인 부분이 오른쪽에 있습니다.
  • 도메인 사양의 가장 구체적인 부분은 하위 도메인 또는 호스트 이름입니다. 이것은 도메인의 영역 파일에 정의되어 있습니다.
  • 각 하위 도메인은 차례로 더 많은 하위 도메인 또는 호스트를 정의할 수 있습니다.

모든 역방향 영역 매핑은 IANA(Internet Assigned Numbers Authority)에서 제어하는 특수 도메인 in-addr.arpa에서 정의됩니다. 이 도메인 아래에는 하위 도메인을 사용하여 IP 주소의 각 옥텟을 매핑하는 트리가 있습니다. IP 주소의 특이성이 일반 도메인의 특이성을 미러링하도록 하기 위해 IP 주소의 옥텟은 실제로 반전됩니다.

따라서 IP 주소가 192.0.2.1인 기본 DNS 서버는 뒤집혀서 1.2.0.192로 읽히게 됩니다. 이 호스트 사양을 in-addr.arpa 도메인 아래에 존재하는 계층 구조로 추가하면 특정 호스트를 1.2.0.192.in-addr.arpa로 참조할 수 있습니다.

DNS를 사용할 때 영역 파일 자체 내에서 개별 호스트(여기서 선행 "1\과 같은)를 정의하므로 구성할 영역은 2.0.192.in-addr.arpa가 됩니다. 네트워크 공급자가 192.0.2.0/24와 같이 /24 주소 블록을 제공했다면 이 in-addr.arpa 부분을 우리에게 위임했을 것입니다.

역방향 영역 이름을 지정하는 방법을 알았으므로 실제 정의는 정방향 영역과 정확히 동일합니다. example.com 영역 정의 아래에서 주어진 네트워크에 대한 리버스 영역을 만듭니다. 다시 말하지만 이것은 주소 블록에 대한 제어 권한을 위임받은 경우에만 필요할 것입니다.

zone "2.0.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.0.2";
};

파일 이름을 db.192.0.2로 지정했습니다. 이것은 영역이 구성하는 것에 대해 구체적이며 반대 표기보다 더 읽기 쉽습니다.

완료되면 파일을 저장하고 닫습니다.

정방향 영역 파일 만들기

이제 정방향 및 역방향 영역에 대해 Bind에 알렸지만 이러한 영역을 정의할 파일을 아직 만들지 않았습니다.

파일 위치를 zones라는 하위 디렉토리 내에 있는 것으로 지정했습니다. 다음 디렉토리를 만들어야 합니다.

sudo mkdir /etc/bind/zones

이제 Bind 디렉토리에 있는 일부 기존 영역 파일을 만들려는 영역 파일의 템플릿으로 사용할 수 있습니다. 정방향 영역의 경우 db.local 파일이 우리가 필요로 하는 것과 비슷할 것입니다. 해당 파일을 named.conf.local 파일에 사용된 이름으로 zones 하위 디렉토리에 복사합니다.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

이 작업을 수행하는 동안 리버스 영역에 대한 템플릿도 복사할 수 있습니다. db.127 파일을 사용할 것입니다. 필요한 것과 거의 일치하기 때문입니다.

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

이제 텍스트 편집기에서 sudo 권한으로 정방향 영역 파일을 엽니다.

sudo nano /etc/bind/zones/db.example.com

파일은 다음과 같습니다.

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
@       IN      A       127.0.0.1
@       IN      AAAA    ::1

가장 먼저 해야 할 일은 첫 번째 @ 기호로 시작하여 닫는 괄호까지 계속되는 SOA(권한 시작) 레코드를 수정하는 것입니다.

localhost.를 이 컴퓨터의 FQDN 이름으로 바꿔야 합니다. 레코드의 이 부분은 정의 중인 영역에 대해 정식으로 응답할 이름 서버를 정의하는 데 사용됩니다. 이것은 우리가 지금 구성하고 있는 머신이 될 것입니다. 우리의 경우에는 ns1.example.com.입니다(후행 점에 주목하십시오. 이것은 항목을 올바르게 등록하는 데 중요합니다!).

또한 @가 점으로 대체된 특수 형식의 이메일 주소인 다음 조각을 변경하려고 합니다. 우리는 이메일이 도메인 관리자에게 전달되기를 원하므로 기존 이메일은 admin@example.com입니다. admin.example.com.처럼 보이도록 번역하겠습니다.

@       IN      SOA     ns1.example.com. admin.example.com. (

편집해야 할 다음 부분은 일련 번호입니다. 일련 번호의 값은 Bind가 업데이트된 정보를 보조 서버로 보내야 하는지 여부를 알려주는 방법입니다.

참고: 일련 번호를 증가시키지 못하는 것은 영역 업데이트 문제로 이어지는 가장 일반적인 실수 중 하나입니다. 수정할 때마다 일련 번호를 반드시 입력해야 합니다.

한 가지 일반적인 방법은 숫자를 증가시키는 규칙을 사용하는 것입니다. 한 가지 방법은 YYYYMMDD 형식의 날짜를 끝 부분에 추가된 날짜의 개정 번호와 함께 사용하는 것입니다. 따라서 2014년 6월 5일에 작성된 첫 번째 개정판의 일련 번호는 2014060501이고 그날 이후에 작성된 업데이트의 일련 번호는 2014060502일 수 있습니다. 값은 10자리 숫자일 수 있습니다.

사용 편의성을 위해 규칙을 채택할 가치가 있지만 데모를 위해 간단하게 유지하기 위해 지금은 5로 설정합니다.

@       IN      SOA     ns1.example.com. admin.example.com. (
                              5         ; Serial

다음으로 파일의 마지막 세 줄(아래에서 @로 시작하는 줄)을 제거할 수 있습니다.

SOA 레코드 다음에 설정하려는 첫 번째 항목은 영역의 이름 서버입니다. 도메인을 지정한 다음 영역에 대해 권한이 있는 두 개의 이름 서버를 이름으로 지정합니다. 이러한 이름 서버는 도메인 자체 내의 호스트가 되므로 약간 자기 참조적인 것처럼 보입니다.

가이드의 경우 다음과 같이 표시됩니다. 다시 한 번 엔딩 점에 주목하세요!:

; Name servers
example.com.    IN      NS      ns1.example.com.
example.com.    IN      NS      ns2.example.com.

영역 파일의 목적은 주로 호스트 이름과 서비스를 특정 주소에 매핑하는 것이므로 아직 완료되지 않았습니다. 이 영역 파일을 읽는 모든 소프트웨어는 권위 있는 영역에 액세스하기 위해 ns1 및 ns2 서버가 어디에 있는지 알고 싶어할 것입니다.

따라서 다음으로 이러한 이름 서버 이름을 이름 서버의 실제 IP 주소에 연결할 A 레코드를 만들어야 합니다.

; A records for name servers
ns1             IN      A       192.0.2.1
ns2             IN      A       192.0.2.2

이제 이름 서버를 올바른 IP 주소로 성공적으로 확인할 수 있는 A 레코드가 있으므로 추가 레코드를 추가할 수 있습니다. 사이트를 제공하는 데 사용하려는 호스트 중 하나에 웹 서버가 있음을 기억하십시오. 일반 도메인(이 경우 example.com)에 대한 요청과 www 호스트에 대한 요청을 이 호스트로 지정합니다. 다음과 같이 표시됩니다.

; Other A records
@               IN      A       192.0.2.3
www             IN      A       192.0.2.3

추가 A 레코드를 생성하여 정의해야 하는 추가 호스트를 추가할 수 있습니다. 추가 레코드 생성과 관련된 몇 가지 옵션에 익숙해지려면 DNS 기본 가이드를 참조하세요.

완료되면 파일은 다음과 같아야 합니다.

$TTL    604800
@       IN      SOA     ns1.example.com. admin.example.com. (
                              5         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

; Name servers
example.com.    IN      NS      ns1.example.com.
example.com.    IN      NS      ns2.example.com.

; A records for name servers
ns1             IN      A       192.0.2.1
ns2             IN      A       192.0.2.2

; Other A records
@               IN      A       192.0.2.3
www             IN      A       192.0.2.3

완료되면 파일을 저장하고 닫습니다.

리버스 존 파일 생성

이제 순방향 영역이 구성되었지만 구성 파일에서 지정한 역방향 영역 파일을 설정해야 합니다. 마지막 섹션의 시작 부분에서 이미 파일을 만들었습니다.

sudo 권한으로 텍스트 편집기에서 파일을 엽니다.

sudo nano db.192.0.2

파일은 다음과 같아야 합니다.

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
1.0.0   IN      PTR     localhost.

우리는 포워드 존에서 했던 것과 거의 같은 절차를 거칠 것입니다. 먼저 도메인 이름, 관리자 이메일 및 일련 번호를 마지막 파일에 있는 것과 정확히 일치하도록 조정합니다(일련 번호는 다를 수 있지만 증가해야 함).

@       IN      SOA     example.com. admin.example.com. (
                              5         ; Serial

다시 SOA 레코드의 닫는 괄호 아래 줄을 지웁니다. 네트워크 범위에 있는 각 IP 주소의 마지막 옥텟을 가져와 PTR 레코드를 사용하여 해당 호스트의 FQDN에 다시 매핑합니다. 각 IP 주소에는 일부 소프트웨어의 문제를 방지하기 위해 단일 PTR 레코드만 있어야 하므로 역 매핑할 호스트 이름을 선택해야 합니다.

예를 들어, 메일 서버를 설정한 경우 많은 시스템에서 역방향 매핑을 사용하여 주소를 확인하기 때문에 메일 이름에 대한 역방향 매핑을 설정하고 싶을 것입니다.

먼저 이름 서버를 다시 설정해야 합니다.

; Name servers
        IN      NS      ns1.example.com.
        IN      NS      ns2.example.com.

다음으로 참조하는 IP 주소의 마지막 옥텟을 사용하여 반환하려는 정규화된 도메인 이름을 다시 가리킵니다. 이 예에서는 다음을 사용합니다.

; PTR Records
1       IN      PTR      ns1.example.com.
2       IN      PTR      ns2.example.com.
3       IN      PTR      www.example.com.

완료되면 파일은 다음과 같아야 합니다.

$TTL    604800
@       IN      SOA     example.com. admin.example.com. (
                              5         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

; Name servers
        IN      NS      ns1.example.com.
        IN      NS      ns2.example.com.

; PTR records
1       IN      PTR      ns1.example.com.
2       IN      PTR      ns2.example.com.
3       IN      PTR      www.example.com.

완료되면 파일을 저장하고 닫습니다.

파일 테스트 및 서비스 다시 시작

이제 주 서버에 대한 구성이 완료되었지만 여전히 변경 사항을 구현해야 합니다.

서비스를 다시 시작하기 전에 모든 구성 파일을 테스트하여 올바르게 구성되었는지 확인해야 합니다. 각 파일의 구문을 확인할 수 있는 몇 가지 도구가 있습니다.

먼저 named-checkconf 명령을 사용하여 named.conf.local 및 named.conf.options 파일을 확인할 수 있습니다. 이 두 파일 모두 스켈레톤 named.conf 파일의 소스이므로 수정한 파일의 구문을 테스트합니다.

sudo named-checkconf

이것이 메시지 없이 반환되면 named.conf.local 및 named.conf.options 파일이 구문적으로 유효함을 의미합니다.

다음으로 영역이 처리하는 도메인과 영역 파일 위치를 named-checkzone 명령에 전달하여 개별 영역 파일을 확인할 수 있습니다. 따라서 가이드의 경우 다음을 입력하여 정방향 영역 파일을 확인할 수 있습니다.

sudo named-checkzone example.com /etc/bind/zones/db.example.com

파일에 문제가 없으면 올바른 일련 번호를 로드했다고 알려주고 "OK\ 메시지를 표시해야 합니다.

zone example.com/IN: loaded serial 5
OK

다른 메시지가 나타나면 영역 파일에 문제가 있음을 의미합니다. 일반적으로 메시지는 어떤 부분이 유효하지 않은지에 대해 매우 잘 설명합니다.

in-addr.arpa 주소와 파일명을 전달하면 역방향 영역을 확인할 수 있습니다. 데모를 위해 다음을 입력합니다.

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

다시 말하지만 올바른 일련 번호를 로드하는 것과 유사한 메시지가 표시됩니다.

zone 2.0.192.in-addr.arpa/IN: loaded serial 5
OK

모든 파일이 체크아웃되면 바인드 서비스를 다시 시작할 수 있습니다.

sudo service bind9 restart

다음을 입력하여 로그를 확인해야 합니다.

sudo tail -f /var/log/syslog

오류가 없는지 확인하려면 이 로그를 주시하십시오.

보조 바인드 서버 구성

기본 서버가 구성되었으므로 계속해서 보조 서버를 설정할 수 있습니다. 이것은 기본 서버보다 훨씬 쉬울 것입니다.

옵션 파일 구성

다시 named.conf.options 파일부터 시작하겠습니다. 텍스트 편집기에서 sudo 권한으로 엽니다.

sudo nano /etc/bind/named.conf.options

주 서버의 파일에 대해 수행한 것과 동일하게 이 파일을 수정합니다.

options {
        directory "/var/cache/bind";
        recursion no;
        allow-transfer { none; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

완료되면 파일을 저장하고 닫습니다.

로컬 구성 파일 구성

다음으로 보조 서버에서 named.conf.local 파일을 구성합니다. 텍스트 편집기에서 sudo 권한으로 엽니다.

sudo nano /etc/bind/named.conf.local

여기서는 주 서버에서 했던 것처럼 각 영역 사양을 생성합니다. 그러나 값과 일부 매개변수는 다를 수 있습니다.

먼저 포워드 존에서 작업합니다. 기본 파일에서 했던 것과 같은 방식으로 시작합니다.

zone "example.com" {
};

이번에는 이 서버가 이 영역의 보조 서버 역할을 하므로 type을 slave로 설정하겠습니다. 이는 단순히 로컬 시스템의 파일이 아닌 전송을 통해 영역 파일을 수신한다는 의미입니다. 또한 영역 파일의 절대 경로 대신 상대 파일 이름을 지정하려고 합니다.

그 이유는 보조 영역의 경우 Bind가 /var/cache/bind 파일을 저장하기 때문입니다. 바인드는 이미 이 디렉터리 위치를 찾도록 구성되어 있으므로 경로를 지정할 필요가 없습니다.

포워드 영역의 경우 이러한 세부 정보는 다음과 같습니다.

zone "example.com" {
    type slave;
    file "db.example.com";
};

마지막으로 allow-transfer 지시문 대신 이 서버가 영역 전송을 수락할 기본 서버를 IP 주소로 지정합니다. 이것은 masters라는 지시문에서 수행됩니다.

zone "example.com" {
    type slave;
    file "db.example.com";
    masters { 192.0.2.1; };
};

이것으로 전방 영역 사양이 완료됩니다. 이와 동일한 형식을 사용하여 역방향 영역 사양을 처리할 수 있습니다.

zone "2.0.192.in-addr.arpa" {
    type slave;
    file "db.192.0.2";
    masters { 192.0.2.1; };
};

완료되면 파일을 저장하고 닫을 수 있습니다.

파일 테스트 및 서비스 다시 시작

이전에 언급한 것처럼 이 서버가 기본 서버에서 영역 파일을 수신하기 때문에 실제로 보조 시스템에서 실제 영역 파일 생성을 수행할 필요가 없습니다. 그래서 우리는 테스트할 준비가 되었습니다.

다시 한 번 구성 파일 구문을 확인해야 합니다. 확인할 영역 파일이 없으므로 named-checkconf 도구만 사용하면 됩니다.

sudo named-checkconf

오류 없이 반환되면 수정한 파일에 구문 오류가 없음을 의미합니다.

이 경우 바인드 서비스를 다시 시작할 수 있습니다.

sudo service bind9 restart

다음을 사용하여 기본 서버와 보조 서버 모두에서 로그를 확인합니다.

sudo tail -f /var/log/syslog

영역 파일이 올바르게 전송되었음을 나타내는 일부 항목이 표시되어야 합니다.

이름 서버에 권한 위임

권한 있는 전용 이름 서버가 이제 완전히 구성되어야 합니다. 그러나 여전히 도메인에 대한 권한을 네임 서버에 위임해야 합니다.

이렇게 하려면 도메인 이름을 구입한 웹사이트로 이동해야 합니다. 인터페이스와 용어는 사용한 도메인 이름 등록 기관에 따라 다를 수 있습니다.

도메인 설정에서 사용하려는 이름 서버를 지정할 수 있는 옵션을 찾습니다. 우리 이름 서버는 우리 도메인 내에 있기 때문에 이것은 특별한 경우입니다.

레지스트라는 단순히 NS 레코드를 사용하여 영역에 대한 권한을 위임하는 대신 글루 레코드를 생성해야 합니다. 글루 레코드는 권한을 위임할 이름 서버를 지정한 후 이름 서버의 IP 주소를 지정하는 A 레코드입니다.

일반적으로 위임에는 도메인의 권한을 처리할 네임서버만 나열되지만 네임서버가 도메인 자체 내에 있는 경우 상위 영역의 네임서버에 대한 A 레코드가 필요합니다. 그렇지 않으면 위임 경로를 따라갈 도메인 이름 서버의 IP 주소를 찾을 수 없기 때문에 DNS 해석기가 루프에 갇히게 됩니다.

따라서 이름 서버 및 해당 IP 주소를 지정할 수 있는 도메인 등록 기관의 제어판 섹션을 찾아야 합니다.

데모로 등록 기관 Namecheap에는 두 개의 서로 다른 이름 서버 섹션이 있습니다.

도메인 내의 이름 서버에 대한 IP 주소를 지정할 수 있는 "이름 서버 등록\이라는 섹션이 있습니다.

내부에서 도메인 내에 존재하는 이름 서버의 IP 주소를 입력할 수 있습니다.

이렇게 하면 상위 영역 파일에 필요한 글루 레코드 역할을 하는 A 레코드가 생성됩니다.

이 작업을 완료하면 활성 이름 서버를 도메인의 서버로 변경할 수 있습니다. NameCheap에서는 "도메인 이름 서버 설정\ 메뉴 옵션을 사용하여 이 작업을 수행합니다.

여기에서 추가한 이름 서버를 사이트의 신뢰할 수 있는 서버로 사용하도록 지시할 수 있습니다.

변경 사항이 전파되는 데 시간이 다소 걸릴 수 있지만 대부분의 등록 기관에서 다음 24~48시간 이내에 이름 서버의 데이터가 사용되는 것을 볼 수 있습니다.

결론

이제 도메인을 처리하도록 구성된 두 개의 신뢰할 수 있는 전용 DNS 서버가 있어야 합니다. 추가 도메인을 획득함에 따라 추가 도메인에 대한 영역 정보를 저장하는 데 사용할 수 있습니다.

자신의 DNS 서버를 구성하고 관리하면 DNS 레코드가 처리되는 방식을 최대한 제어할 수 있습니다. 변경할 수 있으며 DNS 데이터의 모든 관련 부분이 소스에서 최신 상태인지 확인할 수 있습니다. 다른 DNS 솔루션이 이 프로세스를 더 쉽게 만들 수 있지만 옵션이 있다는 것을 알고 더 많은 패키지 솔루션에서 어떤 일이 일어나고 있는지 이해하는 것이 중요합니다.