DNS: Domain Name System which translates the human friendly hostnames into the machine IP addresses
DNS Terminologies (관련 용어)
Domain Registrar(도메인 이름 등록하는 곳): Amazon Route 53, GoDaddy, ...
DNS Records: A, AAAA, CNAME, NS, ...
Zone File: contains DNS records
Name Server: resolves DNS queries
1) Web Browser가 example.com에 접근하기 위해서는 Local DNS server에 물어볼 것
* Local DNS Server: 보통 회사에 의해 할당되고 관리되거나 ISP에 동적으로 할당됨
2) Local DNS Server가 이 쿼리를 본 적이 없다면 먼저 ICANN에 관리된 Root DNS Server에 물어볼 것
→ .com은 알고 있음 (.com NS 1.2.3.4) 반환
3) 1.2.3.4에 있는 .com 도메인 서버에게 쿼리의 답을 요청 (TLD DNS Server, Managed by IANA, Branch of ICANN)
→ DNS 서버는 example.com을 모르지만 example.com 이라는 서버는 알고 있음 (example.com NS 5.6.7.8)
4) 로컬 DNS 서버(서브도메인의 DNS 서버)에 질의: 도메인 네임 레지스트라(Route 53 등)에 의해 관리되는 서버, 최종 서버
→ example.com에 대해 알고 있음. example.com은 A 레코드이고 이것의 결과로 IP 9.10.11.12를 얻음
Route 53
a highly, available, scalable, fully managed and authoritative DNS, DNS 레코드를 업데이트할 수 있음
DNS 레코드를 아마존 Route 53의 호스팅 존에 쓰려고 함, 클라이언트가 example.com을 요청하면 Route 53 서비스가 IP 54.22.33.44를 찾고 있다고 응답함 → 클라이언트는 바로 EC2 인스턴스에 접근함, Route 53도 도메인 이름 레지스트라로 도메인 이름을 example.com으로 등록함
Route 53에서 여러 DNS 레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의함
각 레코드는 도메인이나 example.com과 같은 서브도메인 이름과 같은 정보를 포함함
* TTL: DNS 리졸버에서 레코드가 캐싱되는 시간
Route 53 - Record Types
A - maps a hostname to IPv4
AAAA - maps a hostname to IPv6
CNAME - maps a hostname to another hostname
- 대상 호스트 이름은 A나 AAAA 레코드가 될 수 있음
- Route 53에서 DNS namespace 또는 Zone Apex의 상위 노드에 대한 CNAME을 생성할 수 없음
(e.g., example.com에 대한 CNAME을 만들 수는 없지만, www.example.com에 대한 CNAME 레코드는 만들 수 있음)
NS - Name Servers for the Hosted Zone
- 서버의 DNS 이름 또는 IP 주소로 호스팅 존에 대한 DNS 쿼리에 응답할 수 있음
- 트래픽이 도메인으로 라우팅되는 방식을 제어함
Route 53 - Hosted Zones
a container for records, 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의함
Public Hosted Zones - 쿼리에 도메인 이름 application1.mypublicdomain.com의 IP가 무엇인지 알 수 없음
Private Hosted Zones - 공개되지 않은 도메인 이름을 지원, 가상 프라이빗 클라우드(VPC)만이 URL을 resolve할 수 있음(e.g., application1.company.internal)
Route 53 - Public vs. Private Hosted Zones
Public Hosted Zones: 공개된 클라이언트로부터 온 쿼리에 응답할 수 있음, 웹 브라우저에서 example.com을 요청하면 IP를 반환함
- 퍼블릭 레코드를 위한 호스팅 존
Private Hosted Zones: 해당 VPC에만 동작, 비공개 도메인 이름의 프라이빗 리소스를 식별할 수 있음
- 프라이빗 리소스, 예컨대, VPC에서만 쿼리할 수 있음
EC2 인스턴스가 1개 있고, webapp.example.internal을 식별하고자 함
또 다른 EC2 인스턴스에서는 api.example.internal을 식별하기 원하고 데이터베이스에서는 db.example.internal을 식별하고자 함
private hosted zone에 등록하고자 하는데, 첫번째 EC2 인스턴스가 api.example.internal을 요청하는 경우 프라이빗 호스팅 존은 프라이빗 IP 10.0.0.10이라는 답을 갖고 있음. EC2 인스턴스는 데이터베이스에 연결이 필요할 수도 있는 두번째 EC2 인스턴스에 연결하여 db.example.internal이 무엇인지 물어보면 프라이빗 호스팅 존은 프라이빗 IP를 알려줌
Hands-on#01. Route 53 setting up
1) Registered domains
2) Hosted zones - Create record A
3) cloudshell
sudo yum install -y bind-utils
nslookup domain.com
dig domain.com
4) Create EC2 Instances
- 서로 다른 리전에 세 인스턴스 생성(e.g., NRT, ICN, KIX - Tokyo, Seoul, Osaka)
- proceed without a key pair
- allow HTTP traffic from the internet
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/meta-data/placement/availability-zone)
echo “<h1>Hello World from $(hostname -f) in AZ $EC2_AVAIL_ZONE </h1>” > /var/www/html/index.html
- Hello World 뒤에 인스턴스 정보를 출력할 것, 인스턴스가 시작되는 가용 영역도 포함시키는 과정에서 환경 변수 $EC2_AVAIL_ZONE을 사용
5) Create Load Balancer (DemoRoute53ALB)
- create TG
6) open addresses & LB에서 DNS name이 프로비저닝 되었는지 확인
ap-northeast-1(Tokyo): 54.199.162.15x
ap-northeast-2(Seoul): 43.201.64.18x
ap-northeast-3(Osaka): 13.208.191.12x
Route 53 - Records TTL (Time To Live)
클라이언트가 DNS Route 53와 웹 서버에 접속한다고 할 때,
myapp.example.com에서 DNS 요청을 보내면 DNS로부터 회신을 받음 (회신 내용: A 레코드, IP 주소, TTL(300초 정도))
TTL은 클라이언트에게 이 결과를 캐시하도록 요청함 (클라이언트는 300초 동안 결과를 캐시함)
→ 클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우, 클라이언트는 답변을 캐시에 저장해서 답을 알기 때문에 DNS 시스템에게 쿼리를 보내지 않아도 된다는 의미
하지만 캐시에도 시간이 소요되어 캐시 TTL이 발생, DNS 요청 쿼리를 계속해서 자주 보내는 상황을 원치 않기 때문
저장된 답변을 이용함으로써 웹 서버에 접속이 가능하고 HTTP 요청 및 회신을 보낼 수 있음
1) High TTL - e.g., 24 hr
TTL을 24시간으로 높게 설정하면 결과가 24시간 동안 캐시되므로 Route 53의 트래픽은 현저히 적음 (클라이언트가 요청을 적게 보냄)
-> 클라이언트가 오래된 레코드를 받을 가능성이 있음 (레코드를 바꾸고자 한다면 모든 클라이언트들이 새 레코드를 캐시에 저장할 때까지 24시간을 기다려야 한다는 뜻)
2) Low TTL - e.g., 60 sec.
TTL을 60초 정도로 짧게 설정한다면 DNS에는 트래픽 양의 많아져서 비용이 많이 듦 (Route 53에 들어오는 요청의 양에 따라 요금이 책정되기 때문)
오래된 레코드의 보관 시간은 짧아짐 -> 레코드 변경이 빨라짐
Hands-on#02. TTL
1) Create A record - IP region
2) record name으로 사이트 접속 혹은 cloudshell nslookup or dig
3) edit Record value
- 레코드 캐시가 만료될 때까지 확인
CNAME vs Alias
AWS 리소스(로드밸런서나 CloudFrond 등)를 사용하는 경우 호스트 이름이 노출됨, 그리고 보유한 도메인에 호스트 이름을 매핑하고자 할 수 있음
myapp.mydomain.com에 로드 밸런서를 매핑하는 경우 두 가지 옵션이 있는데,
1) CNAME 레코드로 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있음 (e.g., app.mydomain.com → blabla.anything.com)
- 루트 도메인 이름이 아닌 경우에만 가능 (aka. something.mydomain.com)
2) Alias: Route 53에 한정하여, 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있음 (e.g., app.mydomain.com → blabla.amazonaws.com)
- 루트 도메인과 비루트 도메인 모두에 작동함 (aka. mydomain.com, mydomain.com을 별칭으로 사용해 AWS 리소스로 향하도록 할 수 있음)
- 무료, 자체적으로 상태 확인 가능
Route 53 - Alias Records
AWS 리소스에만 매핑이 되어 있음
예를 들어 Route 53에서 example.com을 A 레코드의 별칭 레코드로 하고 그 값은 로드 밸런서의 DNS 이름을 지정하려 한다고 해보자.
기반이 되는 ALB에서 IP가 바뀌면 별칭 레코드는 바로 인식함
CNAME과 달리 별칭 레코드는 Zone Apex라는 DNS 네임 스페이스의 상위 노드로 사용될 수 있음
AWS 리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA (리소스는 IPv4나 IPv6 중 하나)
별칭 레코드를 사용하면 TTL을 설정할 수 없음 (Route 53에 의해 자동으로 설정됨)
Route 53 - Alias Records Targets
별칭 레코드의 대상은? ELB, CloudFront 배포, API Gateway, Elastic Beanstalk environments, S3 Websites(S3 버킷은 안됨, 버킷들이 웹사이트로 활성화될 시 S3 웹사이트는 가능), VPC Interface Endpoints, Global Accelerator accelerator, Route 53 record in the same hosted zone
- EC2의 DNS 이름은 별칭 레코드의 대상이 될 수 없음
Hands-on#03. CNAME vs. Alias
1) create CNAME record
- value: ALB DNS name
2) create A record
- Alias > Route traffic to ALB
- 별칭 레코드이기 때문에 Evaluate target health는 자동으로 Yes 체크되어 있음
3) create A record without subdomain
References
Udemy, Ultimate AWS Certified Solutions Architect Associate SAA-C03, Section 10: Route 53
'Networking > AWS' 카테고리의 다른 글
[AWS] SAA-C03#12: Route 53 (2) (0) | 2024.08.07 |
---|---|
[AWS] ANS-C01#02: VPC fundamentals (2) | 2024.07.24 |
[AWS] ANS-C01#01: ELB (0) | 2024.07.19 |
AWS products (0) | 2024.07.10 |
[AWS] SAA-C03#10: VPC lab(3) (1) | 2024.07.02 |