도메인은 샀는데 사이트가 안 열린다, 메일이 스팸함으로만 들어간다 — 이런 문제의 상당수는 서버가 아니라 DNS 설정에서 시작됩니다. 레코드 몇 줄이 어디를 가리키느냐에 따라 접속도 메일도 갈리기 때문이에요.
네임서버부터 확인하세요
가장 많이 헷갈리는 지점이 여기예요. 도메인을 A업체에서 샀더라도 네임서버가 B업체로 지정돼 있으면, A업체 DNS 관리 화면에서 아무리 레코드를 고쳐도 반영되지 않습니다. 실제로 적용되는 건 현재 지정된 네임서버 쪽 설정이에요.
그래서 레코드를 손대기 전에 “이 도메인의 네임서버가 지금 어디로 잡혀 있는지”부터 확인하는 게 순서입니다. 호스팅을 옮길 때도 네임서버를 먼저 정리해두면 나중에 원인 모를 삽질을 줄일 수 있어요.
A, CNAME, MX, TXT 뭐가 다른가요
A 레코드는 도메인을 특정 IP 주소로 직접 연결합니다. 서버 IP가 정해져 있으면 가장 기본이 되는 레코드예요.
CNAME은 도메인에 별칭을 붙이는 방식이라, 다른 도메인 이름을 바라보게 만듭니다. 외부 서비스에 연결할 때 자주 쓰지만, 최상위 도메인(루트)에는 제약이 있는 경우가 많아 보통 www나 서브도메인에 씁니다.
MX는 메일을 어느 서버로 보낼지 정하고, TXT는 도메인 소유권 인증이나 SPF 같은 메일 보안 설정에 쓰입니다. 웹은 멀쩡한데 메일만 문제라면 십중팔구 MX와 TXT 쪽을 봐야 해요.
도메인 만료와 접속 중지 상태도 확인하세요
레코드가 맞는데 웹과 메일이 함께 끊겼다면 도메인 등록 상태도 확인해보세요. DNS 관리 화면에 설정이 남아 있어도, 도메인 자체가 DNS에서 활성화되지 않은 상태라면 접속할 수 없어요. ICANN의 상태 코드 안내에서 clientHold는 등록업체가, serverHold는 등록소가 도메인의 DNS 활성화를 막는 상태를 뜻해요. 여기서 등록업체는 도메인을 구매하고 갱신하는 창구이고, 등록소는 해당 최상위 도메인의 등록 정보를 관리하는 곳이에요. 조회 결과에 이런 코드가 보이면 IP 주소를 다시 입력하기보다 등록업체에 중지 사유와 해제 절차를 문의하는 게 순서예요.
다만 상태 코드에 제한을 뜻하는 단어가 있다고 모두 접속 장애는 아니에요. clientTransferProhibited는 다른 등록업체로 도메인을 이전하지 못하게 하는 상태예요. 무단 이전을 막기 위한 보호 장치로도 쓰이기 때문에, 이 코드만 보고 사이트가 차단됐다고 판단하면 안 돼요. 반면 clientHold는 요금 미납이나 분쟁, 삭제 대상이 된 상황 등에서 설정될 수 있다고 ICANN이 안내해요. 조회된 코드 전체와 등록업체의 안내를 함께 확인하고, 문의할 때는 도메인 이름과 표시된 상태를 그대로 전달해보세요. 상태의 뜻을 구분하면 불필요하게 이전 잠금을 해제하는 일도 줄일 수 있어요.
만료도 웹과 메일이 동시에 멈추는 원인이 될 수 있어요. ICANN은 등록업체가 만료된 도메인을 삭제하기 전에 도메인 이름의 해석 경로를 중단해야 한다고 설명해요. 또 만료 후 자동 갱신 유예기간을 둘 수 있지만, 제공 여부와 처리 방식은 등록업체 정책에 따라 달라요. 유예기간이 있을 거라고 생각하고 갱신을 미루기보다는 구매처에서 만료일과 갱신 처리 결과를 확인하는 편이 좋아요. 이미 갱신 비용을 냈는데도 연결이 복구되지 않았다면 결제 내역을 준비해 등록업체에 문의해보세요. 서버 이용료 납부와 도메인 갱신은 각각 확인해두는 게 좋아요.
DNSSEC 오류는 기다리기보다 검증해보세요
DNSSEC는 DNS 응답에 전자서명을 붙여, 응답이 신뢰할 수 있는 것인지 검증하도록 하는 보안 확장이에요. 이름을 주소로 바꾸는 과정에서 위조된 정보를 받아들이지 않도록 돕는 방식이에요. 관련 레코드도 역할이 나뉘어요. DNSKEY에는 서명을 확인하는 공개키가, RRSIG에는 레코드의 서명이 들어가고, DS는 상위 영역에서 하위 영역의 키를 검증하는 연결 고리로 쓰여요. 그래서 A 레코드에 올바른 IP가 들어 있어도 서명과 키의 연결이 맞지 않으면, DNSSEC를 검증하는 조회 서버에서는 정상 응답을 얻지 못할 수 있어요.
특히 DNS 제공업체를 옮길 때는 등록업체 쪽에 예전 DS 정보가 남아 있는지 확인해보세요. Cloudflare 공식 문서는 권한 있는 DNS 제공업체를 바꾸면서 기존 DNSSEC 정보를 갱신하거나 제거하지 않으면 문제가 생길 수 있다고 안내해요. 새 업체가 사용하는 키와 예전 DS가 맞지 않으면 검증 과정에서 SERVFAIL이 반환될 수 있어요. 이 표시는 DNS 조회 처리가 실패했다는 뜻이라, 그 자체만으로 DNSSEC가 원인이라고 단정할 수는 없어요. 다만 업체를 옮긴 직후부터 발생했다면 새 DNS 제공업체의 DNSSEC 안내와 등록업체에 등록된 DS 정보를 함께 확인할 이유가 있어요.
진단할 수 있는 환경이라면 dig로 같은 도메인을 조회하고, DNSSEC 검증을 생략하는 +cd 옵션을 붙인 결과와 비교해볼 수 있어요. Cloudflare는 일반 조회에서는 SERVFAIL이 나오지만 +cd를 붙였을 때 정상 주소가 반환되면 DNSSEC 설정 문제를 의심할 수 있다고 설명해요. 검증 생략은 원인을 좁히기 위한 확인 방법이에요. 복구할 때는 새 제공업체가 안내한 키와 DS가 일치하도록 설정을 정리해야 해요. DNSSEC를 해제하는 방식으로 이전한다면 기존 DS의 TTL이 만료되기 전에 네임서버를 바꾸지 않도록 업체의 절차를 따라주세요. 문의할 때 일반 조회와 검증 생략 조회 결과를 함께 보내면 원인을 설명하기 수월해요.
TTL은 무작정 낮추지 마세요
TTL은 DNS 응답을 얼마나 캐시할지 정하는 값이에요. 짧을수록 변경이 빨리 퍼지지만, 그만큼 조회 요청이 늘어나 응답 속도나 부하 면에서는 손해입니다. 평소에는 넉넉하게 두고, 서버 이전처럼 변경이 예정된 시점 며칠 전에만 미리 낮춰두는 방식이 안전해요.
이전이 끝나고 안정화되면 다시 원래 값으로 올려두면 됩니다. 이 한 가지만 챙겨도 전환 과정에서 접속이 튀는 시간을 크게 줄일 수 있어요.
바꾼 직후에 안 된다고 당황하지 않기
DNS는 전 세계 곳곳에 캐시된 채로 동작하기 때문에, 바꾸자마자 모두에게 반영되지 않습니다. 사무실에서는 새 서버로 붙는데 집에서는 예전 서버로 가는 상황이 정상이라는 뜻이에요. TTL과 각 통신망 캐시에 따라 수십 분에서 하루 정도 차이가 날 수 있습니다.
그래서 서버를 옮길 때는 전환 기간 동안 기존 서버를 바로 내리지 말고 잠시 함께 열어두는 게 안전해요. 도메인 연결부터 메일 레코드까지 한 번에 정리하고 싶다면 웹호스팅·서버 이전 지원을 함께 이용하시면 수월합니다.
