DNS를 바꿨는데 왜 예전 주소로 갈까? 조회와 TTL

About this offer

도메인의 주소를 바꿨는데 일부 사용자는 예전 서버로 접속합니다. “DNS가 전파되는 중”이라고만 말하면 무엇을 기다리는지 알기 어렵습니다. 이번에는 누가 답을 가지고 있고, 언제까지 재사용할 수 있는지 를 중심으로 보겠습니다. 이름을 묻는 곳과 답을 관리하는 곳 일반적인 이름 조회에서 클라이언트는 재귀 리졸버에 질문합니다. 리졸버가 유효한 캐시를 가지고 있으면 재사용하고, 필요하면 이름 서버를 찾아 답을 구합니다. 권한 있는 이름 서버는 자신이 담당하는 영역의 정보를 제공합니다. DNS의 리졸버·이름 서버·캐시 역할은 RFC 1034 에서 설명합니다. 그림은 중간의 루트·최상위 도메인 서버 조회를 접은 개념 흐름입니다. 모든 요청이 권한 서버까지 가는 것은 아닙니다. TTL은 재사용 시간의 기준 TTL은 캐시한 레코드를 재사용할 수 있는 시간의 기준입니다. TTL=60 인 답을 시각 0에 받았다면, 다음 표처럼 생각할 수 있습니다. 여기서는 전송 시간, 시계 차이와 별도 캐시 정책은 제외합니다. 경과 시간 이 모형에서의 판단 20초 40초 남음 59초 1초 남음 60초 만료, 새 조회가 필요함 const ttl = 60; for (const elapsed of [20, 59, 60]) { const remaining = Math.max(0, ttl - elapsed); console.log(`${elapsed}:remaining=${remaining}`); } 출력은 20:remaining=40 , 59:remaining=1 , 60:remaining=0 입니다. TTL 계산 모형을 검증했고 실제 도메인 설정은 변경하지 않았습니다. TTL을 낮췄는데 바로 안 바뀌는 이유 이전에 더 긴 TTL로 받은 캐시는 그 이전 답의 시간을 기준으로 남아 있을 수 있습니다. 지금 권한 서버의 TTL을 낮췄다고 이미 배포된 캐시의 시간을 소급해서 줄이는 것은 아닙니다. 브라우저, 운영체제, 리졸버 등 어느 계층의 답인지도 구분해야 합니다. TTL을 “전체 인터넷이 이 시각에 바뀐다”는 약속으로 보지 않는 편이 좋습니다. 오류 응답 캐시나 만료된 답의 제한적인 제공처럼 추가 규칙도 있습니다. 이 글은 기본 정상 조회만 설명합니다. 확인 문제 캐시가 유효한데 매번 권한 서버에 물어야 할까요? 기존 답의 TTL이 600초였는데 새 TTL을 60초로 바꾸면 기존 캐시도 바로 줄어들까요? TTL 90초인 답을 받은 뒤 35초가 지나면 이 모형에서 얼마나 남을까요? 답과 해설 기본적으로 유효한 캐시를 재사용할 수 있습니다. 아닙니다. 이미 받은 답의 TTL과 새로 받은 답을 구분해야 합니다. 55초입니다. 실제 운영에서는 조회 계층과 추가 정책도 확인합니다. 오늘은 “내가 보는 답은 어느 계층의 캐시인가?”를 적어보겠습니다. 내일은 TTL을 바꾸기 전후의 시간표를 그리고, 일주일 뒤에는 HTTP 캐시와 무엇이 다른지 비교해보면 좋겠습니다. 자료 확인 기준: RFC 1034의 정상 조회와 캐시 개념, 2026-10-04. 합성 TTL 계산을 제외한 실제 DNS 질의·변경 실험은 하지 않았습니다. 예제 검증 환경: Node.js v24.13.1.

Offer details

Provider

velog

Source

velog-rss

Score

54.39

Confidence

49%