DNS 전파와 TTL 이해하기

도메인을 새 서버로 연결하도록 DNS 레코드를 방금 업데이트했습니다. 내 컴퓨터에서 확인해보니 아무것도 달라지지 않았습니다. 5분을 기다렸다가 다시 확인해도 여전히 기존 서버입니다. 나라 건너편에 있는 누군가는 새 사이트가 보인다고 합니다. 같은 사무실에 있는 동료는 아직 기존 사이트가 보입니다.

같은 방에 있는 두 사람이 서로 다른 버전의 웹사이트를 보고 있습니다. 이것이 DNS 전파입니다. 그 이유를 이해하려면 DNS에서 가장 많이 오해받는 개념 중 하나인 TTL(Time to Live)을 알아야 합니다.

DNS 전파란 실제로 무엇인가

대부분의 혼란을 해소하는 핵심이 있습니다. DNS 전파는 실제로 아무것도 전파하지 않습니다. 네트워크 전체에 업데이트가 물결처럼 퍼지는 일은 없습니다. 어떤 중앙 시스템도 내 변경 사항을 전 세계 DNS 서버에 알리지 않습니다.

DNS 레코드를 업데이트할 때, 내 도메인의 원본 데이터를 보유한 권한 네임서버의 데이터를 변경하는 것입니다. 하지만 수백만 개의 DNS 리졸버는 내 네임서버에서 업데이트를 지속적으로 확인하지 않습니다. 대역폭을 절약하고 지연 시간을 줄이기 위해 응답을 캐시에 저장하기 때문입니다.

"전파"란 수많은 독립적인 시스템에서 각자의 일정에 따라 수동적으로 캐시가 만료되는 현상입니다. 각 리졸버는 변경이 이루어지는 순간이 아니라, 자신이 캐시한 복사본이 만료될 때 비로소 업데이트 사실을 알게 됩니다.

서로 다른 시점에 시작되어 서로 다른 시간으로 맞춰진 수백만 개의 카운트다운 타이머를 떠올려 보세요. 내 DNS 변경 사항은 각 리졸버의 타이머가 0이 될 때에야 그 리졸버에게 보이기 시작합니다.

TTL: 캐시 만료를 다스리는 값

모든 DNS 레코드에는 초 단위로 표시된 TTL(Time to Live) 값이 포함되어 있습니다. 이 숫자는 리졸버에게 해당 레코드를 얼마 동안 캐시에 보관한 뒤 삭제하고 새 데이터를 가져와야 하는지 알려줍니다.

리졸버가 권한 네임서버에 쿼리를 보내면, 응답에는 레코드 데이터와 TTL이 함께 포함됩니다. 리졸버는 이 정보를 저장하고 카운트다운을 시작합니다. 이후 TTL이 만료되기 전까지, 해당 리졸버에 내 도메인을 묻는 모든 요청은 네임서버에 접속하지 않고 캐시된 응답을 받습니다.

TTL이 만료되면, 리졸버는 캐시된 레코드를 삭제합니다. 다음 쿼리가 들어오면 새로운 조회가 이루어지며, 현재 존재하는 레코드를 받아옵니다.

이 캐싱 메커니즘은 DNS 확장성의 핵심입니다. 이것이 없다면, 모든 조회마다 권한 서버까지 여러 번 왕복해야 하므로 엄청난 부하와 지연이 발생할 것입니다. 하지만 효율성에는 상충관계가 있습니다. 리졸버가 캐시를 강제로 일찍 만료시키도록 할 수는 없습니다. 카운트다운은 상대방의 시계에서 진행되지, 내 것이 아닙니다.

전파 시간이 제각각인 이유

DNS 전파에 "최대 48시간"이 걸린다는 말은 거의 맞지 않는 보수적인 최악의 시나리오입니다. 여러 요소가 편차를 만들어냅니다.

TTL 설정이 가장 중요한 요소입니다. 이전 레코드의 TTL이 300초였다면 전파는 몇 분 안에 완료될 수 있습니다. 86400초였다면 꼬박 하루를 기다려야 합니다. 48시간 추정치는 높은 TTL 값에 제대로 동작하지 않는 리졸버를 위한 여유 시간까지 더한 것입니다.

리졸버 동작은 예측을 어렵게 만드는 요소입니다. 대부분의 리졸버는 TTL 값을 잘 준수하지만, 일부 적극적인 캐싱 시스템은 상위 쿼리를 줄이기 위해 TTL을 임의로 연장합니다. ISP 리졸버는 지정된 것보다 더 오래 캐시할 수 있습니다. 브라우저 DNS 캐시, 운영체제 캐시, 애플리케이션 수준의 캐시가 레이어를 더해, 리졸버 업데이트가 즉시 반영되지 않을 수 있습니다.

지리적 분포도 영향을 미칩니다. 서로 다른 리졸버가 서로 다른 시간에 내 네임서버를 조회하기 때문입니다. 도쿄의 리졸버는 1시간 전에 내 레코드를 캐시했을 수 있는 반면, 런던의 리졸버는 23시간 전에 캐시했을 수 있습니다.

