sehee

특정 도메인을 담당하는 적절한 네임 서버로 DNS 쿼리를 전달하는 과정에서 DNS 쿼리를 해결하는 데 필수적인 권한 있는 네임 서버의 이름을 확인하기 위해 NS(네임 서버) 레코드를 참조한다.
이 특정 도메인에 대한 권한은 다른 네임 서버에 위임할 때 도메인의 권한 있는 네임 서버(실제 DNS 레코드를 갖고 있는 서버)인지 확인하기 위해 필요하며, 
해당 도메인이 신뢰할 수 있는지 확인하기 위해 각 도메인마다 DNS 레코드 관리를 담당하는 네임 서버가 존재한다.

예를 들어, 아래와 같이 'example.com'에서 레코드명 'sub.example.com'의 NS 레코드가 생성된 상태에서, 권한 있는 'sub.example.com' 도메인의 호스팅 영역을 찾기 위해 네임 서버가 아래와 같은 'sub.example.com' 호스팅 영역을 조회한다.

이 때, 하위 도메인 'sub.example.com'에 대한 네임 서버 변경이 가능한 경우 도메인의 고유한 권한을 확인할 수 없으므로, 상위 도메인 'example.com'의 'sub.example.com'에 대한 NS 레코드를 일치시켜야 한다.

References:

DNS에서 NS(이름 서버) 레코드의 기능은 무엇입니까? - https://ko.eitca.org/cybersecurity/eitc-is-wsa-windows-server-administration/system-administration-in-windows-server/resource-record-types/examination-review-resource-record-types/what-is-the-function-of-a-name-server-ns-record-in-dns/

VPC DNS resolver 우선 순위

0. DNS firewall (R53 전용 Network Firewall)

1. Route 53 Resolver 규칙
   - 명시적으로 정의된 Outbound 규칙
   - 도메인 기반 포워딩 규칙

2. Private Hosted Zone
   - VPC와 연결된 프라이빗 호스팅 영역

$ dig example.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13.9 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63355
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
saraheee.site.          900     IN      SOA     ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 1 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Thu Feb 06 07:15:42 UTC 2025
;; MSG SIZE  rcvd: 129

3. Default VPC Resolver
   - VPC의 기본 .2 리졸버

$ cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search anycompany.corp
nameserver 192.168.2.250
nameserver 192.168.0.2

4. Public DNS resolve 시도 (Route 53 Public Hosted Zone 포함)

$ dig example.com
; <<>> DiG 9.18.28 <<>> example.com;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6753
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
saraheee.site.          30      IN      A       8.8.8.8

;; Query time: 1610 msec
;; SERVER: 10.0.0.2#53(10.0.0.2) (UDP)
;; WHEN: Thu Feb 06 07:15:47 UTC 2025;; MSG SIZE  rcvd: 58

아웃바운드 엔드포인트가 구성된 Resolver 규칙이 있는 경우, 프라이빗 호스팅 영역과 동일한 VPC에 연결되어 있을 때 리졸버 규칙이 우선적으로 적용될 수 있다.

다만 Private hosted zone이 VPC 내부에서만 작동하는 DNS라, dig +trace 시 공개적인 DNS 해석 과정이 포함된 root DNS와는 독립적으로 작동한다.

Route 53 - Routing Policies

