문제

도메인을 샀고 서버를 빌렸습니다. 그리고 어딘가에 서버가 응답하는 IP 주소 — 203.0.113.10 — 가 있습니다. 이제 도메인이 그 IP를 가리키게 해야 합니다. 호스팅 문서는 “A 레코드만 추가하세요”라고 하고, 추가했는데 아무 일도 안 일어나거나 사이트가 엉뚱한 곳으로 뜹니다. 어떤 콘솔은 저장조차 안 시켜 줍니다.

A 레코드는 DNS에서 가장 기본적인 것 — 이름 하나, IP 하나, 끝 — 인데도 사람들이 여기서 막힙니다. 아무도 말해주지 않는 두 가지 디테일이 성패를 가르기 때문입니다. 레코드를 도메인의 어디에 넣는가, 그리고 호스트 칸이 입력한 텍스트로 무엇을 하는가. 이 둘만 맞으면 2분짜리 작업입니다.

A 레코드가 실제로 하는 일

A 레코드는 도메인 DNS 존의 한 줄로, 이름을 IPv4 주소에 매핑합니다. 하는 일은 이게 전부입니다:

shop.example.com.    A    203.0.113.10

리졸버가 “shop.example.com의 주소는?”이라고 물으면 203.0.113.10을 받아 거기로 연결합니다. 형제 격인 AAAA 레코드는 IPv6 주소에 대해 똑같은 일을 합니다. 한 이름은 A만, AAAA만, 또는 둘 다 가질 수 있습니다 — 서로 다른 질문에 대한 서로 다른 답이고, 브라우저는 네트워크가 주는 쪽으로 시도합니다.

마법도 “연동”도 없습니다. 당신은 사실 하나를 발행하는 겁니다 — 이 이름은 이 주소에 산다 — 그러면 인터넷의 모든 리졸버가 그 사실을 읽고 라우팅합니다. 아래 두 가지 실패가 그렇게 흔한 이유가 바로 이것입니다. DNS의 버그가 아니라, 당신이 의도한 것과 살짝 다른 사실을 발행한 것입니다.

apex 함정: 루트에는 CNAME을 못 건다

다른 무엇보다 도메인 연결을 많이 망치는 규칙입니다. 루트 도메인 — 앞에 아무것도 없는 example.com, apex 또는 존 apex라고도 부릅니다 — 은 CNAME을 가질 수 없습니다.

이유는 벤더의 변덕이 아니라 구조적인 것입니다. RFC 1034 §3.6.2는 한 이름에 CNAME이 있으면 다른 레코드 타입이 존재할 수 없다고 못박습니다. 그런데 모든 존의 apex는 SOA 레코드와 NS 레코드를 반드시 가져야 합니다 — 그래야 존이 됩니다. apex의 CNAME은 그것들과 공존해야 하는데 스펙이 이를 금지하므로, 정상 네임서버는 그냥 거부합니다.

이게 중요한 이유는, 많은 호스트 — 특히 Vercel·Netlify·GitHub Pages 같은 플랫폼 — 가 IP가 아니라 호스트명을 주기 때문입니다. 서브도메인에선 문제없습니다. www.example.com을 그쪽 호스트명으로 CNAME 걸면 끝입니다. 하지만 맨 example.com엔 같은 걸 할 수 없습니다. apex에서의 선택지는:

  • 그쪽 IP로 A 레코드. 안정적인 IP를 공개하는 경우에만(주소를 자주 옮기는 곳이 많아 공개 안 하는 경우가 흔합니다).
  • DNS 제공자의 플래트닝 기능: Cloudflare의 CNAME flattening, Route 53의 ALIAS, 다른 곳의 ANAME. 대상 호스트명을 입력하면 제공자가 조용히 A 레코드로 풀어 apex에서 그것을 응답합니다 — 실제 apex CNAME 없이 CNAME 같은 동작을 얻습니다.

등록기관 DNS가 플래트닝을 제공하지 않고 호스트가 호스트명만 줬다면, 표준적인 방법은 www를 그 호스트명으로 CNAME 걸고 맨 도메인을 www로 리다이렉트하는 것입니다.

호스트 칸 함정: 이름이 두 번 붙었다

두 번째 조용한 킬러는 DNS 콘솔의 “이름” 또는 “호스트” 칸에 있습니다. 거의 모든 콘솔이 입력값 뒤에 도메인을 자동으로 덧붙입니다. 그래서 example.com용 레코드를 원하는데 그 칸에 example.com을 입력하면, 방금 example.com.example.com용 레코드를 만든 것일 수 있습니다 — 아무도 해석 못 하는 이름이죠.

