example.com이라는 하나의 서비스 도메인을 가지고, 개발과 운영으로 분리된 AWS 계정에서 각각의 Route 53으로 도메인을 관리하기 위해서는 하위 도메인을 위임해야 한다. 이때, 필요한 것은 네임 서버 설정이다. 이를 통해 해당 도메인이 어떤 호스트 영역에서 관리되는지 확인이 가능하다.
하위 도메인 위임에 대해서, DNS 동작 원리와 연관 지어 알아보도록 하자.
도메인 규칙
필자는 이번 포스팅에서, 하나의 메인 도메인 southouse.com을 발급받았다고 가정하고 진행한다.
개발 환경은 *.dev.southouse.com이라는 규칙을 가지고 서비스에 따라 app.dev.southouse.com 등으로 지정하고, 이를 개발 도메인이라고 부르기로 했다.
운영 환경은 *.southouse.com이라는 규칙을 가지고 서비스에 따라 app.southouse.com 등으로 지정하고, 이를 운영 도메인이라고 부르기로 했다.
따라서, 개발 환경에서는 southouse.com의 하위 도메인인 dev.southouse.com을 메인 도메인으로 사용한다고 생각하면 된다.
먼저, Route 53에서 하나의 도메인을 가지고 하위 도메인을 다른 계정으로 위임하는 설정을 해보도록 한다.
호스팅 영역 생성
운영 계정으로 로그인하여 발급받은 도메인에 대해서 아래와 같이 호스팅 영역을 생성해준다.
AWS에서 도메인을 구매하여 등록하면, 자동으로 호스팅 영역을 생성해준다.
개발 도메인 호스팅 영역 생성
개발 계정으로 로그인하여 개발 도메인에 대해서 아래와 같이 호스팅 영역을 생성해준다.
호스팅 영역을 생성하게 되면, 기본적으로 해당 도메인을 라우팅 시켜주는 NS 레코드가 자동으로 생성되게 된다.
이제 해당 네임 서버 값을 운영 도메인의 호스팅 영역에서 개발 도메인의 이름을 가진 NS 레코드에 추가해주면 된다.
운영 도메인 호스팅 영역에 개발 도메인 네임 서버 등록
다시 운영 계정으로 돌아와서 운영 도메인의 호스팅 영역에서 개발 도메인에 대한 NS 레코드를 등록해준다.
여기서 TTL(초)값을 짧게 해두면, 갱신이 빨라지므로 요구사항에 맞춰 설정하고 갱신이 된 이후에 네임 서버의 안정성 유지를 위해 값을 다시 늘리는 것을 추천한다.
마지막으로, 다시 개발 계정으로 돌아와서 서비스 도메인을 등록하기 위해 A 레코드를 생성한다.
값은 서비스가 동작하고 있는 서버의 IP를 입력한다.
이제 브라우저에서 app.dev.southouse.com으로 접속하면 52.79.104.11 서버로 연결시켜주게 된다.
이렇게 하나의 서비스 도메인을 가지고, 개발과 운영으로 분리된 AWS 계정에서 각각의 Route 53으로 도메인을 관리할 수 있게 되었다.
그런데, 여기서 의문점이 한가지 생겼다. 이렇게 저렇게 설정하여 라우팅하는건 알겠는데
'어떻게 브라우저 단에서 해당 도메인의 호스팅 영역을 찾아가서 서버의 IP를 정확하게 캐치할 수 있는 것인가?'
이 질문에 대한 답은 DNS 동작 원리에서 설명할 수 있다.
DNS 동작 원리
위의 설정을 기반으로 클라이언트에서 `app.dev.southouse.com`을 접속하기 까지의 DNS 동작이다.
그림의 동작을 순서대로 설명해보자면,
- 브라우저에서 app.dev.southouse.com 를 입력하여 접속을 시도하는데, 이때 로컬 네임 서버에 질의를 하게 된다.
→ 만약, 이 때 이전에 접속했던 도메인에 경우에는 로컬 네임 서버에서 캐시 하여 정보를 갖고 있는데, 이 경우에는 로컬 네임 서버에서 바로 10번 단계로 넘어간다. - 루트 네임 서버에게 app.dev.southouse.com 도메인을 질의한다.
- 루트 네임 서버는 .com 네임 서버 정보를 응답한다.
- .com 네임 서버에게 app.dev.southouse.com 도메인을 질의한다.
- .com 네임 서버는 southouse.com 네임 서버 정보를 응답한다.
- southouse.com 네임 서버에게app.dev.southouse.com 도메인을 질의한다.
→ 이 때, 운영 도메인의 호스팅 영역에 접근하게 된다. - southouse.com 네임 서버는 dev.southouse.com 네임 서버 정보를 응답한다.
- dev.southouse.com 네임 서버에게app.dev.southouse.com 도메인을 질의한다.
→ 이 때, 개발 도메인의 호스팅 영역에 접근하게 된다. - dev.southouse.com 네임 서버는 자신의 호스팅 영역에서 app.dev.southouse.com의 A레코드를 통하여 IP 정보를 응답한다.
- 로컬 네임 서버는 응답받은 IP 정보를 브라우저에게 전달한다.
- 브라우저는 IP 52.79.104.11를 가진 서버로 접속한다.
이처럼 우리가 도메인을 처음에 구매하게 되면, 루트 네임 서버와 최상위 도메인(TLD)인 .com 네임 서버에 등록이 되고,
처음 접속하는 혹은 도메인에 대해 캐시가 되지 않은 브라우저의 경우에는 위의 복잡한 과정을 거치게 된다.
그렇다면, 위의 DNS 동작 원리에서 루트 네임 서버와 .com 네임 서버는 도대체 뭐길래 수많은 도메인들을 컨트롤하는 걸까?
루트 네임 서버란?
루트 네임 서버(root name server)는 인터넷의 도메인 네임 시스템(DNS)의 루트 존이다. 루트 존의 레코드의 요청에 직접 응답하고 적절한 최상위 도메인(TLD)에 대해 권한이 있는 네임 서버 목록을 반환함으로써 다른 요청에 응답한다.
말 그대로 네임 서버의 시작점인데, 이는 어떤 기관 혹은 기업들에 의해서 관리되고 있고
아래와 같이 수많은 루트 네임 서버들이 존재한다.
전세계 루트 서버 리스트의 일부
최상위 도메인(TLD, Top-Level Domain)
우리가 흔히 사용하는 도메인 중 .com .kr .jp등 도메인의 가장 끝 부분에 위치하고, 이를 최상위 도메인이라고 부른다.
각각의 도메인마다 쓰임이 있는데, 이는 국제 인터넷 주소 관리 기구인 ICANN에서 관장한다.
최상위 도메인(TLD, Top-Level Domain)의 구조
이렇게 다양한 기관, 기구, 기업에서 도메인의 효율적인 사용을 위해 서비스를 제공하고 있다.
Reference
댓글