DNS 전파에는 얼마나 걸리나요?

DNS 레코드를 변경했고 이제 기다리는 중입니다. 어떤 체커는 새 값을 보여 주고, 다른 체커는 여전히 이전 값을 보여 주며, 등록 기관의 도움말 페이지는 24–48시간을 감안하라고 합니다. 그렇다면 실제로는 얼마나 걸릴까요?

솔직한 답은, 전파 시계는 하나가 아니라는 것입니다. 레코드를 저장해도 인터넷으로 무언가가 밀려 나가는 일은 없습니다. 대신, 각 리졸버가 캐시한 이전 레코드의 사본이 만료됨에 따라 리졸버마다 차례로 변경 사항이 보이게 됩니다. 이 하나의 사실을 이해하면 대기에 대한 거의 모든 의문이 풀립니다.

전파란 사실은 캐시가 만료되는 것일 뿐입니다

리졸버가 도메인을 처음 조회하면 권한 있는 네임서버에 묻고, 답을 받아, 레코드의 TTL(수명)이 허용하는 동안 보관합니다. 그 타이머가 끝나기 전까지는 저장된 답을 계속 내놓으며, 그동안 당신이 무언가를 바꿨는지 결코 확인하지 않습니다.

당신의 편집은 권한 있는 서버를 즉시 업데이트합니다. 그러나 이전 답을 이미 캐시한 모든 리졸버는 자신의 사본이 만료될 때까지 그것을 계속 사용합니다. DNS 전파의 작동 방식은 그 여정을 자세히 따라갑니다. 짧게 말하면, 지연은 전적으로 캐시 안에 있으며, 새 레코드가 어딘가로 천천히 이동하는 것이 아닙니다.

이전 레코드의 TTL이 최대 대기 시간을 정합니다

중요한 타이머는 변경 전 레코드의 TTL입니다. 캐시에 들어 있는 것이 바로 그 사본이기 때문입니다. 이전 A 레코드의 TTL이 3600초였다면, 편집 직전에 그것을 가져간 리졸버는 거의 한 시간 가까이 그것을 계속 제공할 수 있습니다. 이전 TTL이 86400이었다면 같은 일이 거의 하루 동안 일어날 수 있습니다.

• 레코드 유형보다는 TTL이 더 중요합니다. TTL이 같은 A 레코드와 MX 레코드는 같은 일정에 따라 사라집니다.
• 각 리졸버는 서로 다른 순간에 타이머를 시작했으므로, 캐시는 한꺼번에가 아니라 하나씩 만료됩니다.
• 일부 리졸버는 최소 TTL을 강제하고 아주 짧은 TTL을 무시하므로, 대기 시간이 당신이 설정한 것보다 길어질 수 있습니다.
• 긴 TTL에 상한을 두는 리졸버도 있어서, 변경 사항이 최악의 경우보다 빨리 나타날 수 있습니다.

계획된 변경 전에는 현재 TTL을 읽어 최악의 경우를 미리 파악할 가치가 있습니다. 300초로 설정된 레코드는 설계상 짧은 대기를 제공하고, 86400으로 설정된 레코드는 긴급한 수정마저 느리게 만듭니다. 많은 고통스러운 대기는 아무도 설정한 기억이 없는 긴 TTL 때문으로 밝혀지며, 변경이 이미 적용되고 타이머가 이미 돌고 나서야 발견됩니다.

부정 캐싱: '그런 레코드 없음'도 캐시됩니다

이전에 존재하지 않던 레코드를 추가하면 기다려야 할 캐시가 하나 더 있습니다. 리졸버가 이전에 그 이름과 유형을 물어 '그런 레코드 없음'이라는 답을 받았다면, 그 부정적인 답도 영역의 SOA 레코드에서 가져온 타이머로 캐시합니다. 부정 항목이 만료되기 전까지, 그 리졸버는 몇 분 전에 당신이 만들었음에도 레코드가 존재하지 않는다고 계속 주장합니다.

