웹사이트 검색

Ubuntu 14.04에서 Bind를 캐싱 또는 전달 DNS 서버로 구성하는 방법

소개

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

이 가이드에서는 Ubuntu 14.04 시스템에서 Bind9 DNS 서버를 캐싱 또는 전달 DNS 서버로 설치 및 구성하는 방법에 대해 설명합니다. 이 두 가지 구성은 모두 시스템 네트워크에 서비스를 제공할 때 이점이 있습니다.

전제 조건 및 목표

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

유사한 목표를 달성하는 두 가지 개별 구성인 캐싱 및 전달 DNS 서버를 시연할 것입니다.

따라 하려면 두 대의 컴퓨터에 액세스할 수 있어야 합니다(최소 한 대는 Ubuntu 14.04 서버여야 함). 하나는 클라이언트로 작동하고 다른 하나는 DNS 서버로 구성됩니다. 예제 구성의 세부 정보는 다음과 같습니다.

Role IP Address
DNS Server 192.0.2.1
Client 192.0.2.100

쿼리에 DNS 서버를 사용하도록 클라이언트 시스템을 구성하는 방법을 보여줍니다. 필요에 따라 두 가지 다른 구성으로 DNS 서버를 구성하는 방법을 보여드리겠습니다.

캐싱 DNS 서버

첫 번째 구성은 캐싱 DNS 서버용입니다. 이 유형의 서버는 재귀 쿼리를 처리하고 일반적으로 다른 서버에서 DNS 데이터를 추적하는 번거로운 작업을 처리할 수 있기 때문에 확인자라고도 합니다.

캐싱 DNS 서버가 클라이언트의 쿼리에 대한 응답을 추적하면 응답을 클라이언트에 반환합니다. 그러나 레코드의 TTL 값에서 허용하는 기간 동안 응답을 캐시에 저장하기도 합니다. 그런 다음 총 왕복 시간을 단축하기 위해 캐시를 후속 요청의 소스로 사용할 수 있습니다.

네트워크 구성에 있을 수 있는 거의 모든 DNS 서버는 DNS 서버를 캐싱합니다. 이는 대부분의 클라이언트 시스템에 구현된 적절한 DNS 해석기 라이브러리의 부족을 보완합니다. 캐싱 DNS 서버는 많은 상황에서 좋은 선택입니다. ISP DNS 또는 기타 공개적으로 사용 가능한 DNS 서버에 의존하지 않으려면 자체 캐싱 서버를 만드는 것이 좋습니다. 클라이언트 시스템에 물리적으로 근접한 경우 DNS 쿼리 시간을 개선할 가능성도 매우 높습니다.

포워딩 DNS 서버

시연할 두 번째 구성은 전달 DNS 서버입니다. 전달 DNS 서버는 클라이언트의 관점에서 보면 캐싱 서버와 거의 동일하게 보이지만 메커니즘과 작업 로드는 상당히 다릅니다.

전달 DNS 서버는 클라이언트의 DNS 확인 시간을 개선하기 위해 캐시를 유지하는 동일한 이점을 제공합니다. 그러나 실제로 재귀 쿼리 자체는 수행하지 않습니다. 대신 모든 요청을 외부 확인 서버로 전달한 다음 이후 쿼리에 사용할 결과를 캐시합니다.

이를 통해 전달 서버는 재귀 쿼리의 모든 작업을 수행할 필요 없이 캐시에서 응답할 수 있습니다. 이를 통해 서버는 전체 재귀 루틴을 거치지 않고 단일 요청(전달된 클라이언트 요청)만 만들 수 있습니다. 이는 외부 대역폭 전송 비용이 많이 드는 환경, 캐싱 서버를 자주 변경해야 하는 환경 또는 로컬 쿼리를 한 서버로 전달하고 외부 쿼리를 다른 서버로 전달하려는 경우에 이점이 될 수 있습니다.

DNS 서버에 바인드 설치

사용하려는 구성 선택에 관계없이 Bind DNS 서버 구현의 첫 번째 단계는 실제 소프트웨어를 설치하는 것입니다.

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

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

Bind 구성 요소가 설치되었으므로 이제 서버 구성을 시작할 수 있습니다. 전달 서버는 캐싱 서버 구성을 출발점으로 사용하므로 최종 목표에 관계없이 먼저 서버를 캐싱 서버로 구성하십시오.

캐싱 DNS 서버로 구성

먼저 캐싱 DNS 서버 역할을 하도록 Bind를 구성하는 방법을 설명합니다. 이 구성은 클라이언트가 쿼리를 발행할 때 서버가 다른 DNS 서버에서 재귀적으로 응답을 찾도록 강제합니다. 이는 전체 응답을 찾을 때까지 각 관련 DNS 서버를 차례로 쿼리하는 작업을 수행하고 있음을 의미합니다.

