흔한 사례입니다. marketing.example.com이 Webflow를 가리키던 CNAME을 새로 셀프 호스팅한 랜딩 페이지로 바꾸고, DNS 콘솔에서 변경이 반영된 것까지 확인합니다. 5분 후 동료에게서 메시지가 옵니다. “내 노트북에서는 아직 예전 디자인이 보여요.” dig +short marketing.example.com을 실행하니 새 IP가 돌아옵니다. 동료의 노트북은 다른 리졸버에 묻고 있고, 그 리졸버의 캐시에는 아직 옛 레코드가 남아 있을 수 있습니다. 누구의 캐시가 잘못된 것일까요?

지금 조회해 보세요 →

솔직한 답은 “아무도 틀리지 않았다, 변경이 아직 모든 리커시브 리졸버에 도달하지 않았을 뿐이다”입니다 — 하지만 리졸버 하나에 dig 한 번 친 것만으로는 이것을 증명할 수 없습니다. 여러 공용 리커시브 리졸버에 빠르게 질의해서 비교해야 합니다. 예전에는 그 말이 CLI 루프를 돌리거나, 유료 네트워크 모니터링 도구를 쓰거나, 여러 지역에서 조회해 주는 웹사이트를 쓴다는 뜻이었습니다. 브라우저는 도움이 되지 않았습니다. 웹 페이지는 UDP 53번 포트 소켓을 열 수 없으니 클래식 DNS를 말할 수 없기 때문입니다. 이것이 바뀐 것은 2018년 RFC 8484가 DNS-over-HTTPS를 표준화하고, Cloudflare와 Google이 교차 출처 요청을 받는 공용 DoH 엔드포인트를 제공하면서부터입니다. 이제는 fetch()로 HTTPS 요청 한 번이면 어떤 레코드 타입이든 질의할 수 있고, JSON 엔드포인트는 평범한 JSON으로 답합니다.

ZeroTool의 DNS Lookup은 이 엔드포인트들을 감싼 도구입니다. 직접 작성할 법한 그 fetch() 그대로이되, 타입별로 묶은 레코드 카드, dig 스타일의 원본 출력 뷰, ALL을 선택했을 때 가장 많이 쓰이는 8개 타입에 대한 병렬 질의를 제공합니다. 아래는 운영 관점의 실전 가이드입니다. DoH가 실제로 어떻게 동작하는지, 각 레코드 타입이 실무에서 무엇을 알려주는지, 그리고 잘못된 관측 지점에서 DNS를 디버깅할 때 누구나 한 번쯤 걸리는 다섯 가지 함정입니다.

한 문단으로 보는 DNS-over-HTTPS

전통적인 DNS 질의는 UDP/53(잘리면 TCP/53) 위로 흐르는 바이너리 패킷입니다. 브라우저는 이 둘 모두에 대해 소켓 API를 노출하지 않습니다. DoH는 이 같은 질의를 HTTPS 요청으로 인코딩해서 문제를 해결합니다. 두 가지 인코딩이 존재합니다. 하나는 RFC 8484 바이너리 형식(application/dns-message 바디로 POST하거나, base64url 인코딩된 값을 GET ?dns=에 실음)이고, 다른 하나는 Google이 먼저 선보이고 Cloudflare가 채택한 좀 더 이른 JSON 프로파일(GET ?name=...&type=... 형태로 JSON을 반환)입니다. JSON 프로파일은 어떤 RFC에도 들어가 있지 않습니다. Cloudflare 문서는 Google의 스키마를 따른다고 밝히고 있어 필드는 같고, 작은 차이는 아래에서 다룹니다.

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [{ "name": "zerotool.dev", "type": 1 }],
  "Answer": [
    { "name": "zerotool.dev", "type": 1, "TTL": 300, "data": "172.67.170.64" },
    { "name": "zerotool.dev", "type": 1, "TTL": 300, "data": "104.21.95.91" }
  ]
}