네거티브 캐싱은 새로운 레코드를 생성할 때 복잡함을 더합니다. 존재하지 않는 서브도메인을 누군가 조회하면, 리졸버는 그 "없다"는 응답도 캐시에 저장합니다. 나중에 해당 서브도메인을 실제로 생성하더라도, SOA 레코드에 정의된 별도의 TTL로 네거티브 캐시가 만료될 때까지 리졸버는 이를 확인하지 않습니다.

다운타임을 최소화하는 전략

전파 메커니즘을 이해하면 DNS 변경을 전략적으로 계획할 수 있습니다.

미리 TTL을 낮추세요. 가장 중요한 방법입니다. 서버 마이그레이션을 계획하고 있다면, 변경 최소 48시간 전에 TTL을 300초로 줄이세요. 그러면 실제로 레코드를 변경할 때 대부분의 리졸버가 몇 시간이 아닌 몇 분 안에 갱신됩니다. 전파가 완료된 후에는 효율성을 위해 TTL을 다시 높이세요.

중요한 점은 TTL을 변경 이전에 낮춰야 한다는 것입니다. 레코드를 업데이트한 이후에는, 전파 일정이 인터넷 전체에 이미 캐시된 이전 TTL 값에 의해 결정됩니다. 주사위는 이미 던져진 것입니다.

병렬 인프라를 운영하세요. 가능하다면, 전환 기간 동안 기존 시스템과 새 시스템을 동시에 운영하세요. DNS를 변경하기 전에 새 서버가 기존 서버와 동일한 콘텐츠를 제공하도록 구성하세요. 캐시된 기존 레코드로 접속하든 새 레코드로 접속하든, 사용자는 동일한 콘텐츠를 보게 되어 다운타임이 완전히 사라집니다.

여러 위치에서 모니터링하세요. 내 위치에서 변경이 전파된 것처럼 보여도, 전 세계적으로 완료된 것은 아닙니다. 서로 다른 지역과 리졸버 네트워크에서 쿼리하는 DNS 확인 도구를 활용하세요.

트래픽이 적은 시간대를 활용하세요. 일부 불일치를 피할 수 없다면, 영향을 받는 사용자를 최소화하기 위해 트래픽이 가장 낮은 시간대에 DNS를 변경하세요.

흔한 오해들

"전파에는 48시간이 걸린다." TTL을 잘 관리하면 대부분의 DNS 변경은 1시간 이내에 완료됩니다. 48시간 추정치는 높은 TTL 값과 제대로 동작하지 않는 캐시가 있는 최악의 경우를 상정한 것입니다.

"변경 후에도 전파 속도를 높일 수 있다." 그렇지 않습니다. 전파 일정은 변경 전에 이미 캐시된 TTL 값에 의해 결정되어 있습니다. 전파 속도에 영향을 줄 수 있는 유일한 방법은 변경 이전에 TTL 값을 낮추는 것입니다.

"DNS 캐시를 비우면 전파가 강제된다." 이것은 내 기기의 캐시만 지워서 리졸버에 다시 쿼리하도록 하는 것입니다. 하지만 리졸버의 캐시는 여전히 기존 레코드를 가지고 있을 수 있습니다. 전 세계 전파는 개별 캐시 삭제와는 완전히 별개입니다.

DNS 전파에 대해 자주 묻는 질문

왜 동료는 나와 다른 DNS 결과를 볼까요?

서로 다른 DNS 리졸버를 사용하고 있을 가능성이 높습니다. 다른 ISP를 사용하거나, Google이나 Cloudflare처럼 서로 다르게 설정된 DNS 서버를 쓰고 있기 때문입니다. 각 리졸버는 서로 다른 시간에 내 도메인 레코드를 캐시했으며, 각 캐시는 독립적으로 만료됩니다.

DNS 레코드에 TTL을 얼마로 설정해야 할까요?

거의 변경되지 않는 레코드(예: 이메일용 MX 레코드)에는 360086400초(124시간)가 리졸버 부하를 줄여줍니다. 마이그레이션이나 장애 대응 중에 변경될 수 있는 레코드에는 300600초(510분)로 설정하면 필요할 때 더 빠른 전파가 가능합니다. 많은 관리자들이 유연성을 위해 A 레코드의 TTL을 낮게 유지합니다.

DNS 제공업체가 전파 속도를 높여줄 수 있나요?

어떤 제공업체도 독립적인 리졸버들의 TTL 캐싱을 무시할 수는 없습니다. 일부 관리형 DNS 서비스는 리졸버가 쿼리를 보낼 때 업데이트를 더 빠르게 제공하는 고성능 인프라를 갖추고 있고, 주요 리졸버 운영자와의 협력 관계를 통해 특정 상황에서 도움을 줄 수 있습니다. 그러나 근본적인 캐싱 동작은 누구의 통제 밖에 있습니다.

DNS 전파가 완료됐는지 어떻게 확인하나요?

여러 지역과 리졸버 네트워크에서 DNS를 조회하는 온라인 도구를 사용하세요. 서로 다른 네트워크에 연결된 여러 기기에서 직접 확인해보는 것도 좋습니다. "완료"라는 기준은 사실 절대적이지 않습니다. 어딘가에는 항상 오래된 캐시를 가진 리졸버가 남아있기 마련입니다. 하지만 실용적인 관점에서, 주요 리졸버들이 변경 사항을 반영하고 있다면 전파가 완료된 것으로 볼 수 있습니다.