IP를 바꿨는데 옛날 서버로 가요 — DNS 캐싱

증상

서버 마이그레이션을 마쳤습니다. DNS A 레코드를 새 IP로 변경했고, 변경 직후 확인했을 때 레지스트리에서는 새 IP가 제대로 보였습니다. 그런데 일부 사용자, 또는 내 컴퓨터에서 요청을 보내면 여전히 옛 서버에서 응답이 옵니다. 몇 분이 지나도, 심지어 한 시간이 지나도 그렇습니다.

가설

PART 06에서 DNS 캐시와 TTL을 배웠습니다. 리졸버는 DNS 응답을 캐시에 저장하고, TTL이 만료되기 전까지는 같은 도메인을 다시 질의하지 않습니다. 사용자가 접속할 때마다 DNS 서버에 물어보는 것이 아니라, 캐시에 남은 예전 IP를 그대로 씁니다.

문제는 TTL이 생각보다 길게 설정되어 있을 때입니다. 3600초(1시간) 또는 86400초(하루)로 설정된 경우, 변경 후 그 시간이 지나야 전파가 완료됩니다.

도구로 확인하기

먼저 현재 DNS 레코드의 TTL이 얼마인지 확인합니다.

# 파일: 터미널dig api.example.com

ANSWER SECTION에서 두 번째 열이 TTL입니다.

;; ANSWER SECTION:
api.example.com.    3512    IN    A    203.0.113.10

3512라면 이 캐시가 아직 3512초 더 유효하다는 의미입니다. 이미 캐싱된 리졸버들은 이 시간 동안 새 IP를 반환하지 않습니다.

실제로 어떤 IP를 받고 있는지 비교하려면 서로 다른 DNS 서버에 직접 질의해봅니다.

# 파일: 터미널dig @8.8.8.8 api.example.com +shortdig @1.1.1.1 api.example.com +short

내 컴퓨터의 OS 캐시가 문제일 수도 있습니다. OS 캐시를 비우면 다시 리졸버에 질의합니다.

# macOSsudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder# Linux (systemd-resolved)sudo resolvectl flush-caches# Linux (nscd 사용 시)sudo systemctl restart nscd

캐시를 비운 뒤 다시 접속해도 옛 IP가 나온다면, 문제는 내 컴퓨터가 아니라 상위 리졸버(통신사 DNS 등)에 있는 것입니다. 그 리졸버의 캐시가 만료될 때까지는 어떻게 할 수 없습니다.

원인과 해결

TTL을 미리 낮추지 않고 IP를 변경한 것이 원인입니다. 올바른 절차는 이렇습니다.

IP 변경 24~48시간 전에 TTL을 낮게(예: 60초) 설정합니다. TTL이 짧아지면 캐시가 금방 만료되기 때문에, 변경 후 새 IP가 수십 초 안에 전파됩니다. 변경 완료 후에는 TTL을 원래 값으로 되돌립니다.

이미 변경해버렸다면 기다리는 것 외에 방법이 없습니다. 다만 사용자에게 hosts 파일을 임시로 수정해서 새 IP를 직접 지정하게 할 수 있습니다.

# /etc/hosts (macOS, Linux) 또는 C:\Windows\System32\drivers\etc\hosts (Windows)
203.0.113.20    api.example.com

hosts 파일은 DNS보다 우선순위가 높아서 OS 캐시와 관계없이 지정한 IP로 바로 접속합니다. 임시 조치로 쓰기에 적합합니다.

다음 절에서는 연결은 되는데 응답이 느린 또 다른 종류의 문제를 다룹니다.