Status는 표준 DNS RCODE(RFC 1035 §4.1.1, RFC 6895에서 확장)입니다. AD는 DNSSEC “Authenticated Data” 플래그로, 두 제공자 모두 응답 안의 모든 레코드가 검증됐을 때만 true라고 문서에 적고 있습니다. RFC 6840 §5.8은 질의에 DO나 AD 비트가 있을 때만 리졸버가 이 플래그를 켜도록 권합니다. do=1이 없으면 Cloudflare의 AD는 일정하지 않습니다(아래 참고). TC는 트렁케이션 플래그입니다. Cloudflare 문서에 따르면 최대 크기의 응답을 지원하기 때문에 DoH에서는 거의 항상 false입니다.

도구는 do=1(DNSSEC OK)과 cd=0(Checking Disabled = 0)을 보냅니다. cd=0은 리졸버에게 DNSSEC 검증을 요청하고, do=1은 서명을 응답에 넣어 달라고 요청합니다. do=1이 없으면 Cloudflare의 AD는 믿기 어렵습니다. 2026-09-30에 질의마다 30번씩 보냈더니 example.com의 A, AAAA, NS는 매번 "AD": false, MX는 매번 true였습니다. 그보다 앞서 A를 20번 보냈을 때는 true와 false가 10번씩 나왔습니다. do=1을 붙인 질의와 Google 질의는 모두 true였습니다. AD로 판단하려면 do=1을 붙여야 합니다. 반대로 cd=1은 검증을 건너뛰라는 의미인데, 망가진 존을 포렌식으로 들여다볼 때는 유용하지만 일반적인 조회에서 원하는 동작은 아닙니다.

열 가지 레코드 타입, 그리고 각각이 알려주는 것

도구는 열 가지 타입을 노출합니다. 각각은 특정한 운영상의 질문에 답합니다. 잘못된 타입을 고르면 존재하지도 않는 잘못된 설정을 쫓느라 몇 시간을 날립니다.

타입코드묻는 것누락되거나 잘못됐을 때 흔한 운영 장애
A1”이 이름을 서비스하는 IPv4 주소는?”개발자 머신에서는 사이트가 뜨는데 남의 머신에서는 404 — 캐시된 옛 A vs. 새 A.
AAAA28”이 이름을 서비스하는 IPv6 주소는?”AAAA가 옛 호스트를 가리키고 있으면 IPv6를 우선하는 클라이언트에서는 사이트가 열리지 않고, IPv4만 쓰는 환경에서 테스트하면 문제가 보이지 않음.
CNAME5”이 별칭이 가리키는 정식 이름은?”삭제된 Heroku 앱이나 SaaS의 잘못된 테넌트를 가리키는 CNAME.
MX15”이 도메인의 메일을 받아주는 서버는?”모든 인바운드 메일이 “no MX record found”로 반송되거나, 마이그레이션 후 잘못된 제공자로 라우팅됨.
TXT16”어떤 정책 문자열이 게시되어 있는가?”SPF가 soft-fail이라 DMARC 리포트에서 정상 메일이 스팸으로 표시되거나, 도메인 검증이 “pending”에서 멈춤.
NS2”이 존에 대해 권위 있는 서버는?”레지스트라 이전 후 NS가 옛 제공자를 가리켜서 어떤 변경도 전혀 전파되지 않음.
SOA6”프라이머리 서버는 누구이고, 세컨더리는 얼마나 자주 갱신해야 하는가?”세컨더리가 SOA refresh 윈도우를 지나도록 캐시해서 권위 존이 오래된 데이터를 서비스함.
CAA257”이 도메인에 대해 발급할 수 있는 인증 기관은?”목록에 없는 CA는 발급을 거부하므로, CA나 CDN을 옮긴 뒤 갱신이 실패함.
PTR12”이 IP가 자기 이름이라고 주장하는 것은?”전송 IP의 PTR이 HELO 도메인과 일치하지 않아 메일이 반송됨. 평판 서비스가 발신자를 플래그.
SRV33”_xmpp-client._tcp 같은 서비스는 어디에 사는가?”XMPP, SIP, LDAP, Matrix 페더레이션이 SRV가 없거나 포트가 틀려서 호스트를 찾지 못함.

