DNS와 AWS 개요

Sonar0·2022년 12월 17일
DNSaws
0

DNS의 원리

DNS는 사람이 기억하기 쉬운 도메인 이름(hostname)을 컴퓨터가 인식할 수 있는 주소(IP address)로 변환해주는 서비스/시스템 이다. google.com, naver.com 의 주소를 브라우저에 입력하면, 각각 google의 서버, naver의 서버로 연결해서 데이터를 받아올 수 있는 것은 DNS가 google의 서버, naver의 서버의 주소를 찾아주기 때문이다. 이번 장에서 DNS의 동작 원리를 더 깊이 배워본다.

4종류의 DNS server

DNS recursor (DNS Recursive Resolver)

클라이언트로부터 요청(query)을 받는 서버이다. 이미 처리한 적있는 DNS 주소에 대해서는 캐시를 통해서 빠르게 응답한다.

  • 도서관에서 책이 어디에 있는지 물어보는 사서라고 생각하면 쉽다.

Root nameserver (IP 주소를 찾기 위한 시작)

도메인 이름(hostname)을 IP주소로 바꾸는 첫번째 단계를 root nameserver에서 수행한다.
해당 hostname의 IP 주소를 얻을 수 있는 특정 위치에 물어보도록 연결한다.

  • 도서관의 카테고리 안내 색인/방향표 이라고 생각하면 쉽다.

TLD nameserver (Top Level Domain)

특정 IP주소 검색의 다음 단계이고, hostname의 마지막 부분(.com 등)을 호스팅한다.

  • 도서관의 특정 책장이라고 생각하면 쉽다.

Authoritative nameserver

hostname에 해당하는 IP 주소를 가지고 있는 담당 서버이자, DNS로부터 IP주소를 찾는 마지막 단계이다. authoritative nameserver 가 요청한 레코드의 접근을 했었다면, IP 주소를 리턴할 수 있다. 이렇게 얻은 IP주소는 DNS Recursor 에게 전달한다.

  • 도서관 책장에서 실제 책이 어디있는지 찾을 수 있는 사전이라고 생각하면 쉽다.
  • subdomain이 있는 경우, authoritative nameserver가 한 단계 더 추가될 수 있다.

DNS lookup을 하는 과정

  1. 유저가 브라우저에 example.com 과 같은 hostname 를 입력한다. 이 요청은 DNS
    Recursive resolver에 도착한다.

  2. (Recursive) resolver는 DNS root nameserver 에 질의한다.

  3. root server 는 resolver 에게 해당 도메인의 IP주소를 찾을 수 있는 TLD 서버를 알려준다. 이 예제에서는 .com 확장자에 대한 정보를 가진 TLD 서버를 알려준다.

  4. resolver는 TLD 서버에게 요청한다.

  5. TLD 서버는 hostname의 IP주소를 찾을 수 있는 nameserver 를 resolver에게 응답해준다. 이 예제에서는 example.com 을 알고 있는 authoritative nameserver이다.

  6. resolver는 해당 도메인의 nameserver에게 질의한다.

  7. 해당 도메인의 nameserver는 resolver 에게 IP주소를 리턴한다.

  8. DNS resolver가 브라우저에게 IP 주소를 응답한다.

  9. 그 다음에 브라우저는 example.com에 해당하는 IP주소를 이용해서, HTTP request 를 만든다.

  10. 해당 IP의 서버가 HTTP요청에 대한 응답을 브라우저에게 전달한다.

.com 이 왜 Top Level 인가?

Domain Name의 문법은 dot(.)을 기준으로 다음과 같은 tree hierarchy를 구성하고 있다.
우리가 쓰는 도메인 주소는 subdomain.domain.topleveldomain 형식이다.
그리고 그것이 모두 조합된 이름을 hostname 이라고 합니다.

DNS Caching

들어갈 때마다 위에 쓰여진 DNS 주소 찾는 과정을 거친다면, 그만큼 비용이 많이들 것이다.
→ IP 주소가 바뀌지 않는다면 한번 얻은 IP 주소를 계속 사용하면 어떨까?
→ DNS Caching (기본적으로 TTL = Time To Leave를 사용한다. / 일정 시간동안 유지)

Browser DNS Caching

최신 브라우저는 모두 DNS caching을 사용한다.

  • Chrome에서는 chrome://net-internals/#dns에서 DNS 캐시의 상태를 볼 수 있고, 캐시를 삭제할수도 있다.

OS level DNS Caching