라우팅 정책은 Route 53가 DNS 쿼리에 응답하는 것을 도움, DNS 관점(DNS는 트래픽 라우팅하지 않음, 트래픽은 DNS를 통과하지 않음)
- 로드 밸런서가 트래픽을 백엔드 EC2 인스턴스에 라우팅하는 것과는 다름
- DNS는 DNS 쿼리에만 응답하게 되고 클라이언트들은 이를 통해 HTTP 쿼리 등을 어떻게 처리해야 하는지를 알 수 있게 됨
- DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 도움
Route 53이 지원하는 라우팅 정책: 단순, 가중치 기반, 장애 조치, 지연 시간 기반, 지리적, 다중 값 응답, 지리 근접 라우팅 정책
(Simple, Weighted, Failover, Latency based, Geolocation, Multi-Value Answer, Geoproximity (using Route 53 Traffic Flow feature)

Routing Policies - Simple

트래픽을 단일 리소스로 보내는 방식
클라이언트가 foo.example.com으로 가고자 한다면 Route 53이 IP 주소를 알려주는 것 (A 레코드 주소)
동일한 레코드에 여러 개의 값을 지정하는 것도 가능함. DNS에 의해 다중 값을 받은 경우에는 클라이언트 쪽에서 그 중 하나를 무작위로 고르게 됨 (e.g., 클라이언트가 foo.example.com으로 가기를 요청하고, Route 53은 세 개의 IP 주소로 답할 때(A 레코드에 임베딩된 주소), 클라이언트가 셋 중 하나를 골라 라우팅에 적용함)
단순 라우팅 정책에 별칭 레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있음 - 그렇기 때문에 상태 확인은 불가

Hands-on#04. Simple

value IP 추가하면서 테스트

Routing Policies - Weighted

가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능
한 DNS 이름 하에 있는 다른 레코드들과 비교했을 때 해당 레코드로 트래픽을 얼마나 보낼지, 각 레코드에 상대적으로 가중치를 할당함
이렇게 하면 DNS 레코드들은 동일한 이름과 유형을 가져야 하고 상태 확인과도 관련될 수 있음
사용되는 경우: 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때, 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우
- 가중치 0의 값을 보내게 되면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있음
- 만약 모든 리소스 레코드 가중치의 값이 0인 경우는 모든 레코드가 다시 동일한 가중치를 갖게 됨

Hands-on#05. Weighted

Record ID: 가중치 레코드 설정에서 이 특정 레코드를 식별하기 위해 사용됨
- simple 레코드는 여러 개의 IP 주소를 가진 반면 weighted 세 개의 레코드는 각각 하나의 값을 가짐

Routing Policies - Latency-based

지연 시간이 가장 짧은, 가장 가까운 리소스로 리다이렉팅하는 정책
지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우 유용한 정책
지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정
(e.g., 유저가 독일에 있고 미국에 있는 리소스의 지연 시간이 가장 짧다면, 해당 유저는 미국으로 리다이렉팅이 될 것)
- 두 개의 다른 리전에 애플리케이션을 배포할 때

Hands-on#06. Latency-based

별칭이 해당 IP가 어느 지역에 있는 EC2 인스턴스에서 왔다는 것을 알 수 없기 때문에,
값에 IP 주소를 입력해도 이 IP의 리전을 표시해줘야 함

Route 53 - Health Checks

상태 확인은 공용 리소스에 대한 상태를 확인하는 방법
e.g., (다중 지역 셋업) 서로 다른 두 지역에 하나씩 로드 밸런서가 있고 둘은 모두 공용 로드 밸런서임, 그리고 그 둘의 뒤에서 애플리케이션이 작동 중 - 지역 레벨에서 고가용성을 원하는 상황
- Route 53을 이용해 DNS 레코드를 만들 것
- 유저가 mydomain.com과 같은 URL을 이용해 접속하면 해당 유저는 가장 가까운 로드 밸런서로 연결됨 (지연 시간 기반 레코드)
만약 한 지역이 사용 불가능 상태면 유저를 보내고 싶지 않기 때문에 Route 53에서 상태 확인을 생성해야 함
- 두 지역의 상태 확인을 Route 53의 레코드와 연결할 수 있음 (DNS의 장애 조치를 자동화하기 위한 작업)
세 가지의 상태 확인(Health Check)이 가능함
- 각 상태 확인은 각자의 메트릭을 사용하는데 CloudWatch의 지표에서도 확인 가능
1) 공용 엔드 포인트를 모니터링하는 상태 확인
- 애플리케이션, 서버, 다른 AWS 리소스
2) 다른 상태 확인을 모니터링하는 상태 확인 (계산된 상태 확인)
3) CloudWatch 경보의 상태를 모니터링하는 상태 확인
- 제어가 쉽고 개인 리소스들에 유용함

Health Checks - Monitor an Endpoint