도구의 ALL 모드는 앞쪽 8개 타입에 대해 Promise.all 병렬 요청을 동시에 펼칩니다. “이 존에 대해 모든 것을 보여달라”는 가장 흔한 운영 질문에 대한 합리적인 기본값입니다. PTR과 SRV가 ALL에서 빠진 이유는, PTR이 도메인 이름이 아니라 in-addr.arpa 형식(예: 34.216.184.93.in-addr.arpa)으로 입력해야 하고, SRV는 밑줄로 시작하는 특수한 이름(_xmpp-client._tcp.example.com)을 요구하기 때문입니다. 둘 다 일제 조회의 일부보다는, 표적화된 단일 타입 질의로 쓰는 게 자연스럽습니다.

dig와 도구의 결과가 어긋날 수 있는 이유

가장 흔한 당황 포인트는 개발자 노트북의 dig와 브라우저의 DoH가 같은 이름에 대해 서로 다른 답을 내놓는다는 것입니다. 네 가지의 따분한 이유와 한 가지의 흥미로운 이유가 있습니다.

로컬 리커시브 캐시. 노트북, 라우터, 또는 회사의 포워더는 각 레코드의 TTL 동안 DNS를 캐싱합니다. CNAME의 TTL이 86400(24시간)이면, 권위 서버에서의 변경이 노트북까지 도달하는 데 최대 24시간이 걸릴 수 있습니다. DoH 호출은 Cloudflare나 Google에 묻는데, 이들의 캐시는 당신의 캐시와 독립적입니다. Cloudflare와 Google로 한 번씩 조회해서 답을 비교해 보세요. Cloudflare는 새 값을 반환하는데 Google은 옛 값을 반환한다면, 지금 전파가 진행 중인 모습을 실시간으로 보고 있는 것입니다.

스플릿 호라이즌 DNS. 회사 네트워크, VPN, Active Directory 환경은 같은 이름에 대해 서로 다른 답을 반환하는 내부 권위 리졸버를 흔히 운영합니다. internal-tools.example.com은 방화벽 안에서는 10.42.0.5로 해석되고 밖에서는 NXDOMAIN이 될 수 있습니다. DoH 호출은 바깥쪽 뷰를 봅니다. 회사 머신에서는 잘 동작하는 이름에 대해 도구가 NXDOMAIN을 반환한다면, 그 존은 스플릿 호라이즌이고 공용 DNS는 그 이름을 모릅니다.

지오 라우팅된 응답. Cloudflare, Akamai, AWS Global Accelerator, 그리고 대부분의 CDN은 어떤 엣지 POP가 질의를 받느냐에 따라 서로 다른 A/AAAA 레코드를 반환합니다. 도구가 보여주는 IP는 Cloudflare나 Google의 리커시브가 그들의 네트워크 위치에서 본 값이지, 당신 위치에서 본 값이 아닙니다. “이 IP가 맞느냐?”라는 질문에 대해서는, 도구가 일반 공용 관찰자 입장에서 정답입니다. 하지만 “내 POP에서 봤을 때 이 IP가 맞느냐?”는 그 POP에서 직접 질의해야 합니다.

EDNS Client Subnet(RFC 7871). 일부 권위 서버는 리커시브 리졸버가 클라이언트 서브넷 힌트를 함께 전달할 때 더 정확한 지오 라우팅 답을 반환합니다. Google Public DNS 문서는 “보통 대략적인 네트워크 정보를 보낸다(대개 IPv4 주소의 마지막 부분을 0으로 바꾼다)“고 적고 있고, Cloudflare FAQ는 1.1.1.1이 ECS를 보내지 않는다고 밝힙니다. 그래서 같은 지오 라우팅 이름이 두 리졸버에서 다른 IP로 풀릴 수 있고, Google의 답은 질의가 어디서 왔는지에 따라 달라집니다. Google JSON API에서는 edns_client_subnet 파라미터로 서브넷을 직접 지정할 수 있습니다(도구는 이 파라미터를 보내지 않습니다). 2026-09-30에 www.qq.com을 조회했더니 114.114.114.0/24에서는 121.14.77.201과 121.14.77.221, 8.8.8.0/24에서는 43.159.109.55, 139.130.4.0/24에서는 43.168.224.173이 돌아왔습니다. Cloudflare는 같은 파라미터를 무시하고 43.159.109.55를 돌려줬습니다.