운영체제에서도 DNS caching을 사용한다. App에서 cache를 찾지 못하면, OS에서 hit 되는 경우가 많다. OS에서도 찾지 못하면, 그때 DNS resolver 에게 네트워크로 도메인의 IP주소를 찾기위한 요청을 전달한다.

Recursive Resolver 에서의 Caching

Recursive resolver가 client로부터 요청을 받으면 다음과 같은 순서로 캐시를 확인한다.

  1. resolver 가 해당 도메인의 A Record(IP address)를 가지고 있는 경우, 바로 응답한다.

  2. resolver 가 A Record(IP address) 는 가지고 있지 않지만, authoritative nameserver의 NS record(domain)을 가지고 있는 경우. 이 경우에는 앞의 과정을 생략하고 바로 authoritative nameserver로 요청을 전송한다. 위 1.2 DNS lookup을 하는 과정 에서 6단계로 바로간다.

  3. resolver 가 도메인의 TLD 정보를 가지고 있지만 NS record를 가지고 있지 않은 경우, resolver 는 TLD 서버에게 요청한다. 위 1.2 DNS lookup을 하는 과정 에서 4단계로 바로 간다.

  4. 위 1,2,3이 아닌 경우, root server에게 질의하는 것부터 모두 수행한다.

AWS에서 DNS 사용해보기

왜 AWS인가?

  • 클라우드 서비스는 내가 컴퓨터, 인프라를 소유하지 않고도 IT 인프라를 필요한 만큼 비용을 내고 사용하고, 필요 없을 때는 반납할 수 있다. 물리적인 인프라 없이 소프트웨어 만으로도 IT 인프라를 사용할 수 있고, 비용도 사용한 만큼 지불하기 때문에 경제적이다.

  • AWS는 한국어로 된 레퍼런스가 가장 많고, 국내 시장 점유율이 가장 높은 클라우드 서비스 프로바이더이다.

왜 EC2인가

  • EC2는 AWS내에서 컴퓨팅 리소스를 사용할 수 있는 서비스이다.

  • 처음부터 상용 서비스를 다룰 수 있는 범위가 좁아질 수 있다고 한다.

EC2 인스턴스 만들기

인스턴스란

참고
클라우드 컴퓨팅에서 인스턴스는 타사 클라우드 서비스에서 제공하는 서버 리소스

  • EC2 접속

  • 인스턴스 시작
    내가 사용할 서비스가 기본적으로 설치할 운영체제 선택(OS 이미지) : Ubuntu Server 18.04 를 선택했다.

    	- 아키텍처 : 64비트(x86)
	- 인스턴스 유형 : t2.micro
	- 키페어
		a. 키페어 이름 입력
		b. Key pair type : RSA
		c. Private key file format : .pem (for mac)
	- 나머지 설정은 default

인스턴스 정보

  • 인스턴스 ID : 서버의 고유 아이디

  • Public IPv4 주소 : 외부에서(Public) 접속할 때의 주소

  • Public IPv4 DNS : 외부에서 접속할 아이디의 도메인

Route 53 설정하기

Route 53 이란?

Amazon Route 53는 가용성과 확장성이 뛰어난 DNS(도메인 이름 시스템) 웹 서비스. Route 53을 사용하여 세 가지 주요 기능, 즉 도메인 등록, DNS 라우팅, 상태 확인을 조합하여 실행할 수 있다. [ 참고 ]

DNS 생성하기

참고

  • Registered Domain 접속

  • Register Domain 에서 원하는 도메인 이름을 입력

  • 비슷한 이름, 확장자별 가격을 확인하고 자신이 원하는 것을 add-to-cart, continue

  • Registrant Contact 에서 정보를 입력하고 continue

  • Contact detail 을 확인하고, 인증서 자동갱신 여부를 체크하고, 하단의 Terms and Condition 에서 agree.

  • Complete Order

  • console.aws.amazon.com/route53/home#DomainRequests 에서 Pending 중인것 확인

  • 도메인 생성 요청이 완료가되면, Registered Domain 에서 확인할 수 있다.

  • Register 단계에서 입력한 이메일로 verify email 이 도착해 있다. 해당 이메일의 link를 클릭해서 valid email인것을 인증.

Record 설정하기

레코드(DNS 레코드)

