DNS 조회

DoH로 도메인의 DNS 레코드(A/AAAA/MX/TXT/NS/CNAME/SOA)를 조회합니다. 개인정보 보호를 위해 브라우저에서 로컬로 실행

도메인

레코드 유형

DoH 제공자

도메인을 입력하고 레코드 유형을 선택한 뒤 조회를 클릭하세요

DNS 조회란?

DNS(Domain Name System)는 인터넷의 «전화번호부»로, example.com처럼 사람이 읽을 수 있는 도메인을 기계가 통신에 사용하는 IP 주소로 변환합니다. DNS 조회는 DNS 서버에 도메인의 특정 레코드를 요청하는 작업입니다. A 레코드는 IPv4 주소를, MX 레코드는 이메일을 수신하는 서버를, TXT 레코드는 SPF/DKIM과 도메인 소유권 확인에 자주 쓰입니다. 이 도구는 DoH(DNS over HTTPS) 프로토콜로 브라우저 내에서 직접 조회를 수행합니다. 요청은 브라우저에서 공용 DNS 리졸버로 곧장 전송되고 당사 서버를 거치지 않으므로, 조회 내용과 결과가 로컬에 남아 개인정보가 보호됩니다.

사용 방법

단계

조회할 도메인(예: example.com)을 입력합니다
드롭다운에서 조회할 레코드 유형(예: A, MX, TXT)을 선택합니다
선택: DoH 제공자(Cloudflare, Google 또는 AliDNS)를 전환합니다
조회 버튼을 클릭하거나 Enter를 누릅니다
결과 표에서 이름·유형·TTL·값을 확인합니다

참고 사항

TTL(생존 시간)은 초 단위이며 리졸버가 레코드를 캐시하는 기간을 나타냅니다. 값이 작을수록 변경이 더 빨리 전파됩니다.
상태가 NXDOMAIN이면 도메인이 존재하지 않음을 뜻합니다. NOERROR인데 응답 레코드가 없으면 보통 해당 유형이 설정되지 않은 것입니다.
MX 레코드 값은 «10 mail.example.com»처럼 생겼으며, 앞의 숫자가 우선순위로 작을수록 우선합니다.
TXT 레코드는 길고 따옴표를 포함할 수 있으며 정상입니다. SPF, DKIM, DMARC, 도메인 확인에 자주 쓰입니다.

활용 사례

열리지 않는 사이트의 이름 해석 진단A/AAAA 레코드를 조회해 도메인이 올바른 서버 IP로 해석되는지 확인합니다. NXDOMAIN이나 잘못된 IP가 반환되면 문제는 서버가 아니라 DNS 설정에 있는 경우가 많습니다. TTL과 함께 보면 오래된 캐시의 영향인지도 알 수 있습니다.

메일 설정 전 MX 레코드 확인도메인을 메일 제공자(Exchange, Google Workspace 등)에 연결하기 전에 MX 레코드를 조회해 올바른 메일 서버를 가리키는지, 우선순위 순서가 맞는지 확인합니다. 배달 실패나 스팸 분류를 막을 수 있습니다.

SPF/DKIM/DMARC 메일 보안 정책 검증TXT 레코드를 조회해 SPF(v=spf1 ...), DKIM 셀렉터(예: default._domainkey), DMARC(_dmarc)가 올바르게 게시되었는지 확인합니다. 거부되거나 위조된 메일 위험을 낮추는, 전달률 문제 해결의 기본 수단입니다.

DNS 변경 후 글로벌 전파 확인DNS 제공자를 바꾸거나 레코드를 편집한 뒤, 여러 DoH 제공자로 조회해 결과를 비교하여 새 레코드가 전파되었는지 봅니다. TTL이 크면 이전 레코드가 캐시에 남을 수 있으며, 이전 TTL이 만료되면 결과가 수렴합니다.