흥미로운 한 가지: 오래된 부정 캐시. RFC 2308은 NXDOMAIN 응답이 캐시 가능하다고 규정합니다. 없는 레코드에는 자체 TTL이 없으므로, 부정 캐시 시간은 SOA 레코드 자체의 TTL과 MINIMUM 필드 중 작은 값입니다(RFC 2308 §5). 어떤 존이 한 시간 동안 잘못 설정되어 있었고 로컬 리커시브가 그 NXDOMAIN을 캐시했다면, 도구는 정답을 반환하는데 로컬 질의는 그 시간이 지날 때까지 계속 실패할 수 있습니다. 해법은 기다리거나 — 또는 존 변경 전에 SOA MINIMUM을 낮춰두는 것입니다.

요약 필(pill) 읽기

레코드 뷰 위에 다섯 개의 필이 있습니다. 각각은 하나의 운영 신호를 압축합니다.

  • NOERROR / NXDOMAIN / SERVFAIL — RCODE입니다. NOERROR는 질의가 올바르게 처리되었다는 뜻이고, 함께 따라온 레코드 수가 0이라면 “이 이름은 존재하지만 해당 타입의 레코드는 없다”는 의미입니다. NXDOMAIN은 그 이름이 존 어디에도 존재하지 않는다는 뜻입니다. SERVFAIL은 리커시브 리졸버가 질의를 완료할 수 없었다는 뜻으로, 보통 DNSSEC 검증 실패이거나 권위 서버가 에러를 반환한 경우입니다.
  • N records — Answer 섹션의 레코드 개수입니다. NOERROR인데 0개가 돌아왔다면, 고른 타입이 이 이름에 대해 잘못된 질문이라는 뜻입니다. 실제로 원하는 존에 대해 NS를 확인해 보세요.
  • DNSSEC ✓ / no DNSSEC / DNSSEC failed — AD 플래그입니다. “no DNSSEC” 필은 존이 서명되어 있지 않거나, 응답 속 CNAME이 서명 없는 존으로 이어진다는 뜻입니다. 서명 검증에 실패하면 SERVFAIL이 돌아옵니다. SERVFAIL에 DNSSEC 관련 확장 오류 코드(RFC 8914의 1, 2, 5~12)가 붙어 있으면 필은 “DNSSEC failed”가 되고, 그 밖의 SERVFAIL에서는 필을 숨깁니다. 리졸버가 판단할 수 있는 답을 주지 않았기 때문입니다. com, org, dev TLD는 서명되어 있지만(루트 존에 각각의 DS 레코드가 있음), 그 아래 도메인은 소유자가 DNSSEC를 켜야 서명됩니다. example.com은 서명되어 있고 zerotool.dev는 아닙니다.
  • Resolver — 어느 DoH 엔드포인트가 응답했는지입니다. Cloudflare와 Google을 나란히 비교할 때 유용합니다.
  • Latency — fetch() 시작부터 JSON 파싱까지의 왕복 시간입니다. 첫 조회에는 리졸버와의 HTTPS 연결 수립 시간이 포함되므로 이후 조회보다 느립니다.

같은 질의를 직접 작성하기

도구가 존재하는 이유는, 일회성 조회에 한해서는 클릭이 스크립팅보다 빠르기 때문입니다. 자동화 용도라면 DoH JSON 프로파일은 fetch가 있는 어떤 언어에도 곧장 넣을 수 있을 만큼 짧습니다. 서로 다른 맥락에서 유용한 세 가지 참조 구현입니다.