바인딩 구성 파일은 기본적으로 /etc/bind의 디렉터리에 보관됩니다. 지금 해당 디렉터리로 이동합니다.

cd /etc/bind

우리는 이 디렉토리에 있는 대부분의 파일에 대해서는 관심을 두지 않을 것입니다. 기본 구성 파일은 named.conf입니다(named 및 bind는 동일한 응용 프로그램의 두 가지 이름입니다). 이 파일은 단순히 named.conf.options 파일, named.conf.local 파일 및 named.conf.default-zones를 소싱합니다. 파일.

캐싱 DNS 서버의 경우 named.conf.options 파일만 수정합니다. sudo 권한으로 텍스트 편집기에서 이것을 엽니다.

sudo nano named.conf.options

가독성을 위해 주석을 제거한 파일은 다음과 같습니다.

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

        dnssec-validation auto;

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

캐싱을 구성하기 위한 첫 번째 단계는 액세스 제어 목록(ACL)을 설정하는 것입니다.

재귀 쿼리를 해결하는 데 사용될 DNS 서버로서 악의적인 사용자가 DNS 서버를 남용하는 것을 원하지 않습니다. DNS 증폭 공격이라고 하는 공격은 서버가 분산 서비스 거부 공격에 참여할 수 있기 때문에 특히 골칫거리입니다.

DNS 증폭 공격은 악의적인 사용자가 인터넷에서 서버나 사이트를 다운시키려는 한 가지 방법입니다. 이를 위해 재귀 쿼리를 해결할 공용 DNS 서버를 찾으려고 합니다. 피해자의 IP 주소를 스푸핑하고 DNS 서버에 큰 응답을 반환하는 쿼리를 보냅니다. 그렇게 함으로써 DNS 서버는 피해자 서버로 향하는 큰 페이로드로 작은 요청에 응답하여 공격자의 사용 가능한 대역폭을 효과적으로 증폭시킵니다.

공용 재귀 DNS 서버를 호스팅하려면 많은 특수 구성 및 관리가 필요합니다. 귀하의 서버가 악의적인 목적으로 사용될 가능성을 피하기 위해 당사는 신뢰하는 IP 주소 또는 네트워크 범위 목록을 구성합니다.

options 블록 위에 acl이라는 새 블록을 만듭니다. 구성 중인 ACL 그룹에 대한 레이블을 생성합니다. 이 가이드에서는 그룹을 goodclients라고 합니다.

acl goodclients {
};