그래서 완전히 새로운 서브도메인이나 첫 TXT 레코드는 기존 레코드를 편집하는 것보다 느리게 느껴질 수 있습니다. 이전 답의 캐시와 이전 부재의 캐시라는 두 개의 서로 다른 캐시가 모두 비워져야 모두가 같은 것을 볼 수 있기 때문입니다.

실제로는 얼마나 걸리나요

이것들은 약속이 아니라 패턴입니다. 이전 TTL이 짧은 조용한 도메인의 변경은 한 시간도 안 되어 사실상 전 세계에 보일 수 있는 반면, 레지스트리의 TTL이 긴 위임 변경은 다음 날에도 여전히 들쭉날쭉할 수 있습니다. 두 결과 모두 정상이며, 어느 쪽도 무언가 고장 났다는 뜻은 아닙니다.

실제 타임라인: 변경 하나, 리졸버 세 개

구체적인 타이머가 있으면 이 패턴을 믿기가 더 쉬워집니다. 레코드의 이전 TTL이 3600초, 즉 한 시간이고, 10:00에 레코드를 편집했다고 가정해 보겠습니다. 마지막으로 물어본 시점만 빼고 모든 면에서 동일한 리졸버 세 개가 완전히 다른 세 가지 대기를 만들어 냅니다.

그 그림에서 고장 난 것은 아무것도 없습니다. 전체 메커니즘의 축소판일 뿐입니다. 리졸버 A의 사용자는 거의 한 시간 전체를 기다리고, 리졸버 C의 사용자는 변경을 즉시 보며, 두 리졸버 뒤에 있는 사람들은 같은 편집에 대해 완전히 다른 전파 시간을 정직하게 보고할 수 있습니다. 리졸버 세 개를 실제로 당신의 레코드를 보유한 수천 개로 확장해 보십시오. 각각 고유한 가져오기 시점을 가지고 있으며, 사람들이 상상하는 매끄러운 전 세계 롤아웃은 그 실제 모습이 됩니다. 즉 한 시간에 걸쳐 만료되는 개별 타이머들의 흩어짐입니다. 또한 당신 자신의 확인이 어느 방향으로든 거의 아무것도 증명하지 못하는 이유도 보여 줍니다. 당신은 항상 그 리졸버 중 정확히 하나를 통해서만 보고 있으며, 그 타이머는 다른 누구의 타이머에 대해서도 아무것도 말해 주지 않습니다.

등록 기관이 24–48시간이라고 말하는 이유

익숙한 24–48시간이라는 수치는 측정이 아니라 지원 데스크의 최악의 경우입니다. 가장 느린 일반적인 TTL, 위임 변경, 타이머를 늘이는 리졸버를 모두 포괄하여, 대부분의 사람의 변경이 그 안에서 끝나도록 한 것입니다. 많은 변경은 훨씬 빨리 끝나는데, 그래서 어떤 사람은 전파가 오 분 걸렸다고 단언하고 다른 사람은 하루를 기다리기도 합니다. 그들은 서로 다른 레코드를, 서로 다른 이전 TTL로 변경했고, 서로 다른 캐시를 통해 본 것입니다.

다음번에 속도를 높이려면: 먼저 TTL을 낮추세요

이미 시작된 대기는 줄일 수 없습니다. 이전 레코드를 보유한 캐시가 일찍 다시 확인하지 않기 때문입니다. 그러나 다음 변경을 위해 제대로 준비할 수는 있습니다.

1. 1

   미리 TTL 낮추기

   계획된 변경 하루 이상 전에 레코드의 TTL을 300초로 설정하세요. 이것은 더 긴 이전 TTL이 모든 곳에서 완전히 만료된 뒤에야 도움이 되기 시작하므로 일찍 하세요.

2. 2

   이전 TTL이 지나가게 두기

   최소 하나의 완전한 이전 TTL 기간이 지나가게 두세요. 그 후에는 전 세계의 모든 캐시 사본이 만료 후 300초 이내에 새로 고쳐집니다.

3. 3

   변경하기

   레코드를 편집하세요. 이제 리졸버는 저장된 사본이 차례로 만료됨에 따라 짧은 TTL 창 안에서 새 값을 가져옵니다.