브라우저 / Node 18+ 버전은 도메인만 있으면 두 줄입니다.

const url = `https://cloudflare-dns.com/dns-query?name=${encodeURIComponent('zerotool.dev')}&type=MX&do=1&cd=0`;
const res = await fetch(url, { headers: { accept: 'application/dns-json' } });
const json = await res.json();
console.log(json.Answer); // [{ name, type, TTL, data }, ...]

타임아웃이 필요하면 AbortSignal.timeout(5000)을, 네트워크 장애를 잡으려면 try/catch를 더하세요. Cloudflare와 Google DoH 둘 다 위와 같은 JSON 형태를 반환하므로, URL만 바꾸면 제공자를 갈아탈 수 있습니다.

Python 버전은 httpx나 urllib을 씁니다. 표준 라이브러리만으로 작성하면 이렇습니다.

import json
import urllib.request

def doh(name: str, qtype: str, resolver: str = "cloudflare"):
    if resolver == "google":
        url = f"https://dns.google/resolve?name={name}&type={qtype}&cd=0"
        headers = {}
    else:
        url = f"https://cloudflare-dns.com/dns-query?name={name}&type={qtype}&cd=0"
        headers = {"accept": "application/dns-json"}
    req = urllib.request.Request(url, headers=headers)
    with urllib.request.urlopen(req, timeout=5) as resp:
        return json.loads(resp.read())

print(doh("zerotool.dev", "CAA"))

셸 스크립트와 CI 단계에서는 curl + jq 조합이 정석입니다. 다음 한 줄은 도메인의 모든 MX 타깃을 우선순위 순으로 뽑아 줍니다.

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=cloudflare.com&type=MX' \
  | jq -r '.Answer[] | "\(.data)"' | sort

이걸 for 루프로 감싸면 터미널을 떠나지 않고도 자체 전파 추적기를 만들 수 있습니다. Bash 함수로 만들어 ~/.bashrc에 넣어두면, 임시 작업용으로는 dig의 절반을 대체한 셈입니다.

TXT 세그먼테이션 — 255바이트 규칙

긴 SPF, DKIM, DMARC 레코드는 RFC 1035 §3.3.14가 TXT 레코드 내부의 개별 문자열에 부과한 255바이트 한도를 일상적으로 넘습니다. DNS 프로토콜은 한 TXT 레코드 안에 여러 문자열을 허용하고, SPF의 관행(RFC 7208 §3.3)은 구분자 없이 이어 붙여 논리적 레코드를 만드는 것입니다. 두 JSON API는 문자열을 보여 주는 방식이 다릅니다. Cloudflare는 dig처럼 문자열마다 따옴표를 붙이고 공백으로 구분하며, Google은 따옴표 없이 하나의 값으로 이어 붙입니다. Cloudflare의 형식은 다음과 같습니다.

{
  "name": "google.com",
  "type": 16,
  "TTL": 300,
  "data": "\"v=spf1 include:_spf.google.com ~all\""
}

더 긴 레코드라면 두 개의 인접한 문자열로 나타납니다.

{
  "data": "\"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; \" \"fo=1; aspf=r; adkim=r\""
}

도구는 리졸버가 전달한 값을 그대로 보여 줍니다. Cloudflare 형식에서 논리적 값을 얻으려면 바깥 따옴표와 세그먼트 사이의 따옴표-공백-따옴표(" ")를 제거하면 됩니다. SPF(RFC 7208 §3.3)와 DKIM(RFC 6376 §3.6.2.2) 모두 문자열 사이에 아무것도 넣지 말고 이으라고 규정합니다. Google 형식은 이미 이어져 있습니다. cf2024-1._domainkey.zerotool.dev의 DKIM 공개 키는 Cloudflare에서 255자짜리 첫 문자열 뒤에 " " 하나가 들어간 425자로, Google에서는 같은 키가 420자로 돌아왔습니다.