ALB에 대한 특정 지역의 상태 확인을 한다고 하면, 전 세계로부터 15개 정도의 AWS 상태 확인이 옴
→ 우리가 루트를 설정한 공용 엔드 포인트로 모두 요청을 보냄
→ 엔드 포인트의 상태를 확인하고 임계값을 정상 혹은 비정상으로 설정함 (200 OK 코드 또는 우리가 정의한 코드를 받으면 리소스는 정상으로 간주됨)
- 간격: 30초마다 정기적으로 확인 혹은 10초마다(더 높은 비용)
- 지원 프로토콜: HTTP, HTTPS, TCP
- 18% 이상의 상태 확인이 엔드 포인트를 정상이라고 판단하면 Route 53도 이를 정상이라고 간주함
- 상태 확인에 사용될 위치 선택 가능
- 로드 밸런서로부터 2xx나 3xx의 코드를 받아야만 통과가 됨
텍스트 기반 응답일 경우 상태 확인은 응답의 처음 5120 byte를 확인함 (응답 자체에 해당 텍스트가 있는지 보기 위해)
상태 확인의 작동이 가능하려면 상태 확인이 ALB나 엔드 포인트에 접근이 가능해야 함
Route 53의 상태 확인 IP 주소 범위에서 들어오는 모든 요청을 허용해야 함 (주소 범위는 https://ip-ranges.amazonaws.com/ip-ranges.json 참고)

Route 53 - Calculated Health Checks

여러 개의 상태 확인 결과를 하나로 합쳐주는 기능
- 조건: OR, AND, NOT
하위 상태 확인을 256개까지 모니터링할 수 있고 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있음
→ 상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트를 유지 관리하도록 하는 경우

Health Checks - Private Hosted Zones

개인의 리소스를 모니터링하는 것은 어려울 수 있음
Route 53 상태 확인이 공용 웹에 있기 때문에 health checkers는 VPC 외부에 있음
개인 엔드 포인트에 접근 불가능 (개인 VPC나 온프레미스 리소스)
그래서 CloudWatch 지표를 만들어 CloudWatch 알람을 할당하는 식으로 이 문제를 해결할 수 있음
→ CloudWatch 경보를 상태 확인에 할당할 수 있음 (CloudWatch 메트릭을 이용해 개인 서브넷 안에 있는 EC2 인스턴스를 모니터링하는 것)
메트릭이 침해되는 경우 CloudWatch 알람을 생성하게 되고, 알람이 ALARM 상태가 되면 상태 확인은 자동으로 비정상이 됨
→ 개인 리소스에 대한 상태 확인 완료

Hands-on#07. Health Check

1) 엔드 포인트가 될 region 인스턴스의 상태 확인을 생성 (세 리전 모두)
path: /health (엔드 포인트 자체의 상태에 대한 응답)
Advanced configuration: String matching - 첫 5120 바이트 문자열을 비교할지 여부를 선택
2) 특정 region에 있는 한 인스턴스의 보안 그룹에서 80번 포트를 차단하고 security groups의 HTTP 관련 rule을 삭제 (상태 확인 장애를 발생시킴)
3) create health check - name: calculated / status of other health checks (calculated health check)
4) create health check - state of CloudWatch alarm
- 개인 EC2 인스턴스의 상태를 모니터링할 수 있음
- 개인 리소스의 상태 확인을 Route 53 상태 확인에 연결하는 것

Routing Policies - Failover (Active-Passive)

장애 조치에 관한 것
Route 53에 대해 하나는 기본 EC2 인스턴스, 하나는 보조 EC2 인스턴스(재해 복구 EC2 인스턴스)일 때
상태 확인과 기본 레코드를 연결하는데 필수적
상태 확인이 비정상이면 자동으로 Route 53은 두번째의 EC2 인스턴스로 장애 조치하며 결과를 보내기 시작함
보조 EC2 인스턴스도 상태 확인을 연결할 수 있지만 기본과 보조가 각각 하나씩만 있을 수 있음
→ 클라이언트의 DNS 요청은 정상으로 생각되는 리소스를 자동으로 얻음

Hands-on#08. Failover

상태 확인을 통해 장애 조치 레코드를 생성 (호스팅 영역에서 레코드를 생성)
보안 그룹 수정하여 장애 조치가 실행되는 위치를 확인

Routing Policies - Geolocation

사용자의 실제 위치를 기반으로 함 (지연 시간 기반의 정책과는 다르게)
사용자가 특정 대륙이나 국가 또는 어떤 주에 있는지 지정하는 것이며, 가장 정확한 위치가 선택되어 그 IP로 라우팅되는 것
일치하는 위치가 없는 경우는 기본 레코드를 생성해야 함
사용 사례: 콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트 현지화
- 상태 확인과 연결할 수 있음
e.g., 유럽의 지도에서, 독일의 유저가 독일어 버전의 앱을 포함한 IP로 접속되도록 독일의 지리 레코드를 정의할 수 있음, 프랑스는 프랑스어의 버전의 앱을 가진 IP로 가야 함, 그 외의 다른 곳은 앱에서 영어 버전이 포함된 기본 IP로 이동해야 함

Hands-on#09. Geolocation

Location이 다른 IP에 대해 테스트

Geoproximity Routing Policy