도메인의 권한 네임서버 파악NS 레코드를 조회하면 도메인을 관리하는 권한 네임서버를 알 수 있습니다. DNS 호스팅 전환이 완료되었는지 확인하거나 해석 이상 시 책임 소재를 파악하는 데 유용하며, SOA 레코드와 함께 갱신 주기도 확인할 수 있습니다.

기술 원리

DNS 조회는 전통적으로 UDP 53번 포트에서 이루어집니다. 클라이언트가 쿼리 이름과 유형을 담은 DNS 메시지를 설정된 재귀 리졸버로 보내면, 리졸버가 루트·최상위·권한 서버를 재귀적으로 따라가며 응답을 반환합니다. RFC 1035에 정의된 이 메시지는 압축된 바이너리 형식이며, 브라우저는 보안 제약 때문에 원시 UDP 53을 직접 송수신할 수 없어 웹 기반 DNS 도구는 보통 백엔드 프록시가 필요합니다. RFC 8484에 정의된 DoH(DNS over HTTPS)는 DNS 메시지를 HTTPS 요청으로 감싸 기본 443번 포트에서 전송합니다. 두 가지 페이로드 형식이 있는데, 바이너리 wireformat(application/dns-message)과 JSON 형식(application/dns-json, Google이 RFC 8484 외부에서 제공하며 Cloudflare도 지원)입니다. 이 도구는 JSON 형식을 사용해 브라우저가 `Accept: application/dns-json` 헤더를 단 GET 요청을 `https://cloudflare-dns.com/dns-query?name=example.com&type=A`로 보내 구조화된 JSON을 직접 받습니다. 백엔드는 필요 없습니다. 반환된 JSON의 주요 필드는 다음과 같습니다. `Status`는 DNS RCODE입니다(0=NOERROR, 3=NXDOMAIN은 도메인이 존재하지 않음, 2=SERVFAIL은 서버 장애). `Answer` 배열의 각 항목은 `name`(레코드 이름), `type`(숫자 유형 코드, 예: 1=A, 28=AAAA, 15=MX, 16=TXT, 2=NS, 6=SOA, 5=CNAME), `TTL`(캐시 생존 시간, 초), `data`(레코드 값)를 가집니다. 권한 응답은 `Authority`(SOA, NS)와 `Additional` 섹션에 나타날 수도 있습니다. DoH의 핵심 가치는 프라이버시와 변조 방지입니다. DNS 쿼리가 HTTPS로 암호화되어 평문 UDP 53처럼 중간자가 내용을 엿보거나 변조할 수 없고, 포트 식별로 트래픽을 가로채기도 어렵습니다. 이것이 이 도구를 브라우저만으로 실행 가능하게 만드는 이유이며, 트래픽은 DoH 제공자로 직행하고 어떤 중간 서버도 거치지 않습니다.

전통 DNS: RFC 1035, UDP/TCP 53번 포트, 바이너리 메시지. 브라우저는 직접 송수신할 수 없어 백엔드 프록시가 필요.
DoH: RFC 8484, DNS를 HTTPS로 감싸 443번 포트 사용, 쿼리 내용 암호화, 엿보기·가로채기에 강함.
JSON DoH: 요청에 `Accept: application/dns-json`을 붙여 구조화된 JSON 반환. Cloudflare와 Google이 지원하고 CORS도 열려 있어 브라우저에서 직접 호출 가능.
RCODE: 0=NOERROR, 2=SERVFAIL, 3=NXDOMAIN(도메인 없음), 5=REFUSED.
레코드 유형 코드: 1=A, 28=AAAA, 5=CNAME, 15=MX, 16=TXT, 2=NS, 6=SOA, 33=SRV, 257=CAA.
TTL은 초 단위 캐시 생존 시간. 재귀 리졸버는 TTL이 만료될 때까지 캐시 결과를 반환하고, 만료 후 권한 서버에 다시 쿼리합니다.

예시

example.com의 A 레코드 조회

도메인: example.com
유형:   A
상태:   NOERROR

Answer:
  example.com.   300   A   93.184.216.34