한 번 알고 나면 규칙은 일관됩니다:

  • 루트 도메인엔 @를 입력(또는 빈 칸 — 콘솔마다 다름). example.com이 아닙니다.
  • 서브도메인엔 라벨만: shop, shop.example.com이 아닙니다.

레코드를 추가하고 오류 없이 저장했는데도 이름이 여전히 해석 안 된다면, 무엇을 건드리기 전에 호스트 칸부터 보세요. 이름이 두 번 붙은 것이야말로 “추가했는데 안 돼요”의 압도적 1위입니다.

A 레코드 확인하는 법

순서는 빠르고, 매번 문제를 격리해 줍니다:

  1. 레코드를 조회해 값을 읽는다. 설정한 정확한 이름의 A 레코드를 질의합니다. 응답이 있는데 IP가 틀렸거나, 두 번 붙은 이름에 응답이 뜬다면 데이터 문제 — 레코드를 고치세요.
  2. 이름이 생각한 그대로인지 확인한다. 도메인 중복 함정을 주시하세요. dig example.com A와 dig example.com.example.com A를 비교하면 실제로 어느 것을 만들었는지 즉시 드러납니다.
  3. 리졸버 하나 이상에서 확인한다. 한 리졸버엔 반영됐고 다른 리졸버엔 옛값이면 실수가 아니라 전파입니다. 값이 틀렸다고 판단하기 전에 레코드 TTL만큼 기다리세요.
  4. 서버가 거기서 응답하는지 확인한다. 아무것도 리스닝하지 않는 IP를 가리키는 올바른 A 레코드는 해석되는 이름과 죽은 연결을 줍니다 — 전혀 다른 문제입니다(DNS는 제 일을 했습니다).

DechoNet으로 확인하기

  • DNS 조회는 임의 이름의 라이브 A·AAAA 레코드를 읽어, 값을 확인하고 두 번 붙은 호스트명을 잡아내며 apex가 주소로 응답하는지 볼 수 있습니다.
  • DNS 전파는 서로 다른 네트워크의 리졸버들에서 레코드를 동시에 확인합니다 — “내가 실수했다”와 “아직 안 퍼졌다”를 가르는 방법입니다.

해결 체크리스트

  • 레코드 위치를 정한다: 루트(@)인가 서브도메인(shop 같은 라벨만)인가. 호스트 칸에 전체 도메인을 절대 입력하지 말 것.
  • 루트에는 IP로 향하는 A 레코드 — 호스트가 호스트명만 줬다면 제공자의 ALIAS/ANAME/CNAME 플래트닝. apex에 생 CNAME은 절대 금지.
  • 서브도메인에는 A 레코드(IP)나 CNAME(호스트명) 둘 다 가능 — 호스트가 준 것에 맞춰 고르세요.
  • AAAA는 서버가 그 IPv6 주소에서 실제로 응답할 때만 발행하고, 아니면 두지 마세요.
  • 저장 후 정확한 이름이 정확한 IP로 여러 리졸버에서 해석되는지 확인하고, 깨졌다고 단정하기 전에 TTL을 넘겨 기다리세요.

언제 확대할까

  • 레코드가 올바르게 해석되는데도 사이트가 안 뜨면 문제는 DNS를 넘어간 것입니다 — 서버가 그 포트를 리스닝하지 않거나, 방화벽이 연결을 버리거나, TLS 설정이 틀렸습니다. 레코드가 아니라 연결/인증서 문제입니다.
  • IP를 바꾸는 호스트명 쪽으로 apex 동작이 필요한데 DNS 제공자가 플래트닝을 제공하지 않으면, 제공하는 곳으로 DNS를 옮겨야 할 가능성이 큽니다 — 대상의 현재 IP를 A 레코드에 손으로 복사하는 방식은 호스트가 주소를 바꾸는 순간 깨집니다.
  • 서로 다른 리졸버가 TTL보다 훨씬 오래 불일치하면, 등록기관의 도메인 네임서버가 레코드를 쥔 DNS 제공자와 실제로 일치하는지 확인하세요 — 네임서버 불일치는 인터넷 절반이 당신이 편집 중인 존과 다른 존을 읽고 있다는 뜻입니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.