Domain IP Lookup

같은 도메인이 다르게 응답하는 세 가지 이유

지리적 라우팅

지역마다 다른 엣지 서버

캐싱

독립된 TTL, 독립된 캐시

스플릿 호라이즌

의도된 다른 응답

실무 가이드

Android에서 DNS를 플러시하는 방법

읽는 시간 6분작성자: Domain IP Lookup Team

화요일 밤에 사이트를 새 호스트로 옮기고 DNS를 업데이트한 뒤, 검사기가 리졸버마다 초록색으로 바뀌는 것을 지켜봤지만 — 제 전화기는 목요일까지 옛 사이트를 계속 불러왔습니다. 데스크톱이었다면 서른 초면 됐을 것입니다. 프롬프트를 열고 캐시를 플러시하면 끝입니다. 전화기는 그저 거기 앉아 우쭐한 채로 어제의 인터넷을 불러왔습니다. 그 주에 저는 모든 Android 사용자가 결국 배우는 것을 배웠습니다. 플러시 버튼은 없습니다. 숨겨져 있지도 않고, 개발자 메뉴에 묻혀 있지도 않습니다. 그냥 없는 것입니다.

그렇다고 여러분이 무력하다는 뜻은 아닙니다. Android의 DNS 캐시는 데스크톱의 것과 같은 방식으로 작동하지 않으며, 그것을 실제로 지우는 것들은 조금 간접적이라는 뜻입니다. 어떤 것은 할 가치가 있습니다. 어떤 것은 민속 신앙입니다. 그리고 그중 하나 — 유명한 그것 — 은 몇 년 전에 대부분 작동을 멈췄습니다.

누를 버튼이 없는 이유

Windows나 macOS에서는 하나의 시스템 서비스가 거의 모든 것의 조회를 답하므로, 명령 하나로 그 캐시를 비울 수 있습니다. Android는 결코 정말로 그런 모양을 가진 적이 없습니다. 앱은 공유 시스템 서비스를 통해 이름을 확인하고, 브라우저는 그 위에 자체 캐시를 두며, 제조사는 그 위에 자체 조정까지 더합니다. 결과는 비울 수 있는 하나의 탱크가 아니라, 응답이 숨은 작은 은신처 여러 개입니다.

응답이 얼마나 오래 머무는지도 여러분의 전화기가 정하지 않습니다. 모든 레코드는 TTL을 지니는데, 이는 사이트 소유자가 정한 수명이고 캐시는 그것을 지켜야 합니다. DNS 변경이 이웃에게는 즉각적으로 느껴지고 여러분에게는 낡게 느껴지는 조용한 이유가 바로 이것입니다. 여러분의 전화기가 운 나쁜 순간에 물었고, 아직 만료되지 않은 답을 붙들고 있는 것입니다. 그 전체 사슬을 원하신다면 DNS 전파가 작동하는 방식에 대한 설명이 있습니다.

진정으로 도움이 되는 것들

  1. 비행기 모드 전환 (때때로)

    비행기 모드를 스무 초나 서른 초 켰다가 끄면 전화기는 네트워크 연결을 다시 만들고 제공업체에 다시 등록해야 합니다. 많은 빌드에서는 그 과정에서 캐시된 응답이 부수적으로 흔들려 떨어집니다. 다른 빌드에서는 손대지 않습니다. 비용은 없고 서른 초 반이면 되니 한 번 시도할 가치는 있습니다 — 다만 실패를 놀라운 일로 취급하지는 마십시오. 솔직히 최근 버전에서는 이 요령이 메커니즘이라기보다는 희망에 가깝습니다.

  2. 전화기 재시작

    무딘 도구이자, 확실하게 작동하는 것입니다. 완전히 재시작하면 시스템이 메모리에 지닌 휘발성 캐시가 지워지고, 네트워크 스택이 초기화되며, 조회가 새로 시작됩니다. 다른 모든 것을 한 뒤에도 사이트가 옛 주소를 보여 준다면, 더 영리한 것을 시도하기 전에 전화기를 재시작하십시오. 네, 기술 지원에서 가장 오래된 조언입니다. 그리고 여기서는 그것이 맞는 조언이기도 합니다.

  3. 여러분의 Wi-Fi라면 라우터도 재시작

    문제는 전화기가 전혀 아닐 수 있습니다. 집 라우터도 응답을 캐시하고, 여러분의 전화기는 그 낡은 복사본을 계속 받을 것입니다. 라우터를 재시작하면 그 캐시가 지워지고, 보너스로 집 안의 모든 기기가 옛 사이트를 보는지, 여러분의 것만 그런지 알게 됩니다.

Chrome 자체의 캐시는 어떻습니까?

Android의 Chrome에는 예전에 이것을 위한 자체 내부 페이지가 있었습니다 — 많은 오래된 안내가 여전히 플러시 버튼을 누르라며 chrome://net-internals로 보냅니다. 그 페이지는 폐지되었습니다. 현재 빌드에서는 그 주소가 DNS 도구를 더 이상 제공하지 않습니다. 오래된 설명이 계속 도는 것은 인터넷이 아무것도 지우지 않기 때문입니다. 어떤 안내가 거기로 가라고 한다면, 낡은 것은 여러분의 전화기가 아니라 그 안내입니다.