사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅함
이 정책으로 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동하는 것
→ 지리적 위치를 변경하려면 편향값을 지정해야 함, 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 됨, 리소스에 트래픽을 줄이려면 편향값을 음수로 축소시키면 됨
리소스는 AWS의 리소스로 속한 특정 리전을 지정하면 목록에서 자동으로 올바른 라우팅을 계산하거나, AWS 리소스가 아닌 온프레미스 데이터 센터의 경우 위도와 경도를 지정해서 AWS가 위치를 파악하도록 해야 함
기능을 선택하는데 편향 활용을 위해 고급 Route 53 트래픽 플로우를 사용함
- 편향이 없다면, 사용자 위치에서 가장 가까운 리소스 리전으로 이동하는 것
- 편향으로 인해 다른 방식으로 사용자를 다른 리전으로 라우팅할 수 있음, 편향으로 해당 리소스에 더 많은 사용자와 트래픽이 발생함 (편향이 높을 경우)
예를 들어, 전 세계로 리소스를 설정하고 특정 리전에 더 많은 트래픽을 더 보내야 한다고 하면 지리 근접 라우팅 정책을 사용해 특정 리전의 편향을 증가시키면 더 많은 사용자가 생기게 되고 특정 리전에 더 많은 트래픽이 발생하게 됨
- 지리 근접 라우팅은 편향을 증가시켜 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다는 것

Routing Policies - IP-based Routing

클라이언트 IP 주소를 기반으로 라우팅을 정의함 → Route 53에서 CIDR 목록을 정의함 (클라이언트 IP 범위) → CIDR에 따라 트래픽을 어느 로케이션으로 보내야 하는지를 정함
- 이것을 사용하면 성능을 최적화할 수 있음, IP를 미리 알고 있기 때문
- 네트워크 비용을 절감할 수 있음, IP가 어디에서 오는지 알기 때문
예를 들어 특정 ISP가 특정 IP 주소 셋을 사용하는걸 안다면 특정 엔드포인트로 라우팅할 수 있음
e.g., Route 53에서 두 로케이션을 서로 다른 두 CIDR 블록으로 정의함 (location-1: 203.x.x.x/24, location-2: 200.x.x.x/24)
→ 로케이션을 레코드에 연결 (record name: example.com / value: 1.2.3.4 and 5.6.7.8 / IP-based: location1 and location2)
- 이 값들은 두 개의 EC2 인스턴스의 공용 IP를 나타냄
→ 사용자 A가 location-1 CIDR blocks에 속하는 특정 IP로 들어오면 첫번째 EC2 인스턴스인 IP 1.2.3.4로 보내짐
+ 사용자 B가 location-2에 속하는 IP 주소로 들어오면 리디렉션되어 IP 5.6.7.8의 EC2 인스턴스에 대한 DNS 쿼리 응답을 받게 됨

Routing Policies - Multi-Value

- 트래픽을 다중 리소스로 라우팅할 때 사용함, 그래서 Route 53은 다중 값과 리소스를 반환함
- 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있음
- 각 다중 값 쿼리에 최대 8개의 정상 레코드가 반환됨
- ELB와 유사해 보이지만 ELB를 대체할 수는 없음 (클라이언트 측면의 로드 밸런싱)
e.g., example.com에서 다중 A 레코드를 설정하고 상태 확인과 연결함
클라이언트에서 다중 값 쿼리를 실행하면 최대 8개의 레코드를 수신하게 되고 클라이언트는 하나를 선택함, 하지만 최소한 상태 확인과 결합하면 반환되는 8개 레코드 중 1개 혹은 최대 8개의 레코드가 정상일 것을 알고 있음
그래서 클라이언트는 안전한 쿼리를 가질 수 있음
e.g., 다중 값이 있는 단순한 라우팅의 경우에는 단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있음, 이것이 다중 값이 조금 더 강력한 레코드 유형인 이유

Hands-on#10. Multi-Value

세 리전에 대한 multi
Health checks에서 Invert health check status 체크하여 정상에서 비정상으로 변경

Domain Registar vs. DNS Service

도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구매할 수 있음, 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공함, 그래서 Amazon 호스트 이름으로 DNS 이름을 등록했다면 DNS 레코드 관리를 위한 Route 53 호스팅 존을 가짐
도메인 이름을 등록하면 네임 서버 옵션이 생기는데 사용자 정의 이름 서버를 지정할 수 있음 (Route 53에서 원하는 도메인의 공용 호스팅 영역을 생성하고 호스팅 영역 상세의 우측 네임 서버를 구매한 사이트(GoDaddy 등)에서 변경해야 함)
GoDaddy에서 사용할 이름 서버에 관한 쿼리에 응답하면 네임 서버가 Amazon의 Route 53 이름 서버를 가리키고 그렇게 Route 53을 사용해서 해당 콘솔에서 직접 전체 DNS 레코드를 관리함
- 정리: 도메인을 타사 등록 대행사에서 구매해도 DNS 서비스 제공자로 Route 53을 사용 가능한데, 사용하려면 Route 53에서 공용 호스팅 영역을 생성한 뒤 도메인을 구매한 타사 웹사이트에서 NS 혹은 이름 서버를 업데이트하면 Route 53 이름 서버를 가리키게 됨
→ 도메인 이름 레지스트라는 모두 비슷해 보이지만 DNS 서비스가 다름