도메인 또는 하위 도메인의 트래픽을 라우팅할 방법을 정의하는 데 사용되는 호스팅 영역 내 객체. 예를 들어 IP 주소가 192.0.2.234인 웹 서버로 트래픽을 라우팅하는 example.com과 www.example.com의 레코드를 생성할 수 있습니다. 참고

  • Registered Domain의 호스팅 영역 → 내가 설정한 DNS 주소 클릭 → 레코드 생성(Create Record)

  • 빠른 레코드 생성

    	레코드 이름 설정
	레코드 유형 선택 (회사 내부용 도메인 주소는 CNAME) : A Record 선택
	값 (Value) : EC2 서버의 Public IPv4 주소 입력
	TTL(Time To Leave) : DNS가 정보를 유지할 시간을 설정
	라우팅 정책 : simple (단순 라우팅)

  • 연결 확인

//host 명령어는 DNS를 lookup 해서 Record, IP 정보 등을 간단하게 확인할 수 있는 명령어이다.
MacBookPro ~ % host simple.de-dns.link
simple.de-dns.link has address 52.79.80.109

GSLB (Global Server Load Balancing)

GSLB 브랜드

  • AWS, GCP, Azure
  • Akamai
  • Cloudflare
  • Citrix
  • NGINX
  • NCloud
  • NHNCloud

GSLB 란?

GSLB는 이름을 보면 LoadBalancer 의 일종 같지만, 실제로는 client 가 전세계 어디에 있던지 빠르게 신뢰성있는 응답을 제공하기위한 지능적인 DNS이다. 초기에는 전 세계에 퍼져서 DNS 서비스를 제공할 수 있다는 것으로 알려졌지만, 그것을 위해 기능적으로 많은 것들이 필요해서 필요한 기술의 총체로 말할 수 있다.

GSLB의 주요 기능

GSLB 제품이나 서비스마다 제공하는 기능이나 특이점이 다를 수 있지만, 통상 아래와 같은 기능들을 제공할 때 GSLB가 가능하다고 볼 수 있다.

  • Performance: client의 request를 네트워크상 가까운 서버로 연결할 수 있다. 트래픽을 지역에 맞게 분산해서 연결할 수 있다.

  • Customized Content: 지역이나 언어별로 커스텀한 콘텐츠를 자동으로 제공할 수 있다.

  • Disaster Recovery: 네트워크 장애나 데이터센터 장애 등이 발생했을 때, 다른 지역에 있는 서버로 redirect해서 HA(high availability) 구성이 가능하게 한다.

  • Maintenance: 연결 규칙이나 구성이 (쉽게, 소프트웨어적으로) 변경 가능해야한다.

  • Compliance: 국가나 지역의 규제에 맞게 요청을 전달할 수 있다.

AWS Route53에서 TCP 연결

AWS에서는 GSLB라고 따로 정의한 상품이 있지는 않지만, Route53의 라우팅 정책을 통해서 GSLB의 기능적인 목표를 달성할 수 있다.

nc command로 TCP 연결 받기

EC2의 보안규칙에 모든 TCP 연결을 받을 수 있도록 설정한다.

// EC2 서버에 접속하려면 먼저 key file 의 권한을 400으로 변경해줘야 함
% chmod 400 be-study.pem

// 권한이 변경되었음을 확인
% ls -al
total 24
drwxr-xr-x  4 sonar0  staff   128 12 16 18:22 .
drwxr-xr-x  4 sonar0  staff   128 12 16 18:22 ..
-rw-r--r--@ 1 sonar0  staff  6148 12 16 18:22 .DS_Store
-r--------@ 1 sonar0  staff  1674 12 16 18:15 be-study.pem

// EC2 서버 접속
// ssh -i [키 파일 이름] ubuntu@[EC2 인스턴스 퍼블릭 IPv4 DNS / IPv4 주소]
% ssh -i be-study.pem ubuntu@ec2-13-209-3-228.ap-northeast-2.compute.amazonaws.com 

// 접속 확인
ubuntu@ip-172-31-38-250:~$ hostname
ip-172-31-38-250

// 2000번 포트 열기
// -l localhost, -p 2000 해당 포트로 listen, -k 응답 후에도 계속 live
ubuntu@ip-172-31-38-250:~$ nc -l -p 2000 -k

로컬 서버에서 echo 명령어로 TCP 연결이 됐는지 확인

// echo [message] | nc [adress] [port number]
MacBookPro ~ % echo hiiii | nc 15.164.97.16 2000
MacBookPro ~ % echo server2 | nc 15.164.97.16 2000

제대로 에코 메세지가 출력되는 것으로 연결을 확인할 수 있다.

profile
Sonar0
초보 개발자
이전 포스트

CacheDB (Redis)

다음 포스트

AWS Route 53에서 여러가지 Routing 정책

0개의 댓글