문제

도메인을 Cloudflare에 추가했는데 뭔가 이상합니다. 대시보드가 몇 시간째 **“Pending Nameserver Update”**에서 Active로 안 넘어가거나, 애초에 네임서버를 Cloudflare로 어디서 보내는지 못 찾겠거나 — 최악의 경우 — 네임서버를 바꿨더니 도메인 전체가 SERVFAIL을 내거나 아예 안 풀립니다. 도메인은 분명히 존재합니다. Cloudflare 계정에 존이 그대로 있으니까요. 끊긴 건 ‘이 이름의 DNS는 누가 응답하는가’라는 한 가지 사실에 대해 세 당사자가 합의하는 과정입니다. 그리고 Cloudflare는 아주 특정한 방식으로 이걸 헷갈리게 만듭니다 — Cloudflare가 당신에게 요구하는 변경이, 정작 Cloudflare 안에서 일어나지 않기 때문입니다.

증상

  • Cloudflare가 **“Pending Nameserver Update”**를 띄운 채 Active로 안 넘어갑니다.
  • Cloudflare 대시보드 안에서 ‘네임서버를 Cloudflare로 설정’하는 옵션을 못 찾겠습니다.
  • 네임서버를 바꿨는데 몇 시간 뒤에도 아무 일이 없습니다 — Cloudflare가 계속 기다립니다.
  • 전환 직후 도메인이 SERVFAIL을 내거나 아예 안 풀립니다.
  • 사이트는 뜨는데 메일이 멈췄습니다 — 또는 잘 되던 서브도메인이 사라졌습니다.
  • Cloudflare 프록시(오렌지 구름)를 켠 뒤에만 리다이렉트 루프나 SSL 오류가 납니다.

모두가 거꾸로 아는 한 가지

도메인 연결은 세 개의 층이 쌓인 구조이고, Cloudflare로 옮기는 건 그 가운데 층의 주인을 바꾸는 것뿐입니다. 층을 구분하면 위 증상들이 전부 그중 하나로 정리됩니다.

1층 — 등록기관(이름을 소유하는 곳). 도메인을 산 곳입니다. 이 작업에서 이곳의 역할은 하나 — 도메인의 네임서버(NS) 레코드를 ‘DNS에 응답할 주체’로 가리키게 하는 것. Cloudflare는 당신의 등록기관이 아닙니다(등록 자체를 Cloudflare Registrar로 이전한 경우는 별개). 그래서 네임서버 변경은 여기, 등록기관에서 일어납니다 — Cloudflare가 아니라. 거의 모두가 여기서 걸립니다 — 사이트를 Cloudflare에 추가하고 Cloudflare가 ‘알아서 넘겨받길’ 기다리는데, 정작 Cloudflare는 당신이 등록기관으로 돌아가 NS를 바꾸길 기다리고 있습니다.

2층 — 네임서버(응답하는 곳). 사이트를 추가하면 Cloudflare는 존에 특정 네임서버 쌍을 배정합니다 — 계정마다 고유한, .ns.cloudflare.com으로 끝나는 호스트명 2개. 당신 할 일은 등록기관에서 기존 네임서버를 전부 그 2개로 바꾸는 것입니다. 블로그에서 복사한 일반값이 아니라, Cloudflare가 이 도메인에 보여주는 바로 그 2개. 그 둘이 도메인의 권위 NS가 되기 전까지 Cloudflare는 응답하지 않고, 존을 “Pending”에 둡니다.

3층 — DNS 레코드(응답의 내용). Cloudflare가 권위가 되면 Cloudflare DNS 탭 안의 레코드가 세상이 받는 실제 응답입니다. 그리고 메일을 잡아먹는 함정이 여기 있습니다 — 이제 Cloudflare가 존 전체에 응답하므로, 가진 레코드만 서빙합니다. 가져오기 스캔이 놓친 건 더 이상 존재하지 않습니다.

머릿속 모델은 이렇습니다 — 사이트를 Cloudflare에 추가하는 건 새 네임서버를 준비하는 것이고, 등록기관에서 NS를 바꾸는 건 그걸 임명하는 것입니다. 사람들은 앞은 하고 뒤는 건너뛰거나 어설프게 한 뒤, (정확하게) 아직 기다리고 있는 대시보드를 멍하니 봅니다.