References

Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 10: Route 53

Topics

What is VPC?

AWS Service scope with respect to Region, AZ and VPC

AWS Services inside and outside of VPC

VPC Addressing (CIDR)

VPC Subnets and Route Tables (Public/Private)

IP Addresses (IPv4, IPv6, Private/Public/Elastic)

Security Groups and Network ACL

NAT gateway and NAT instance

Transit Gateway: 2018년 출시한 네트워킹 라우터

VPC의 서브넷: 개별 LAN 네트워크, VPC로부터의 작은 주소 범위

서브넷이 사용자 지정 route table을 생성하여 Main Route Table을 따르지 않으면, 두 다른 AZ의 서브넷이 Local Router를 통해 연결할 수 없음

VPC의 모든 서브넷이 같은 종류의 네트워크 연결을 원할 경우 메인 루트 테이블 수정

Amazon에서 제공하는 IPv6 DNS가 없음

Security groups are stateful

Network Access Control List(NACL):

1) works at Subnet level

2) Stateless(inbound/outbound 별도)

3) contains both Allow and Deny rules

4) 규칙 번호 순서대로 평가

5) default NACL allows all inbound and outbound traffic
6) NACL are a great way of blooking a specific IP at the subnet level

Hands-on#01

1) create VPC public

2) create Internet Gateways > Attach to VPC

3) create subnet > modify auto-assign IP settings

4) create Route Table > routes 0.0.0.0/0 IGW

VPC 내 고립된 라우트 테이블

5) create VPC private

VPC secondary CIDR blocks

ENI: IP 주소 제공, 네트워크 통신 가능하게 하는 VPC의 논리적 구성 요소, 가상 네트워크 카드

IP주소는 EC2 인스턴스를 실행할 때 AWS가 만드는 ENI를 이용해 할당됨

Bring Your Own IP

Hands-on#02

EC2 인스턴스 2개 - app / DB server

Domain-name = corp.internal

Steps

1) Create a VPC with Public & Private subnet

2) (Optional) Create DHCP Option set with domain as corp.internal and associate with your VPC

- Domain name: corp.internal / Domain name servers: AmazonProvidedDNS

- Edit VPC settings: option set - corp.internal

3) Launch one EC2 instance in Public subnet (say app) and one instance in Private subnet (say db).

- Allow SSH (source type: My IP) and ICMP IPv4 (source type: 10.0.0.0/16) in the security group

4) Create Route 53 Private hosted zone and associate with the VPC

- NS, SOA + app (10.10.0.206), db (10.10.1.173)

5) Create A records for ec2 instances pointing to their Private IPs

6) SSH into Public EC2 instance and ping to other instance using it's DNS name

- cat /etc/resolv.conf : nameserver

- ping db.corp.internal or ping db

VPC DNS with custom DNS server

Step - Setup a VPC and launch instances

- Create a VPC with public and private subnets

- Launch DNS server ec2 instance: Security group to allow UDP 53 from VPC CIDR, SSH (22)

- Launch an app server & db server ec2 instances: Security group to allow SSH (22), ICMP IPv4 All (ping)

----------------------------------------------
Step 4a – Configure on-premise DNS server
----------------------------------------------
1. Login to on-premise DNS server (via SSH into VPN server first)
2. Install DNS server packages

sudo su
yum update –y
# DNS를 위한 패키지 설치, util을 binding
yum install bind bind-utils –y

3. Create file /var/named/corp.internal.zone

$TTL 86400
@ IN  SOA     ns1.corp.internal. root.corp.internal. (
  2013042201  ;Serial
  3600        ;Refresh
  1800        ;Retry
  604800      ;Expire
  86400       ;Minimum TTL
)
; Specify our two nameservers
IN  NS    dnsA.corp.internal.
IN  NS    dnsB.corp.internal.
; Resolve nameserver hostnames to IP, replace with your two droplet IP addresses.
dnsA IN  A   1.1.1.1
dnsB IN  A   8.8.8.8
; Define hostname -> IP pairs which you wish to resolve
@ IN  A   10.0.11.191
app IN A   10.0.11.191
db IN A   10.0.0.221

# APP 10.0.11.191
# DB 10.0.0.221

4. Create file /etc/named.conf [Replace X.X with your DNS server IP]

options {
  directory "/var/named";
  dump-file "/var/named/data/cache_dump.db";
  statistics-file "/var/named/data/named_stats.txt";
  memstatistics-file "/var/named/data/named_mem_stats.txt";
  allow-query { any; };
  allow-transfer { localhost; 10.0.11.191; };
  recursion yes;
  forward first;
  forwarders {
    10.0.0.2;
  };
  dnssec-enable yes;
  dnssec-validation yes;
  dnssec-lookaside auto;
  /* Path to ISC DLV key */
  bindkeys-file "/etc/named.iscdlv.key";
  managed-keys-directory "/var/named/dynamic";
};
zone "corp.internal" IN {
    type master;
    file "corp.internal.zone";
    allow-update { none; };
};

