[AWS] Route 53

DNS (Domain Name System)

• DNS : 친숙한 hostname을 서버의 ip로 변환해주는 시스템 (www.google.com -> 172.217.18.36)
• Domain Registrar : Domain name 등록 (ex. Amazon Route53 등)
• Domain Records : ex. A, AAAA, CNAME, NS 등
• Zone File : hostname과 IP를 일치시키는 방법 (모든 DNS records를 포함)
• Name Server : DNS 쿼리를 실제로 처리하는 서버
• TLD (Top Level Domain) : .com, .us, .in, .gov, .org 등
• SLD (Second Level Domain : amazon.com, google.com 등
  
  
  

• DNS 동작 과정

1. Domain Name DNS서버에 등록 (example.com)
2. Local DNS 서버에 요청 Domain Name이 있는지 쿼리 (일반적으로 회사에서 할당하고 관리 or 인터넷 서비스 제공자(ISP)에 동적으로 할당)
3. Local DNS 서버에 없는 Domain Name이라면, ICANN에 의해 관리되는 DNS서버의 root에 질의 (알 수 없는 도메인 or Name Server Record인 .com만 알고있다고 응답 -> .com은 IP 1.2.3.4로 가보라고 응답 -> 답을 좀 더 좁혀 나감)
4. IP 1.2.3.4에 있고 IANA에 의해 관리되는 TLD DNS Server에 쿼리 (record가 뭔지 몰라 IP가 뭔지 바로 응답은 못해주지만, example.com이 등록되어 있는 경우, example.com에 해당하는 서버로 안내함 (5.6.7.8)
5. IP 5.6.7.8에 있고 Amazon Route53과 같은 Domain Registrar에 의해 관리되는 SLD DNS Server에 쿼리 (record를 알고있어 해당하는 IP인 9.10.11.12를 응답)
6. Local DNS Server는 해당 응답을 받게되어 캐시에 저장함
7. 브라우저 또한 해당 응답을 Local DNS Server를 통해 받게되어 캐시에 저장함

Route 53 개요

• Route53 : 고가용성 및 확장성을 갖춘, 사용자가 직접 DNS record를 업데이트할 수 있는 DNS (DNS 제어 가능)
  
  
  

• 특징

1. Domain Registrar로써 특정 ip에 매핑되는 Domain Name을 등록
2. Route53 리스소 관련 상태확인 가능
3. 100% SLA 가용성 제공
4. why? Route53 : 53포트는 DNS서버에 사용되는 전통적인 DNS 포트
5. Domain Record는 Domain Name이나 Subdomain Name과 같은 정보를 포함 (ex. example.com)
   
   
   

• Domain Record 포함 정보

1. Domain Name
2. Record Type (ex. A or AAAA or CNAME or NS / 고급 : CAA or DS or MX 등)
3. Value (ex. 123.456.789.123)
4. Routing Policy : Route53이 쿼리에 응답하는 방식
5. TTL : Record가 캐싱되는 시간 (amount of time)
   
   
   

• Record Type

1. A : hostname과 IPv4 IP를 매핑
2. AAAA : hostname과 IPv6 IP를 매핑
3. CNAME : hostname를 다른 hostname과 매핑 (다른 hostname은 record type이 A or AAAA가 될 수 있음)
   • DNS Name Space or Zone Apex의 상위 노드에 대한 CNAMES를 생성할 수 없음 (ex. example.com(상위노드)에 대한 CNAME을 만들 수는 없지만, www.example.com에 대한 CNAME을 만들 수는 있음)
4. NS : Hosted Zone의 Name Servers, DNS Name 또는 IP주소로 Hosted Zone에 대한 DNS쿼리에 응답할 수 있음
   • 트래픽이 도메인으로 라우팅 되는 방식을 제어
     
     
     

• Hosted Zone : Record의 컨테이너, 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의

1. public Hosted Zone
   • ex. application1.mypublicdomain.com이 public domain이라면, public Hosted Zone을 생성할 수 있음
   • application1.mypublicdomain.com의 IP를 알 수 있음
   • application2.mypublicdomain.com은 application1.mypublicdomain.com과 같은 Hosted Zone에 속하므로 동일 Hosted Zone에서 IP를 알 수 있음 (application1, application2는 동일 ip를 응답으로 받게 됨)
2. private Hosted Zone : 공개되지 않는 도메인 이름을 지원
   • VPC (Virtual Private Cloud) 만이 해당 도메인을 관리할 수 있음
   • ex. application1.company.internal -> 사내망에서만 접근할 수 있는 URL도 해당
     
     
     

• public Hosted Zone vs private Hosted Zone
  : public은 사용자 누구나 접근할 수 있음, private는 VPC와 같은 private 네트워크 내에서만 접근할 수 있음

TTL (Time To Live)

• TTL : DNS서버로부터 응답으로 받는 값 -> 받은 client는 해당 값 동안 record 데이터를 캐싱 (TTL시간 동안 DNS에 같은 요청을 보낼 경우, 캐싱된 값을 활용하게 됨) -> Domain에 대한 ip를 변경해도 TTL시간 내에서는 즉각적인 변경이 안됨
  
  
  

• TTL값에 따른 Case

1. Higt TTL : DNS서버로의 트래픽 down, 이미 만료된 record값 전송 가능성 up
2. Low TTL : DNS서버로의 트래픽 up (비용 상승), 새로 갱신된 record값을 전송할 수 있음
   
   
   

CNAME vs Alias

• CNAME/Alias : AWS 자원을 사용할 때, 해당 AWS의 hostname이 노출됨 -> 해당 hostname으로의 mapping이 필요할 때 사용 (ex. lb1-1234.us-east-2.elb.amazonaws.com hostname을 myapp.mydomain.com hostname에 매핑, ALB hostname을 특정 custom hostname으로 매핑)
  
  
  

• CNAME vs Alias

1. CNAME
   • root domain에는 매핑이 안됨 -> mydomain.com (x), myapp.mydomain.com (o)
2. Alias
   • Route53 한정
   • hostname이 특정 AWS 리소스로 향하게 할 수 있음 (ex. app.mydomain.com -> blabla.amazonaws.com) -> root domain 제약이 없음 -> 실제로는 인스턴스의 ip에 매핑(?)
   • Free
   • 자체적인 health check 가능
   • AWS 리소스에만 매핑
   • record는 A 또는 AAAA
   • TTL을 설정할 수 없음 (Route53에 의해 자동 설정) -> target ip변화를 인식할 수 있음
   • Target : ELB(Elastic Load Balancer), Amazon CloudFront, API Gateway, Elastic Beanstalk, S3 Websites (buckets (x)), VPC Interface Endpoints, Global Accelerator, Route53 Record (same Hosted name) -> EC2는 불가
     
     
     

• Alias Records

Routing Policies

• DNS Routing Policies : DNS가 요청으로 들어온 host Name을 어떤 인스턴스로 어떻게 매핑해야하는 지에 대한 정책
  
  
  

• Routing Policies types

1. Simple
   • 트래픽을 단일 리소스로 보내는 방식
   • 여러개의 ip를 매핑할 수도 있는데, 해당 경우에는 client가 받은 ip중 무작위로 하나를 선택하게 됨 (캐싱이 갱신되어야 ip가 바뀜)
   • health check 불가
2. Weighted
   • 요청 트래픽의 일부를 특정 리소스로 보냄 (가중치에 맞게 DNS서버가 client로 ip응답을 보내줌)
   • 트래픽의 비율에 맞게 ip를 응답으로 주기 때문에 응답으로 주는 ip에 해당하는 인스턴스로의 트래픽 비율은 DNS 라우팅 정책의 가중치의 비율과 동일함
   • 전체 가중치의 합이 100일 필요는 없음
   • DNS record들은 동일한 name과 type을 가져야함 -> health check와도 연관됨
   • use case : 다른 region에 대한 트래픽 분산, 적은 양의 트래픽을 통한 신규 인스턴스의 테스트 등
   • 가중치가 0일 경우, 트래픽을 보내지 않게됨 -> 모든 레코드의 가중치가 0일 경우, 모든 레코드에 대한 트래픽이 균등해짐

3. Failover
   • primary 인스턴스의 상태가 비정상일 경우, secondary 인스턴스로의 장애조치 -> client는 정상으로 판단되는 인스턴스의 ip를 자동으로 받아볼 수 있음
   • primary 비정상 판단 시, primary failover record -> secondary failover record로 자동전환

4. Latency based
   • 지연시간이 가장 짧은 가장 가까운 리소스로 redirect해주는 방식
   • 지연시간에 민감한 case에 효과적
   • 지연시간 : 가장 가까운 AWS region에 연결하기까지의 걸리는 시간 -> health check와도 연관됨
   • record등록 시, region도 선택해줘야함 -> ip로는 어떤 region인지 식별 불가

5. Geolocation
   • 사용자 실제 위치 기반 (지연시간과 유사하지만 다름)
   • 해당 도메인에 접근할 수 있는 지역을 사전 지정 (대륙/국가 단위)
   • 일치하는 위치가 없는 경우, 사전 생성되어 있는 default record로 라우팅됨
   • Use case : 특정 언어로된 웹사이트에 특정 언어권 지역의 사용자만 접근할 수 있도록 설정

6. Multi-Value Answer

   • 트래픽을 다중 리소스로 라우팅할 때 활용 -> 다중 값/리소스 반환
   • 반환되는 값은 health checker에 의해 정상으로 판단된 값 (최대 8개 반환) -> client측면의 load balancing
   • 다중값을 반환하는 Simple방식과의 차이점은 Simple방식은 health check와 관련되어있지 않음

7. Geoproximity (using Route53 Traffic Flow Feature)

   • 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅해주는 방식
   • 편향값(bias)를 기반으로 특정 지역의 리소스로 트래픽을 전환함
   • 특정 리소스에 더 많은 트래픽을 보내기 위해 편향값(bias)을 증가시켜 확장해야 함
   • 트래픽을 줄이기 위해 편향값을 음수로 줄여야 함
   • 리소스의 위치 판단
     • AWS 리소스의 경우 region으로 계산
     • 온프레미스의 경우 위도-경도 값을 지정해줘야 함
   • 편향값 활용을 위해 고급 Route53 트래픽 플로우 활용

8. IP-Based
   • IP주소기반 라우팅 방식
   • CIDR(IP주소) 목록 정의 필요 (이후 CIDR에 endpoints 매핑)
   • use case : 특정 업체가 특정 IP대역을 활용한다는 것을 알고있다면, 특정 업체만의 서비스를 제공하기 위해 활용될 수 있음

health checks

• health checks : pubcli resources에 대한 상태 확인 방법 -> DNS의 장애조치 자동화
  
  
  

• health check types

1. public endpoints 모니터링
   • application, server etc...
   • ip, hostname 지정 가능
   • 특정 인스턴스에 대한 전세계 15개 region에서온 health check에 응답함 -> region별 임계값을 비교한 후 정상/비정상 판단
   • Interval은 10/30s 선택 가능
   • HTTP/HTTPS/TCP 등 프로토콜 지원
   • global region의 18% 이상이 정상이라고 판단한다면 Route53에서도 해당 인스턴스를 정상으로 간주
   • 상태확인은 2xx/3xx 응답만 성공으로 간주
   • 텍스트 기반 응답의 경우, 처음 5120bytes를 읽고 정상/비정상 판단
   • 상태확인이 가능하려면 상태확인이 필요한 인스턴스에 접근이 가능해야 함 (route53의 ip주소범위에 대한 권한을 허용해야 함)

2. Calculated Health Check
   • 하위 health check 값을 확인하고 최종 계산하여 정상/비정상 판단
   • 하위 health check값 계산 방법은 OR/AND/NOT이 있음
   • 하위 health check는 256개까지 생성 가능
   • 하위 health check 통과 갯수를 지정할 수 있음
   • 몇몇의 하위 health check 상태와 관계없이 상위 health check로 웹사이트를 유지하려는 경우 활용됨

3. Privated Hosted Zones
   • Route53의 health checker는 모두 VPC 외부에 있음 -> VPC 내부의 인스턴스에 접근 불가
   • Route53이 CloudWatch를 통해 VPC 내부 health check 가능
   • CloudWatch가 metic에 침해되는 경우, 알람을 발생시키고 Route53이 이를 인지하여 비정상 판단하는 방식

Domain Registrar vs DNS Service

• Domain Registrar : Domain이름을 등록하는 서비스, 이에 따른 비용지불 필요
• Amazon Route53이 아닌 다른 Domain Registrar활용 가능 (ex. GoDaddy, Amazon Registrar, Google Domain 등)
• Domain Registrar를 이용한다면 DNS 레코드 관리를 위한 DNS 서비스 제공 (Route53 이용 시, DNS 레코드 관리를 위한 Route53 Hosted Zone을 가짐)
• 도메인을 타사(ex. GoDaddy 등)에서 구매하고 해당 도메인을 Route53에 등록한다면, Route53에서 DNS 서비스 이용 가능
  1. Route53 public Hosted Zone 생성
  2. 타사 custom nameservers를 Route53 public Hosted Zone 세부정보의 Name Server로 변경 -> 사용자가 도메인으로 쿼리를 하면 타사 도메인은 Route53의 name server를 가리키게 되고, 해당 name server의 정책을 따르게 됨
• 결론 : Domain Registrar != DNS Service