HTTPS 적용 사전 지식
HTTPS를 적용하면서 적용과정만 작성했기 때문에 이곳에 관련 지식들을 정리해봤다.
HTTPS란
HTTPS는 HTTP 프로토콜에 SSL 기술이 더하여 전달되는 데이터를 SSL 암호화하여 보안성을 더 높였다.
간단히 말하자면 HTTPS(Hypertext Transfer Protocol Secure)는 이름처럼 HTTP 프로토콜보다 보안성이 뛰어난 프로토콜이다.
HTTPS를 사용하려면 일반적으로 관련 인증서가 필요하다. 이 인증서를 발급받는데도 비용이 든다.
그리고 그 인증서를 적용하려는 웹서버에 올려 적용하고, HTTP > HTTPS 리다이렉션 등을 해야 한다.
AWS 클라우드는 CloudFront와 함께 이것을 쉽게 처리할 수 있다
CloudFront를 이용한 HTTPS 구성
Client는 뒷단 서버에 HTTPS 프로토콜로 요청을 보낼 것이다.
여기서 point는 CloudFront 뒤로는 HTTP 통신을 한다는 것이다.
외부 인터넷을 통해오는 요청만 HTTPS 프로토콜을 이용하고 이후 뒷단에 Private 한 공간은 HTTP 프로토콜을 이용함으로써
EC2서버나 S3는 HTTPS 프로토콜을 위한 별도의 작업이 필요하지 않다는 것이다.
위 그림에는 없지만, 필요하다면 CloudFront와 ALB를 연결해 뒷단(S3, EC2 etc…)까지 HTTPS 요청 전달도 고려할 수 있다.
HTTPS통신은 SSL 인증서가 필요하다고 했었다.
AWS에서 인증서는 ACM 서비스가 담당하며 HTTPS 연동을 위해 사용되는 것이라면 무료로 무한정 제공된다.
DNS
도메인 이름 시스템(DNS)은 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com)을
머신이 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환하는 시스템을 말한다.
인터넷을 구성하고 있는 IP 주소는 IPv4의 경우 192.168.0.1 같이 숫자로 구성된다.
실제 컴퓨터 통신에서는 naver.com이라는 문자열 주소를 192.168.0.1 같은 IPv4 주소로 변환해주는 서비스가 필요하다.
이런 서비스를 DNS 서비스라고 한다.
1. USER가 브라우저에 ‘haedal.com’ 라는 도메인을 입력하면 도메인 주소들을 가지고 있는 네임서버(DNS 서버)에 접속한다.
2. 네임서버에 접속한 도메인(haedal.com)과 연결된 IP 정보(123.456.789)를 확인하고 IP를 사용자 PC에게 전달한다.
3. 사용자 PC는 전달 받은 서버의 IP 주소로 접속한다.
4. 서버의 IP로 연결된 브라우저에 서버의 내용(홈페이지)을 출력한다.
DNS 동작 순서
1. 웹 브라우저에 www.naver.com을 입력하면
먼저 PC에 저장된 Local DNS(기지국 DNS 서버)에게 www.naver.com 이라는 hostname에 대한 IP 주소를 요청한다.
Local DNS에는 www.naver.com 의 IP 주소가 있을 수도 없을 수도 있다.
(여기서는 Local DNS에 www.naver.com 의 IP 주소가 없다고 가정)
만일 네이버에 접속했던 전적이 있다면, Local DNS에 접속정보가 캐싱이 되어있어서 바로 PC에 IP 주소를 주고 끝난다.
(1번 → 8번으로 넘어가 빠르게 웹페이지에 접속할 수 있다.)
Local DNS(기지국 DNS 서버) 란?
기본적으로 인터넷을 사용하기 위해선 IP를 할당해주는 통신사(KT, SK, LG 등…)에 등록하게 된다.
컴퓨터의 LAN선을 통해 인터넷이 연결되면, 가입했던 각 통신사의 기지국 DNS 서버가 등록되게 된다.
KT를 사용하는 집이면 KT DNS가 되고, SK 사용하는 집이면 SK DNS가 자동으로 셋팅 된다.
2. Local DNS는 이제 www.naver.com 의 IP 주소를 찾아내기 위해 다른 DNS 서버들과 통신(DNS 쿼리)을 시작한다.
먼저 Root DNS 서버에게 www.naver.com 의 IP 주소를 요청한다.
Root DNS(루트 네임서버) 란?
Root DNS는 인터넷의 도메인 네임 시스템의 루트 존이다.
ICANN이 직접 관리하는 절대 존엄 서버로, TLD DNS 서버 IP들을 저장해두고 안내하는 역할을 한다.
전세계에 961개의 루트 DNS가 운영되고 있다.
3. Root DNS 서버는 Root DNS 서버 는 www.naver.com 의 IP 주소 를 찾을 수 없어
com 도메인을 관리하는 TLD DNS 서버로 가라고 응답한다.
4. Local DNS 서버는 com 도메인을 관리하는 TLD DNS 서버(최상위 도메인 서버)에 www.naver.com에 대한 IP 주소를 요청한다.
TLD(Top-Level Domain, 최상위 도메인) DNS Server 란?
TLD는 도메인 등록 기관(Registry)이 관리하는 서버로, 도메인 네미의 가장 마지막 부분을 말한다.
.com 이나 co.kr 같은 도메인들을 관리하고 부여하는 서버이다.
Authoritative DNS 서버 주소를 저장해두고 안내하는 역할을 한다.
5. com 도메인을 관리하는 DNS 서버에도 해당 정보가 없으면,
Local DNS 서버에게 www.naver.com 의 IP 주소 찾을 수 없음. 다른 DNS 서버에게 물어봐 라고 응답을 한다.
6. Local DNS 서버는 naver.com DNS 서버(Authoritative DNS 서버)에게 다시 www.naver.com 의 IP 주소 를 요청한다.
Authoritative DNS Server 란?
실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버다.
그래서 권한의 의미인 Authoritative가 붙는다. (가비아에서 직접 입력)
일반적으로 도메인/호스팅 업체의 ‘네임서버’를 말하지만, 개인이나 회사 DNS 서버 구축을 한 경우에도 해당된다.
7. naver.com DNS 서버 에는 www.naver.com 의 IP 주소 가 있다.
그래서 Local DNS 서버에게 www.naver.com에 대한 IP 주소는 222.122.195.6 라는 응답을 한다.
8. 이를 수신한 Local DNS는 www.naver.com 의 IP 주소를 캐싱을 하고 이후
다른 요청이 있을시 응답할 수 있도록 IP 주소 정보를 단말(PC)에 전달해 준다.
Recursive Query
이렇게 Local DNS 서버가 여러 DNS 서버에 차례대로
Root DNS 서버 → TLD DNS 서버(.com) → Authoritative DNS 서버(naver.com) 요청하여
그 답을 찾는 과정을 재귀적 쿼리 Recursive Query 라고 부른다.
→ 결과물(IP 주소)를 돌려주는 작업
Iterative Query (반복적 질의)
Recursive DNS 서버가 다른 DNS 서버에게 쿼리를 보내어 응답을 요청하는 작업이다.
Recursive 서버가 권한 있는 네임 서버들에게 반복적으로 쿼리를 보내서 결과물(IP 주소)를 알아낸다.
Recursive 서버에 이미 IP 주소가 캐시 되어있다면 이 과정은 건너 뛴다.
DNS 구성 요소
Route 53을 적용하다보면 레코드 종류가 여러가지가 있는 것을 확인할 수 있다.
해당 링크를 통해 구글 관리 콘솔 도구 상자를 통해서 조회할 수 있다.
DNS Record
DNS Record는 DNS 서버가 해당 패킷을 받았을 때 어떤 식으로 처리할지를 나타내는 지침을 말한다.
→ DNS 상에서 도메인에 관한 설정을 하기 위해 사용되는 일련의 설정 문자
DNS 레코드 종류
| 종류 | 설명 |
|---|---|
A | 해당 도메인 주소가 가지는 IP(1:1) |
CNAME | 별칭을 부여한 특정 도메인 주소 |
NS | 영역을 풀이할 수 있는 DNS 서버 목록 |
SOA | 도메인의 시작점(Start Of Authority) |
A
A 레코드는 DNS에 저장되는 정보의 타입으로 도메인 주소와 서버의 IP 주소가 직접 매핑 시키는 방법이다.
ex) 도메인 이름 : domain.com - 맵핑된 주소 : 111.222.333.444
→ A 레코드는 domain 도메인은 IP 주소 111.222.333.444에 연결 되어있다 라고 말하는 역할
A 레코드는 반드시 도메인과 IP간의 1:1 매칭이 될 필요는 없다.
도메인 매핑 설정에 따라서 1:N, N:1이 될 수도 있다.
CNAME (Canonical Name record)
CName 레코드는 도메인 별명 레코드라고 부르며,
도메인 주소를 또 다른 도메인 주소로 이중 매핑 시키는 형태의 DNS 레코드 타입이다.
→ 도메인 주소로 연결한 부분에 다시 한번 도메인 주소로 연결하는 방식이다.
CNAME 레코드는 무조건 다른 도메인 주소를 등록해야 하며 A 레코드처럼 직접 IP 주소를 등록해서는 안 된다.
ex) domain.com 도메인이 있을 때, 이 도메인의 CNAME을 domain22.com으로 정해서
domain22.com을 입력하면 domain.com으로 접근되는 형식이다.
그 다음 domain.com에 매핑된(A 레코드) IP 주소 111.222.333.444 을 얻어
최종적으로 서비스에 접속하게 되는 방식이다.
| 서비스 | 도메인 주소 | 등록 주소 | Type(형식) |
|---|---|---|---|
| domain | domain.com | 111.222.333.444 | A |
| domain2 | domain22.com | domain.com | CNAME |
A vs CNAME
DNS는 Domain Name System의 약자로 naver.com 같은 문자열 주소를 IP 주소로 해석해주는 네트워크 서비스를 말한다.
DNS 서버에는 도메인 주소와 IP 주소의 쌍(Pair)이 저장된다.
예를 들어,
| . | . |
|---|---|
naver.com | 192.168.0.1 |
google.com | 172,17.0.1 |
plusblog.co.kr | 10.234.34.12 |
이런 정보가 DNS 서버에 저장되고 사용자가 웹 브라우저나 프로그램에서 naver.com을 요청하면
이 테이블에서 naver.com을 찾아 192.168.0.1 을 응답해준다.
사용자의 웹 브라우저나 프로그램은 이 IP 주소를 이용해서 통신하게 된다.
결국 위 테이블에서 하나의 행(Row)를 ‘레코드(Record)’라고 하며, 저장되는 타입에 따라 A Record와 CNAME으로 구분할 수 있다.
A 레코드의 장점은 한번의 요청으로 찾아갈 서버의 IP 주소를 한번에 알 수 있다. (= 빠르다)
단점은 IP 주소가 자주 바뀌는 환경에서는 조금 번거로울 수 있다.
예를 들어 coco.site에서 A레코드로 IP 주소 1.0.11.111을 매핑했다고 가정한다.
그러다가 IP 주소를 2.55.3.333으로 변경되었다고 한다면
실 서버주소와 도메인에 맵핑된 주소가 달라 접속이 불가능해질 것이다.
따라서 도메인의 A레코드를 변경해줘야 한다.
도메인을 수십 개 관리하고 있는 환경에서는 번거로워지게 된다.
NAME 레코드의 장점은 IP 주소가 자주 변경되는 환경에서 유연하게 대응할 수 있다.
예를 들어, haedal.com 와 dal.com 두 개의 서브 도메인을 메인 도메인인 coco.site 로 매핑시키는 CNAME 레코드로 저장하고,
coco.site 라는 주소를 서버 IP 1.0.11.111 주소로 매핑시키는 A 레코드로 저장했다면,
서버의 IP 주소가 바뀌었을 때 main.co.kr의 A 레코드 정보만 변경시키면 된다.
그러나 CNAME 레코드의 단점은
맵핑을 중복으로 연달아 해서 실제 IP 주소를 얻을 때까지 여러번 DNS 정보를 요청해야 한다는 점이다.
DNS 정보를 해석하는데 경우에 따라서 성능저하를 유발할 수 있게 된다.
정리 하자면, A레코드와 CNAME은 장점과 단점이 서로 상반되어 있다고 보면 된다.
| Type | 장점 | 단점 |
|---|---|---|
| A | 도메인이 바뀌어도 IP는 그대로 이므로 유지가 된다. | 서버 이전등의 문제로 IP가 변동될시에 일일히 변경해야 한다. |
| CNAME | 서버 이전등의 문제로 IP가 변동될시에 변경하지 않아도 된다. | 도메인이 바뀌면 변경해야 한다. 여러 번 요청이 될 경우 성능 저하가 일어날 수가 있다. |
NS (Name Server)
NS 레코드는 네임 서버 레코드로 도메인에 대한 네임서버의 권한을 누가 관리하고 있는지 알려주는 레코드다.
쉽게 말해, 내가 dal.site 라는 도메인을 gabia에서 구입해서 사용하고 있다고 하면,
dal.site 도메인을 관리하는 네임 서버는 당연히 gabia가 되게 된다.
즉 NS 레코드는 어떤 도메인에 대한 처리를 다른 도메인 네임 서버에게 위임하는 기능을 가진 레코드이다.
ex) dal.site의 네임서버
ns1.dal.site
ns2.dal.site
ns3.dal.site
ns4.dal.site
DNS 서버 자신에서 domain name에 대한 주소를 알아내지 못할 때, 이 NS 레코드에 정의된 서버로 가서 주소를 알아오게 된다.
TTL(Time To Live)라는 값은 DNS서버나 사용자 PC의 캐쉬(메모리)에 저장되는 시간을 말한다.
SOA (Start of Authority)
SOA레코드는 네임서버가 해당 도메인에 관하여 인증된 데이터를 가지고 있음을 증명하는 레코드이다.
이 레코드는 기본 이름 서버, 도메인 관리자의 전자 메일, 도메인 일련 번호 및 영역 새로 고침과 관련된 여러 타이머를 포함하여
DNS 영역에 대한 핵심 정보를 지정한다.
즉, SOA레코드가 없는 도메인은 네임서버에서 정상적으로 동작하지 않게 되는 것이다.
SOA레코드는 도메인당 1개이다.
하늘색과 주황색 표시된 부분은 같은 내용이며 하늘색을 풀어쓴 것이 주황색이며 하늘색의 시간은 초단위이다.
◼️ Mname / primary name : 도메인에 대한 기본 호스트네임
◼️ RName / mail addr : 관리자의 이메일 주소. 일반적인 이메일 형식인 @가 아니라 마침표가 들어있음.
◼️ Serial : 도메인의 갱신 버전 번호. 일반적으로 날짜(YYYYMMDD)형식.
◼️ Refresh : 도메인 영역의 데이터 갱신 여부를 체크하는 주기(초 단위)
◼️ Retry : (장애 등의 이유로)refresh 주기로 체크하지 못했을 경우, 체크를 재시도하는 주기(초 단위)
◼️ Expire : retry의 주기로 체크를 수차례 반복하다가, 도메인을 더이상 신뢰할 수 있는 영역이라고 간주하지 않아 서비스를 중단하는 최대 기한.
◼️ minimum : 도메인을 찾을 수 없는 경우, 네임 서버가 도메인의 부재정보를 캐싱하는 시간
즉, Refresh 시간만큼 기다렸다가 Secondary Name Server는 Primary Name Server에 DNS 정보를 물어본다.
DNS 정보는 SOA 레코드가 가장 먼저 전달되는데, SOA 레코드의 Serial 정보를 보고
Secondary Name Server에 보관된 Serial과 다르다면 DNS 정보를 전체 가져와서 갱신한다.
Route 53
AWS에서 제공하는 DNS(Domain Name System)이다.
Reference