CAA — TLS 발급을 끊어버릴 수 있는 단 하나의 레코드

CAA(RFC 8659)는 공용 인증 기관 중 어느 곳이 해당 도메인에 대해 인증서를 발급할 수 있는지를 알려줍니다. 규정을 따르는 CA는 발급 전에 CAA를 확인해야 하며, 어떤 issue 레코드에도 이름이 없는 CA는 발급해서는 안 됩니다(RFC 8659 §3). 다른 발급자를 쓰는 CDN이나 CA로 옮기면서 CAA 업데이트를 잊으면 다음 인증서 갱신이 실패하는데, 이 실패는 다른 어떤 DNS 질의로도 보이지 않습니다 — CAA 조회만이 그 제약이 걸려 있다는 사실을 알려줍니다.

Let’s Encrypt와 Google Trust Services(pki.goog)에 발급을 허용하고 와일드카드 인증서를 막는 존은 다음과 같습니다.

example.com. 0 issue "letsencrypt.org"
example.com. 0 issue "pki.goog"
example.com. 0 issuewild ";"
example.com. 0 iodef "mailto:security@example.com"

issuewild ";"는 모든 와일드카드 발급을 거부합니다. iodef는 권한 없는 발급자가 요청을 보내왔을 때 CA가 보고를 보낼 곳을 알려줍니다. 도구의 CAA 질의는 각 레코드를 태그(issue, issuewild, iodef)와 값으로 함께 보여주므로, 발급을 트리거하기 전에 정책을 확인할 수 있습니다.

함정들

우선순위 0에 타깃이 .인 MX. RFC 7505는 “Null MX” 레코드 — 0 . — 를 정의하고 있는데, “이 도메인은 메일을 일절 받지 않는다”는 뜻입니다. 메일을 처리해야 한다고 생각한 도메인에 대해 도구가 0 .를 반환한다면, 레지스트라나 DNS 제공자가 이 플레이스홀더를 명시적으로 게시한 것입니다. 이걸 갱신하려면 존을 편집해야지, 전파를 기다린다고 풀리는 문제가 아닙니다.

에이펙스에서의 CNAME은 불법입니다. CNAME이 있는 이름에는 다른 레코드가 있을 수 없고(RFC 1034 §3.6.2, RFC 1912 §2.4), 존 에이펙스(example.com)에는 SOA와 NS가 있어야 합니다. Cloudflare(CNAME 평탄화)와 Route 53(별칭 레코드)은 에이펙스에서 CNAME처럼 보이지만 질의 시점에 A/AAAA로 답하는 레코드를 제공합니다. 이런 존의 에이펙스를 DoH로 조회하면 CNAME이 아니라 평탄화된 A/AAAA가 돌아옵니다. 이는 올바른 동작이지만, 대시보드에서 설정한 CNAME을 그대로 보길 기대한 사람을 헷갈리게 할 수 있습니다.

프라이빗 리졸버와 Pi-hole. Pi-hole, NextDNS, AdGuard Home, 또는 DNS 기반 콘텐츠 필터를 돌리는 네트워크에서는 브라우저와 OS의 일반 조회가 그 필터를 거치고, 거기서 응답이 재작성되거나 차단될 수 있습니다. 도구의 질의는 HTTPS로 공용 리졸버에 가므로 필터는 조회한 이름을 보지 못합니다. 다만 브라우저는 cloudflare-dns.com이나 dns.google 자체를 로컬 DNS로 풀기 때문에, 필터가 이 두 이름을 막을 수는 있습니다. 노트북의 일반 DNS 조회는 실패하는데 도구는 실제 답을 줄 수 있는 이유가 이것입니다. 어떤 경우에는 도움이 되고(잘못 설정한 Pi-hole 룰 디버깅), 어떤 경우에는 오해를 부릅니다(네트워크가 막고 있는 도메인을 도구는 잘 동작한다고 말함).