# DNS 10.0.11.191

5. Restart named service

service named restart
chkconfig named on

+ create DHCP Option sets

+ edit VPC DHCP option set

+ reboot App, DNS, DB server

----------------------------------------------
Step 5b – Configure on-premise DNS server
----------------------------------------------
1. Add following to /etc/named.conf. Replace ENDPOINT IPs with Route53 inbound resolver IPs.

zone "cloud.com" { 
  type forward; 
  forward only;
  forwarders { INBOUND_ENDPOINT_IP1; INBOUND_ENDPOINT_IP2; }; 
};

2. Restart named service
sudo service named restart

VPC DNS & DHCP exam essentials

- VPC has a default DNS server AmazonProvidedDNS

[TCP/IP Protocol #19] Part 4 | Chapter 19. 도메인 네임 시스템(DNS)

DNS(Domain Name System)

1. 정의

다른 응용 프로그램을 지원하는 데 사용되는 클라이언트/서버 응용 프로그램

응용 계층에서의 호스트 이름을 망 계층에서의 IP 주소로 매핑하는 데 사용

2. 배경

TCP/IP 프로토콜은 개체를 구분하기 위해, 인터넷에서 호스트 연결을 유일하게 식별하는 IP 주소를 사용한다.

하지만 사람들은 주소보다는 이름을 사용하고자 하는 경향이 있다.

그래서 이름을 주소로 바꿔주고, 주소를 이름으로 주는 시스템이 필요해지게 된다.

인터넷이 작은 규모일 경우는 호스트 파일(host file, 항목: 이름, 주소)을 사용하여 매핑 수행

but, 모든 호스트에 대한 호스트 파일을 저장하기에는 크기가 너무 큼, 변화가 있을 때마다 갱신하는 것도 불가능

해결책: 전체 호스트 파일을 단일 컴퓨터에 저장하여 매핑을 요구하는 모든 컴퓨터에게 이 정보를 접근해 가져갈 수 있도록 함 ⭢ 인터넷에 수많은 트래픽이 발생

⭢ (현재) 정보를 작은 부분으로 나누어 서로 다른 컴퓨터에 각 부분을 나누어 저장하는 것

⭢ 각 호스트들은 매핑이 필요할 경우 이 정보를 가지는 가장 가까운 컴퓨터와 통신하게 됨

⭢ 이 방법이 도메인 네임 시스템에 의해 사용됨

사용자는 원격 호스트에 동작하는 파일 전송 서버에 접속하여 파일을 클라이언트로 전송하고자 한다.

사용자는 파일 전송 서버 이름(xxx.com)만 알고 있다.

TCP/IP 집합은 연결을 설정하기 위해 파일 전송 서버의 IP 주소를 알아야 함

3. 서버 분류

DNS를 통해 서비스를 수행할 경우 DNS 서버가 필요하다.

네임 서버의 4가지 유형: DNS 해석기, 루트 네임 서버, TLD 네임 서버, 권한 있는 네임 서버

DNS 해석기(DNS Resolver)

클라이언트와 네임 서버의 중계자 역할

DNS 요청을 네임 서버로, DNS 응답을 클라이언트에게 전달

루트 네임 서버(Root Name Server)

DNS 서버의 최상위 네임 서버로 DNS 해석부터 발생한 DNS 요청에 대해 적절한 TLD 네임 서버 정보를 반환한다.

TLD 네임 서버(Top Level Domain Name Server)

.com, .net과 같은 최상위 도메인에 대한 네임 서버로 해당 영역에 포함되는 모든 도메인 이름의 정보를 유지한다.

DNS 요청에 대해 TLD 네임 서버에서 권한 있는 네임 서버를 지정하여 반환한다.

권한 있는 네임 서버(Authoritative Name Server)

DNS 해석기가 TLD 네임 서버로부터 응답을 받으면, 확인자는 해당 응답을 권한 있는 네임 서버로 보낸다.

요청하는 도메인 주소에 대한 IP 주소를 확인하는 마지막 단계

4. DNS의 동작 원리

1) 사용자가 웹 브라우저 주소 표시줄에 www.amazon.com을 입력하고 Enter를 누른다.

2) www.amazon.com에 대한 요청은 일반적으로 케이블 인터넷 공급 업체, DSL 광대역 공급업체 또는 기업 네트워크와 같은 인터넷 서비스 제공 업체(ISP)가 관리하는 DNS 해석기로 전달된다.

