1. 라이브러리
  2. DNS
  3. DNS 레코드

업데이트됨 1개월 전

DNS 레코드를 변경했습니다. 도메인을 새 서버로 연결했거나, 이메일 설정을 수정했거나, 새 호스팅 업체로 이전했을 수도 있습니다. 이제 초조하게 기다릴 차례입니다: 제대로 됐을까요?

DNS는 즉시 업데이트되지 않습니다. 권한 있는 네임서버에는 바로 올바른 레코드가 표시될 수 있지만, 인터넷의 나머지 부분은 캐시된 복사본으로 작동하고 있습니다. 더 문제인 것은, 내 컴퓨터도 DNS를 캐싱한다는 점입니다. 그래서 다른 사람들은 여전히 예전 설정을 보고 있는데 나만 변경 사항을 볼 수도 있습니다.

문제는 단순히 "내 DNS 레코드가 뭐지?"가 아닙니다. "누구를 믿어야 할까?"입니다.

빠른 확인: dig

dig 명령어는 macOS나 Linux에서 DNS 레코드를 확인하는 가장 빠른 방법입니다:

dig example.com A +short

이 명령은 도메인이 가리키는 IP 주소만 반환합니다. 예상한 IP가 보인다면, 해당 리졸버에는 업데이트가 반영된 것입니다.

하지만 이 쿼리는 시스템의 기본 DNS 리졸버로 전달되는데, 예전 레코드를 캐시하고 있을 수 있습니다. 특정 리졸버가 무엇을 알고 있는지 확인하려면 직접 물어보세요:

dig @8.8.8.8 example.com A +short    # Google DNS
dig @1.1.1.1 example.com A +short    # Cloudflare DNS

리졸버마다 다른 답이 나온다면 변경 사항이 아직 전파 중이라는 의미입니다.

신뢰 계층 구조

권한 있는 네임서버와 당신 사이의 모든 계층이 거짓말을 하고 있을 수 있습니다. 악의가 있어서가 아니라, 더 이상 사실이 아닌 것을 기억하고 있기 때문입니다.

로컬 캐시ISP 리졸버공개 리졸버권한 있는 네임서버

진실을 알려면 출처로 직접 가야 합니다. 먼저 어떤 네임서버가 도메인에 대한 권한을 가지는지 확인합니다:

dig example.com NS +short

그런 다음 직접 쿼리합니다:

dig @ns1.your-dns-provider.com example.com A +short

권한 있는 네임서버가 잘못된 레코드를 보여준다면, DNS 제공업체에 변경 사항이 아직 반영되지 않은 것입니다. 올바른 레코드를 보여주지만 공개 리졸버에서는 그렇지 않다면, 변경 사항이 전파 중인 것입니다. 캐시가 만료되기를 기다리는 상황입니다.

다양한 레코드 유형 확인

dig example.com A        # IPv4 주소
dig example.com AAAA     # IPv6 주소
dig example.com MX       # 메일 서버
dig example.com TXT      # SPF, DKIM, 도메인 인증
dig example.com CNAME    # 별칭
dig example.com NS       # 네임서버

전체 응답을 보려면 +short 플래그를 빼세요. TTL(Time to Live)도 확인할 수 있습니다. TTL은 리졸버가 다시 요청하기 전까지 이 레코드를 캐시해 두는 시간(초)입니다.

Windows에서: nslookup

Windows에는 기본적으로 dig이 포함되어 있지 않지만, nslookup이 내장되어 있습니다:

nslookup example.com
nslookup -type=MX example.com
nslookup example.com 8.8.8.8    # 특정 리졸버에 쿼리

dig보다 출력 내용이 덜 상세하지만, 핵심 질문에는 답해 줍니다: 이 리졸버는 내 도메인이 어디를 가리킨다고 생각하는지.

전파 상황 확인하기

