Https 도입과정 DNS 구조 이해(브라우저에 도메인 입력시 과정)
인트로
이 주제는 요근래 백엔드 파트로 도메인을 사고 배포하는 과정에서 예전에 제대로 잡히지 않은 부분들이 세팅을 하면서 알게 되어 개인적으로 정리하기 위한 글이라, 해당 개념에 대한 정의나 정해져있는 정보에 대한 글을 쓰지않고 내가 이해한 흐름대로 써내려가고자한다.
상황
먼저 상황은 자바스프링부트 프로젝트를 ec2 인스턴스를 생성해서 해당부분에서 build하고 백그라운드로 실행하도록 구현한 상태,
postman 및 클라이언트에서 해당 api의 endpoint 별로 데이터가 잘 내려오는지 확인하기위해 public ip address 또는 public dns주소가 필요했고 ec2 인스턴스를 생성시 해당 정보를 제공하기때문에 해당 주소들로 api 테스트하였다.
하지만 http 라는 부분과 ssl 도입이 필요했고 프론트엔드 https에서 서버 http로 요청시 안되는부분들도 있어서 https로 바꾸기로 결정
예전에 프론트엔드로 작업시 완전 초기에 https로 따라해보거나 http로만 배포한 상태였고 실제 실무에서도 직접적으로 작업할 상황이아니여서 해당 플로우가 정확히 큰 그림을 그리지 못하고있었고 백엔드 ec2의 도메인을 구축하면서 그냥 넘어갔던부분들이 하나둘씩 이해하기시작하였다. 먼저 도메인의 경우 가비아를 통해 구입, AWS로 DNS관리(Route53) 및 프로젝트 관리담당(EC2)하도록 설정, 이 과정중에 Reverse Proxy(SSL 관리) 및 트래픽 분산이라는 부분을 적용하기위해 AWS 로드밸런서 적용하였고 이렇게 추가되다보니 로드밸런서 대상 그룹, Route53 A레코드, Cname 레코드 등 여러가지 섞이면서 뭐가뭔지 몰라서 테스트해가면서 이해하기시작하였다.
본론
본론으로 들어가자면 가비아에서 도메인을 사고 가비에서도 A레코드나 CNAME을 설정할수있다. 그런데 이때당시 이해가 안간게 이미 Route53에서도 레코드 A라는걸 입력했고 Cname이란것도 따라했는데 인터넷 검색시 이게 나의 상황과 맞지않은부분이니 가비아에서도 관리툴에서 레코드 A나 Cname을 입력해라 이런 정보들이있었음, 이부분은 가비아 쪽의 서버네임을 사용시에 관리를 위해 하는 부분이지만 나의 경우 이미 Route53으로 네임서버를 변경하였기때문에 해당하지 않았던 것이다. 그래서 가비아사이트에서는 Ns 주소 4개 입력하라는 부분에 route53의 ns를 다 썼다면 가비아에서는 레코드는 신경안써도된다는 것이다.
위에 NS를 가비아 NS입력란에 입력하기때문에 이제 관리는 AWS route53에서 관리해준다.
그리고 유형 A를 보면 값부분에 IP주소가 아닌 문자열 주소값으로 되어있는데 앞서 말한 로드밸런서를 만들었기때문에 해당 로드밸러서 그룹으로 연결되도록한것이다. 그럼 로드밸런서는 이 트래픽요청을 받고 분산된 또는 특정 Ec2 Ip 정보를 전달 또는 http요청을 하는것이다.
여기까지 이해하고나니 큰 그림은 이해가 되었다. 이를 위해 내가 이해한 그림을 공유하고자한다.
처음 이해했을 당시 그려진 그림 프로젝트 아키텍쳐 및 DNS 구조
그림에서 가비아 NS -> Route53 부분은 정확한 흐름은 아니지만 전체적인 흐름에서 이정도로 이해하게 되었다. 실제론 가비아같은경우 도메인을 팔고 NS도 관리할수있게 하는 부분이지 가비아에서 샀다고해서 도메인이 무조건 가비아를 거치지 않는다. 실제론 등록된게 TLD와 루트 DNS(ICANN)에 등록되는거고 가비아가 아니더래도 도메인을 사는(ICANN 에서 승인 위임한)곳에서도 등록할수있는것이다. 이렇게 까지 아니깐 좀더 깊이있게 또는 제너럴하게 알고싶어졌다. 이유는 보통 면접 질문중에 www.naver.com을 치면 어떻게 되는가 라는 단골질문으로 인터넷에 떠도는데 이때까지만해도 제대로 알지못했다. 그냥 브라우저가 어디로 통하고 어딘가에 캐싱은 있다고하고 어디 최상위 도메인쪽으로 요청갔다가 어쩌고저쩌고 했던기억은 있었지만 정확히 몰랐었고 이 도메인을 적용하면서 갑자기 '아 이부분에 대한게 혹시 그때 그질문부분인가?' 라고 번득였고 그래서 다시한번 찾기시작
찾아보니 이론적으로 다시한번 했던부분이 이해가기 시작했다. 위에는 내가 생각했던 이해도 이고 찾아가면서 도메인 시스템(DNS)에 대한 부분만 다시 흐름과 라이프사이클을 이해하게되었다. 이부분도 글을 쓰고 내가 이해한 부분을 그림으로 공유하고자한다.
내가 이해한 DNS 원리
1. 먼저 클라이언트(일반적으로 브라우저)에서 해당 도메인을 입력한다.
2. 브라우저에서 해당 도메인에 대한 DNS 캐싱된 정보가있는지 체크해보고 없다면 OS 캐싱에서도 확인한다.
3. 만약 없다면 ISP(Internet Service Provider)의 도메인 캐싱여부를 체크한다.
일단 여기까지 이해했을땐 모르는부분을 검색해보면서 알아갔다
첫번째 ISP가뭔데?
이는 우리가 인터넷을 사용할떄 집에 인터넷 모뎀이있을거다 나같은경우는 KT모뎀이있는데 이부분이라고 생각하면되고 이 모뎀이 로컬 NS서버 관리를한다.
두번째 캐싱여부를 체크한다고했는데 어떻게 하고 무슨정보가 있고 만약 도메인에 매핑된 NS가 바뀌거나 IP가 달라진다면 동기화가 틀리면 어떻게 되는데?
단순히 DNS의 최종목적은 도메인과 매핑된 IP Adress를 제공하는것이다. 따라서 도메인의 IP 주소(A레코드), 네임서버(NS) 정보, 그리고 TTL 정보를 가지고있다. 만약 TTL(Time To Live)부분이 30초라면 30초마다 해당 캐싱을 업데이트해주는것이다. 이 TTL의 경우 NS서버쪽에서 설정한 TTL을 그대로 가져오기때문에 정보가바뀐다면 해당 시간에 맞춰 바뀔것이고, 만약 1시간이라고 해놓고 그사이에 정보가 바뀐다면 어쩔수없이 잘못된 캐싱정보로 전달되기때문에 업데이트 된 IP나 NS의 정보를 제공하지못한다는 것이다. 이는 브라우저나 OS 캐싱도 같은 이치라고 보면된다. 그래서 보통 우리가 브라우저에서 강력 새로고침을 하는이유는 해당 브라우저의 캐싱을 지우고 해당 도메인에 대한 정보를 다시 얻고자 하는것이다. 이부분은 보통 컨텐츠 즉 프로젝트에서 기능이 추가되거나 바뀐 부분도 있겠지만 도메인에 대한 정보 또한 이에 해당하는것이다.
4. ISP에도 도메인 정보가 없다면 이제 루트 DNS으로 요청을 보낸다. 여기서 루트 DNS 서버는 중앙관리를 하는 ICANN 기관이다. 그리고 현재 13개의 루트서버 클러스터로 분산되어있다.
5. 요청을 받은 ICANN 루트 DNS 서버는 TLD 서버의 위치를 반환한다. 여기서 TLD 는 Top-Level-Domain 을 뜻하고 도메인 주소에서 상위도메인이다. 예를들어 .net, .co.kr, .com 등이 여기서 해당되고 나의 경우는 .store을 사용하기에 이부분이 TLD 서버 위치정보이다.
이러한 TLD를 제공하는 기관들은 ICANN으로 부터 관리를 위임받은 곳으로 레지스트리(TLD Registry)에 속하고
Verisign, Radix Registry, PIR 등등이 이러한 기관/기업인것이다.
6. 그다음 TLD서버에서 NS서버정보를 넘겨준다. 예를들어 ns-1260.awsdns-29.org. 와 같은 부분이 네임서버 정보이다.
7. 네임서버에서 도메인이름을 관리하며 A 레코드 또는 CNAME레코드를 반환해준다.
8. 최종적으로 얻은 IP adress로 브라우저는 HTTP(S) 요청을 보낸다.
9. 만약 HTTP라면 리스너에 설정된 :80 포트로 요청하게되고 https:443으로 리다이렉트해줬기때문에 https:443으로 리다이렉트된다. 이를 받은 EC2는 내가 설정해준 포트 포워딩으로 해당 프로젝트의 8080포트로 요청을 보낸다
9-1 만약 HTTPS 라면 443포트로 요청이오고 이떄 미리 ACM을 통해 도메인 소유권 인증으로 얻은 ssl인증서를 로드밸런서에서 인코딩된 HTTP요청 복호화작업을 할때 사용하고 해당 ec2 프로젝트 8080포트로 보낸다(Reverse Proxy 서버 역할).
최종 DNS 및 아키텍쳐 간략 이해도
