root 도메인을 www 서브도메인으로 리다이렉트

 

참고

Route 53를 사용하여 도메인을 다른 도메인으로 리디렉션

How do I redirect a naked (apex) domain to www using Route 53?

Using Application Load Balancers to Handle Multiple Domain Redirects

배경

현재 사이드 프로젝트를 진행하며, aws route53에서 구매한 도메인을 기반으로 개발한 서비스를 라우팅해주고 있다.

구매한 도메인은 nangmanski.com으로써, 이는 root(루트) 도메인 또는 naked, apex 등으로 불린다.

즉 메인 도메인으로써, 일반적으로는 해당 루트 도메인을 프론트엔드 서비스로 라우팅해주고는 한다.

반면, 우리가 아는 일반적인 웹 서비스는 앞에 www가 붙어있다. 예) www.naver.com

이는 world wide web의 약어인데, 웹 초창기 시절부터 홈페이지를 라우팅하는 대표적인 도메인으로 사용하면서 대부분은 루트 도메인과, 해당 www.도메인을 동일시하여 생각한다.

하지만 이는 사실상 서브 도메인이다. 즉, 우리로 가정하면 nangmanski.com 과 www.nangmanski.com 이 엄밀히 다른 곳으로 라우팅할 수 있다고 생각하면 된다.

위에서 이야기했듯이 보통 사람들은 관습적으로 이 둘을 같은 도메인으로 생각하기에, 일반적으로는 해당 루트 도메인과 www 서브도메인 모두 동일한 서비스로 라우팅되게 하는 것이 알맞다.

 

현재 우리의 경우는 프론트엔드, 백엔드 각각 하나씩 총 두개의 서비스를 띄웠다.

프론트엔드 서비스는 www 서브 도메인에 라우팅 해주었고, 백엔드 서버는 또 다른 특정 서브 도메인으로 라우팅 해주었다.

• 프론트엔드 서버(www.nangmanski.com): EC2 한대, 로드밸런서 한대
• 백엔드 서버(xxx.nangmanski.com): EC2 한대, 로드밸런서 한대

각자 다른 인스턴스에 배포를 진행했기 때문에, 각자 다른 서브도메인으로 라우팅되는 주체를 다르게 하였다.

여기서 각 EC2의 공인 IP 주소로 연결해주어도 되지만, 로드밸런서를 활용한 이유는 SSL 인증서를 포함시키기 위함이다.

즉 흔히 보는 https를 먹이기 위해서 사용했다고 생각하면 된다.

인스턴스 내에서 사설 인증서를 발급하는 방법도 있지만, AWS에서 제공해주는 ACM 서비스가 가격도 비싸지 않고, 같은 클라우드 서비스 내에서 처리할 수 있기 때문에 편하다.

ACM의 경우는 아래와 같이 *을 붙여줘서 와일드카드 도메인, 즉 모든 서브도메인에 대해 발급을 진행했다.

 

문제와 해결

문제 1)

여기서 문제가 발생했다. www 서브도메인에 대해서는 정상적으로 프론트엔드 서비스가 접근이 되지만,

루트 도메인에 대해서는 접근이 안되는 것이었다.

 

해결 1)

이는 당연하게도, 루트 도메인에 무언가 연결을 해주지 않았기 때문이었는데, 이를 해결하기 위해 동일한 프론트엔드 서비스를 라우팅시켜주었다.

 

문제 2)

 

기존 로드밸런서에는 위와 같은 설정을 통해, http로 접속시 https로 리다이렉트 되게 만들어주었다.

www 서브도메인은 의도한대로 정상적으로 동작하였지만,

당연하게도 *.nangmanski.com 으로 ACM을 받았고, 이를 로드밸런서에 연동해 주었기에

루트 도메인에서는 http 접속시에만 동작하고, 당연하게도 리다이렉트나 https로의 접속은 안되었다.

당연하게도 nangmanski.com 루트 도메인으로는 ACM을 안 받았기에 + 그리고 역시 해당 로드밸런서는 *.nangmanski.com 으로 연동되어 있기에

 

해결 2)

 