Chrome 안에 아직 살아 있는 것은 사이트 데이터입니다. 못되게 행동하는 그 하나의 사이트의 캐시된 이미지와 파일을 지우거나, Android의 앱 설정에서 Chrome을 강제 종료해 차갑게 시작하게 하면, 브라우저 자체가 지닌 답을 흔들어 떨어뜨릴 수 있습니다. 시스템 수준의 캐시는 지우지 못합니다 — 어떤 앱이 하는 일도 그것을 지울 수 없습니다 — 하지만 '사이트가 업데이트되지 않는다'는 불평 중 상당수는 네트워크가 아니라 브라우저로 드러나며, 이것이 그것을 솔직하게 가려내는 방법입니다.

비공개 DNS: 플러시가 아니라 우회이다

대부분의 Android 전화기 네트워크 설정 깊숙이 묻혀 있는 것이 비공개 DNS로, 여러분이 고른 리졸버로 향하는 암호화된 연결을 통해 조회를 라우팅합니다. 현재 리졸버 — 대개 제공업체나 라우터의 것 — 가 낡은 답을 지니고 있다면, 다른 리졸버로 전환하면 전혀 다른 캐시를 얻습니다. 새 레코드를 이미 지니고 있을지도 모르는 캐시입니다.

그것이 무엇을 하고 무엇을 하지 않는지 주목하십시오. 아무것도 비우지 않습니다. 가득 찬 선반을 비우는 대신 그 둘레를 돌아갑니다. 그래도 유용합니다 — 전환하는 순간 사이트가 올바르게 불러와지면, 잘못이 옛 리졸버의 캐시에 있었고 치료법은 사실 시간뿐이라는 것을 배운 셈입니다. DNS 서버를 바꾸는 방법에 대한 안내는 리졸버 고르기와 개인정보 맞교환을, 여러분의 조회를 다른 누군가에게 넘긴다는 사실을 포함해 솔직하게 다룹니다.

어느 캐시가 답을 붙들고 있는지 알아내기

다른 무언가를 재시작하기 전에, 잠시 시간을 들여 오래된 답이 어느 캐시의 것인지 좁혀 보십시오. 테스트는 지루합니다. 확실함은 근사합니다.

  1. 두 번째 브라우저로 시도하기

    다른 브라우저에서 사이트를 여십시오. Firefox든 Samsung Internet든, 이미 설치된 것이면 됩니다. 새 사이트가 보이면 여러분의 네트워크와 전화기의 시스템은 멀쩡하고, 옛 답을 붙들고 있는 것은 첫 번째 브라우저입니다. 그 브라우저의 사이트 데이터를 지우거나 강제 종료하면 끝입니다.

  2. Wi-Fi와 모바일 데이터 비교하기

    Wi-Fi를 끄고 페이지를 다시 불러오십시오. 모바일 데이터에서 새 사이트가 나타나면 집 쪽 경로는 유죄입니다. 라우터의 캐시, 혹은 그 뒤에 있는 제공업체의 리졸버입니다. 양쪽 모두에서 옛 사이트가 보이면 오래된 답은 전화기 자체에 있거나 아직 인터넷을 여행 중이며, 다음 테스트가 어느 쪽인지 가립니다.

  3. 여러분에게 빚진 것 없는 리졸버에게 묻기

    도메인을 온라인 전파 검사 도구에 넣어 보십시오. 여러 나라의 리졸버가 이미 새 주소를 보여 준다면 세상은 이미 나아갔고, 동의하지 않는 것은 여러분의 캐시뿐입니다. 그들도 옛 주소를 보여 준다면 재시작은 그만두십시오. 변경 자체가 아직 퍼지는 중이고, 전화기의 어떤 설정도 거기 닿지 않습니다.

개발자 가이드 중에는 컴퓨터 연결과 디버깅 도구를 통해 DNS 동작을 바꾸는 방법을 언급하는 것들이 있습니다. 그 길은 실재하지만 앱을 테스트하기 위해 존재하는 것이고, 매일 의지하는 전화기에는 과분합니다. 오래된 답에 대해 그것이 할 수 있는 일은 무엇이든 재시작이 더 간단히 해냅니다. 이 이야기를 꺼내는 것은, 그 조언을 만났을 때 그것이 없던 설정 페이지가 아니라 작업장 도구라는 것을 알아보시도록 하기 위해서뿐입니다.

거짓말하는 앱과 무고한 전화기

알아 둘 은신처가 하나 더 있습니다. 개별 앱입니다. 행실 좋은 앱은 시스템 리졸버를 쓰고 그 답을 물려받지만, 어떤 앱은 자체 확인을 실행하거나 연결을 고정해 시스템이 한참 앞으로 나아간 뒤에도 주소를 계속 사용합니다. 전형적인 양상은 브라우저는 새 사이트를 보여 주는데 은행이나 쇼핑 앱 하나가 옛 사이트를 여전히 보여 주거나 — 오류를 내는 것입니다. 그 앱을 강제 종료하거나 설정에서 그 캐시를 지우는 것이 앱별 재시작에 해당합니다.

