نوێکراوەتەوە 1 month ago
DNS 레코드를 업데이트하고 브라우저를 새로 고침해도 아무것도 바뀌지 않습니다. 한 시간이 지나도 여전히 마찬가지입니다. 인터넷을 검색하면 "DNS 전파는 최대 48시간이 걸릴 수 있습니다"라는 문구를 발견하게 됩니다.
황당하게 느껴질 수 있습니다. 데이터베이스에서 값 하나를 바꿨을 뿐인데, 왜 인터넷 전체가 이틀이나 기다려야 알아채는 걸까요?
답은 이렇습니다. DNS 캐시는 자신이 틀렸다는 사실을 모릅니다. 그것을 알려줄 방법이 없습니다. 각 캐시는 섬처럼 독립되어 자신만의 타이머를 세고 있을 뿐, 진실이 바뀌었다는 것을 아무것도 모릅니다. 여러분은 정보가 퍼지기를 기다리는 것이 아닙니다. 무지함이 만료되기를 기다리는 것입니다.
겹겹이 쌓인 캐시
웹사이트를 방문할 때, 컴퓨터는 권한 DNS 서버에 직접 묻지 않습니다. 요청은 여러 캐시 계층을 통과합니다.
브라우저는 DNS 응답을 캐시에 저장합니다. 운영체제도 자체 캐시를 유지합니다. 라우터는 가정 전체를 위해 응답을 캐시합니다. ISP는 수백만 명의 고객을 위한 결과를 캐시하는 DNS 서버를 운영합니다. 기업 네트워크와 CDN은 더 많은 계층을 추가합니다.
각 캐시는 같은 질문을 두 번 하지 않으려고 DNS 응답을 저장합니다. 이 덕분에 DNS는 빠릅니다. 대부분의 요청은 로컬 네트워크를 벗어나지도 않습니다. 하지만 이는 곧 DNS 레코드 변경 사항이 사용자와 출처 사이의 모든 캐시에서 만료되어야만 업데이트가 보인다는 뜻이기도 합니다.
Time to Live
모든 DNS 레코드에는 TTL(Time to Live)이 포함됩니다. 이는 캐싱 서버에 해당 레코드를 얼마나 오래 저장해야 하는지를 초 단위로 알려주는 값입니다. 일반적인 값은 300초(5분)에서 86,400초(24시간) 사이입니다.
캐싱 서버가 DNS 레코드를 가져오면, 응답을 저장하고 카운트다운을 시작합니다. TTL이 0이 되면 레코드는 만료됩니다. 다음 요청이 들어오면 새로운 조회가 시작됩니다.
중요한 점이 있습니다. 권한 서버에서 레코드를 변경해도 기존 캐시는 무효화되지 않습니다. "지금 새로 고침" 버튼 같은 것은 없습니다. ISP가 변경 5분 전에 24시간 TTL로 레코드를 캐시했다면, 그 고객들은 거의 24시간 동안 이전 값을 보게 됩니다.
이것은 설계 실수가 아닙니다. 이것이 아키텍처입니다. 전 세계 캐시를 즉시 무효화하는 방법이 있다면, 모든 캐시가 수백만 개의 권한 서버로부터 오는 메시지를 수신해야 합니다. 이는 DNS를 확장 가능하게 만드는 "필요할 때만 요청한다"는 설계 원칙과 정반대입니다. DNS가 작동하는 이유는 캐시들이 섬처럼 독립적이기 때문입니다. 서로 소문을 주고받지 않습니다. 동기화하지 않습니다. 그냥 카운트다운만 합니다.
"48시간"의 근거
"48~72시간" 추정치는 기술적인 요구 사항이 아닙니다. 최악의 경우를 기반으로 한 보수적인 여유 시간입니다.
- 많은 제공업체들이 역사적으로 24시간 TTL을 기본값으로 사용했습니다.
- 일부 재귀 서버는 TTL 값을 완전히 무시합니다.
- 모든 DNS 구현이 사양을 엄격하게 따르지는 않습니다.
- 네트워크 문제로 인해 업데이트가 일반적인 TTL 기간을 넘어 지연될 수 있습니다.
48시간 지침은 오작동하는 서버를 포함하여 모든 곳에서 변경 사항이 확실히 전파되도록 보장합니다. 실제로 현대적인 인프라와 합리적인 TTL을 사용하면, 대부분의 변경 사항은 몇 시간 내에 전파됩니다.
실제 전파 시간
- TTL 5분(300초): 대부분의 사용자가 5~10분 내에 변경 사항을 확인할 수 있습니다.
- TTL 1시간(3,600초): 대부분의 캐시가 1~2시간 내에 업데이트됩니다.
- TTL 24시간(86,400초): 대다수 사용자가 24~36시간 내에 변경 사항을 확인할 수 있습니다.
편차는 타이밍에서 비롯됩니다. 캐싱 서버가 최근에 도메인을 조회하지 않았다면 캐시된 레코드가 없으므로, 해당 사용자들은 변경 사항을 즉시 볼 수 있습니다. 서버가 변경 1초 전에 레코드를 캐시했다면, 그 사용자들은 TTL이 다 끝날 때까지 기다려야 합니다.
전파 시간 단축하기
TTL 값은 여러분이 제어할 수 있습니다. 즉, 전파 속도를 제어할 수 있다는 의미입니다.
계획된 변경 전: 변경 최소 24~48시간 전에 TTL을 300초로 낮추세요. 마이그레이션 시점이 되면 어떤 캐시도 긴 TTL로 이전 레코드를 보유하지 않게 됩니다.
변경 사항이 전파된 후: TTL을 다시 3,600초 또는 86,400초로 높이세요. TTL이 낮을수록 권한 서버에 더 많은 요청이 발생합니다.
긴급 상황의 경우: 일부 DNS 제공업체는 매우 짧은 내부 TTL과 즉각적인 API 업데이트를 갖춘 전 세계 분산 네트워크를 운영합니다. 이것이 ISP와 기기의 캐싱을 없애주지는 않지만, 권한 서버가 가능한 한 빨리 올바른 정보를 제공하도록 보장합니다.
전파 상태 확인
dig와 nslookup 같은 커맨드라인 도구를 사용하면 특정 DNS 서버에 직접 쿼리할 수 있습니다. 온라인 전파 확인 도구는 전 세계 서버에 쿼리하여 지리적 전파 현황을 보여줍니다. Google Public DNS(8.8.8.8)와 Cloudflare DNS(1.1.1.1)에 쿼리하면 글로벌 상태를 파악할 수 있습니다.
한 가지 주의사항이 있습니다. 브라우저와 운영체제는 DNS를 독립적으로 캐시합니다. 전 세계적으로 전파가 완료된 후에도 로컬에서는 이전 값이 보일 수 있습니다. DNS 캐시를 초기화하고 브라우저 데이터를 지워 확인하세요.
제어할 수 있는 것과 없는 것
제어할 수 있는 것: TTL 값. DNS 제공업체 선택. 사전에 변경 계획 세우기. 전파 상태 모니터링.
제어할 수 없는 것: 서드파티 리졸버의 동작. 모든 DNS 소프트웨어가 사양을 따르는지 여부. 분산 시스템의 근본적인 현실—존재하는지조차 모르는 업데이트를 확인하라고 캐시를 강제할 수는 없습니다.
DNS 전파는 극복해야 할 결함이 아닙니다. 실시간 정확성보다 최종적 일관성(eventual consistency)을 수용함으로써 수십억 건의 요청을 처리하는 시스템의 대가입니다. 이를 이해하면 기다림이 답답함에서 계획으로 바뀝니다. 변경 전에 TTL을 낮추고, 이후에 전파를 확인하고, 30초마다 브라우저를 새로 고침하는 것을 멈추세요. 캐시는 결국 따라잡을 것입니다. 단지 자신이 틀렸다는 것을 깨달을 시간이 필요할 뿐입니다.
DNS 전파에 관해 자주 묻는 질문
DNS를 강제로 더 빨리 전파시킬 수 있나요?
아니요. 서드파티 캐시에 새로 고침을 강제할 수 없습니다. 레코드가 변경되었다는 사실을 그들은 알 수도 없습니다. 하지만 변경 최소 24~48시간 전에 TTL을 300초로 낮추면 전파 시간을 최소화할 수 있습니다. 이렇게 하면 변경 시점에 캐시들이 수명이 짧은 레코드를 보유하게 됩니다.
일부 사용자는 즉시 변경 사항을 보는데 다른 사용자는 왜 못 볼까요?
타이밍 때문입니다. 사용자의 DNS 리졸버가 최근에 해당 도메인을 조회하지 않았다면 캐시된 레코드가 없어 즉시 최신 데이터를 가져옵니다. 변경 직전에 레코드를 캐시했다면, 그 사용자는 TTL이 다 끝날 때까지 기다려야 합니다. 동일한 변경, 다른 경험—각 캐시가 마지막으로 조회한 시점이 전부를 결정합니다.
레코드가 변경될 때 DNS가 모든 캐시에 알림을 보낼 수는 없나요?
그러면 전체 아키텍처가 뒤집힙니다. 캐시가 필요할 때 조회하는 대신, 모든 캐시가 전 세계 수백만 개의 권한 서버로부터 오는 무효화 메시지를 수신해야 합니다. 조정에 따른 부하로 시스템이 붕괴될 것입니다. DNS가 확장 가능한 이유는 정확히 캐시들이 필요할 때만 입을 여는, 각자 고립된 섬들이기 때문입니다.
ئایا ئەم پەڕەیە بەسوود بوو؟