소개
서버 구성 및 인프라를 관리하는 중요한 부분 중 하나는 이름으로 네트워크 인터페이스 및 IP 주소를 찾는 방법을 유지하는 것입니다. 이를 수행하는 한 가지 방법은 적절한 도메인 이름 시스템(DNS)을 설정하는 것입니다. IP 주소 대신 완전히 정규화된 도메인 이름(FQDN)을 사용하여 네트워크 주소를 지정하면 서비스 및 응용 프로그램의 구성을 최적화하고 구성 파일의 유지 관리성을 높일 수 있습니다. 사설 네트워크용 DNS를 설정하여 서버의 관리를 개선하는 것은 훌륭한 방법입니다.
이 자습서에서는 두 개의 Ubuntu 22.04 서버를 사용하여 내부 DNS 서버를 설정합니다. BIND 이름 서버 소프트웨어 (BIND9)를 사용하여 사설 호스트 이름과 사설 IP 주소를 해결합니다. 이렇게 하면 내부 호스트 이름과 사설 IP 주소를 중앙에서 관리할 수 있으며 환경이 몇 개 이상의 호스트로 확장될 때 필수적입니다.
전제 조건
이 자습서를 완료하려면 다음 인프라가 필요합니다. 각 서버를 동일한 데이터 센터 사설 네트워킹이 활성화된 위치에 생성하십시오:
- A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
- (권장 사항) 보조 DNS 서버로 사용할 두 번째 Ubuntu 22.04 서버, ns2.
- 적어도 하나의 추가 서버. 이 안내서는 클라이언트 서버로 참조될 두 개의 추가 서버가 있다고 가정합니다. 이러한 클라이언트 서버는 DNS 서버가 있는 데이터 센터와 동일한 위치에 만들어져야합니다.
이 서버 각각에서 관리자 sudo 사용자를 구성하고 Ubuntu 22.04 초기 서버 설정 안내서에 따라 방화벽을 설정하십시오.
DNS 개념이 익숙하지 않은 경우, 최소한 DNS 관리 소개의 처음 세 부분을 읽는 것을 권장합니다.
DigitalOcean에서 생성된 모든 새로운 드롭렛은 기본적으로 가상 사설 클라우드(VPC)에 배치됩니다. 자세한 내용은 VPC 제품 설명서를 확인하십시오.
예시 인프라 및 목표
이 문서의 목적을 위해 다음을 가정합니다:
- 두 개의 서버가 있으며 이를 DNS 이름 서버로 지정할 것입니다. 이 안내서에서는 ns1과 ns2로 참조합니다.
- 당신이 만들 DNS 인프라를 사용할 두 개의 추가 클라이언트 서버가 있습니다. 이 가이드에서는 host1 및 host2로 지칭됩니다. 필요한 만큼 많은 클라이언트 서버를 추가할 수 있습니다.
- 이 모든 서버는 동일한 데이터 센터에 있습니다. 이 튜토리얼에서는 이 데이터 센터를
nyc3이라고 가정합니다. - 이 모든 서버에는 개인 네트워킹이 활성화되어 있으며
10.128.0.0/16서브넷에 있습니다 (귀하의 서버에 대해 이를 조정해야 할 수 있습니다). - 모든 서버는
example.com에서 실행되는 프로젝트에 연결되어 있습니다. 이 가이드에서는 내부, 개인 DNS 시스템을 설정하는 방법에 대해 설명합니다. 따라서 공용 인터넷에서 지정된 도메인에 연결을 시도하지 않고 항상 먼저 내부적으로 요청을 라우팅하려고 합니다. 그러나 소유한 도메인을 사용하면 공개적으로 라우팅 가능한 도메인과의 충돌을 피할 수 있습니다.
이러한 가정을 바탕으로이 가이드의 예제에서는 예제 사설 서브넷 또는 영역을 참조하기 위해 하위 도메인 nyc3.example.com을 기반으로하는 명명 체계를 사용합니다. 따라서 host1의 개인 완전한 정규화된 도메인 이름(FQDN)은 host1.nyc3.example.com이 될 것입니다. 다음 표에는이 가이드 전체에서 사용되는 관련 세부 정보가 포함되어 있습니다:
| Host | Role | Private FQDN | Private IP Address |
|---|---|---|---|
| ns1 | Primary DNS Server | ns1.nyc3.example.com |
10.128.10.11 |
| ns2 | Secondary DNS Server | ns2.nyc3.example.com |
10.128.20.12 |
| host1 | Generic Host 1 | host1.nyc3.example.com |
10.128.100.101 |
| host2 | Generic Host 2 | host2.nyc3.example.com |
10.128.200.102 |
참고: 여러분의 설정은 다를 수 있지만, 예제 이름과 IP 주소는 내부 DNS를 구성하는 방법을 보여주기 위해 사용될 것입니다. 호스트 이름과 사설 IP 주소를 여러분의 것으로 대체하여 이 설정을 여러분의 환경에 맞게 조정할 수 있어야 합니다. 데이터 센터의 지역 이름을 네이밍 체계에 사용할 필요는 없지만, 여기에서는 이러한 호스트가 특정 데이터 센터의 사설 네트워크에 속한다는 것을 나타내기 위해 사용합니다. 여러 데이터 센터에서 서버를 실행하는 경우 각각의 데이터 센터 내에서 내부 DNS를 설정할 수 있습니다.
이 자습서를 따라하면 기본 DNS 서버 ns1 및 선택적으로 백업 역할을 하는 보조 DNS 서버 ns2를 갖게 될 것입니다.
이 자습서를 따를 때 이 설정에서 특정 서버에서 특정 명령을 실행해야 할 때가 있습니다. ns1에서 실행해야 하는 명령은 다음과 같이 파란색 배경으로 표시됩니다:
-
마찬가지로, ns2에서 실행해야 하는 명령은 다음과 같이 빨간색 배경으로 표시됩니다:
-
그리고 여러분의 클라이언트 서버 중 하나에서 실행해야 하는 명령은 다음과 같이 녹색 배경으로 표시됩니다:
-
여러 대의 서버에서 실행해야 하는 명령은 표준 해군 배경으로 표시됩니다:
-
마지막으로, 명령 또는 코드 블록에 이와 같이 강조된 텍스트가 포함되어 있는 경우 해당 텍스트가 중요하다는 의미입니다. 이러한 강조는 설정을 자체로 바꾸거나 구성 파일에 수정하거나 추가해야 하는 세부 정보를 나타내기 위해이 안내서 전체에 걸쳐 사용됩니다. 예를 들어, 예제에 host1.nyc3.example.com와 같은 내용이 포함된 경우 이를 자신의 서버의 FQDN으로 바꿉니다.
ns1 및 ns2에 BIND를 설치하여 시작합니다.
DNS 서버에 BIND 설치 단계 1
두 DNS 서버 ns1 및 ns2에서 다음을 입력하여 apt 패키지 캐시를 업데이트합니다.
- sudo apt update
그런 다음 각 기계에 BIND를 설치합니다.
- sudo apt install bind9 bind9utils bind9-doc
DigitalOcean의 개인 네트워킹은 전적으로 IPv4를 사용합니다. 사용하는 경우 BIND를 IPv4 모드로 설정하십시오. 두 서버 모두에서 기본 텍스트 편집기를 사용하여 named 기본 설정 파일을 편집합니다. 다음 예제에서는 nano를 사용합니다.
- sudo nano /etc/default/named
OPTIONS 매개 변수 끝에 -4를 추가합니다.
. . .
OPTIONS="-u bind -4"
작업을 마치면 파일을 저장하고 닫습니다. 파일 편집에 nano를 사용한 경우 CTRL + X, Y, 그런 다음 ENTER를 눌러서 닫을 수 있습니다.
BIND를 재시작하여 변경 사항을 적용하십시오:
- sudo systemctl restart bind9
이제 BIND가 설치되었으니 기본 DNS 서버를 구성해 봅시다.
단계 2 — 기본 DNS 서버 구성
BIND의 구성은 주 구성 파일 named.conf에서 포함된 여러 파일로 구성됩니다. 이 파일 이름은 BIND가 실행하는 프로세스 이름인 named으로 시작합니다 (named는 “도메인 이름 데몬”의 약어인 “namedaemon”의 줄임말입니다). 먼저 named.conf.options 파일을 구성하겠습니다.
옵션 파일 구성
ns1에서 편집을 위해 named.conf.options 파일을 엽니다:
- sudo nano /etc/bind/named.conf.options
기존의 옵션 블록 위에 새 ACL (액세스 제어 목록) 블록을 생성하고 trusted라고합니다. 여기에는 재귀 DNS 쿼리를 허용 할 클라이언트 목록을 정의합니다 (즉, ns1과 동일한 데이터 센터에있는 서버). 다음 라인을 추가하여 ns1, ns2, host1 및 host2를 신뢰하는 클라이언트 목록에 추가하십시오. 자신의 서버의 예제 개인 IP 주소로 대체하십시오:
acl "trusted" {
10.128.10.11; # ns1
10.128.20.12; # ns2
10.128.100.101; # host1
10.128.200.102; # host2
};
options {
. . .
신뢰할 수있는 DNS 클라이언트 목록이 준비되었으므로 옵션 블록을 편집할 수 있습니다. 현재 이 블록의 시작입니다:
. . .
};
options {
directory "/var/cache/bind";
. . .
}
디렉토리 지시문 아래에 강조 표시된 구성 라인을 추가하고 적절한 ns1 개인 IP 주소로 대체하십시오:
. . .
};
options {
directory "/var/cache/bind";
recursion yes; # enables recursive queries
allow-recursion { trusted; }; # allows recursive queries from "trusted" clients
listen-on { 10.128.10.11; }; # ns1 private IP address - listen on private network only
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .
};
포워더 블록에는 두 개의 IP 주소가 포함되어 있습니다: 8.8.8.8 및 8.8.4.4. 이 블록은 BIND가 외부 네임 서버로의 링크 트래픽을 줄이기 위해 사용하는 특수한 메커니즘 인 포워더를 정의합니다. BIND는 포워더를 사용하여 인터넷에 직접 액세스 할 수없는 서버의 쿼리를 허용할 수도 있습니다. 이는 지역 네트워크의 부하를 줄이는 데 도움이되어 이러한 쿼리에 대한 응답을 더 빠르게 할 수 있습니다.
이 블록의 두 개의 IP 주소는 Google의 공개 DNS 리졸버를 나타냅니다. 그러나 여기에서는 공개 재귀 이름 서버의 IP 주소를 사용할 수 있습니다. 예를 들어, Cloudflare의 DNS 서버의 IP 주소 (1.1.1.1)를 대신 사용할 수 있습니다.
작업이 완료되면 named.conf.options 파일을 저장하고 닫으십시오. 위의 구성은 당신의 DNS 서버에 외부 도메인에 대한 쿼리를 할 수 있는 것은 당신 자신의 서버인 trusted 서버들뿐이라는 것을 지정합니다.
다음으로, named.conf.local 파일을 구성하여 DNS 존을 지정합니다.
로컬 파일 구성하기
ns1에서 편집을 위해 named.conf.local 파일을 엽니다:
- sudo nano /etc/bind/named.conf.local
주석이 몇 개 있을 수 있지만, 파일은 비어 있습니다. 여기서는 전방 및 후방 존을 지정합니다. DNS 존은 DNS 레코드를 관리하고 정의하기 위한 특정 범위를 지정합니다. 이 안내서의 예제 도메인은 모두 nyc3.example.com 하위 도메인에 있을 것이므로 전방 존으로 사용하겠습니다. 예제 서버의 사설 IP 주소가 각각 10.128.0.0/16 IP 공간에 있기 때문에 다음 예제에서는 해당 범위 내에서 후방 조회를 정의할 수 있도록 후방 존을 설정합니다.
다음 줄을 사용하여 전방 존을 추가하고, 구역 이름을 자신의 것으로 바꾸고 allow-transfer 지시문에서 보조 DNS 서버의 사설 IP 주소를 대체합니다:
. . .
zone "nyc3.example.com" {
type primary;
file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary
};
우리의 사설 서브넷이 10.128.0.0/16인 것으로 가정하면, 다음 줄을 사용하여 후방 존을 추가합니다 (후방 존 이름이 10.128의 옥텟 반전인 128.10으로 시작하는 것에 유의하십시오):
. . .
};
zone "128.10.in-addr.arpa" {
type primary;
file "/etc/bind/zones/db.10.128"; # 10.128.0.0/16 subnet
allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary
};
서버가 여러 개의 개인 서브넷에 걸쳐 있지만 동일한 데이터 센터에 있는 경우 각각의 고유한 서브넷에 대해 추가적인 존 및 존 파일을 지정해야 합니다. 원하는 모든 존을 추가한 후에는 named.conf.local 파일을 저장하고 닫으십시오.
이제 BIND에 존이 지정되었으므로 해당하는 전방 및 후방 존 파일을 만들어야 합니다.
전방 존 파일 만들기
전방 존 파일은 전방 DNS 조회를 위한 DNS 레코드를 정의하는 곳입니다. 즉, DNS가 예를 들어 host1.nyc3.example.com에 대한 이름 조회를 받으면 전방 존 파일에서 host1에 해당하는 개인 IP 주소를 해결합니다.
존 파일이 위치할 디렉터리를 생성하십시오. named.conf.local 구성에 따르면 해당 위치는 /etc/bind/zones여야 합니다:
- sudo mkdir /etc/bind/zones
예제 전방 존 파일을 적절한 위치로 복사하십시오. 다음 명령어를 사용하여 복사합니다:
- sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com
이제 전방 존 파일을 편집하십시오:
- sudo nano /etc/bind/zones/db.nyc3.example.com
초기에는 다음과 같은 내용이 포함되어 있을 것입니다:
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line
먼저 SOA 레코드를 편집해야합니다. 첫 번째 localhost를 ns1의 FQDN으로 대체하고, root.localhost를 admin.nyc3.example.com으로 대체하십시오. 존 파일을 편집할 때마다 Serial 값을 증가시켜야하며, named 프로세스를 다시 시작하기 전에 증가시키십시오. 여기에서는 3으로 증가시키십시오.
. . .
;
$TTL 604800
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
다음으로, 파일 끝에 있는 세 개의 레코드를 삭제하십시오 (SOA 레코드 뒤에 있습니다). 어떤 줄을 삭제해야하는지 확실하지 않은 경우, 이전 예제에서 delete this line으로 표시된 주석을 확인하십시오.
파일 끝에 다음과 같은 라인으로 네임 서버 레코드를 추가하십시오 (이름은 직접 변경하십시오). 두 번째 열은 NS 레코드라는 것을 명시합니다:
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
이제 이 존에 속하는 호스트의 A 레코드를 추가하십시오. 이에는 .nyc3.example.com로 끝나는 서버의 이름을 사용하는 모든 서버가 포함됩니다 (이름과 사설 IP 주소를 대체하십시오). 예제 이름과 사설 IP 주소를 사용하여 다음과 같이 ns1, ns2, host1 및 host2에 대한 A 레코드를 추가하겠습니다:
. . .
; name servers - A records
ns1.nyc3.example.com. IN A 10.128.10.11
ns2.nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 - A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102
최종 예제 포워드 존 파일에는 다음과 같은 내용이 포함됩니다:
$TTL 604800
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
; name servers - A records
ns1.nyc3.example.com. IN A 10.128.10.11
ns2.nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 - A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102
db.nyc3.example.com 파일을 저장하고 닫으십시오.
이제 리버스 존 파일로 넘어갑시다.
리버스 존 파일 생성
리버스 존 파일은 리버스 DNS 조회를 위해 DNS PTR 레코드를 정의하는 곳입니다. 즉, DNS가 IP 주소로 쿼리를 받으면 예를 들어 10.128.100.101이라고 한다면 리버스 존 파일에서 해당하는 FQDN, 이 경우에는 host1.nyc3.example.com을 확인하기 위해 검색합니다.
ns1에서 named.conf.local 파일에서 지정된 각각의 리버스 존에 대해 리버스 존 파일을 생성합니다. 예제 리버스 존 파일은 db.127 존 파일을 기반으로 합니다. BIND는 이 파일을 로컬 루프백 인터페이스에 대한 정보를 저장하는 데 사용합니다. 127은 localhost(127.0.0.1)을 나타내는 IP 주소의 첫 번째 옥텟입니다. 다음 명령을 사용하여 해당 파일을 올바른 위치로 복사합니다(대상 파일 이름을 리버스 존 정의와 일치하도록 대체하십시오).
- sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128
named.conf.local에 정의된 리버스 존에 해당하는 리버스 존 파일을 편집합니다.
- sudo nano /etc/bind/zones/db.10.128
초기에 파일에는 다음과 같은 내용이 포함됩니다.
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
1.0.0 IN PTR localhost. ; delete this line
포워드 존 파일과 마찬가지로 SOA 레코드를 편집하고 시리얼 값을 증가시켜야 합니다.
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
이후 파일 끝에 있는 두 개의 레코드(즉, SOA 레코드 이후)를 삭제합니다. 어떤 줄을 삭제해야 하는지 확실하지 않다면, 이전 예제에서는 delete this line 주석으로 표시되어 있습니다.
파일 끝에 다음 줄을 사용하여 자신의 네임 서버 레코드를 추가합니다(이름을 자신의 것으로 바꿉니다). 두 번째 열은 이것이 NS 레코드임을 지정합니다.
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
그런 다음 편집 중인 영역 파일의 서브넷에 있는 IP 주소를 가진 모든 서버에 대해 PTR 레코드를 추가하세요. 우리 예제에서, 이것은 10.128.0.0/16 서브넷에 모두 있는 우리 호스트를 모두 포함합니다. 첫 번째 열은 서버의 개인 IP 주소의 마지막 두 옥텟을 역순으로 구성한다는 것을 주의하세요. 서버의 이름과 개인 IP 주소를 교체해 맞추세요:
. . .
; PTR Records
11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11
12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12
101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101
102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
최종 예제 역방향 영역 파일은 다음과 비슷할 것입니다:
$TTL 604800
@ IN SOA nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; name servers
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
; PTR Records
11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11
12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12
101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101
102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
역방향 영역 파일을 저장하고 닫으세요. 더 많은 역방향 영역 파일을 추가해야 하는 경우, 이 섹션을 반복하세요.
파일 편집을 마쳤으니, 다음으로 파일에 오류가 없는지 확인할 수 있습니다.
BIND 구성 문법 검사
named.conf* 파일의 문법을 검사하기 위해 다음 명령어를 실행하세요:
- sudo named-checkconf
named 구성 파일에 문법 오류가 없다면, 오류 메시지가 없을 것이고 쉘 프롬프트로 돌아갑니다. 구성 파일에 문제가 있는 경우, 오류 메시지와 기본 DNS 서버 구성 섹션을 검토한 후, named-checkconf를 다시 시도하세요.
named-checkzone 명령은 존 파일의 정확성을 확인하는 데 사용할 수 있습니다. 첫 번째 인수는 존 이름을 지정하고, 두 번째 인수는 해당 존 파일을 지정합니다. 이 둘은 모두 named.conf.local에서 정의됩니다.
예를 들어, nyc3.example.com 포워드 존 구성을 확인하려면 다음 명령을 실행합니다(포워드 존과 파일 이름을 맞추십시오):
- sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
Outputzone nyc3.example.com/IN: loaded serial 3
OK
그리고 128.10.in-addr.arpa 리버스 존 구성을 확인하려면 다음 명령을 실행합니다(리버스 존과 파일 이름을 맞추십시오):
- sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
모든 구성 및 존 파일에 오류가 없으면 BIND 서비스를 다시 시작할 준비가되었습니다.
BIND 다시 시작
BIND 다시 시작:
- sudo systemctl restart bind9
UFW 방화벽을 구성한 경우 BIND에 대한 액세스를 열려면 다음을 입력하십시오:
- sudo ufw allow Bind9
기본 DNS 서버가 설정되어 DNS 쿼리에 응답할 준비가되었습니다. 이제 보조 DNS 서버를 구성하겠습니다.
단계 3 — 보조 DNS 서버 구성
대부분의 환경에서는 기본 DNS 서버가 사용 불가능해지면 대체 DNS 서버를 설정하는 것이 좋은 아이디어입니다. 다행히도, 대체 DNS 서버를 구성하는 것은 기본 서버를 설정하는 것보다 훨씬 복잡하지 않습니다.
ns2에서 named.conf.options 파일을 편집하십시오:
- sudo nano /etc/bind/named.conf.options
파일 상단에 신뢰하는 모든 서버의 사설 IP 주소를 사용하여 ACL을 추가하십시오:
acl "trusted" {
10.128.10.11; # ns1
10.128.20.12; # ns2
10.128.100.101; # host1
10.128.200.102; # host2
};
options {
. . .
directory 지시문 아래에 다음 라인을 추가하십시오:
. . .
recursion yes;
allow-recursion { trusted; };
listen-on { 10.128.20.12; }; # ns2 private IP address
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .
named.conf.options 파일을 저장하고 닫으십시오. 이 파일은 ns1의 named.conf.options 파일과 동일해야 하지만 ns2의 사설 IP 주소로 구성되어야 합니다.
이제 named.conf.local 파일을 편집하십시오:
- sudo nano /etc/bind/named.conf.local
기본 DNS 서버의 기본 존에 해당하는 보조 존을 정의하십시오. 유형이 secondary이고 파일에 경로가 없으며, 기본 DNS 서버의 사설 IP 주소로 설정해야 하는 primaries 지시문이 있습니다. 기본 DNS 서버에서 여러 역존을 정의한 경우 모두 여기에 추가해야 합니다:
zone "nyc3.example.com" {
type secondary;
file "db.nyc3.example.com";
primaries { 10.128.10.11; }; # ns1 private IP
};
zone "128.10.in-addr.arpa" {
type secondary;
file "db.10.128";
primaries { 10.128.10.11; }; # ns1 private IP
};
이제 named.conf.local 파일을 저장하고 닫으십시오.
구성 파일의 유효성을 확인하려면 다음 명령을 실행하십시오:
- sudo named-checkconf
이 명령이 오류를 반환하지 않으면 BIND를 다시 시작하십시오:
- sudo systemctl restart bind9
그런 다음 UFW 방화벽 규칙을 변경하여 서버로의 DNS 연결을 허용하십시오:
- sudo ufw allow Bind9
그렇게 하면 이제 사설 네트워크 이름 및 IP 주소 해결을 위한 주요 및 보조 DNS 서버가 있습니다. 이제 클라이언트 서버를 구성하여 사설 DNS 서버를 사용하도록 설정해야 합니다.
DNS 클라이언트 구성 단계 4
신뢰하는 trusted ACL의 모든 서버가 DNS 서버를 쿼리하려면 각각을 ns1 및 ns2로 설정해야 합니다.
클라이언트 서버가 Ubuntu에서 실행 중인 경우 개인 네트워크와 연결된 장치를 찾아야 합니다. 이를 위해 각 클라이언트 머신에서 ip address 명령으로 개인 서브넷을 쿼리할 수 있습니다. 다음 명령을 각 클라이언트 머신에서 실행하여 각 클라이언트 서버가 사용하는 개인 DNS 서버로 설정합니다. 강조된 서브넷을 자체 서브넷으로 바꿔 실행합니다:
- ip address show to 10.128.0.0/16
Output3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
altname enp0s4
altname ens4
inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
valid_lft forever preferred_lft forever
이 예에서 개인 인터페이스는 eth1입니다. 이 섹션 전체의 예에서는 개인 인터페이스를 eth1로 참조하지만 귀하의 서버의 개인 인터페이스를 반영하도록 이러한 예를 변경해야 합니다.
Ubuntu 22.04에서 네트워킹은 Netplan을 사용하여 구성되며, 표준화된 네트워크 구성을 작성하고 호환되는 백엔드 네트워킹 소프트웨어에 적용할 수 있는 추상화입니다. DNS를 구성하려면 Netplan 구성 파일을 작성해야 합니다.
/etc/netplan에 00-private-nameservers.yaml라는 새 파일을 만듭니다:
- sudo nano /etc/netplan/00-private-nameservers.yaml
내부에서 다음 내용을 추가하십시오. 사설 네트워크의 인터페이스를 수정하고, ns1 및 ns2 DNS 서버의 주소, 그리고 DNS 영역을 수정해야 합니다:
참고: Netplan은 구성 파일에 YAML 데이터 직렬화 형식을 사용합니다. YAML은 들여쓰기와 공백을 사용하여 데이터 구조를 정의하므로 일관된 들여쓰기를 사용하여 오류를 피하십시오.
network:
version: 2
ethernets:
eth1: # Private network interface
nameservers:
addresses:
- 10.128.10.11 # Private IP for ns1
- 10.132.20.12 # Private IP for ns2
search: [ nyc3.example.com ] # DNS zone
작업이 완료되면 파일을 저장하고 닫으십시오.
이제 새 구성 파일을 사용하도록 Netplan에 지시하려면 netplan try를 사용하십시오. 네트워킹 손실을 유발하는 문제가 있으면 Netplan은 제한 시간이 경과한 후 변경 사항을 자동으로 롤백합니다:
- sudo netplan try
OutputWarning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds
하단에서 카운트다운이 올바르게 업데이트되는 경우, 새 구성은 적어도 SSH 연결을 끊지 않고 작동합니다. 새 구성을 수락하려면 ENTER를 누르십시오.
이제 시스템의 DNS 리졸버를 확인하여 DNS 구성이 적용되었는지 확인하십시오:
- sudo resolvectl status
내부 네트워크 인터페이스 섹션을 찾을 때까지 스크롤하여 DNS 서버의 사설 IP 주소가 먼저 나열되어 있어야 하며, 일부 대체 값이 뒤를 따라야 합니다. 도메인은 DNS Domain 뒤에 나와야 합니다:
Output. . .
Link 3 (eth1)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
DNS Domain: nyc3.example.com
Ubuntu 클라이언트는 이제 내부 DNS 서버를 사용하도록 구성되었습니다.
단계 5 — 클라이언트 테스트
nslookup을 사용하여 클라이언트가 이름 서버에 쿼리를 할 수 있는지 테스트합니다. 구성하고 있는 모든 클라이언트에서 이 작업을 수행할 수 있어야 합니다. 그리고 이들은 trusted ACL에 있어야 합니다.
먼저 전방 조회를 수행할 수 있습니다.
전방 조회
host1.nyc3.example.com의 IP 주소를 검색하려면 다음 명령을 실행합니다:
- nslookup host1
host1을 쿼리하면 search 옵션으로 개인 서브도메인이 설정되어 있기 때문에 host1.nyc3.example.com으로 확장됩니다. DNS 쿼리는 이 서브도메인을 찾은 후 호스트를 다른 곳에서 찾습니다. 이전 명령은 다음과 같은 출력을 반환합니다:
OutputServer: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: host1.nyc3.example.com
Address: 10.128.100.101
다음으로 역방향 조회를 확인할 수 있습니다.
역방향 조회
역방향 조회를 테스트하려면 host1의 개인 IP 주소로 DNS 서버에 쿼리를 날립니다:
- nslookup 10.128.100.101
이는 다음과 같은 출력을 반환해야 합니다:
Output11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.
Authoritative answers can be found from:
모든 이름과 IP 주소가 올바른 값으로 해석되면, 당신의 존 파일이 올바르게 구성된 것입니다. 예기치 않은 값이 반환되면, 주 DNS 서버(db.nyc3.example.com 및 db.10.128 같은)에서 존 파일을 검토해야 합니다.
마지막 단계로, 이 튜토리얼에서는 존 레코드를 유지하는 방법에 대해 설명하겠습니다.
단계 6 — DNS 레코드 유지하기
이제 작동하는 내부 DNS를 갖고 있으므로, DNS 레코드를 유지하여 서버 환경을 정확하게 반영해야 합니다.
DNS에 호스트 추가하기
환경에 호스트를 추가할 때마다(동일한 데이터 센터 내), DNS에 추가해야 합니다. 수행해야 할 단계 목록은 다음과 같습니다:
기본 이름 서버
- 전방 존 파일: 새 호스트에 대한
A레코드를 추가하고,Serial값 증가 - 역순 존 파일: 새 호스트에 대한
PTR레코드를 추가하고,Serial값 증가 - 새 호스트의 사설 IP 주소를
trustedACL(named.conf.options)에 추가
구성 파일을 테스트하세요:
- sudo named-checkconf
- sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
- sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
재로드 BIND:
- sudo systemctl reload bind9
이제 기본 서버는 새 호스트로 구성되어야 합니다.
보조 이름 서버
trustedACL (named.conf.options)에 새 호스트의 사설 IP 주소를 추가하세요.
구성 구문을 확인하세요:
- sudo named-checkconf
그런 다음 BIND를 다시로드하세요:
- sudo systemctl reload bind9
보조 서버는 이제 새 호스트로부터의 연결을 허용합니다.
새 호스트를 DNS에 사용하도록 구성하세요.
/etc/resolv.conf를 사용하여 DNS 서버를 설정하세요.nslookup을 사용하여 테스트하세요.
DNS에서 호스트 제거
환경에서 호스트를 제거하거나 DNS에서 제거하려면 DNS에 서버를 추가할 때 추가된 모든 항목을 제거하세요(즉, 이전 단계의 반대).
결론
지금부터는 IP 주소가 아닌 이름으로 서버의 개인 네트워크 인터페이스를 참조할 수 있습니다. 이렇게 하면 개인 IP 주소를 기억할 필요가 없어서 서비스 및 응용 프로그램을 구성하는 것이 더 간단해지며, 파일을 읽고 이해하기가 덜 어려워집니다. 또한 이제 구성을 새로운 서버를 가리키도록 변경할 수 있으며, 기존에는 여러 개의 분산 구성 파일을 편집해야 했지만 이제는 기본 DNS 서버 하나만 수정하면 되므로 유지 관리가 최적화됩니다.
내부 DNS를 설정하고 구성 파일이 네트워크 연결을 지정하기 위해 개인 FQDN을 사용하도록 설정한 후에는 DNS 서버가 올바르게 유지되어야 합니다. 둘 다 사용 불가능해지면 이에 의존하는 서비스 및 응용 프로그램이 제대로 작동하지 않을 수 있습니다. 이것이 DNS를 적어도 하나의 보조 서버로 설정하고 모두의 작동 백업을 유지하는 것이 권장되는 이유입니다.
DNS에 대해 더 자세히 알고 싶다면, 당사의 기사 DNS 용어, 구성 요소 및 개념 소개를 확인하는 것을 권장합니다.