전화기를 탓하기 전에 검사를 바꿔 보십시오. 브라우저 셋과 앱 다섯이 모두 옛 사이트를 보여 준다면, 낡은 답은 앱보다 위에 있습니다. 정확히 하나의 앱만 나머지 모두와 어긋난다면, 그 앱이 범인입니다.

아무도 원하지 않는 답: TTL을 기다리기

여기서는 여러분에게 솔직해야 합니다. 어떤 사이트가 긴 TTL — 말하자면 하루 — 로 DNS를 바꿨고, 여러분의 전화기나 라우터의 리졸버가 변경 직전에 옛 답을 캐시했다면, 일찍 새 답을 만들어 낼 누를 수 있는 것은 아무것도 없을 수 있습니다. DNS 캐시 플러시하기에 대한 안내서는 데스크톱 명령과 같은 캐시 논리를 다루며, 그 논리는 여기서 지지 않습니다. 캐시는 여러분의 일정이 아니라 레코드의 일정에 따라 만료됩니다.

여러분이 할 수 있는 것은 그것이 정말로 여러분의 상황인지 확인하는 것입니다. Wi-Fi 대신 모바일 데이터로 사이트를 불러오십시오. 비공개 DNS를 통해 새 리졸버를 시도해 보십시오. 독립적인 네트워크들이 새 사이트를 보여 주고 평소의 경로만 옛 사이트를 보여 준다면, 여러분은 캐시가 비워지는 것을 보고 있는 것이고, 그것은 끝날 것입니다. 아무도, 어디에서도 새 사이트를 보지 못한다면 변경 자체가 아직 도착하지 않은 것이며 — 그것도 여러분 전화기의 잘못은 아닙니다.

사이트를 옮기는 사람이 여러분이라면

지금까지의 모든 이야기는 DNS 변경을 기다리는 쪽에서 쓰였습니다. 언젠가 변경을 하는 사람이 여러분이라면, 방문객들에게 이 번거로움의 대부분을 덜어 줄 수 있습니다. 이전하기 꼬박 하루 전에, 바꿀 레코드들의 TTL을 낮추십시오. 세상에 “이 답을 하루 동안 간직하라”고 말하던 레코드는 이제 “오 분간 간직하라”고 말하고, 곳곳의 캐시는 빠르게 새로워지며, 이전하는 밤이면 새 주소는 목요일까지 질질 끌지 않고 몇 분 만에 퍼집니다. 독자께서 기억하시겠지만, 그것은 바로 이 글이 시작된 방식이기도 합니다.

먼지가 가라앉으면 TTL을 다시 올려 캐시가 평소의 일을 하게 하고, 전환 후에도 최소한 옛 TTL의 길이만큼은 옛 호스트를 계속 돌리십시오. 어딘가의 누군가의 전화기는 아직 옛 답을 붙들고 있고, 그것이 문을 두드리러 왔을 때 작동하는 사이트를 만날 자격이 있습니다.

도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.

자주 묻는 질문

관련 글

실무에서 TTL 정하기

60-300s마이그레이션 중: 빠른 전파, 쿼리 증가
3,600s대부분의 일반 레코드에 적합한 기본값
86,400sMX, NS처럼 거의 바뀌지 않는 레코드
DNS 기초

Windows, macOS, Linux에서 DNS 캐시 비우는 방법

계층별 DNS 캐시 비우기 명령어 참고서입니다. 각 명령어가 무엇을 지우는지, 그리고 캐시를 비워도 닿지 않는 계층은 무엇인지 설명합니다.

읽는 시간 8분

“DNS 서버”라는 이름을 공유하는 세 계층

스텁 리졸버

내 기기 자체

재귀 리졸버

ISP, 라우터, 1.1.1.1

권한 네임서버

도메인 자체의 DNS

실무 가이드

DNS 서버를 바꾸는 방법 (라우터 또는 기기)

여러분의 기기는 무엇이든 불러오기 전에 리졸버에게 묻습니다. 라우터를 바꿀지 기기 자체를 바꿀지 알면, 바꾸는 데 몇 분이면 됩니다.

읽는 시간 7분

“전파”란 사실 캐시 만료일 뿐

0분

변경 사항 저장

0-5분

DNS 호스트가 업데이트

TTL까지

이전 응답이 아직 캐시됨

TTL 이후

모두 새 응답을 확인

어디로도 푸시되지 않으며, 각 캐시가 사본 재사용을 멈출 뿐입니다

DNS 기초

DNS 전파 쉽게 이해하기: 변경에 시간이 걸리는 이유

아무것도 퍼지지 않아요. 새 레코드는 원본에서 이미 적용되어 있고, 각 리졸버 캐시가 자기 시계대로 만료될 뿐이에요. 타임라인과 실제 한계, 직접 제어할 수 있는 것을 정리했어요.

읽는 시간 8분