# TTL 300초: 이 IPv4 레코드는 5분간 캐시됩니다.

gmail.com의 MX 레코드 조회

도메인: gmail.com
유형:   MX
상태:   NOERROR

Answer:
  gmail.com.   3600   MX   5 gmail-smtp-in.l.google.com.
  gmail.com.   3600   MX   10 alt1.gmail-smtp-in.l.google.com.

# 앞의 숫자는 우선순위로 작을수록 우선. 메일은 우선순위 5 서버로 먼저 배달됩니다.

example.com의 TXT 레코드 조회(SPF)

도메인: example.com
유형:   TXT
상태:   NOERROR

Answer:
  example.com.   3600   TXT   "v=spf1 -all"

# 이 SPF 정책은 도메인이 메일을 보내지 않으며 모든 출처를 거부함을 뜻합니다.

존재하지 않는 도메인 조회(NXDOMAIN)

도메인: this-domain-does-not-exist-12345.com
유형:   A
상태:   NXDOMAIN

Answer: (없음)

# Status=3은 DNS에 해당 도메인이 존재하지 않음을 나타내며, 서버 장애가 아닙니다.

자주 묻는 질문

DNS 조회가 개인정보를 노출시키나요?

아닙니다. 요청은 브라우저에서 선택한 DoH 제공자(Cloudflare, Google 또는 AliDNS)로 직접 전송되어 HTTPS로 완전히 암호화되며 당사 서버를 거치지 않습니다. 무엇을 조회하는지 당사는 볼 수 없으며, 평문 UDP 53보다 오히려 더 안전합니다.

제공자마다 결과가 다를 때가 있는 이유는?

DNS 결과는 TTL에 따라 각 리졸버 수준에서 캐시됩니다. 제공자마다 캐시 상태와 갱신 시점이 달라 레코드 변경 직후 전파 기간에는 이전 값과 새 값을 반환할 수 있습니다. 이전 레코드의 TTL이 만료되면 결과는 수렴합니다.

NOERROR인데 응답 레코드가 없다는 것은?

도메인은 존재하고 조회는 성공했지만, 해당 도메인에 조회한 유형의 레코드가 없음을 뜻합니다. 예를 들어 MX 결과가 비어 있으면 보통 그 도메인이 메일을 수신하지 않는 것입니다. Authority 섹션은 보통 네거티브 캐시 근거로 SOA 레코드를 반환합니다.

TTL 값은 무엇에 영향을 주나요?

TTL(초)은 리졸버가 레코드를 캐시하는 기간을 결정합니다. TTL이 크면 글로벌 해석이 빠르고 서버 부하가 적지만 변경 전파는 느립니다. TTL이 작으면 변경이 빨리 반영되지만 쿼리가 잦아집니다. DNS 변경 전에 TTL을 낮추는 경우가 많습니다.

역방향 DNS(IP→도메인)를 지원하나요?

지원합니다. PTR 레코드를 조회할 때는 IP 주소를 역방향 형식으로 입력합니다. 8.8.8.8은 8.8.8.8.in-addr.arpa가 되고, IPv6는 ip6.arpa 접미사를 씁니다. 반환된 PTR 레코드가 해당 IP가 역방향 해석하는 도메인 이름입니다.

브라우저에서 DoH URL을 직접 열면 400이 뜨는 이유는?

Cloudflare의 JSON DoH 엔드포인트는 Accept: application/dns-json 헤더를 요구합니다. 주소창은 기본적으로 HTML Accept 헤더를 보내므로 400이 반환됩니다. 예상된 동작이며, fetch로 사용자 지정 헤더를 붙이면 정상 호출됩니다.

모든 최상위 도메인을 조회할 수 있나요?

네. 도메인이 DNS에 등록되어 관련 레코드가 설정되어 있다면, gTLD(.com, .org), ccTLD(.cn, .jp, .de), 신규 gTLD 모두 DoH 제공자가 재귀적으로 해석해 결과를 반환합니다.