DNS 전파, TTL, 그리고 즉시 반영되지 않는 이유

레코드를 고쳤습니다. 어떤 사람들은 새 사이트를 보는데, 나는 아직 옛 사이트가 보입니다. 고장 난 것이 아닙니다.

'전파'의 실체는 캐시

브로드캐스트 같은 것은 없습니다. 리졸버가 레코드를 조회하면 그 레코드의 TTL 동안 응답을 캐시합니다. TTL이 만료될 때까지는 나와 그 리졸버를 쓰는 모든 사람에게 옛 응답을 계속 제공합니다. '전파'란 이 캐시들이 서로 다른 시점에 만료되는 것일 뿐입니다.

TTL이 조절 레버

• TTL 300초(5분) — 몇 분 안에 변경이 보입니다.

• TTL 3600초(1시간) — 최대 1시간 동안 옛 값이 남습니다.

• TTL 86400초(1일) — 최대 하루.

변경 전에 저렴하게 속도를 얻는 방법: 미리 TTL을 충분히 낮추고, 변경한 뒤, 다시 올리세요.

브라우저가 아니라 진실을 확인하세요

브라우저와 운영체제도 DNS를 캐시합니다. 세상이 보는 값을 확인하려면 권한 네임서버에 직접 질의하세요.

dig example.com A +short                    # your configured resolver
dig @1.1.1.1 example.com A +short           # Cloudflare public resolver
dig @8.8.8.8 example.com A +short           # Google public resolver
dig @ns1.yourhost.example example.com A +short   # YOUR authoritative server (the source of truth)

권한 서버가 올바른 응답을 갖고 있는데 공개 리졸버만 옛 값이라면 캐시가 만료되기를 기다리는 중입니다. 권한 서버 자체가 틀렸다면 영역을 고치세요.

기다리는 동안 내 캐시 비우기

# Linux (systemd-resolved)
resolvectl flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

브라우저도 자체 캐시를 갖고 있으므로, 시크릿 창이나 다른 브라우저로 우회할 수 있습니다.

'나는 되는데 다른 사람은 안 돼요' 체크리스트

1. 권한 네임서버에 질의합니다 — 거기서 레코드가 올바른가요?

2. apex와 www를 모두 확인합니다.

3. TTL과 레코드를 변경한 지 얼마나 되었는지 확인합니다.

4. 실제로 운영 중인 영역을 편집했는지 확인합니다(옛 등록기관의 사본이 아니라).

5. 같은 유형의 충돌하는 두 번째 레코드가 없는지 찾아봅니다.

관련 글

• DNS 레코드, 쉽게 설명합니다

• 네임서버와 DNS가 실제로 있는 곳