명령줄 도구는 한 번에 리졸버 하나만 확인합니다. 온라인 도구는 수십 개를 동시에 쿼리합니다:

  • whatsmydns.net — 세계 지도 위에 결과를 표시합니다. 변경 사항이 전파되면서 각 대륙에 초록색 체크 표시가 나타납니다.
  • dnschecker.org — 비슷한 화면이며, 서버가 지역별로 묶여 있습니다.
  • dns.google — DNSSEC 유효성 검사 상태를 포함한 Google DNS입니다.

내 컴퓨터가 거짓말을 한다

운영 체제는 반복적인 조회를 피하기 위해 DNS를 캐싱합니다. 이 때문에 공개 리졸버가 여전히 예전 레코드를 제공하고 있는데도 로컬에서 테스트할 때는 새 설정이 보일 수 있습니다.

로컬 DNS 캐시를 비워보세요:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux (systemd)
sudo systemd-resolve --flush-caches

캐시를 비운 후 다음 DNS 쿼리는 캐시된 결과가 아닌 최신 데이터를 가져옵니다.

문제가 생겼을 때

NXDOMAIN: 해당 도메인이 DNS에 존재하지 않습니다. 도메인이 등록되지 않았거나, 네임서버가 설정되지 않았거나, 입력이 잘못됐을 수 있습니다.

SERVFAIL: DNS 서버가 요청을 처리할 수 없었습니다. 주로 DNSSEC 설정 오류나 접근 불가능한 네임서버가 원인입니다.

리졸버마다 다른 답: 전파 중에는 정상입니다. 권한 있는 네임서버를 확인하세요. 올바르다면 캐시가 만료되기를 기다리면 됩니다.

몇 시간이 지나도 변경 사항이 반영되지 않음: 이전 레코드의 TTL을 확인하세요. 86400(24시간)으로 설정되어 있었다면, 변경 직전에 캐시한 리졸버는 하루 동안 다시 조회하지 않습니다. 이것이 경험 많은 관리자들이 변경 전에 TTL을 낮춰두는 이유입니다.

DNS 레코드에 관한 자주 묻는 질문

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

이전 레코드의 TTL에 따라 다릅니다. 예전 레코드의 TTL이 300초(5분)였다면, 대부분의 리졸버는 5분 안에 새 레코드를 가져갑니다. 86400초(24시간)였다면 전파에 최대 24시간이 걸릴 수 있습니다. 흔히 듣는 "48시간"이라는 수치는 기본 TTL이 더 길었던 시절의 최악의 경우 추정치입니다.

내가 새 레코드를 보는데 동료는 못 보는 이유가 뭔가요?

동료의 리졸버가 나의 리졸버와 다른 시간에 예전 레코드를 캐시했기 때문입니다. 동료의 캐시는 몇 시간 후에야 만료될 수 있지만, 내 캐시는 이미 최신 데이터를 가져온 것입니다. 동료가 로컬 DNS 캐시를 비우거나 리졸버의 캐시가 만료되기를 기다리면 해결됩니다.

이메일 DNS 레코드가 올바른지 확인하는 방법은?

MX, SPF, DKIM 레코드를 쿼리하세요:

dig example.com MX +short
dig example.com TXT +short
dig selector._domainkey.example.com TXT +short

"selector"는 실제 DKIM 셀렉터로 바꾸세요(이메일 제공업체가 알려줄 것입니다). mxtoolbox.com의 MX Toolbox는 이메일 DNS에 대한 종합적인 분석을 제공합니다.

DNS 전파를 빠르게 할 수 있나요?

변경 후에는 불가능합니다. 캐시가 자연스럽게 만료되기를 기다려야 합니다. 하지만 다음 변경 전에는 하루 먼저 TTL을 짧게(예: 300초) 낮춰두세요. 그 낮은 TTL이 전파되고 나면, 실제 변경 사항은 빠르게 퍼져나갑니다.

이 페이지가 도움이 되었나요?

😔
🤨
😃
DNS 레코드 확인 방법 • 라이브러리 • Connected