DNS 변경은 원래 얼마나 걸리나요?

대시보드의 DNS 레코드 편집 화면은 전파까지 최대 5분이 걸릴 수 있다고 안내하고, 네임서버 변경 화면은 최대 48시간이 걸릴 수 있다고 안내합니다. 두 값이 다른 이유는 레코드는 권한 네임서버 안에서 바뀌고 네임서버 변경은 상위 레지스트리의 위임 정보가 바뀌기 때문입니다.

권한 네임서버에는 새 값이 보이는데 제 PC 에서는 옛 값이 보입니다.

중간 리졸버나 OS, 브라우저 캐시에 옛 값이 남은 것입니다. 설정은 정상이므로 고칠 것은 없고 캐시가 만료되기를 기다리거나 각 계층의 캐시를 비우면 됩니다. 기다릴 시간은 바꾸기 전 레코드의 TTL 이 기준입니다.

TTL 을 지금 낮추면 반영이 빨라지나요?

이미 캐시된 응답에는 소용이 없습니다. 리졸버는 응답을 받을 때 함께 받은 TTL 만큼 보관하므로, 지금 낮춘 값은 다음 조회부터 적용됩니다. 그래서 전환을 계획할 때는 바꾸기 하루 이틀 전에 TTL 을 미리 낮춰 둡니다.

몇 시간을 기다렸는데도 전혀 안 바뀝니다.

기다림의 문제가 아니라 애초에 값이 반영되지 않은 경우입니다. 권한 네임서버에 직접 질의해서 새 값이 보이지 않는다면 편집한 콘솔이 그 도메인의 실제 권한 네임서버가 아닙니다. 네임서버 위임을 먼저 확인하세요.

레코드를 수정했는데 저장이 되지 않습니다.

기관이전이 진행 중이면 이전이 끝날 때까지 DNS 레코드를 편집할 수 없다는 안내가 뜹니다. 도메인 상태가 활성이 아닌 경우에도 편집이 제한될 수 있습니다. 상태를 먼저 확인하고 그래도 저장되지 않으면 문의로 연락해 주세요.

DNS 변경이 반영되지 않을 때

DNS 변경이 반영되지 않을 때 가장 빠른 확인은 권한 네임서버에 직접 질의해 보는 것입니다. dig @ns1.example-dns.com A example.co.kr 에 새 값이 보이면 설정은 끝난 것이고 남은 것은 캐시가 만료되기를 기다리는 일뿐입니다. 반대로 권한 네임서버에도 옛 값이 보이면 기다려서 해결될 문제가 아니고, 값이 실제로 저장되지 않았거나 엉뚱한 콘솔에서 고친 것입니다.

이 한 번의 질의로 "기다리면 되는 문제"와 "고쳐야 하는 문제"가 갈립니다. 아래에서는 계층을 하나씩 올라가며 어디까지 반영됐는지 확인합니다.

계층별로 어디까지 반영됐는지 확인합니다

DNS 응답은 다섯 계층을 거쳐 사용자에게 도달합니다. 아래로 내려갈수록 우리가 통제할 수 없는 영역입니다.

계층	확인 명령	여기만 옛 값이면
권한 네임서버	`dig @ns1.example-dns.com A example.co.kr`	저장이 안 됐거나 다른 콘솔에서 고침
공개 리졸버	`dig @1.1.1.1 A example.co.kr`	캐시 만료 대기
사내 리졸버	`dig @192.0.2.53 A example.co.kr`	사내 DNS 캐시 비우기
OS 캐시	`ping example.co.kr` 로 보이는 IP	OS 캐시 비우기
브라우저	시크릿 창에서 접속	브라우저 캐시와 HSTS 확인

# 1. 권한 네임서버가 누구인지 먼저 확인
dig NS example.co.kr +short

# 2. 그 네임서버에 직접 질의 (캐시를 거치지 않음)
dig @ns1.example-dns.com A example.co.kr +noall +answer

# 3. 공개 리졸버가 지금 답하는 값과 남은 캐시 시간
dig @1.1.1.1 A example.co.kr
dig @8.8.8.8 A example.co.kr

# 4. 내 PC 가 실제로 쓰는 리졸버의 답
dig A example.co.kr

공개 리졸버 응답의 TTL 값은 "이 답이 캐시에서 사라지기까지 남은 초"입니다. 같은 질의를 몇 초 뒤 다시 실행해서 숫자가 줄어들고 있으면 캐시된 응답이고, 그 숫자가 0이 되는 순간 새 값으로 바뀝니다.

기다려야 하는 시간 계산

기준은 바꾸기 전 레코드의 TTL 입니다. 새로 설정한 TTL이 아닙니다. 리졸버는 응답을 받을 때 함께 받은 TTL만큼 보관하기 때문입니다.

