도메인과 DNS와 HTTPS가 배포 주소를 잇는 과정

Vercel이나 다른 배포 서비스에서 프로젝트를 공개하면 먼저 서비스가 만든 긴 주소를 받을 수 있습니다. 내 도메인을 연결하려고 하면 DNS 레코드, 네임서버, 인증서 같은 말이 한꺼번에 나타납니다. 세 가지를 같은 설정으로 보면 어디서 문제가 났는지 찾기 어렵습니다.

도메인은 가게 이름과 주소 표기, DNS는 그 주소를 실제 건물 위치로 안내하는 지도, HTTPS 인증서는 도착한 가게가 맞는지 확인하고 대화를 봉투에 넣는 장치에 가깝습니다. 배포 서비스는 실제로 콘텐츠를 제공하는 건물 역할을 합니다.

도메인은 사람이 기억하는 인터넷 이름이다

도메인은 nupcoding.com처럼 사람이 읽을 수 있는 웹 주소의 핵심 이름입니다. MDN은 도메인이 인터넷 서버에 사람이 읽을 수 있는 주소를 제공한다고 설명합니다. 점으로 나뉜 부분은 오른쪽에서 왼쪽으로 계층을 이룹니다.

도메인을 구매했다는 사실만으로 웹사이트가 생기지는 않습니다. 도메인 등록 기관에 이름을 등록하고, DNS에서 어디로 갈지 연결하고, 배포 서비스에 해당 도메인을 사용할 권한을 설정해야 합니다. 이메일을 같은 도메인으로 쓴다면 관련 DNS 레코드도 함께 존재할 수 있습니다.

DNS는 이름을 서버 위치 정보로 바꿔 찾는다

DNS는 Domain Name System의 줄임말로 도메인 이름을 IP 주소나 다른 호스트 이름에 연결하는 분산 체계입니다. 연락처 앱에서 사람 이름으로 전화번호를 찾는 것과 비슷합니다. 브라우저는 여러 DNS 서버와 캐시를 거쳐 목적지를 찾을 수 있습니다.

www.example.com  CNAME  project.hosting.example
example.com      A      192.0.2.10

CNAME은 한 이름을 다른 호스트 이름으로 가리키는 레코드이고, A는 이름을 IPv4 주소로 연결하는 레코드입니다. 위 값은 문서용 예시이므로 실제 서비스에 입력하면 안 됩니다. 배포 서비스가 안내한 정확한 종류와 이름과 값을 사용해야 합니다.

네임서버와 레코드는 변경 범위가 다르다

네임서버는 이 도메인의 DNS 장부를 어느 제공자가 관리하는지 알려 줍니다. 개별 A나 CNAME 레코드 변경은 장부 한 줄을 고치는 일이고, 네임서버 변경은 장부 관리처 자체를 옮기는 일에 가깝습니다. 잘못 옮기면 웹뿐 아니라 메일과 소유권 확인 기록도 사라진 것처럼 보일 수 있습니다.

• 현재 DNS 레코드 전체를 먼저 저장합니다.
• 웹, 이메일, 인증용 레코드를 구분합니다.
• 배포 서비스가 요구한 호스트 이름을 정확히 확인합니다.
• apex 도메인과 www 하위 도메인을 따로 봅니다.
• 네임서버 변경은 기존 레코드 이전 계획 없이 실행하지 않습니다.

apex는 example.com처럼 앞에 www가 없는 루트 도메인을 뜻합니다. www.example.com과는 별도 호스트이므로 둘 중 하나만 연결될 수 있습니다. 어느 주소를 표준으로 쓸지 정하고 다른 쪽은 의도한 리디렉션을 제공하는지 확인합니다.

DNS 변경은 캐시 때문에 한 번에 같아 보이지 않는다

DNS 응답은 TTL이라는 보관 시간 동안 중간 서버나 기기에 캐시될 수 있습니다. TTL은 time to live의 줄임말로 응답을 얼마 동안 다시 사용할지 나타냅니다. 값을 바꿔도 지역과 네트워크에 따라 이전 결과가 잠시 남을 수 있습니다.

