DNS Resolver
1교시
배 아프다....
DNS Resolver 기능이 있는 Route 53의 사용법
-> 클라이언트와 네임 서버의 중계자 역할. DNS 요청을 네임 서버로 전달하며, DNS 응답을 클라이언트에게 전달
왜 필요한가? 외부 DNS Resolver가 있는데?
-> 고객사가 온프레미스에서 사용하던 서비스를 AWS로 옮겨왔더라도, 계속 온프레미스를 유지하는 서비스가 있을 수 있다.
-> 온프레미스(IDC)와 AWS 간 프라이빗 통신
- AWS 부하분산 - Route 53(DNS Resolver)
1. 프라이빗 호스팅 영역
AWS VPC 서비스로 생성한 하나 이상의 VPC 내에 있는 도메인과 그 하위 도메인에 대해 Route 53의 DNS 쿼리 응답 정보(DNS 정보가 담긴 일종의 zone 파일)가 담긴 컨테이너
-> 영역이 존재하면 DNS 해석기는 해당 영역에 쿼리를 보낸다.
-> 다수의 VPC가 1개의 프라이빗 호스팅 영역에 연결 가능
2. VPC DNS 옵션
- DNS resolution(DNS 확인) : AWS가 제공하는 DNS 해석기. 비활성화 시 AWS 제공 DNS 해석기 사용 불가.
- DNS hostname(DNS 이름) : AWS가 제공하는 Publoc/Private hostname. 비활성화 시 AWS 제공 hostname 사용 불가
회사 내부 도메인을 밖으로 노출시키지 않고 사용하고 싶은 것.
3. VPC DNS 고려 사항
퍼블릭 호스팅 영역 쿼리보다 프라이빗 호스팅 영역 쿼리를 우선시한다.
EC2 인스턴스는 Resolver에 초당 1024회의 요청을 보낼 수 있다.
하이브리드 환경에서 온프레미스와 AWS VPC 사이의 서로 간에 도메인 쿼리가 불가.
-> Route 53 Resolver와 전달 규칙을 사용해 쿼리 가능
-> Resolver 사용을 위해서는 VPC DNS 옵션인 DNS hostname/DNS resolution을 반드시 활성화해야 한다.
- 관련 용어
Route 53 Resolver : Route 53 해석기
Forwarding Rule : 전달 규칙. 다른 네트워크 환경에 도메인 쿼리를 하기 위한 정보
Inbound Endpoint : AWS VPC에 DNS 쿼리를 받을 수 있는 네트워크 인터페이스(ENI)
Outbound Endpoint : 전달 규칙을 다른 네트워크로 쿼리 할 수 있는 ENI
아웃바운드의 경우에는 반드시 전달 규칙을 생성하여 VPC를 연결해야 한다.
2~4교시
DNS 인스턴스 설정. 예전에도 어렵더니 여전히 어렵다.
왜 어렵겠냐 복습 제대로 안 해서지
- 일단 DNS 인스턴스에 bind 패키지를 설치해야 한다.
-> sudo yum -y install bind bind-util bind-libs
-> sudo systemctl start named
- /etc/named.conf
-> allow-query는 any로, options 아래 사진에 있는 내용을 추가하되, 사진의 환경은 우분투라 차이가 있으니 주의.
위 사진의 우분투 환경이 아닌 내가 했던 AWS 리눅스 환경에서는,
1. options 내부에 있는 listen-on port 53을 수정
-> DNS 인스턴스의 사설 주소를 쓰라는데, any도 상관없대서 any로 수정했다.
2. options 내부에 있는 allow-query를 any로 수정
3. options 내부에 있는 forward 관련 내용 추가
forwarders {
8.8.8.8;
};
forward only;
auth-nxdomain no;
4. 파일 하단에 zone 관련 내용 추가
zone "awsneta.internal" {
type forward;
forward only;
forwarders { 10.70.1.250; 10.70.2.250; };
};
zone "ap-northeast-2.compute.internal" {
type forward;
forward only;
forwarders { 10.70.1.250; 10.70.2.250; };
};
- /etc/named.rfc1912.zones
위 사진의 내용에서 상단의 블록만 추가해도 충분하다. 하단 블록은 역방향 용도.
type master;는 동일하지만 file의 내용은 해당 zone 파일의 이름을 적으면 된다. 기본 경로는 /var/named/ 다. 사진처럼 절대 경로를 적지 않아도 알아서 찾아간다.
이제 저 경로에 .zone 파일을 만들면 된다.
- zone 파일
존 파일은 기존의 것을 수정하는 것이 아니라 새로 만들어야 한다. 존 파일의 이름은 idc.zone이다.
첫 번째 블록은 기타 정보들이니 그냥 생각 없이 예전에 했던 것과 똑같이 적으면 된다.
ns 적는 것은 그냥 하는 것 같다. 아직 잘 이해가 안 간다.
아무튼 하단의 websrv와 dnssrv가 본론이다. 지정했던 사설 주소를 작성해 주면 된다.
※ sudo vim으로 생성했을테니 파일 생성 후 파일의 소유자:소유 그룹은 root:root로 되어 있는데, 이러면 작동하지 않는다. 소유자:그룹을 root:named로 수정한다.
-> sudo chown root:named /var/named/idc.zone
- 결과 확인하기 : IDC-WEBSRV에서 /etc/resolv.conf 파일 수정
DNS 설정 확인을 위해 같은 VPC의 다른 인스턴스에서 nslookup으로 확인
-> server 치면
-> websrv.idcneta.internal을 치면
안되길래 한참 찾았더니 위 /etc/resolv.conf 사진에서 보이듯, 10.80.1.200인데 10.80.0.200으로 적어서 그랬던 것이다.
에라이
DNS 인스턴스 구축에서 많은 교육생들이 어려워했다. 나도 예전에 기록해둔 것을 다시 봐도 조금 헷갈렸고.
오늘 다시 해보니 그나마 더 알겠다는 느낌인데...
5교시
5교시는 통으로 날아갔다. 기본 설정은 끝났고...
IDC-VPC2의 DHCP option 사용자 지정
-> 모든 VPC 내 서브넷의 첫 주소(0)는 네트워크, 두 번째 주소(1)는 외부로 나갈 용도, 세 번째 주소(2)는 자체 DNS 서버 주소.
-> 인스턴스가 생성될 때 자동 세팅되는 자체 DHCP 서버 주소의 기본값을 바꾸는 것
6교시
VPC 좌측의 DHCP 옵션 세트 > DHCP 옵션 세트 생성 > 정보 작성(이름 IDC-VPC2-DHCPOption/도메인 이름 idcneta.internal/도메인 이름 서버 10.80.1.200, 8.8.8.8/NTP 서버 203.248.240.140, 168.126.3.6), 나머지는 두고 생성
VPC > 설정할 VPC(IDC-VPC2) 체크 > 작업 > DHCP 옵션 세트 편집 > 생성했던 세트 선택해서 연결
이제 이 VPC에 인스턴스를 만들어 보면 기본 DNS 정보가 고정되어 있다.
여기까지 IDC-VPC 쪽 설정이 끝. 이제 AWS-VPC 쪽 설정
Route 53 > 호스팅 영역 생성 > 도메인 이름(awsneta.internal), 유형은 프라이빗, 리전과 VPC(AWS-VPC1) 선택 후 생성
레코드 2개 추가
정책은 단순 라우팅 > 단순 레코드 정의 > 레코드 유형은 A, 대상은 레코드 유형에 따른 IP 주소 또는 다른 값, 대상은 10.70.1.100과 10.70.2.100
VPC 좌측 목록의 피어링 연결 > 피어링 연결 생성 > 정보 작성(이름 작성, 요청자는 awsvpc, 수락자는 idcvpc) > 생성
-> 보안상 수락자 쪽에서 피어링 연결 수락을 해줘야 한다.
-> 같은 계정이니 그냥 체크하고 작업에서 요청 수락 클릭 후 수락
라우팅 테이블 편집
-> AWS-RT에는 10.80.0.0/16에 대한 피어링 연결, IDC-RT에는 10.70.0.0/16에 대한 피어링 연결 추가
사설 주소로 핑 테스트를 해보면 모두 통한다.
aws -> idc, aws <- idc 모두 핑 테스트 성공.
그런데 websrv.idcneta.internal로 핑을 날려 보면 안 먹힌다.
-> DNS 문제.
nslookup으로 들어가서 server 10.80.1.200을 실행한 뒤 websrv.idcneta.internal을 찾아보면 응답이 온다.
AWS-VPC의 인스턴스끼리 nslookup이 안 되는 것을 확인.
7~8교시
AWS-VPC의 작업 > DNS 호스트 이름 편집 > DNS 호스트 이름 활성화 체크
동일하게 DNS 확인도 체크 후 조금 기다리면 nslookup이 되는 것을 확인할 수 있다.
이제 도메인 통신이 가능하게 하기 위해 리졸버 인바운드 엔드포인트를 설정할 것이다.
IDC에서 AWS로 들어오는 통신을 가능하게 한다.
아웃바운드 엔드포인트는 AWS에서 밖으로 내보내는 용도.
일단 지금은 도메인으로 통신 불가.
Route 53 > 좌측 목록의 인바운드 엔드포인트 > 인바운드 엔드포인트 생성 > 이름 작성, VPC 선택(AWS-VPC), 보안 그룹 선택(DNS 열린 것으로), 그 아래 IP 주소 #1에서 가용 영역은 a, 서브넷 선택(AWS-VPC1-SN1), 지정한 IP 주소 사용 체크(IDC DNS에 작성했던 포워더 주소 10.70.1.250), #2에서는 영역 c, 서브넷 선택, 지정 IP 주소 사용 체크(10.70.2.250)
끝. 전송 클릭
생성이 끝나면 IDC-WEB 인스턴스에서
curl http://10.70.1.100 실행해서 확인, 도메인명으로도 확인
모두에게 인바운드 엔드포인트에서 도메인 해석이 되지 않는 상황 발생. IP 주소로는 통신 확인.
-> 일단 IDC-VPC에서는 DNS 확인과 DNS 호스트 이름을 비활성화해야 한다. 체크 해제.
-> IDC의 DNS 서버의 /etc/named.conf 파일에서
dnssec-enable no;
dnssec-validation no;
로 수정. 기본값은 yes다.
-> 통신 확인. 해결했다.
이번에는 아웃바운드 엔드포인트 생성
이름 작성, VPC 선택(AWS-VPC), DNS 열려있는 보안 그룹 선택 > 가용 영역, 서브넷 선택, 지정 주소 작성(10.70.1.251)
대충 인바운드 엔드포인트와 동일
생성 완료되면 좌측 해석기 > 규칙으로 이동
규칙 생성 > 이름 작성, 규칙 유형은 전달, 도메인 이름은 idcneta.internal, VPC는 AWS-VPC 선택, 아웃바운드 엔드포인트는 아까 만든 것 선택 > 대상 IP 주소는 10.80.1.200(DNS 서버)
끝. 전송
테스트를 위해 AWS 인스턴스 쪽에서 IDC 도메인을 curl로 확인
-> 성공.
DNS Resolver 쪽은 설정 방법보다는 흐름을 기억해야 한다.
내일은 CloudFront
오늘 DNS 소동으로 복습이 부족하다는 것을 다시 느꼈다.
하루에 지금까지 작성한 글 중 최소 1개의 글을 복습하자.
수업 중 DNS Resolver의 흐름 내용 추가로 정리하기(수업 막바지)
'교육' 카테고리의 다른 글
| [48일 차] 21.09.29 : AWS 8 (0) | 2021.09.29 |
|---|---|
| [47일 차] 21.09.28 : AWS 7 (0) | 2021.09.28 |
| [45일 차] 21.09.24 : AWS 5 (0) | 2021.09.24 |
| [44일 차] 21.09.23 : AWS 4 (0) | 2021.09.23 |
| [43일 차] 21.09.17 : AWS 3 (0) | 2021.09.22 |
댓글