4. 4

   추측하지 말고 확인하기

   하나의 리졸버가 캐시한 것만 보여 주는 자신의 브라우저를 믿지 말고, 전 세계의 리졸버를 확인하세요.

5. 5

   TTL 다시 높이기

   변경이 안정되면 권한 있는 서버의 쿼리 부하를 줄이기 위해 3600초와 같은 더 긴 TTL로 복원하세요.

당신의 브라우저도 캐시를 유지합니다

어떤 리졸버보다 더 가까이에 또 하나의 캐시가 있습니다. 바로 당신 자신의 기기입니다. 운영 체제는 최근 답변의 작은 로컬 캐시를 유지하고, 브라우저는 그 위에 또 하나를 유지하므로, 테스트에 사용하는 노트북은 모든 리졸버가 이미 넘어간 뒤에도 한동안 이전 레코드에 매달릴 수 있습니다. 같은 변경이 당신의 휴대폰에서는 완료된 것처럼 보이고 책상에서는 미완료로 보이는 이유가 바로 이것입니다. DNS 캐시를 비우는 방법은 일반적인 시스템에서 이러한 로컬 복사본을 지우는 방법을 다룹니다. 비우기는 당신 자신의 화면만 고치며, 때로는 그것이 정확히 필요한 전부이고, 다른 누구의 네트워크가 무엇을 보고 있는지에 대한 증거는 결코 되지 않습니다.

추측하지 말고 진행 상황을 확인하세요

자신의 기기는 하나의 리졸버가 생각하는 것만 보여 줄 수 있습니다. DNS 전파 체커는 세계 여러 지역의 공용 리졸버 10곳에 같은 레코드를 묻고, 각 답을 나란히 보여 주며, 일치하는지도 알려 줍니다. 대부분이 이미 새 값을 반환한다면, 노트북이 뭐라고 하든 전파는 거의 끝난 것입니다.

여기에 DNS TTL 조회를 함께 사용하면 리졸버가 어떤 TTL에서 카운트다운하고 있는지 볼 수 있고, 타이머의 규칙을 온전히 알고 싶다면 DNS TTL의 의미를 읽어 보세요.

대기가 전혀 전파가 아닐 때

멈춰 있는 변경 중 일부는 캐시가 아니며, 아무리 기다려도 낫지 않습니다. 타이머를 탓하기 전에, 타이머가 고칠 수 없는 결함부터 배제하십시오.

• 잘못된 영역을 편집했습니다. 네임서버 변경 후에도 이전 제공업체의 제어판은 당신의 편집을 정중하게 계속 받아들일 수 있지만, 인터넷은 이제 새 제공업체의 영역 복사본을 읽습니다. 변경은 위임이 실제로 가리키는 곳에서 이루어져야 합니다.
• 권한 있는 서버 하나가 일치하지 않습니다. 여러 서버가 영역을 제공하는 경우, 동기화 실패로 그중 하나가 이전 레코드로 계속 응답하게 되어, 아무리 오래 기다려도 일부 쿼리가 오래된 데이터에 도달합니다.
• 새 레코드에 오타가 있습니다. 주소의 숫자 하나가 틀렸거나 호스트 이름의 철자가 틀린 경우에도 전파는 완벽하게 이루어집니다. 그저 잘못된 답변일 뿐이며, 설계된 대로 정확히 퍼져 나갑니다.
• DNSSEC 검증이 실패합니다. 변경으로 영역의 서명이 깨지면, 검증하는 리졸버는 당신의 레코드 대신 오류를 반환하며, 이는 느린 업데이트가 아니라 사라진 사이트처럼 보입니다.

나누는 기준은 간단합니다. 권한 있는 서버가 새 레코드를 제공하고 있다면 기다리는 것이 치료법이고 타이머가 이야기의 전부입니다. 그렇지 않다면 결함은 전 세계의 캐시가 아니라 영역 안에 있으며, 더 넓은 점검 목록은 DNS 변경이 적용되지 않을 때에 있습니다.