전파 시간을 근거 없이 몇 분이나 몇 시간으로 단정하지 않습니다. 현재 권한 DNS의 실제 응답, 로컬 조회, 다른 네트워크의 결과를 구분합니다. 변경 직후 같은 값을 반복 수정하면 원인을 더 흐릴 수 있으므로 적용한 시각과 이전 값을 기록하고 관찰합니다.

HTTPS는 인증서와 암호화된 통신을 함께 사용한다

HTTPS는 HTTP 통신을 TLS라는 보안 통신 규칙으로 보호하는 방식입니다. 인증서는 브라우저가 접속한 서버가 해당 도메인을 위해 발급된 공개키를 제시하는지 확인하게 돕습니다. 자물쇠 표시는 통신이 암호화되고 인증서 검사가 통과했다는 뜻이지, 그 사이트의 모든 내용과 사업이 믿을 만하다는 보증은 아닙니다.

Let’s Encrypt 공식 설명에 따르면 인증 기관은 인증서 발급 전에 요청자가 도메인을 제어하는지 DNS 레코드나 정해진 HTTP 자원 같은 방법으로 확인할 수 있습니다. 확인 뒤 인증서를 발급하며, 갱신 때도 검증과 발급 과정이 반복됩니다.

배포 서비스 연결은 세 장소를 맞추는 일이다

첫째, 배포 서비스에서 프로젝트가 정상 배포돼 임시 주소로 열리는지 확인합니다. 둘째, 배포 서비스에 내 도메인을 추가하고 안내된 DNS 값을 받습니다. 셋째, DNS 제공자에서 해당 레코드를 입력합니다. 넷째, 배포 서비스가 도메인과 인증서 상태를 확인할 때까지 기다립니다.

도메인 소유 확인이 실패하면 안내된 호스트와 값, 중복 레코드, 네임서버 관리처를 봅니다. 인증서 발급이 실패하면 DNS가 아직 옛 서버를 가리키는지, CAA 같은 인증 제한 레코드가 있는지 서비스 문서를 확인합니다. 비밀키 파일을 직접 다운로드해 채팅에 붙이는 방식으로 해결하지 않습니다.

연결 뒤에는 주소별 응답과 실제 내용을 따로 본다

www, apex, http, https 조합을 각각 열어 의도한 최종 주소로 가는지 확인합니다. 리디렉션은 다른 주소로 보내는 응답입니다. 일시 이동과 영구 이동 코드는 의미가 다르므로 상태 코드와 Location 헤더를 같이 기록합니다.

인증서가 정상이어도 옛 프로젝트가 열릴 수 있고, 올바른 프로젝트가 열려도 일부 경로가 404일 수 있습니다. 홈페이지뿐 아니라 대표 상세 주소, 이미지, robots.txt, sitemap을 확인합니다. canonical은 검색엔진에 표준 주소를 알리는 표식이므로 실제 리디렉션 정책과 맞아야 합니다.

오늘 바로 해볼 작은 실습

내 도메인을 바꾸지 않고 연결 설계표만 만듭니다.

1. 사용하려는 apex와 www 주소를 두 줄로 적습니다.
2. 현재 배포 서비스의 임시 URL을 적습니다.
3. DNS 관리 제공자와 현재 네임서버를 읽기만 합니다.
4. 웹, 메일, 인증 레코드를 표에서 다른 색으로 구분합니다.
5. 표준 주소와 리디렉션 방향을 한 문장으로 정합니다.
6. HTTPS, 대표 상세 페이지, sitemap 확인 항목을 적습니다.

DNS 삭제와 네임서버 교체는 사이트와 이메일을 동시에 끊을 수 있습니다. 뜻을 모르는 레코드와 인증서 비밀키는 수정하거나 공유하지 마세요. 결제와 로그인 서비스가 연결돼 있다면 테스트 시간과 복구 계획을 먼저 합의하고 한 번에 한 값만 바꿉니다.