도메인의 DNS 레코드를 업데이트하고 변경 사항을 저장하면 새 웹사이트나 메일 서비스가 즉시 작동할 것으로 기대합니다. 하지만 동료가 여전히 이전 웹사이트를 보거나, 온라인 체크기가 다른 주소를 표시하거나, 이메일 전송이 일관되지 않게 동작하는 경우가 있습니다. 이러한 지연 현상은 일반적으로 다음이라고 불립니다. DNS 전파.
이 문구는 단일 업데이트가 중앙 인터넷 시스템을 통해 이동하는 것처럼 들릴 수 있습니다. 그러나 DNS는 분산되어 있습니다. 도메인 정보는 권한 있는 네임 서버, 재귀적 해결기, 라우터, 운영 체제 및 애플리케이션 전반에 걸쳐 저장되고 캐시됩니다. 각 시스템은 서로 다른 시점에 정보를 새로 고칠 수 있습니다.
대부분의 DNS 변경은 캐시가 만료되고 리졸버가 최신 레코드를 가져오면서 가시화됩니다. 이 과정에 소요되는 시간은 해당 레코드의 이전 TTL(Time to Live), 리졸버의 동작 방식, 그리고 권위 있는 DNS 구성이 올바른지에 따라 달라집니다. 모든 사용자가 새 응답을 보도록 보장하는 보편적인 시간은 존재하지 않습니다.
이 가이드는 DNS 전파가 무엇을 의미하는지, DNS 변경 사항이 서로 다른 시점에 나타나는 이유, 도메인의 현재 응답을 확인하는 방법, 그리고 업데이트가 여전히 불완전한 것처럼 보일 때 취해야 할 조치에 대해 설명합니다.
DNS 전파란 무엇을 의미합니까?
DNS 전파는 DNS 레코드가 변경된 후에도 서로 다른 사용자나 DNS 재귀 쿼리 서버가 서로 다른 응답을 받을 수 있는 기간을 의미하는 일반적인 용어입니다. 한 네트워크의 사용자는 이미 새로운 IP 주소를 볼 수 있지만, 다른 사용자의 재귀 쿼리 서버는 여전히 캐시된 이전 주소를 반환할 수 있습니다.
기반 DNS 변경은 도메인의 권한 있는 네임 서버에서 이루어집니다. 재귀 확인기는 해당 레코드를 검색하고 사용자를 위해 캐시합니다. 이러한 확인기는 사용자가 도메인을 방문할 때마다 매번 권한 있는 서버에 다시 질문하지 않습니다. 유효 기간이 만료될 때까지는 캐시된 답변을 재사용할 수 있습니다.
이것이 바로 “전파”를 더 잘 이해할 수 있는 이유입니다. 캐시 만료 및 새로고침중앙 복사본이 모든 인터넷 연결 장치에 동시에 업데이트될 필요가 없습니다. 일부 리졸버가 여전히 오래된 캐시 데이터를 제공 중이더라도, 권한 있는 레코드는 이미 정확할 수 있습니다.
DNS 캐싱 작동 방식
브라우저가 도메인의 IP 주소를 찾아야 할 경우, 운영 체제에 이름 해결을 요청합니다. 운영 체제는 이미 캐시된 답변을 가지고 있을 수 있습니다. 만약 그렇지 않다면, 인터넷 서비스 제공업체, 기업 또는 공개 DNS 서비스가 운영하는 구성된 재귀적 리졸버에 요청합니다.
재귀 확인기는 캐시된 답변을 가지고 있을 수도 있습니다. 해당 답변이 여전히 캐수 수명 내에 있다면, 권한 있는 네임 서버에 연락하지 않고도 이를 반환할 수 있습니다. 캐시된 레코드가 만료되면 확인기는 권한 있는 DNS 시스템에 쿼리하여 업데이트된 답변을 저장할 수 있습니다.
캐싱은 조회 시간을 줄이고 DNS 인프라의 부하를 감소시킵니다. 또한 레코드 변경 사항이 모든 리졸버에 동시에 표시되지 않을 수 있음을 의미합니다. 기존 응답은 캐시가 만료되거나 리졸버가 이를 새로 고칠 때까지 리졸버에서 계속 사용할 수 있습니다.
서로 다른 사용자는 서로 다른 재귀 DNS 서버를 사용할 수 있습니다. 같은 가정에 거주하더라도 각기 다른 DNS 서비스, VPN, 모바일 네트워크 또는 로컬 캐시를 사용하는 기기라면 서로 다른 결과를 확인할 수 있습니다.
DNS에서 TTL이란 무엇인가요?
TTL은 Time To Live의 약자입니다. 생존 시간. 이는 재귀적 리졸버가 업데이트된 답변을 확인하기 전에 DNS 레코드를 캐시할 수 있는 기간을 나타내는 값으로, 일반적으로 초 단위로 측정됩니다.
예를 들어, TTL이 3600 1시간을 의미합니다. 만약 리졸버가 해당 TTL을 가진 레코드를 검색하면, 일반적으로 1시간 동안 그 답변을 계속 사용할 수 있으며, 이후에 새로 고침해야 합니다. TTL이 300 다섯 분을 의미합니다.
변경 후 중요한 TTL은 일반적으로 이미 리졸버가 캐시한 기존 레코드의 TTL입니다. 레코드 변경 직전에 TTL을 낮추더라도 이전의 높은 TTL을 캐시한 리졸버들의 대기 시간을 단축하지 못할 수 있습니다. 이러한 리졸버들은 원래 캐시 기간이 만료될 때까지 기존 응답을 계속 사용할 수 있습니다.
계획된 마이그레이션의 경우, 관리자들은 종종 사전에 TTL을 낮추고 이전 TTL이 만료될 때까지 충분히 기다린 후 DNS 변경을 수행합니다. 변경이 안정화된 후에는 반복적인 쿼리를 줄이기 위해 TTL을 다시 높일 수 있습니다. 적절한 값은 서비스와 운영자의 변경 절차에 따라 달라집니다.
DNS 변경이 서로 다른 시간에 걸리는 이유는 무엇인가요?
가장 흔한 이유는 리졸버들이 서로 다른 캐시된 사본을 가지고 있기 때문입니다. 일부는 이미 레코드를 새로 고쳤지만, 다른 것은 아직 만료되지 않은 응답을 사용하고 있습니다. 또한 리졸버는 자체적인 새로 고침 동작을 적용하거나 레코드가 존재하지 않음을 나타내는 응답인 부정적 답변을 캐시에 저장할 수 있습니다.
로컬 캐싱은 또 다른 계층을 추가할 수 있습니다. 컴퓨터, 라우터, 브라우저 또는 보안 애플리케이션이 DNS 정보를 일시적으로 보유할 수 있습니다. 브라우저를 다시 시작하거나 운영 체제의 DNS 캐시를 지우는 것이 경우에 따라 도움이 될 수 있지만, 재귀적 리졸버가 여전히 캐시하고 있는 내용은 변경되지 않습니다.
DNS 제공자 변경은 추가적인 타이밍 요소를 도입할 수 있습니다. 등록기관에서 도메인의 권한 있는 네임 서버를 변경하면, 리졸버는 위임 정보뿐만 아니라 해당 네임 서버가 제공하는 레코드도 새로 고쳐야 할 수 있습니다. 이는 동일한 DNS 호스팅 서비스 내에서 A 또는 AAAA 레코드를 편집하는 것과 다른 유형의 변경입니다.
마지막으로, 업데이트가 권한 있는 소스에서 정확하지 않을 수 있습니다. 잘못된 레코드가 편집되었거나 변경 사항이 저장되지 않았으며, 도메인이 다른 권한 있는 네임 서버를 사용하거나 레코드에 구문 오류가 있는 경우, 기다린다고 해서 근본적인 구성 문제가 해결되지는 않습니다.
DNS 전파와 권위 있는 DNS 업데이트
권위 있는 DNS 서버는 도메인 또는 존에 대한 공식 레코드를 제공합니다. DNS 제공업체의 제어 패널에서 레코드를 편집하면, 제공업체는 자신이 제공하는 권위 있는 데이터를 업데이트해야 합니다.
再귀 확인기는 클라이언트 장치에 DNS 응답을 제공합니다. 변경 사항 이전에 캐시된 데이터를 보유하고 있을 수 있습니다. 따라서 권한 서버는 새 주소를 반환할 수 있는 반면, 재귀 확인기는 이전 주소를 계속 반환할 수 있습니다.
이 구분은 문제 해결 시 유용합니다. 먼저 권한 있는 네임 서버가 반환하는 내용을 확인하십시오. 이미 예상되는 레코드가 포함되어 있다면 변경 사항이 소스에서 게시되었으며, 나머지 차이는 일반적으로 캐싱 또는 리졸버 동작 때문입니다. 권한 있는 서버가 여전히 이전 값이나 값 자체를 반환하지 않는다면 DNS 공급자의 구성과 레코드 자체를 조사하십시오.
네임서버를 변경하면 또 다른 계층이 추가됩니다. 상위 DNS 영역은 의도된 권한 있는 네임서버를 가리켜야 하며, 해당 서버는 올바른 영역을 제공해야 합니다. 도메인이 다른 제공자의 네임서버로 위임되어 있다면 DNS 제공업체의 정확한 레코드는 유용하지 않습니다.
일반적인 DNS 변경 사항 및 그 영향
변경하는 레코드 changes the IPv4 address returned for a hostname. Changing an AAAA 레코드 IPv6 주소를 변경합니다. 둘 다 존재하는 경우, 클라이언트는 네트워크 및 연결 동작에 따라 두 주소 패밀리 중 하나를 사용할 수 있습니다.
변경 CNAME 레코드 별칭이 가리키는 호스트 이름을 변경합니다. 이로 인해 리졸버는 대상 이름과 해당 주소의 레코드를 다시 조회해야 할 수 있습니다. 대상의 레코드 변경은 CNAME 자체는 그대로 유지된 경우에도 최종 결과에 영향을 미칠 수 있습니다.
변경하는 MX 레코드 도메인의 이메일을 수신하는 메일 서버에 영향을 미칩니다. 메일 시스템은 이러한 레코드를 캐시할 수 있으며, 이메일 라우팅 업데이트가 반영되기까지 시간이 걸릴 수 있습니다. 메일 제공자를 변경할 때 관리자는 MX 레코드와 SPF, DKIM 또는 DMARC와 같은 관련 메일 인증 레코드를 별도로 확인해야 합니다.
변경 중 네임서버 DNS 제공자를 도메인에 대해 권한을 가진 것으로 변경합니다. 이 작업은 등록기관에서의 올바른 위임과 새 제공자에서의 올바른 영역 구성이 필요합니다. 네임서버 마이그레이션은 새 제공자에서 누락된 레코드로 인해 웹사이트, 이메일 또는 기타 서비스를 사용할 수 없게 될 수 있으므로 신중하게 계획해야 합니다.
DNS 변경 사항이 반영되었는지 확인하는 방법
사용 중인 컴퓨터에서 도메인을 쿼리하는 것으로 시작하세요. Windows, macOS 및 Linux에서는 nslookup 일반적으로 사용 가능합니다:
nslookup example.comIPv4 주소 레코드를 확인하려면 다음을 사용하십시오:
nslookup -type=A example.comIPv6의 경우:
nslookup -type=AAAA example.com메일 서버 레코드에 대해:
nslookup -type=MX example.commacOS 및 Linux에서는 dig 더 자세한 출력을 제공합니다:
dig example.com A정답 섹션만 표시합니다:
dig example.com A +noall +answer특정 재귀 확인 서버를 쿼리하여 답변을 비교할 수 있습니다. 예를 들어:
dig @1.1.1.1 example.com AWindows에서는 다음을 사용하여 DNS 서버를 지정할 수 있습니다:
nslookup example.com 1.1.1.1바꾸다 example.com 자신의 도메인과 함께 사용하십시오. 이러한 예시의 리졸버 주소는 하나의 가능한 공개 리졸버일 뿐이며, 조직이나 제공자가 사용하는 DNS 서비스도 쿼리할 수 있습니다.
조회한 리졸버, 응답 및 시간을 기록합니다. 여러 리졸버에서 결과를 비교하면 해당 차이가 특정 리졸버에만 국한된 것인지 아니면 더 광범위하게 나타나는지 판단하는 데 도움이 됩니다.
권위 있는 네임 서버 쿼리하는 방법
도메인의 권한 있는 네임 서버를 찾으려면 다음을 사용하십시오:
dig example.com NS그런 다음 변경한 레코드를 직접 해당 네임 서버 중 하나에 쿼리합니다:
dig @ns1.example-dns.com example.com A바꾸다 ns1.example-dns.com 도메인에 대한 권한 서버가 나열되어 있습니다. 직접 쿼리가 예상된 주소를 반환하지만 재귀 확인자가 이전 주소를 반환하는 경우, 권한 데이터는 업데이트되었지만 확인자는 여전히 캐시된 답변을 사용하고 있을 수 있습니다.
또한 질문하실 수 있습니다 dig 위임 프로세스를 추적하기 위해:
dig +trace example.com이는 루트부터 도메인의 권한 서버까지 DNS 계층 구조를 따라 수행됩니다. 위임 문제를 식별하는 데 도움이 될 수 있지만, 출력 결과가 대부분의 기본 검사에서 요구하는 것보다 더 상세합니다.
DNS 제공업체의 제어 패널을 사용하는 경우, 도메인이 해당 페이지에 표시된 네임서버로 실제로 위임되었는지 확인하십시오. 레코드는 한 제공업체의 대시보드에서는 정확할 수 있지만, 공개 도메인은 다른 제공업체를 가리킬 수 있습니다.
만약 일부 사용자가 이전 웹사이트를 본다면?
먼저 권한 있는 A 또는 AAAA 레코드가 의도한 값을 가지고 있는지 확인하십시오. 그런 다음 여러 재귀 이름 서버에 쿼리를 보내고 동일한 응답을 반환하는지 확인하십시오. 권한 있는 데이터가 정확하지만 일부 이름 서버가 이전 주소를 반환한다면, 캐싱이 원인일 가능성이 높습니다.
다음으로 사용자의 로컬 구성을 확인하십시오. VPN, 회사 DNS 리졸버, 보안 제품, 브라우저 캐시 또는 로컬 호스트 파일은 반환되는 주소에 영향을 줄 수 있습니다. 모바일 연결과 같은 다른 네트워크에서 결과를 비교하여 동작이 변경되는지 확인하십시오.
또한 이전 서버와 새 서버가 모두 응답하는지 확인하십시오. 이전 호스트가 캐시된 사본을 제공하거나 다르게 리디렉션하는 경우 마이그레이션이 불일치로 보일 수 있습니다. DNS 레코드가 정확하더라도 사용자의 리졸버가 새로 고침하지 않은 경우 이전 서버에 여전히 접근할 수 있습니다.
문제가 IPv4 또는 IPv6 중 하나에만 영향을 미치는 경우 A 레코드와 AAAA 레코드를 별도로 비교하십시오. 한 장치는 IPv6를 통해 연결될 수 있는 반면, 다른 장치는 IPv4를 사용할 수 있습니다. 하나의 주소 패밀리가 새 서버를 가리키는 동안 다른 하나는 여전히 이전 서버를 가리킬 수 있습니다.
DNS 변경 후 웹사이트를 사용할 수 없게 되는 경우
도메인의 권한 이름 서버가 정확하고 접근 가능한지 확인하십시오. 그런 다음 해당 서버에 관련 레코드가 존재하는지 검증하십시오. 최근에 이름 서버를 변경한 경우, 새로운 DNS 제공업체에 웹사이트, 이메일, 인증 및 서비스 레코드를 포함한 모든 필수 레코드가 있는지 확인하십시오.
도메인에 대한 연결 수락을 위해 대상 서버가 준비되었는지 확인하십시오. DNS 업데이트는 클라이언트가 리디렉션되는 위치만 변경합니다. 웹 서버를 구성하거나, 인증서를 설치하거나, 방화벽 포트를 열거나, 웹사이트 파일을 복사하지 않습니다.
DNS가 예상되는 IP 주소를 반환하지만 웹사이트가 여전히 작동하지 않는 경우, 서버와 애플리케이션을 별도로 테스트하십시오. 문제는 웹 서버, 방화벽, TLS 인증서, 호스팅 구성 또는 애플리케이션에 있을 수 있습니다. DNS 조회는 이름 해결이 확인되었음을 의미할 뿐, 서비스가 정상적으로 동작한다는 것을 보장하지 않습니다.
장치와 목적지 간의 일반적인 경로 확인에 대한 가이드를 참조하세요. 네트워크 연결 문제 진단을 위한 traceroute 사용. Traceroute와 DNS 조회는 연결의 서로 다른 부분을 테스트하므로, 문제를 좁혀갈 때 함께 유용합니다.
음성 캐싱 및 “레코드 없음” 결과
리졸버는 레코드가 존재하지 않는다는 사실을 캐시할 수 있습니다. 이를 음의 캐싱(negative caching)이라고 합니다. 만약 리졸버가 레코드 생성 전에 해당 이름을 조회했다면, 레코드가 추가된 후에도 일시적으로 “찾을 수 없음” 응답을 반환할 수 있습니다.
음성 캐싱에도 SOA 레코드와 리졸버 규칙에 기반한 TTL이 있습니다. 정확한 동작은 상황에 따라 다를 수 있습니다. 새로 생성된 하위 도메인이 즉시 해결되지 않는 경우, 먼저 권한 있는 네임 서버를 확인하십시오. 해당 서버가 새 레코드를 반환하면 음성 캐시가 만료될 때까지 기다린 후 다른 리졸버들을 비교해 보십시오.
“레코드 없음” 응답은 해당 레코드가 잘못된 존에 추가되었거나, 호스트 이름이 잘못 입력되었거나, 도메인이 다른 권한 있는 네임 서버를 사용하고 있음을 나타낼 수도 있습니다. 문제가 전파 지연에만 기인한다고 가정하기 전에 전체 호스트 이름, 레코드 유형 및 DNS 제공자를 확인하십시오.
DNS 마이그레이션 계획하기
생산 서비스의 레코드를 변경하기 전에, 해당 서비스가 의존하는 모든 호스트명과 레코드를 나열하십시오. 웹사이트는 A 및 AAAA 레코드를 사용할 수 있으며, 이메일은 MX, SPF, DKIM 및 DMARC 레코드에 의존합니다. 애플리케이션도 검증 또는 서비스 발견 레코드에 의존할 수 있습니다.
변경이 계획된 경우, 관련 TTL을 사전에 줄이고 이전 TTL 기간 이상 대기한 후 목적지를 전환하십시오. DNS 업데이트 전에 새 서버나 제공자를 준비하십시오. 가능한 경우 직접 테스트하고, 인증서, 방화벽 규칙, 애플리케이션 설정 및 메일 서비스가 준비되었는지 확인하십시오.
변경 후 권한 있는 답변과 여러 재귀 이름 서버를 확인하십시오. 웹사이트 가용성, 이메일 전송 및 애플리케이션 오류를 모니터링하십시오. 캐시된 답변이 만료되는 동안 일부 사용자가 여전히 기존 서비스에 접근할 수 있으므로 가능한 한 전환 기간 동안 기존 서비스를 유지하십시오.
새로운 구성이 안정화되면 적절한 TTL을 복원하십시오. 거의 변경되지 않는 서비스의 경우, 매우 낮은 TTL을 지속적으로 유지하면 DNS 쿼리량이 증가할 뿐 큰 이점을 제공하지 못합니다.
일반적인 DNS 전파 오해
일반적인 오해 중 하나는 DNS 변경이 정확히 24시간 또는 48시간이 걸린다는 것입니다. 고정된 보편적인 기간은 존재하지 않습니다. 실제 지연 시간은 이전 TTL 값, 리졸버 캐싱, 위임 변경 및 권위 있는 구성의 정확성에 따라 달라집니다.
또 다른 오해는 브라우저 캐시를 지우면 전 세계 DNS가 업데이트된다는 것입니다. 이는 해당 장치에 저장된 정보를 지울 수는 있지만, 원격 재귀 확인기의 캐시는 지울 수 없습니다. 마찬가지로 라우터를 재시작하면 로컬 캐시는 지워질 수 있지만 권위 있는 레코드는 변경되지 않습니다.
세 번째 오해는 DNS 체크기가 서로 다른 응답을 표시하면 도메인이 손상되었다는 것을 증명한다는 것입니다. 계획된 마이그레이션 중에는 특히 리졸버들이 서로 다른 시점에 캐시 데이터를 보유하고 있을 때 서로 다른 응답이 발생할 수 있습니다. 중요한 질문은 권한 있는 레코드가 정확한지, 그리고 나머지 차이점이 이전 TTL과 일관성이 있는지입니다.
마지막으로, DNS 전파는 대상 서비스를 구성하지 않습니다. 서버, 방화벽, TLS 인증서 또는 애플리케이션이 준비되지 않은 경우 올바른 IP 주소로도 웹사이트에 접근할 수 없을 수 있습니다.
DNS 전파에 대한 자주 묻는 질문
DNS 전파는 얼마나 걸리나요?
단일 보장된 지속 시간은 없습니다. 일부 변경 사항은 빠르게 나타나지만, 캐시 레코드가 만료될 때까지 일관되지 않은 상태로 남아있는 경우도 있습니다. 이전 TTL, 리졸버 동작 및 네임서버가 변경되었는지 여부가 모두 타이밍에 영향을 미칩니다.
TTL을 낮추면 변경이 즉시 적용됩니까?
아니요. TTL을 낮추면 리졸버가 새 TTL을 가져온 후의 미래 캐싱에 영향을 미칩니다. 기존 레코드를 이미 캐시한 리졸버는 이전 TTL이 만료될 때까지 해당 레코드를 계속 사용할 수 있습니다.
DNS 체크기가 서로 다른 결과를 표시하는 이유는 무엇인가요?
서버는 서로 다른 위치에서 다양한 재귀 DNS 서버에 쿼리를 보낼 수 있습니다. 이러한 재귀 DNS 서버는 서로 다른 캐시된 응답을 보유할 수 있으며, 다른 시점에 갱신되거나 지리적 DNS 정책에 따라 서로 다른 응답을 받을 수 있습니다.
컴퓨터의 DNS 캐시를 비워야 할까요?
자신의 장치가 오래된 답변을 캐시한 경우에 도움이 될 수 있습니다. 이는 인터넷 제공업체, 회사 리졸버 또는 공개 DNS 서비스에서 유지하는 캐시를 지우지 않습니다.
왜 내 웹사이트는 해결되지만 여전히 로드되지 않나요?
DNS는 올바른 주소를 반환하고 있지만 대상 서버나 애플리케이션에 문제가 있을 수 있습니다. 웹 서버, 방화벽, TLS 인증서 및 호스팅 구성을 각각 확인하십시오.
네임서버 변경이 레코드 변경보다 더 오래 걸릴 수 있나요?
등록 기관 및 상위 DNS 존에서 추가 위임 정보가 포함될 수 있습니다. 새로운 제공자는 완전하고 정확한 존을 제공해야 합니다. 새로운 권위 서버에서의 위임과 레코드를 모두 확인하십시오.
DNS 변경은 권한 있는 네임 서버와 재귀적 리졸버가 서로 다른 역할을 수행하며, 리졸버가 TTL 값에 따라 응답을 캐싱하기 때문에 서로 다른 시점에 나타날 수 있습니다. 한 사용자는 이전 주소를 볼 수 있는 반면, 다른 사용자는 이미 새로운 주소를 받을 수 있습니다.
조사를 위해 먼저 권한 있는 네임 서버를 확인한 후, 여러 재귀 해결기의 응답을 비교하십시오. 레코드 유형, 호스트 이름, TTL 및 네임서버 위임을 확인합니다. DNS가 예상된 주소를 반환하지만 서비스가 여전히 사용 불가능한 경우, 문제의 별도 구성 요소로서 대상 서버와 애플리케이션을 점검하십시오.
캐싱을 이해하면 DNS 변경 사항을 더 쉽게 계획하고 문제 해결할 수 있습니다. 더 많은 네트워킹 기본 지식을 위해 다음 가이드를 계속 참조하세요: IP 주소, 기본 게이트웨이, 및 트aceroute.