로드밸런서의 http 포트와 https 포트에서 위와 같은 설정을 해주었다.

참고: https://medium.com/swlh/using-application-load-balancers-to-handle-multiple-domain-redirects-8e5077be3b28

하지만 이는 반쪽자리 해결책이었다.

http에서는 정상적으로 동작했지만, 즉 http://nangmanski.com 으로 접속하면 정상적으로 리다이렉트 되었지만, https에서는 동작하지 않았다.

이는 아무래도 기본적으로 해당 https(443) 포트에 ACM이 걸려있고, 이는 *.nangmanski.com 으로 발급 받은 것이 때문이다.

그렇기에 당연하게도 발급 받은 인증서가 없는 nangmanski.com 으로는 접속조차 안되는 것이었다.

 

문제 3)

그래 까짓꺼 인증서 가격 얼마한다고, 하나 더 받아보지 뭐…

 

루트 도메인으로도 인증서를 발급 받았다.

하지만 여기서 또 문제가 발생했다. 얘를 어떻게 연결해주지…? 만약 로드밸런서 당 하나의 인증서만 연결해줄 수 있는 것이라면, 또 로드밸런서를 하나 더 생성해야할테고, 이는 정말 쓸데 없는 비용 낭비가 될 것이다.

로드밸런서 가격은 생각보다 비싸다…

 

해결 3)

굳이 생성할 필요 없이, 루트 도메인을 www 서브도메인으로 라우팅 시켜주면 되지 않을까?

하지만 루트 도메인에는 cname 별칭 레코드를 쓰거나 해줄 수 없었다…

bar.comis a zone therefore it implicitly has an SOA record for the bar.com  name. You can't have both a SOA record and a CNAME with the same name.

 

여기서 정말 많은 고민을 했다…

 

1) 로드밸런서에 multiple ACM 인증서를 연동해주는 법…? 과연 될까…?

2) 아래 참고 링크처럼 s3 버킷을 nangmanski.com 이름으로 생성하고 정적사이트 호스팅 설정 및 www.nangmanski.com 으로 리다이렉트 해주기

참고: https://aws.amazon.com/ko/premiumsupport/knowledge-center/redirect-domain-route-53/

 

하지만 매우 간단한 방법이 존재했다.

However, given that SOA records are generally used only for zone maintenance, these situations where you want to provide a CNAME at the zone's apex are quite common. Even though the RFC prohibits it, many engineers would like a behaviour such as: "follow the CNAME unless the query explicitly asks for the SOA record". That's why Route 53 provides alias records

이름하여 Route 53에서는 alias records 라는 것을 제공한다는 것이다!!

 

위와 같이 수정해주었다.

 

문제 4)

후.. 문제는 쉽게 끝나지 않았다.

여기서의 결과는 해결 2) 부분과 동일했다. http로의 접속은 정상적으로 www 서브도메인으로 리다이렉트 되지만, https로 접속했을 때는 해결이 안되었다.

http://example.com -> https://www.example.com
https://example.com -> ETIMEDOUT
http://www.example.com -> https://www.example.com
https://www.example.com -> https://www.example.com

위와 같이 한 개 케이스에 대해서 상황이 해결이 안되는 것이다…

 

해결 4)

순서를 바꿔서, 기존 로드밸런서에는 nangmanski.com 을 연동해주고, 이후 www 서브도메인에 cname 별칭 레코드를 사용해서 루트 도메인 연동해주기

해답은 위의 방법이었다. 위의 방법 역시, www 서브도메인 접속시 https 케이스에서 문제가 생길 줄 알았는데, 정상적으로 동작하였다.

 

그 이유는 결국 브라우저는 www 로 접속시 루트 도메인의 IP를 요청할 것이고, 이에 따라 자연스럽게 해당 도메인의 인증서를 받아오기 때문에, 모든 케이스에서 정상 동작하는 거로 파악된다.

 

결과

http://example.com -> https://example.com
https://example.com -> https://example.com
http://www.example.com -> https://example.com
https://www.example.com -> https://example.com

정상적으로 위와같이 동작한다.

쉬운 길을 놔두고 정말 돌고 돌아갔다….