options {
    . . .

이 블록 내에서 이 DNS 서버를 사용하도록 허용되어야 하는 IP 주소 또는 네트워크를 나열합니다. 서버와 클라이언트가 모두 동일한 /24 서브넷 내에서 작동하고 있으므로 예제를 이 네트워크로 제한합니다. 또한 이 작업을 자동으로 시도하는 localhost 및 localnets를 추가합니다.

acl goodclients {
    192.0.2.0/24;
    localhost;
    localnets;
};

options {
    . . .

이제 요청을 해결하려는 클라이언트의 ACL이 있으므로 options 블록에서 해당 기능을 구성할 수 있습니다. 이 블록 내에 다음 줄을 추가합니다.

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

    recursion yes;
    allow-query { goodclients; };
    . . .

재귀를 명시적으로 켠 다음 ACL 사양을 사용하도록 allow-query 매개변수를 구성했습니다. ACL 그룹을 참조하기 위해 allow-recursion과 같은 다른 매개변수를 사용할 수 있었습니다. 존재하고 재귀가 켜져 있으면 allow-recursion은 재귀 서비스를 사용할 수 있는 클라이언트 목록을 지시합니다.

그러나 allow-recursion이 설정되지 않은 경우 Bind는 allow-query-cache 목록에 폴백한 다음 allow-query 목록에 폴백합니다. , 마지막으로 기본값은 localnets 및 localhost뿐입니다. 캐싱 전용 서버(자체 권한 영역이 없고 요청을 전달하지 않음)를 구성하고 있으므로 allow-query 목록은 항상 재귀에만 적용됩니다. ACL을 지정하는 가장 일반적인 방법이기 때문에 사용하고 있습니다.

이러한 변경을 마치면 파일을 저장하고 닫습니다.

이것은 실제로 캐싱 DNS 서버에 필요한 모든 것입니다. 이것이 사용하려는 서버 유형이라고 결정했다면 구성 파일을 확인하고 서비스를 다시 시작하고 클라이언트 구성을 구현하는 방법을 알아보기 위해 건너뛰어도 됩니다.

그렇지 않으면 대신 전달 DNS 서버를 설정하는 방법을 배우려면 계속 읽으십시오.

전달 DNS 서버로 구성

포워딩 DNS 서버가 귀하의 인프라에 더 적합한 경우 대신 쉽게 설정할 수 있습니다.

캐싱 서버 구성에서 중단한 구성부터 시작하겠습니다. named.conf.options 파일은 다음과 같아야 합니다.

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

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

        recursion yes;
        allow-query { goodclients; };

        dnssec-validation auto;

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

동일한 ACL 목록을 사용하여 DNS 서버를 특정 클라이언트 목록으로 제한합니다. 그러나 서버가 더 이상 자체적으로 재귀 쿼리를 수행하려고 시도하지 않도록 구성을 변경해야 합니다.

이를 위해 recursion을 no로 변경하지 않습니다. 전달 서버는 권한이 없는 영역에 대한 쿼리에 응답하여 여전히 재귀 서비스를 제공하고 있습니다. 대신 요청을 전달할 캐싱 서버 목록을 설정해야 합니다.

이 작업은 options {} 블록 내에서 수행됩니다. 먼저 요청을 전달할 재귀 이름 서버의 IP 주소를 포함하는 forwarders라는 블록을 내부에 생성합니다. 가이드에서는 Google의 공용 DNS 서버(8.8.8.8 및 8.8.4.4)를 사용합니다.

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

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        . . .

그런 다음 forward 지시문을 "only\로 설정해야 합니다. 이 서버는 모든 요청을 전달하고 자체적으로 요청을 해결하려고 시도해서는 안 되기 때문입니다.

완료되면 구성 파일은 다음과 같습니다.

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

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

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        forward only;

        dnssec-validation auto;

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

마지막으로 변경해야 할 사항은 dnssec 매개변수입니다. 현재 구성에서는 전달된 DNS 서버의 구성에 따라 로그에 다음과 같은 오류가 표시될 수 있습니다.

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53

이를 방지하려면 dnssec-validation 설정을 "yes\로 변경하고 dnssec을 명시적으로 활성화합니다.

. . .
forward only;

dnssec-enable yes;
dnssec-validation yes;

auth-nxdomain no;    # conform to RFC1035
. . .

완료되면 파일을 저장하고 닫습니다. 이제 전달 DNS 서버가 있어야 합니다. 다음 섹션으로 계속 진행하여 구성 파일의 유효성을 검사하고 데몬을 다시 시작하십시오.

구성 테스트 및 바인드 다시 시작

이제 Bind 서버를 캐싱 DNS 서버 또는 전달 DNS 서버로 구성했으므로 변경 사항을 구현할 준비가 되었습니다.

급락하여 시스템에서 Bind 서버를 다시 시작하기 전에 Bind에 포함된 도구를 사용하여 구성 파일의 구문을 확인해야 합니다.

다음을 입력하면 쉽게 할 수 있습니다.

sudo named-checkconf

구성에 구문 오류가 없으면 셸 프롬프트가 출력을 표시하지 않고 즉시 반환됩니다.

구성 파일에 구문 오류가 있는 경우 오류가 발생한 위치와 줄 번호에 대한 경고가 표시됩니다. 이런 일이 발생하면 돌아가서 파일에 오류가 있는지 확인하십시오.

구성 파일에 구문 오류가 없음을 확인했으면 Bind 데몬을 다시 시작하여 변경 사항을 구현합니다.

sudo service bind9 restart

그런 다음 클라이언트 시스템을 설정하는 동안 서버 로그를 주시하여 모든 것이 원활하게 진행되는지 확인하십시오. 이것을 서버에서 실행 상태로 두십시오.

sudo tail -f /var/log/syslog

이제 새 터미널 창을 열어 클라이언트 시스템을 구성하십시오.

클라이언트 시스템 구성

이제 서버를 가동하고 실행했으므로 쿼리에 이 DNS 서버를 사용하도록 클라이언트 시스템을 구성할 수 있습니다.

클라이언트 시스템에 로그인합니다. 사용 중인 클라이언트가 DNS 서버에 대해 설정한 ACL 그룹에 지정되었는지 확인하십시오. 그렇지 않으면 DNS 서버가 클라이언트에 대한 요청 처리를 거부합니다.

서버가 이름 서버를 가리키도록 /etc/resolv.conf 파일을 편집해야 합니다. 여기에서 변경한 사항은 재부팅할 때까지만 지속되므로 테스트하기에 좋습니다. 테스트 결과에 만족하면 이러한 변경 사항을 영구적으로 적용할 수 있습니다.

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

sudo nano /etc/resolv.conf

이 파일은 nameserver 지시문을 설정하여 쿼리를 해결하는 데 사용할 DNS 서버를 나열합니다. 현재 항목을 모두 주석 처리하고 DNS 서버를 가리키는 nameserver 줄을 추가합니다.

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

파일을 저장하고 닫습니다.

이제 몇 가지 일반적인 도구를 사용하여 쿼리가 올바르게 해결되는지 테스트할 수 있습니다.

ping을 사용하여 도메인에 연결할 수 있는지 테스트할 수 있습니다.

ping -c 1 google.com

PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

이것은 클라이언트가 DNS 서버를 사용하여 google.com에 연결할 수 있음을 의미합니다.

dig와 같은 DNS 관련 도구를 사용하여 더 자세한 정보를 얻을 수 있습니다. 이번에는 다른 도메인을 사용해 보세요.

dig linuxfoundation.org

; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.		IN	A

;; ANSWER SECTION:
linuxfoundation.org.	6017	IN	A	140.211.169.4

;; Query time: 36 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE  rcvd: 64

쿼리에 36밀리초가 걸렸음을 알 수 있습니다. 요청을 다시 하면 서버는 캐시에서 데이터를 가져와서 응답 시간을 줄여야 합니다.

dig linuxfoundation.org

; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.		IN	A

;; ANSWER SECTION:
linuxfoundation.org.	6012	IN	A	140.211.169.4

;; Query time: 1 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE  rcvd: 64

보시다시피 캐시된 응답이 훨씬 더 빠릅니다.

또한 dig의 -x 옵션을 사용하여 찾은 IP 주소(이 경우 140.211.169.4)를 사용하여 역방향 조회를 테스트할 수 있습니다.

dig -x 140.211.169.4

; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN	CNAME	4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN	PTR	load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE  rcvd: 117

보시다시피 역방향 조회도 성공합니다.

DNS 서버로 돌아가서 테스트 중에 오류가 기록되었는지 확인해야 합니다. 표시될 수 있는 한 가지 일반적인 오류는 다음과 같습니다.

. . .
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53

이는 서버가 IPv6 정보를 확인하려고 하지만 서버가 IPv6에 대해 구성되지 않았음을 나타냅니다. Bind에 IPv4만 사용하도록 지시하여 이 문제를 해결할 수 있습니다.

이렇게 하려면 sudo 권한으로 /etc/default/bind9 파일을 엽니다.

sudo nano /etc/default/bind9

내부에서 OPTIONS 매개변수를 수정하여 -4 플래그를 포함하여 IPv4 전용 동작을 강제합니다.

OPTIONS="-u bind -4"

파일을 저장하고 닫습니다.

서버를 다시 시작합니다.

sudo service bind9 restart

로그에 이러한 오류가 다시 표시되지 않아야 합니다.

클라이언트 DNS 설정을 영구적으로 만들기

앞에서 언급했듯이 클라이언트 시스템을 DNS 서버로 지정하는 /etc/resolv.conf 설정은 재부팅 후에도 유지되지 않습니다. 변경 사항을 마지막으로 적용하려면 이 파일을 생성하는 데 사용되는 파일을 수정해야 합니다.

클라이언트 시스템이 Debian 또는 Ubuntu를 실행 중인 경우 sudo 권한으로 /etc/network/interfaces 파일을 엽니다.

sudo nano /etc/network/interfaces

dns-nameservers 매개변수를 찾습니다. 기존 항목을 제거하고 DNS 서버로 바꾸거나 옵션 중 하나로 DNS 서버를 추가할 수 있습니다.

. . .
iface eth0 inet static
        address 111.111.111.111
        netmask 255.255.255.0
        gateway 111.111.0.1
        dns-nameservers 192.0.2.1
. . .

완료되면 파일을 저장하고 닫습니다. 다음에 부팅할 때 설정이 적용됩니다.

클라이언트가 CentOS 또는 Fedora를 실행 중인 경우 대신 /etc/sysconfig/network/network-scripts/ifcfg-eth0 파일을 열어야 합니다.

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

내부에서 DNS로 시작하는 줄을 찾습니다. DNS1을 DNS 서버로 변경합니다. 다른 DNS 서버를 폴백으로 사용하지 않으려면 다른 항목을 제거하십시오.

DNS1=192.0.2.1

완료되면 파일을 저장하고 닫습니다. 클라이언트는 다음 부팅 시 해당 설정을 사용해야 합니다.

결론

이제 클라이언트에 서비스를 제공하도록 구성된 캐싱 또는 전달 DNS 서버가 있어야 합니다. 이는 관리 중인 컴퓨터에 대한 DNS 쿼리 속도를 높이는 좋은 방법이 될 수 있습니다.

자신의 도메인 영역에 대해 신뢰할 수 있는 DNS 서버를 생성하려는 경우 신뢰할 수 있는 전용 DNS 서버를 구성하거나 이러한 솔루션을 결합할 수 있습니다.