* DSL: 도메인 특화 언어(Domain Specific Language), 특정 도메인에 특화된 비교적 작고 간단한 프로그래밍 언어

3) ISP의 DNS 해석기는 www.amazon.com에 대한 요청을 DNS 루트 이름 서버에 전달된다.

4) ISP의 DNS 해석기는 www.amazon.com에 대한 요청을 .com 도메인의 TLD 이름 서버 중 하나에 다시 전달한다. .com 도메인의 이름 서버는 amazon.com 도메인과 연관된 4개의 Amazon Route 53 이름 서버의 이름을 사용하여 요청에 응답한다.

5) ISP의 DNS 해석기는 Amazon Route 53 이름 서버 하나를 선택해 www.amazon.com에 대한 요청을 해당 이름 서버에 전달한다.

6) Amazon Route 53 이름 서버는 amazon.com 호스팅 영역에서 www.amazon.com  레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받고 이 IP 주소를 DNS 해석기로 반환한다.

7) ISP의 DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 확보하게 된다. 해석기는 이 값을 웹 브라우저로 반환한다. 또한 DNS 해석기는 다음에 누군가가 amazon.com을 탐색할 때 좀 더 빠르게 응답할 수 있도록 사용자가 지정하는 일정 기간 동안 amazon.com의 IP 주소를 캐싱(저장)한다.(TTL(Time to Live) 참조)

8) 웹 브라우저는 DNS 해석기로부터 얻은 IP 주소로 www.amazon.com에 대한 요청을 전송한다. 여기가 콘텐츠(Contents)가 있는 곳으로, 웹 사이트 엔드 포인트(End-point)로 구성된 Amazon S3 버킷 또는 Amazon EC2 인스턴스에서 실행되는 웹 서버이다.

9) 192.0.2.44에 있는 웹 서버 또는 그 박의 리소스는 www.amazon.com의 웹 페이지를 웹 브라우저로 반환하고, 웹 브라우저는 이 페이지를 표시한다.

[호스트 이름을 IP 주소로 매핑하는 절차]

1. 사용자: 호스트 이름을 파일 전송 클라이언트에 전달

2. 파일 전송 클라이언트는 호스트 이름을 DNS 클라이언트에 전달

3. 부팅된 후 컴퓨터들이 DNS 서버의 주소를 앎 - DNS 클라이언트는 DNS 서버의 알려진 주소를 사용하여 파일 전송 서버의 이름을 질의하는 메시지를 DNS 서버에 보냄

4. DNS 서버는 원하는 파일 전송 서버의 IP 주소를 응답

5. DNS 클라이언트는 IP 주소를 파일 전송 클라이언트에 전달

6. 파일 전송 클라이언트는 수신한 IP 주소를 사용하여 파일 전송 서버에 접속

-

사람이 읽을 수 있는 도메인 이름(sarahee.tistory.com)을 머신이 읽을 수 있는 IP 주소(211.231.99.250)로 변환

IP 주소: 인터넷상의 모든 컴퓨터라는 숫자를 사용해서 통신하는 숫자

DNS 서비스(e.g., Amazon Route 53)

쿼리: DNS 서버에서 이름을 IP 주소로 변환하여 도메인 이름을 웹 브라우저에 입력할 때 최종 사용자를 어떤 서버에 연결할 것인지를 제어/요청

재귀적 DNS: DNS 레코드를 소유하고 있지 않지만 사용자를 대신해서 DNS 정보를 가져올 수 있는 중간자의 역할을 함

1. 사용자가 웹 브라우저를 열어 주소 표시줄에 www.example.com을 입력하고 Enter 키를 누릅니다.
2. www.example.com에 대한 요청은 일반적으로 케이블 인터넷 공급업체, DSL 광대역 공급업체 또는 기업 네트워크 같은 인터넷 서비스 제공업체(ISP)가 관리하는 DNS 해석기로 라우팅됩니다.
3. ISP의 DNS 해석기는 www.example.com에 대한 요청을 DNS 루트 이름 서버에 전달합니다.
4. ISP의 DNS 해석기는 www.example.com에 대한 요청을 이번에는 .com 도메인의 TLD 네임 서버 중 하나에 다시 전달합니다. .com 도메인의 이름 서버는 example.com 도메인과 연관된 4개의 Amazon Route 53 이름 서버의 이름을 사용하여 요청에 응답합니다.
5. ISP의 DNS 해석기는 Amazon Route 53 이름 서버 하나를 선택해 www.example.com에 대한 요청을 해당 이름 서버에 전달합니다.
6. Amazon Route 53 이름 서버는 example.com 호스팅 영역에서 www.example.com 레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받고 이 IP 주소를 DNS 해석기로 반환합니다.
7. ISP의 DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 확보하게 됩니다. 해석기는 이 값을 웹 브라우저로 반환합니다. 또한, DNS 해석기는 다음에 누군가가 example.com을 탐색할 때 좀 더 빠르게 응답할 수 있도록 사용자가 지정하는 일정 기간 example.com의 IP 주소를 캐싱(저장)합니다. 자세한 내용은 Time to Live(TTL)를 참조하세요.
8. 웹 브라우저는 DNS 해석기로부터 얻은 IP 주소로 www.example.com에 대한 요청을 전송합니다. 여기가 콘텐츠가 있는 곳으로, 예를 들어 웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 또는 Amazon EC2 인스턴스에서 실행되는 웹 서버입니다.
9. 192.0.2.44에 있는 웹 서버 또는 그 밖의 리소스는 www.example.com의 웹 페이지를 웹 브라우저로 반환하고, 웹 브라우저는 이 페이지를 표시합니다.