바꾸기 전 TTL	최대 대기 시간	비고
1분	약 1분	전환 직전에 쓰기 좋은 값
5분	약 5분	대시보드 DNS 레코드 기본값
30분	약 30분	평상시 운영에 무리 없는 값
1시간	약 1시간	일반적인 기본값
24시간	약 24시간	전환 계획이 있으면 미리 낮춰야 함

대시보드의 DNS 레코드 추가 화면에서 TTL은 1분 / 5분 / 30분 / 1시간 / 24시간 다섯 개 중에서 고르며 기본값은 5분입니다. 임의의 초를 직접 입력하는 방식은 아닙니다. 전환을 계획한다면 예정일 하루 이틀 전에 TTL을 1분으로 낮춰 두고, 전환이 끝난 뒤 원래 값으로 되돌리세요.

가장 흔한 원인: 엉뚱한 콘솔에서 고쳤습니다

실제 문의에서 가장 많은 원인입니다. 도메인은 레토에 등록되어 있지만 네임서버가 다른 서비스를 가리키고 있으면, 레토 대시보드의 DNS 레코드를 고쳐도 아무 일도 일어나지 않습니다. 반대 경우도 마찬가지입니다. 레코드는 지금 위임받은 네임서버 안에서만 의미가 있습니다.

실제 권한 네임서버를 확인합니다
```
dig NS example.co.kr +short
dig NS example.co.kr +trace | tail -10
```
WHOIS 조회의 네임서버 항목에서도 같은 값을 볼 수 있습니다.
그 네임서버를 운영하는 콘솔에서 고칩니다
출력된 이름이 레토 네임서버라면 대시보드 도메인 상세의 DNS 및 포워딩 탭에서 DNS 레코드 카드를 고칩니다. 외부 DNS 서비스 이름이라면 그 서비스의 콘솔에서 고쳐야 합니다. 어느 쪽으로 모을지 정하는 기준은 외부 서비스 연결하기를 참고하세요.
관리 주체를 옮기려면 레코드를 먼저 복제합니다
레토 네임서버로 옮기고 싶다면 새 존에 기존 레코드를 모두 넣은 뒤 네임서버를 바꿉니다. 순서를 바꾸면 웹과 메일이 함께 멈춥니다. 절차는 네임서버 변경하기에 있습니다.

네임서버 자체가 아직 옛 것을 가리키는 경우

네임서버를 바꿨는데도 옛 DNS 서비스의 답이 계속 돌아온다면 레지스트리의 위임이 아직 안 바뀐 것입니다. 위임은 상위 존이 관리하므로 레코드 변경보다 느리게 퍼집니다.

# 루트부터 끝까지 따라가며 각 단계의 위임을 확인
dig NS example.co.kr +trace

# 상위 존의 네임서버를 먼저 찾고, 그 서버에 위임을 직접 물어본다
dig NS co.kr +short
dig @<위에서 나온 상위 네임서버> NS example.co.kr +noall +authority +answer

+trace 출력의 마지막 단계에 새 네임서버가 나오면 위임은 끝난 것입니다. 그 뒤에도 일부 사용자가 옛 사이트를 보는 것은 각 리졸버가 들고 있는 옛 위임이 순차적으로 만료되기 때문이며, 최대 48시간이 걸릴 수 있습니다. 이 기간에는 옛 존을 지우지 말고 양쪽이 같은 답을 하도록 유지하세요. 전파 중에 옛 존을 지우면 일부 사용자에게 장애가 고정됩니다.

계층별로 캐시 비우기

권한 네임서버에 새 값이 확인된 뒤에만 의미가 있는 작업입니다.

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Windows (관리자 권한 명령 프롬프트)
ipconfig /flushdns

# Linux (systemd-resolved)
sudo resolvectl flush-caches

브라우저는 별도 캐시를 씁니다. 크롬은 chrome://net-internals/#dns 에서 호스트 캐시를 지울 수 있고, HTTPS 강제 전환 때문에 증상이 남는다면 chrome://net-internals/#hsts 에서 해당 도메인을 삭제합니다. 사내 리졸버는 네트워크 담당자에게 캐시 비우기를 요청해야 하며, 통신사 리졸버는 우리가 비울 수 없으므로 기다리는 것이 유일한 방법입니다.

그래도 해결되지 않으면

권한 네임서버에 새 값이 보이지 않거나, 충분히 기다렸는데도 계층 사이 값이 계속 어긋난다면 아래 자료와 함께 문의로 연락해 주세요.

도메인 이름과 바꾼 레코드의 타입, 이름, 이전 값, 새 값
변경한 시각과 변경한 콘솔 (레토 대시보드인지 외부 DNS 서비스인지)
dig NS 출력과 dig @권한네임서버 질의 결과
dig @1.1.1.1 과 사내 리졸버 질의 결과의 차이
바꾸기 전 레코드의 TTL 값