AWS Route 53에 등록된 서브도메인 github page에 연결.

고통의 시작.

블로그를 처음 만들고 잘 운영하던 중 jekyll과 Gem Dependency와 Ruby 버전 그리고 Bundle까지 뭔가 엉키고 꼬여서 풀리지 않고 어느새 블로그는 엉망이 되어버렸습니다.

그리하여 깔끔하게 데이터 백업 후 밀어버리고 더 이쁜 블로그 테마를 찾아버렸습니다(오히려 좋아👍)

그렇게 아주 기분 좋게 블로그를 옮기고 잘 운영되나 싶었는데 ‘얼씨구?’ AWS Route 53에서 등록한 서브도메인을 github page와 연결해 놓았었는데 이 친구가 아주 먹통이 되어버렸습니다.

“DNS가 깃헙 서버와 맞지 않는다는 경고를 내보내주었습니다.”

아….. 찝찝한게 제일 싫은 나는 결국 오전 4시 기상해서 하나씩 알아보기 시작했습니다.

Domain Name System(이후 DNS)은 인터넷의 전화번호부 같은 역할을 합니다.
- 사람들이 웹사이트에 접속시, 일반적으로 기억하기 쉬운 도메인 이름(예: www.devkobe24.com)을 사용합니다.
- 그러나 인터넷 자체는 IP 주소(예:192.0.2.1)라는 숫자 주소 체계를 사용하여 컴퓨터들 사이의 통신을 가능하게 합니다.
  - “DNS는 사용자가 웹 브라우저에 입력한 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환하는 시스템입니다.”
    - 이를 통해 사용자는 복잡한 IP 주소를 기억하지 않고도 웹사이트에 쉽게 접근할 수 있습니다.

도메인 이름 해석 : 사용자가 웹 브라우저에 URL을 입력하면, DNS 서버는 해당 URL의 도메인 이름을 IP 주소로 변환합니다. 이 과정을 “이름 해석” 또는 “도메인 이름 해석”이라고 합니다.
계층적 구조 : DNS 시스템은 계층적 구조로 되어 있습니다. 맨 위에는 루트 DNS 서버가 있으며, 그 아래에는 최상위 도메인(TLD)서버(예: .com, .net, .org등), 그리고 더 아래에는 권한 있는 이름 서버가 위치합니다. 권한 있는 이름 서버는 특정 도메인(예: devkobe24.com)에 대한 정보를 관리합니다.
캐싱 : DNS 쿼리의 효율성을 높이기 위해, DNS 서버는 해석된 주소 정보를 일정 시간 동안 저장(캐싱)합니다. 이렇게 하면 같은 요청에 대해 반복적으로 최상위 서버에 접근할 칠요가 없어집니다.
재귀적 및 반복 쿼리 : 사용자의 DNS 쿼리는 먼저 로컬 DNS 서버로 전송됩니다. 로컬 DNS 서버는 요청된 도메인의 IP 주소를 알고 있으면 바로 응답합니다. 모르는 경우, 다른 DNS 서버에 요청을 전달하여 답을 찾습니다. 이 과정에서 재귀적 쿼리(사용자를 대신해 답을 찾는 과정)와 반복적 쿼리(요청을 다른 서버로 전달하는 과정)가 사용됩니다.

DNS는 인터넷 사용의 핵심요소로, 사용자가 웹사이트에 접근하고, 이메일을 보내고 받으며, 다양한 온라인 서비스를 이용할 수 있게 해줍니다.

이렇게 DNS에 대하여 알아보고나서 이전에 연결을 어떻게 했었는지 이전에 블로그를 찾아봤습니다.

먼저 연결 전 사전 준비물(?)이 필요합니다.

이렇게 준비 한 뒤 Route 53 콘솔을 세팅합니다.

Route 53 콘솔로 갑니다 > 호스팅 영역을 클릭 > 보유 도메인을 설정합니다.
레코드 생성
- 레코드 이름 : 서브(2차) 도메인 명 > www
- 레코드 유형 : CNAME
- 값 : (자신의 깃헙 레포 이름) > ex) devKobe24.github.io

레포지토리 > 셋팅 > 페이지 > 커스텀 도메인

하지만 저는 나오지 않았습니다.

그래서!! 더 알아 본 결과!!

Route 53에서 A레코드를 추가해주었어야 했습니다.

Route 53 > 호스팅 영역 > 등록할 호스팅 영역의 이름 클릭 > 레코드 생성

레코드 이름은 비워둡니다.
레코드 유형은 A
값은 다음 IP 중 하나를 골라 사용합니다.
- 185.199.108.153
- 185.199.109.153
- 185.199.110.153
- 185.199.111.153
나머지 옵션은 건들지 않습니다.
이후 레코드 생성을 눌러 생성합니다.

이후 깃헙 레포로 돌아갑니다.