도메인 구매도 끝냈고 서버 세팅도 마쳤는데 주소창에 쳐도 사이트가 안 열립니다. 이럴 때 서버부터 뜯어보는 분이 많은데, 열에 아홉은 서버가 아니라 DNS 문제예요. 도메인과 서버를 연결해주는 이 중간 단계에서 뭔가 어긋난 겁니다.
먼저 볼 것은 네임서버
도메인을 산 곳과 실제 DNS 설정을 관리하는 곳이 다를 수 있습니다. 네임서버는 “이 도메인의 주소록을 누가 관리하느냐”를 정하는 값이에요. 도메인 등록 업체에 네임서버가 A사로 지정돼 있는데 정작 B사 관리 화면에서 레코드를 열심히 고치고 있다면, 아무리 고쳐도 반영되지 않습니다.
그래서 순서가 중요합니다. 네임서버가 어디를 가리키는지 먼저 확인하고, 그 관리 화면에 들어가서 레코드를 손대야 해요. 이 확인 없이 레코드부터 건드리면 원인을 못 찾고 몇 시간을 날리게 됩니다.
레코드 종류만 알아도 절반은 해결
A 레코드는 도메인을 IP 주소에 직접 연결합니다. 가장 기본이고, 사이트가 안 열릴 때 첫 번째로 볼 값이에요. CNAME은 도메인을 다른 도메인 이름에 연결합니다. www를 본 도메인에 붙일 때 흔히 씁니다. 다만 최상위 도메인 자체에는 CNAME을 쓸 수 없는 경우가 많아서, 이걸 모르고 설정했다가 막히는 일이 자주 생겨요.
MX는 메일을 어느 서버로 보낼지 정합니다. 사이트는 멀쩡한데 메일만 안 되는 상황이면 대부분 여기가 원인이에요. 웹 서버를 옮기면서 A 레코드만 바꾸고 MX를 그대로 두면 메일이 옛날 서버로 계속 흘러갑니다. TXT는 도메인 소유 확인이나 메일 인증(SPF, DKIM 등)에 쓰이는데, 메일이 스팸함으로만 들어간다면 이 값들을 점검해볼 필요가 있습니다.
전파 시간, 그리고 TTL
레코드를 바꿔도 즉시 반영되지 않습니다. 전 세계 DNS 서버들이 이전 값을 캐시하고 있어서, 그 캐시가 만료돼야 새 값을 보게 되거든요. 이 캐시 유지 시간이 TTL입니다.
여기서 실무 요령이 하나 있어요. 서버 이전 계획이 있다면 이전하기 하루 이틀 전에 TTL을 미리 짧게 낮춰두는 겁니다. TTL이 하루로 잡혀 있으면 IP를 바꿔도 하루 종일 옛 서버로 접속이 흘러들지만, 미리 5분으로 줄여두면 전환이 몇 분 만에 끝납니다. 이전이 끝난 뒤 다시 원래대로 올리면 되고요. 이 준비 하나로 무중단 이전의 성패가 갈립니다.
그리고 내 컴퓨터에서만 안 열리는 경우도 흔합니다. 이럴 땐 로컬 DNS 캐시를 비우거나, 다른 네트워크나 휴대폰 데이터로 접속해보면 금방 구분이 됩니다.
기다려도 안 풀리면 DNSSEC을 확인해요
DNS 설정에는 주소를 적는 일 말고도 그 주소가 믿을 만한지 검증하는 장치가 있어요. DNSSEC은 DNS 데이터에 전자서명을 붙여, 응답이 올바른 출처에서 왔고 중간에 변조되지 않았는지 확인하는 기술입니다. 검증에 실패하면 DNS 응답을 버리고 오류를 돌려주기 때문에, 레코드에 IP가 제대로 적혀 있어도 접속이 막힐 수 있어요. 보안 기능을 켰다는 사실만으로 연결까지 정상이라고 판단하면 안 됩니다.
특히 DNS 관리 업체를 바꾼 뒤라면 등록 업체에 남아 있는 DS 레코드를 확인해보세요. DS는 상위 DNS 영역에서 해당 도메인의 서명 키를 검증하는 데 쓰이는 정보예요. 새 업체로 옮겼는데 예전 업체의 DS가 남아 있으면 새 서명 키와 맞지 않아 검증이 깨질 수 있습니다. 이때 DNS 조회 결과에 SERVFAIL이 나타날 수 있어요. 기다리는 것만으로 서명 정보의 불일치가 해결되지는 않으니, 등록 업체와 새 DNS 업체 양쪽의 DNSSEC 설정을 함께 확인해야 해요.
엔지니어에게 문의할 때는 도메인 이름과 함께 DNS 업체를 바꾼 시점, DNSSEC 사용 여부, 조회 오류를 전달하면 좋습니다. dig를 쓸 수 있다면 같은 조회에서 검증을 생략하는 +cd 옵션을 넣었을 때만 응답이 나오는지도 비교해보세요. 일반 조회는 SERVFAIL인데 검증을 생략하면 정상 응답이 나오는 결과는 DNSSEC 문제를 좁히는 단서예요. 검증 생략은 진단용으로 쓰고, 남은 DS 정보를 갱신하거나 제거해야 하는지는 이전 절차에 맞춰 업체에 확인하는 게 좋습니다.
후이즈 조회가 낯설어졌다면 RDAP이에요
후이즈를 검색했는데 예전과 다른 조회 화면이 나오더라도 당황할 필요는 없어요. ICANN은 2025년 1월 28일부터 일반 최상위 도메인 등록정보 제공의 기준을 WHOIS에서 RDAP으로 전환했습니다. RDAP은 등록정보를 조회하는 새 규약으로, 응답 형식을 표준화하고 국제화와 안전한 데이터 접근을 지원해요. 도메인을 다시 사거나 DNS 레코드를 바꾸라는 뜻이 아니라, 등록정보를 받아오는 방식이 바뀐 겁니다. 이 전환 안내의 대상은 일반 최상위 도메인이에요.
조회할 때는 ICANN Lookup 같은 RDAP 기반 도구를 이용하면 됩니다. 이 도구는 등록소나 등록 업체가 제공하는 정보를 실시간으로 받아 보여줘요. 조회 화면의 DNSSEC 항목에는 위임의 서명 여부나 DS 정보가 표시될 수 있어서, 앞에서 설명한 서명 설정을 확인하는 참고 자료로도 쓸 수 있습니다. 다만 등록정보 조회와 실제 DNS 응답 검증은 확인 대상이 달라요. 조회 화면에 서명 정보가 보인다는 이유만으로 현재 접속 문제가 해결됐다고 판단하지는 마세요.
등록자 이름이나 연락처가 비어 있거나 redacted라고 표시되는 경우도 있어요. ICANN 안내에 따르면 일부 등록정보는 공개되지 않으며, 정당한 조회 목적을 인정받은 이용자에게만 보일 수 있습니다. 그러니 개인정보가 가려졌다는 사실만으로 도메인이 미등록 상태라고 판단하면 안 돼요. 조회 결과의 Notices와 Remarks에는 서비스나 해당 등록정보에 관한 안내가 들어갑니다. 빈칸을 오류로 단정하기 전에 이런 설명을 읽으면, 공개되지 않은 정보인지부터 구분하는 데 도움이 돼요.
후이즈로 알 수 있는 것
후이즈 조회는 도메인의 등록 정보를 확인하는 창구입니다. 여기서 가장 중요한 건 만료일이에요. 잘 돌아가던 사이트가 어느 날 갑자기 통째로 안 열린다면 도메인 만료를 먼저 의심해봐야 합니다. 자동 갱신을 걸어뒀어도 등록된 결제 수단이 만료돼 결제가 실패하는 일이 생각보다 자주 있어요.
네임서버 정보도 후이즈에서 확인할 수 있어서, 앞서 말한 “어느 관리 화면을 봐야 하는지”를 여기서 바로 알 수 있습니다. 도메인 상태값도 눈여겨볼 만합니다. 이전 잠금이 걸려 있으면 다른 업체로 옮길 수 없고, 만료 후 유예 기간에 들어가 있으면 서비스는 멈췄지만 아직 복구가 가능한 상태라는 뜻이에요.
도메인 연결이나 서버 이전 때문에 막히셨다면 TIDC로 문의해주세요. 국내 데이터센터에서 직접 운영하는 호스팅이라 DNS 설정부터 무중단 이전까지 전담 엔지니어가 함께 확인해드립니다.