주요 원인 3가지

  1. 등록기관에서 네임서버 변경을 안 했거나 틀리게 했다. 사이트는 Cloudflare에 추가했지만 NS를 안 바꿨거나, 엉뚱한 곳에서 바꿨거나, 2개 중 1개만 바꿨거나, 옛 네임서버를 남겼거나, 지정 쌍을 잘못 넣은 경우. 증상: Cloudflare가 “Pending Nameserver Update”에 머물고, 실제 NS 조회에 Cloudflare의 정확한 2개 외의 것이 보입니다.
  2. 옛 제공자의 DNSSEC 찌꺼기 → SERVFAIL. 이전 DNS 호스트가 존에 서명했고, 등록기관이 그 옛 키의 DS 레코드를 아직 발행 중입니다. 위임이 Cloudflare로 넘어가면 서명이 DS 레코드와 안 맞고 검증 리졸버가 모든 응답을 거부합니다. 증상: NS가 넘어가기 전까지 멀쩡하던 도메인이, 전환 순간 검증 리졸버를 쓰는 모두에게 SERVFAIL — 서서히가 아니라 즉시.
  3. 가져오기가 놓친 레코드가 전환 때 사라졌다. Cloudflare가 존 전체의 권위가 됐고 가져온 것만 서빙합니다. MX와 이메일 TXT(SPF/DKIM/DMARC)가 흔한 희생양입니다. 증상: 웹사이트는 풀리는데 메일이 반송되거나, 한 시간 전까지 되던 서브도메인이 NXDOMAIN을 냅니다.

값에 관한 한마디: Cloudflare의 지정 네임서버는 계정마다 고유하고, DS 레코드 값도 존마다 생성됩니다. 둘 다 당신 대시보드에서 읽으세요 — 특정 *.ns.cloudflare.com 쌍이나 DS 레코드를 튜토리얼에서 복사하지 마세요. 아래 층들은 각 값을 어디에 넣는지 알려주고, 무엇인지는 Cloudflare가 알려줍니다.

DechoNet으로 진단

  • DNS 조회로 도메인의 현재 NS 레코드와 A/MX/TXT 응답을 봅니다. NS부터 확인하세요 — Cloudflare의 지정 2개와 정확히 같지 않으면 문제는 Cloudflare가 아니라 등록기관 변경입니다. Cloudflare인데 SERVFAIL이 계속되면 DNSSEC 함정을 보고 있는 겁니다.
  • DNS 전파 확인은 전 세계 리졸버에 동시에 질의합니다. 네임서버 변경 직후엔 한동안 엇갈립니다 — 정상 전파입니다. 전부 Cloudflare 네임서버로 바뀌었다면 위임은 끝났고 Cloudflare의 재확인만 기다리면 됩니다.
  • SSL 확인은 오렌지 구름 프록시를 켠 뒤 인증서를 확인해, 반쯤 설정된 SSL 모드와 진짜 TLS 문제를 구분해 줍니다.

해결 체크리스트

  • Cloudflare에서 도메인 Overview를 열어 이 존에 표시된 지정 네임서버 2개를 복사합니다(둘 다 .ns.cloudflare.com으로 끝남).
  • 등록기관에서 — Cloudflare가 아니라 — 기존 네임서버를 전부 지우고 그 2개로만 바꿉니다.
  • 전환 전에 옛 DNSSEC를 없애세요: 이전 제공자가 서명했다면 등록기관에서 DS 레코드를 지우고(DNSSEC 끄기) 그 삭제가 전파될 시간을 줍니다. 이것이 SERVFAIL을 막습니다.
  • 옛 존과 Cloudflare DNS Records 탭을 비교해 가져오기가 놓친 걸 다시 넣습니다 — MX와 SPF/DKIM/DMARC TXT부터(조용히 실패하므로).
  • DNS 조회로 실제 NS가 Cloudflare 쌍과 정확히 같은지 확인하고, 무언가 고장 났다고 단정하기 전에 DNS 전파 확인으로 여러 리졸버를 봅니다.
  • Active가 되면, 프록시를 쓸 경우 SSL/TLS 모드를 **Full (Strict)**로 두고 유효한 오리진 인증서를 깔며 — Cloudflare 안에서 DNSSEC를 다시 켜고, 생성된 새 DS 레코드를 등록기관에 다시 넣습니다.

에스컬레이션 시점

  • 실제 NS 조회가 어디서나 Cloudflare의 정확한 쌍을 보이는데 24시간 뒤에도 대시보드가 Pending이면, 위임은 끝났고 보류는 Cloudflare 쪽입니다 — 다른 걸 건드리지 말고 Cloudflare 지원에 문의하세요.
  • 오렌지 구름을 켠 뒤에만 리다이렉트 루프나 525가 난다면, DNS 이동은 성공했고 문제는 HTTPS를 못 끝내는 오리진을 만난 프록시의 SSL 모드입니다 — 오리진 인증서와 SSL 모드를 고치세요, 네임서버는 건드리지 마세요.
  • 도메인이 어디서나 맞는 곳으로 풀리는데 사이트가 안 뜨면, DNS는 끝났고 문제는 그 IP의 오리진 서버로 넘어간 겁니다.

내 도메인에서 바로 확인

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