* DSL 광대역 공급업체: Domain Specific Language

* DNS 해석기: (resolver, 재귀적 DNS)

* TLS name server

Reference

https://aws.amazon.com/ko/route53/what-is-dns/

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

김원일, 서종호, 따라하며 배우는 AWS 네트워크 입문, enBergen, BOOKK

권영환, 아마존 웹 서비스(AWS Discovery Book), 정보문화사

DRDoS 개념

Distributed Reflection Denial of Service (분산 반사 서비스 거부 공격)

특징

출발지 IP를 위조(Source IP Spoofing)

공격자는 IP를 공격 대상으로 Spoofing, 대량의 공격 요청을 반사 대상(서버 등)에 보냄

→ IP를 기반으로 공격을 방어하거나 공격자 역추적이 어려움

다수의 정상 동작 서버에 공격 트래픽 발생시켜, 정상 트래픽과의 구분이 어려움

공격 트래픽이 수백 Gbps 이상의 대규모로 발생하여, 탐지 하더라도 방어하기 어려움

UDP 기반 증폭 공격

DNS

NTP

SSDP

SNMP

Chargen

Others

NetBios

PC의 이름 등록(name registration)과 resolution을 수행하는 프로토콜의 디버깅을 위한 nbtstat 명령 이용

약 3배 정도의 증폭 효과

QOTD

Quote Of The Day, CharGen 프로토콜과 거의 유사한 형태

17/UDP port

TCP SYN Flooding

공격자가 IP를 목표물로 설정

반사 서버로 Syn 요청

반사 서버는 목표물에게 SYN+ACK 보냄

일정 시간 이후 목표물이 SYN+ANK 재전송(TCP 연결 특성상)

P2P

프로토콜별 증폭 공격이 가능한 이유, 공격 기법

공격자는 보통 네트워크 스캐너를 이용하여 증폭 공격에 이용할 취약 서버 리스트를 확보

(e.g. 디바이스 검색엔진 Shodan 이용)

과정

증폭 공격에 대한 공격 대상이 네트워크에 존재하는 경우

공격에 사용되는 서버가 네트워크에 존재하는 경우

공격자가 네트워크에 존재하는 경우

보안 대책

ISP에서 IP Spoofing 패킷 진입 불가(Ingress Filtering) 설정

네트워크 보안 장비(e.g. 방화벽)에서 동일 IP에 대해 일정 요청 이상은 차단하도록 설정

NTP의 경우 monlist 기능 비활성화(ntpdc -c monlist (NTP server add))

Proactive Attack Prevention

사전에 DRDoS 증폭 공격을 방어하는 방법

1) IP spoofing을 원천적으로 막는 안티스푸핑(Anti spoofing) 기법 적용

2) 프로토콜 취약점을 패치

1. 안티 스푸핑(Anti-Spoofing)

: 인증을 이용한 안티 스푸핑 기법

1) 세션 토큰을 이용한 인증

2) 암호화 기법을 이용한 인증

3) 제삼자(third-party)를 이용한 인증

성능 상의 오버헤드나 추가적으로 트래픽 발생

2. 네트워크 토폴로지를 이용한 방법

[참조]

최현상,박현도,이희조, "DRDoS 증폭 공격 기법과 방어 기술 연구(A Study on Amplification DRDoS Attacks and Defenses)", 한국정보전자통신기술학회논문지, 15-08-05-429 Vol.8 No.5 (2015), 9page.

김효종, 한군희, 신승수, "DRDoS 증폭 공격 대응 시스템(Response System for DRDoS Amplification Attacks)", 융합정보논문지(Journal of Convergence for Information Technology), Vol.10 No12 (2020), 22~30page