EDNS Client Subnet과 CDN 테스트. CDN의 지오 라우팅을 테스트할 때, DoH가 반환하는 IP는 Cloudflare나 Google의 시점이지 당신의 시점이 아닙니다. 특정 리전에서 테스트하려면 DNS Checker 같은 여러 지역 조회 도구를 쓰거나, 해당 리전의 클라우드 VM에서 dig를 돌리세요. ZeroTool의 도구가 답하는 질문은 “이 공용 리졸버는 무엇을 돌려주는가?”이지, “상파울루에 있는 내 사용자가 무엇을 볼까?”가 아닙니다.

DNSSEC 실패는 서버 장애처럼 보입니다. 어떤 존이 DNSSEC 체인을 잘못 서명했다면, Cloudflare와 Google 모두 AD=false와 함께 SERVFAIL을 반환합니다. 리졸버가 존에 전혀 닿지 못할 때와 같은 응답 코드입니다. 레코드 아래의 리졸버 메모로 둘을 구분할 수 있습니다. dnssec-failed.org의 경우 Cloudflare 메모는 EDE(9): DNSKEY Missing ...(RFC 8914 확장 오류 9)입니다. Google은 “DNSSEC validation failure”로 시작하는 설명 문장과 함께 extended_dns_errors 필드(코드 9)를 돌려주고, 도구는 후자를 EDE(9): No DNSKEY matches DS RRs of dnssec-failed.org로 보여 줍니다. 어느 리졸버든 필은 “DNSSEC failed”로 표시됩니다. 도구는 항상 cd=0을 보내는데, 일상적인 조회에 대한 올바른 기본값입니다. 검증 전의 답을 보려면 dig +cd를, 체인 전체를 분석하려면 DNSViz를 쓰세요.

DNS 조회 도구들 사이에서 이 도구의 자리

아래 도구들은 각자 다른 질문에 답합니다.

DNS Checker는 자체 서버에서 “전 세계 여러 지역에 있는 선택된 DNS 서버 목록”에 질의하고 전파 지도를 그립니다. “이 변경이 모든 리전에 도달했는가?”라는 질문에 답하는 도구입니다.

Google Admin Toolbox Dig는 질의를 자체 백엔드(/apps/dig/lookup)로 보냅니다. 2026-09-29 테스트에서 dnssec-failed.org에 대해 “Record not found!”를 표시했고, rcode SERVFAIL은 Raw 보기에만 나왔습니다. 서명된 example.com의 플래그 줄은 QR RD RA로, AD가 없었습니다.

dig와 kdig는 CLI 참조 구현입니다. 스크립팅과, 권위 서버를 지정한 질의(dig @ns1.example.com)가 필요한 작업에는 이쪽이 정답입니다.

ZeroTool 도구는 그 사이의 자리를 채웁니다. dig 설치가 Homebrew 패키지나 WSL 배포판을 추가한다는 뜻이 되는 머신에서 브라우저로 빠르게 조회하고 싶고, 조회 사이트의 서버를 거친 결과가 아니라 공용 리졸버 자신의 답을 보고 싶은 개발자를 위한 도구입니다. Cloudflare와 Google을 바꿔 가며 비교하고, AD 플래그와 리졸버 메모를 보고, 원본 JSON을 복사할 수 있습니다. 전파 지도나 권위 전용 질의에는 적합하지 않습니다. 그런 용도에는 위에서 언급한 도구들이 더 낫습니다.

더 읽을거리

내부 링크:

  • HTTP Header Analyzer — DNS 해석이 끝난 뒤 서버가 무엇을 돌려주는지.
  • SSL Certificate Decoder — 해석된 IP에서 제공된 인증서가 호스트명과 일치하는지 확인.
  • URL Parser — 호스트를 해석하기 전에 URL을 프로토콜, 호스트, 포트, 경로, 쿼리로 분해.
  • IP Subnet Calculator — A/AAAA를 손에 넣은 뒤 방화벽 규칙용 서브넷 구조를 도출.

외부 링크: