DNS 조회

무료 DNS 조회 도구로 도메인, 호스트, IP 주소의 DNS 레코드를 확인하세요. 도메인 자체 네임서버에서 받은 모든 DNS 레코드를 Google과 Cloudflare가 캐시한 값과 나란히 보여 주므로, 변경 사항이 모든 사람에게 반영되었는지 바로 알 수 있습니다.

업데이트: 2026년 10월 21일

출처: 루트 서버에서 찾아간 도메인의 권한 있는 네임서버 · Google Public DNS · Cloudflare 1.1.1.1

도메인, 호스트, URL, 이메일 또는 IP 주소3개 출처 · 매번 새로 조회

도메인, 호스트, URL, 이메일 주소, IP를 입력할 수 있습니다. 조회할 때마다 서버에 다시 질의하며, 저희 캐시는 사용하지 않습니다.

레코드 유형

예시

조회 방식 4단계 · 약 1초

루트루트 서버 13대
TLD레지스트리 서버
네임서버도메인 자체 서버
응답모든 레코드 유형
Google8.8.8.8
Cloudflare1.1.1.1

조회할 때마다 경로를 직접 따라갑니다. 루트 서버에서 TLD 레지스트리를 거쳐 도메인 자체 네임서버에서 현재 레코드를 가져오고, Google과 Cloudflare가 캐시하고 있는 값도 함께 질의합니다.

DNS 조회로 확인할 수 있는 정보

DNS 조회는 도메인 네임 시스템(DNS)에 어떤 이름에 대해 무엇이 등록되어 있는지 묻는 것입니다. 웹사이트의 IP 주소(A, AAAA), 메일 서버(MX), 네임서버(NS), 텍스트 레코드(TXT) 등을 알 수 있으며, DNS 확인 또는 DNS 주소 확인이라고도 합니다. 이 DNS 확인 도구는 세 곳에 동시에 질의합니다. 현재의 정확한 값을 가진 도메인 자체의 권한 있는 네임서버, 그리고 수백만 명에게 캐시된 사본을 제공하는 세계에서 가장 바쁜 공개 리졸버 두 곳인 Google Public DNS와 Cloudflare 1.1.1.1입니다.

세 곳의 응답이 다르다면, DNS 변경이 '적용되지 않는' 흔한 이유를 찾은 것입니다. 리졸버가 이전 응답을 아직 가지고 있으며, 레코드의 TTL이 끝날 때까지 유지합니다. 결과에는 어느 리졸버인지, 어떤 값을 아직 제공하는지, 갱신까지 얼마나 남았는지 표시됩니다.

DNS 조회 결과: 도메인 네임서버의 레코드를 Google과 Cloudflare 캐시와 비교하고 루트부터의 경로와 DNSSEC 상태를 표시 — github.com을 DNS 조회한 예시입니다. 루트부터의 경로, 모든 레코드 유형, Google과 Cloudflare가 제공하는 값을 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

DNS 레코드 유형별 설명

도메인의 존에는 여러 유형의 레코드가 있으며, 각 레코드에는 이름, TTL, 값이 있습니다. DNS 레코드 조회에 표시되는 유형은 다음과 같습니다:

유형	담고 있는 정보	예시 값
A	이름의 IPv4 주소: 브라우저가 접속하는 곳입니다.	203.0.113.20
AAAA	이름의 IPv6 주소.	2001:db8::20
CNAME	별칭: 이 이름은 다른 이름이니 그 이름을 대신 조회하라는 뜻입니다. 다른 레코드와 함께 둘 수 없으므로 도메인의 최상위(apex)에는 쓸 수 없습니다.	www.example.com → example.com
MX	도메인의 메일 서버와 우선순위: 숫자가 가장 낮은 서버부터 시도합니다. 우선순위 0과 "."로 된 MX 하나는 도메인이 메일을 받지 않는다는 뜻입니다.	10 mail.example.com
NS	도메인의 레코드를 보관하는 네임서버.	ns1.example.net
TXT	자유 텍스트: 이메일용 SPF, DMARC, DKIM과 Google, Microsoft 등에 도메인 소유를 증명하는 토큰.	v=spf1 include:_spf.example.net -all
SOA	존의 권한 시작(Start of Authority): 주 서버, 담당자, 일련번호, 그리고 새로 고침·재시도·만료·부정 캐싱 타이머.	ns1.example.com hostmaster.example.com 2026102001 7200 3600 1209600 300
CAA	도메인의 인증서를 발급할 수 있는 인증 기관(CA).	0 issue "letsencrypt.org"
HTTPS	첫 요청 전에 연결 방법을 알려 줍니다: HTTP/3 지원, 포트, 주소 힌트. Chrome, Firefox, Apple 시스템이 이 레코드를 조회합니다.	1 . alpn=h3,h2
SRV	서비스가 실행되는 위치(우선순위, 가중치, 포트, 호스트)를 _sip._tcp 같은 이름 아래에 둡니다.	10 5 5060 sip.example.com
PTR	IP 주소에 연결된 이름: 역방향 DNS.	20.113.0.203.in-addr.arpa → host.example.com
DSDNSKEY	DNSSEC: 존의 공개 키(DNSKEY)와 상위 존에 있는 그 지문(DS)으로, 서명을 루트까지 연결합니다.	2371 13 2 3299…

DNS 조회는 어떻게 작동하나요?

기기가 인터넷 전체를 검색하는 것은 아닙니다. 보통 ISP의 리졸버나 Google, Cloudflare 같은 공개 리졸버 하나에 묻고, 리졸버는 답을 가진 서버가 응답할 때까지 이름을 따라 위임을 차례로 따라갑니다:

1
루트 서버에 질의
캐시된 정보가 없으면 리졸버는 12개 기관이 운영하는 13개 루트 서버(a부터 m까지) 중 하나에서 시작합니다. 루트는 example.com을 모르지만 .com을 누가 운영하는지는 압니다. 바쁜 리졸버는 이미 알고 있으므로 이 단계를 건너뜁니다.
2
TLD의 위임 따라가기
.com 서버도 example.com의 레코드를 갖고 있지 않습니다. 대신 도메인 자체 네임서버, 즉 NS 레코드에 있는 서버로 리졸버를 안내합니다.
3
권한 있는 응답 받기
도메인의 네임서버는 AA(authoritative answer) 플래그를 설정해 응답합니다. 소유자가 게시한 그대로의 레코드입니다.
4
TTL 동안 캐시
리졸버는 TTL이 허용하는 동안 응답을 보관하고, 만료될 때까지 묻는 모든 사람에게 TTL이 줄어드는 같은 사본을 건넵니다.

이 도구는 Cloudflare 네트워크에서 이 경로를 직접 따라가므로 각 단계를 볼 수 있습니다. 그런 다음 Google과 Cloudflare에 캐시에 무엇이 있는지 묻습니다.

루트부터의 경로

루트a.root-servers.net16 ms · 위임: .com 서버 13대
위임 · 글루 · DS
.COMa.gtld-servers.netVerisign · 150 ms · 위임: ns1–ns2.example.com
위임 · 글루
네임서버ns1.example.comexample.com · 203.0.113.53 · 20 ms권한 있는 응답(AA) · TCP 연결 하나로 유형 11개
최신 응답 · AA
응답레코드 8개, 유형 7개NOERROR · 응답 31 ms · 4개 비어 있음(CNAME, HTTPS, DNSKEY, DS)

리졸버가 지금 제공하는 값
Google Public DNS8.8.8.8같은 레코드 · 가장 오래된 사본 갱신까지 2:58
Cloudflare DNS1.1.1.1같은 레코드 · 가장 오래된 사본 갱신까지 4:04

결과에 표시되는 것과 같은 경로: example.com 조회

왜 아직 이전 DNS 레코드가 보이나요?

리졸버가 캐시했기 때문입니다. 모든 레코드에는 초 단위의 TTL(time to live)이 있으며, 레코드를 가져온 리졸버는 그 시간이 끝날 때까지 사본을 계속 제공하고 그 후에 다시 묻습니다. DNS 호스트에서 레코드를 바꾸면 권한 있는 응답은 즉시 바뀌지만, 이전 레코드를 이미 가진 리졸버는 만료될 때까지 그것을 유지합니다.

따라서 변경에 걸리는 시간은 정해진 24~48시간이 아니라 이전 레코드의 TTL만큼이며, 이보다 짧은 경우도 많습니다. TTL은 최댓값이고, Google Public DNS는 레코드를 최대 약 6시간까지만 보관하기 때문입니다. 없는 레코드도 캐시됩니다. '그런 이름 없음'이나 '그 유형의 레코드 없음'은 SOA 레코드의 TTL과 SOA의 마지막 필드인 MINIMUM 중 작은 값만큼 보관됩니다. 실패조차 최대 5분 동안 캐시됩니다.

할 수 있는 일

여기서 권한 있는 응답을 확인하세요. 도메인 자체 네임서버에 새 값이 보이면 변경은 끝난 것이고, 캐시만 뒤처져 있을 뿐입니다.
계획된 변경 전에 TTL을 낮추세요. 적어도 이전 TTL만큼 미리 낮춰 두면 캐시가 이전 값을 빨리 버립니다. 변경 후에는 다시 높이세요.
Google과 Cloudflare에 사본 삭제를 요청하세요. 두 곳 모두 캐시에서 이름을 새로 고치는 공개 페이지가 있습니다(Google, Cloudflare).
컴퓨터의 캐시를 비우세요. Windows에서는 ipconfig /flushdns를 실행합니다.

권한 있는 응답ns1.example.com · AA 플래그
도메인 자체 네임서버입니다. 여기서 응답하는 값이 현재 레코드이며, 여기서 바꾸면 나머지가 따라옵니다.
캐시8.8.8.8 · TTL 감소 중
TTL이 끝날 때까지 제공되는 리졸버의 사본입니다. 세상 대부분이 보는 값이며, 변경이 '적용되지 않는' 것처럼 보이는 이유입니다.
내 캐시내 컴퓨터 · 내 공유기
컴퓨터와 공유기도 사본을 보관합니다. 캐시를 비우면 컴퓨터의 사본이 지워지고, 공유기의 사본은 저절로 만료됩니다.

nslookup과 dig: DNS 조회 명령어

터미널에서도 같은 조회를 할 수 있습니다. nslookup은 Windows, macOS, Linux에, dig는 macOS와 대부분의 Linux에, Resolve-DnsName은 Windows의 PowerShell에 들어 있습니다. 위의 결과에는 방금 실행한 조회에 맞는 명령어가 표시됩니다.

조회 대상	nslookup	dig
A 레코드	nslookup example.com	dig example.com
메일 서버	nslookup -type=MX example.com	dig example.com MX
텍스트 레코드(TXT)	nslookup -type=TXT example.com	dig example.com TXT
특정 리졸버에 질의	nslookup example.com 8.8.8.8	dig @8.8.8.8 example.com
역방향 DNS	nslookup 8.8.8.8	dig -x 8.8.8.8
값만 보기	—	dig +short example.com
루트부터의 경로	—	dig +trace example.com

nslookup 출력의 "Non-authoritative answer"(한국어 Windows에서는 "권한 없는 응답")는 응답이 도메인 자체 네임서버가 아니라 리졸버에서 왔다는 뜻입니다. 권한 있는 응답을 받으려면 도메인의 네임서버 하나를 서버로 지정하세요: nslookup example.com ns1.example.net.

ANY는 모든 레코드를 뜻하지 않습니다. 서버는 한 유형으로만 응답하거나 "RFC8482"라고만 적힌 자리 표시 응답을 보낼 수 있으며, 1.1.1.1은 이 질의를 거부합니다. 이 도구는 유형마다 따로 질의합니다. macOS에 기본으로 들어 있는 dig는 HTTPS 레코드를 모르므로 대신 TYPE65로 질의하세요.

DNS 오류: NXDOMAIN, SERVFAIL, REFUSED

모든 DNS 응답에는 응답 코드가 있습니다. 빈 결과가 항상 오류는 아니며, 코드를 보면 어디를 확인해야 할지 알 수 있습니다:

응답	의미	확인할 것
NOERROR	이름이 존재하고 해당 유형의 레코드가 반환되었습니다.	없음. 값을 비교하세요.
NODATA	이름은 존재하지만 이 유형의 레코드가 없습니다. 별도의 코드가 아니라 빈 응답과 함께 오는 NOERROR입니다.	레코드가 있어야 한다면 DNS 호스트에서 추가하세요.
NXDOMAIN	이름이 아예 존재하지 않으며, 그 아래의 이름도 존재하지 않습니다.	철자, 도메인이 등록되어 있고 만료되지 않았는지, 서브도메인이라면 생성되었는지.
SERVFAIL	리졸버가 유효한 응답을 받지 못했습니다. 네임서버가 실패했거나 DNSSEC 검증이 실패했습니다.	DNSSEC 판정, 그리고 도메인의 네임서버가 응답하는지.
REFUSED	서버가 이 질의에 응답하지 않습니다. 이 도메인에 대한 권한이 없고, 재귀 질의도 해 주지 않습니다.	NS 레코드가 실제로 존을 호스팅하는 서버를 가리키는지.
Timeout	응답이 전혀 없습니다.	네임서버가 다운되었거나, 차단되었거나, 주소가 잘못되었는지.

DNSSEC: 안전, 미서명, 손상 중 어느 상태인가요?

DNSSEC는 존의 레코드에 서명해 리졸버가 위조되지 않았음을 증명할 수 있게 합니다. 상위 존은 도메인 키의 지문인 DS 레코드를 게시하고, 도메인은 DNSKEY 레코드에 키를 게시하므로 서명이 루트까지 연결됩니다. Google Public DNS와 Cloudflare 1.1.1.1은 모두 DNSSEC를 검증합니다.

DNSSEC 안전
안전
서명되어 있고 Google의 검증 리졸버가 서명을 확인했습니다. 응답에 AD(authenticated data) 비트가 있으며, 이는 응답이 검증되었다는 리졸버의 표시입니다.
DNSSEC 미서명
미서명
상위 존에 DS 레코드가 없어 존이 서명되지 않았습니다. 정상적으로 해석되지만, 응답이 진짜임을 증명할 수는 없습니다.
DNSSEC 손상
손상
검증에 실패하므로 검증 리졸버는 SERVFAIL을 응답하고, 그 사용자에게는 도메인에 접속할 수 없습니다. 검증을 끄고 질의하면 데이터는 그대로 있습니다. 흔한 원인은 새 DNS 호스트로 옮긴 뒤 상위 존의 DS가 존의 어떤 키와도 일치하지 않는 경우입니다.

DNS 조회로 보는 이메일 레코드

도메인으로 오는 메일은 MX 서버로 가며, 수신 측은 메일을 신뢰하기 전에 TXT 레코드를 확인합니다. SPF는 도메인의 메일을 보낼 수 있는 서버를 나열하며, 레코드 하나가 일으킬 수 있는 DNS 조회는 최대 10회입니다. _dmarc에 있는 DMARC는 실패한 메일을 어떻게 처리할지 알려 주며, 서브도메인에 DMARC가 없으면 이름을 위로 거슬러 올라가며 찾습니다(2026년 5월부터 RFC 9989). _mta-sts에 있는 MTA-STS는 발신 측에 TLS로 전달하도록 요청합니다. 결과는 이 레코드를 모두 읽고 MX 호스트 뒤의 메일 제공업체를 알려 줍니다.

레코드 하나를 더 자세히 점검하려면 MX 조회, SPF 레코드 확인, DMARC 확인을 사용하세요.

DNS 조회 API

무료 엔드포인트 두 개를 제공하며, 브라우저용 CORS를 지원합니다. /api/dns-query는 리졸버 하나에 유형 하나를 질의하며 이전 API의 필드를 유지합니다. /api/dns-lookup은 이 페이지의 전체 조회를 JSON Lines로 스트리밍합니다.

리졸버 하나에서 유형 하나 조회

$ curl -X POST https://dnsrobot.net/api/dns-query \
    -H "Content-Type: application/json" \
    -d '{"domain": "google.com", "recordType": "MX", "dnsServer": "8.8.8.8"}'
{
  "status": "success", "responseTime": 4,
  "resolvedIPs": ["10 smtp.google.com"],
  "dnsServer": "8.8.8.8", "recordType": "MX", "domain": "google.com", …
}

전체 조회 스트리밍

$ curl "https://dnsrobot.net/api/dns-lookup?domain=google.com"
{"t":"start","name":"google.com","kind":"name","types":["A","AAAA","CNAME","MX",…]}
{"t":"hop","hop":{"zone":".","server":"a.root-servers.net","ms":16,"outcome":"referral",…}}
{"t":"answers","source":"google","server":"dns.google","sets":[{"type":"A",…}]}
{"t":"answers","source":"auth","server":"ns1.google.com","sets":[…]}
{"t":"dnssec","verdict":"unsigned",…}
{"t":"done","ms":57}

DNS 조회 자주 묻는 질문

DNS 조회란 무엇인가요?

DNS 조회는 도메인 네임 시스템에 어떤 이름의 레코드를 묻는 것입니다. 웹사이트의 IP 주소, 메일 서버, 네임서버, 텍스트 레코드 등을 알 수 있습니다. 기기는 사이트를 열 때마다 DNS 조회를 합니다. 이 도구는 도메인 자체 네임서버와 Google, Cloudflare 공개 리졸버에서 받은 모든 레코드 유형을 한 번에 보여 줍니다.

도메인의 DNS 레코드는 어떻게 확인하나요?

위에 도메인을 입력하고 '전체'를 선택하세요. 도구가 도메인의 권한 있는 네임서버에 각 레코드 유형(A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, HTTPS, DNSKEY, DS)을 질의하고, 각 유형 옆에 Google과 Cloudflare의 캐시된 사본을 보여 줍니다. 한 유형만 보려면 그 유형을 고르고, 같은 조회를 직접 실행하려면 dig와 nslookup 명령어를 복사하세요.

nslookup을 온라인으로 실행할 수 있나요?

네. 이 페이지는 더 자세한 정보를 보여 주는 nslookup 온라인 도구입니다. nslookup은 서버 하나에 레코드 유형 하나를 묻지만, 여기서는 모든 유형, 권한 있는 응답과 두 리졸버의 캐시, TTL, 루트부터의 경로를 한 번에 볼 수 있습니다. 결과에는 터미널에서 실행할 수 있는 nslookup, dig, Resolve-DnsName 명령어도 그대로 표시됩니다.

nslookup으로 TXT 레코드는 어떻게 확인하나요?

터미널에서 nslookup -type=TXT example.com을 실행하세요. dig에서는 dig example.com TXT입니다. TXT 레코드에는 이메일용 SPF, DMARC, DKIM과 Google, Microsoft 등에 도메인 소유를 증명하는 토큰이 들어 있습니다. 이 페이지에서 TXT를 선택하면 권한 있는 응답과 Google, Cloudflare의 캐시를 함께 보여 주고, 각 TXT 토큰이 어떤 서비스의 것인지도 알려 줍니다.

DNS 변경 사항이 반영되기까지 얼마나 걸리나요?

이전 레코드의 TTL만큼 걸립니다. 도메인의 네임서버는 새 값을 즉시 제공하지만, 이전 값을 캐시한 리졸버는 TTL이 끝날 때까지 그 값을 계속 유지합니다. 예를 들어 300초면 5분, 86400초면 하루입니다. 결과에는 Google과 Cloudflare 사본의 남은 시간이 표시됩니다. 계획된 변경이 있다면 하루 전에 미리 TTL을 낮춰 두세요.

nslookup의 '권한 없는 응답'은 무슨 뜻인가요?

도메인 자체 네임서버가 아니라 리졸버의 캐시에서 온 응답이라는 뜻입니다. nslookup은 리졸버에 질의할 때마다 '권한 없는 응답(Non-authoritative answer)'을 표시하는데, 거의 항상 그렇습니다. 대개는 정확하지만 TTL이 끝날 때까지는 오래된 값일 수 있습니다. 권한 있는 응답은 AA 플래그와 함께 존의 네임서버에서 오며, 이 도구는 루트부터 따라 내려가 그 응답을 받습니다.

NXDOMAIN은 무슨 뜻인가요?

NXDOMAIN은 DNS에 그 이름이 존재하지 않는다는 뜻입니다. 도메인이라면 철자, 그리고 등록되어 있고 만료되지 않았는지 확인하세요. WHOIS 조회로 상태를 볼 수 있습니다. 서브도메인이라면 레코드가 생성된 적이 없거나 삭제된 것입니다. 이름은 있지만 요청한 유형의 레코드가 없으면 대신 빈 응답과 함께 NOERROR가 오며, 흔히 NODATA라고 부릅니다.

SERVFAIL은 무슨 뜻인가요?

SERVFAIL은 리졸버가 유효한 응답을 받지 못했다는 뜻입니다. 원인은 두 가지입니다. 도메인의 네임서버가 다운되었거나 설정이 잘못된 경우, 또는 DNSSEC 검증이 실패해 Google, Cloudflare 같은 검증 리졸버가 응답을 거부한 경우입니다. 이 도구는 두 경우를 구분합니다. 검증을 끄고 질의했을 때 데이터가 돌아오면 DNSSEC 판정이 '손상'으로 표시됩니다.

DNS에서 TTL이란 무엇인가요?

TTL(time to live)은 리졸버가 레코드를 캐시에 보관했다가 다시 묻기까지의 초 단위 시간입니다. 레코드마다 TTL이 따로 있습니다. 300초처럼 짧은 TTL은 변경이 빨리 퍼지지만 질의가 늘고, 86400초(하루)처럼 긴 TTL은 부담이 적지만 변경이 느립니다. 캐시된 사본은 TTL이 계속 줄어들므로 여기 표시되는 Google과 Cloudflare의 TTL이 더 낮습니다.

역방향 DNS 조회는 어떻게 하나요?

위에 IP 주소를 입력하세요. 도구가 주소를 역방향 이름으로 바꾸고(8.8.8.8은 8.8.8.8.in-addr.arpa가 됩니다) PTR 레코드를 질의한 다음, 그 이름을 정방향으로 확인합니다. 그 이름이 같은 IP로 다시 해석되면 역방향 DNS가 확인된 것이며, 메일 서버가 바로 이것을 확인합니다. 터미널에서는 nslookup 8.8.8.8 또는 dig -x 8.8.8.8을 실행합니다.

DNS 조회와 DNS 전파 확인은 무엇이 다른가요?

DNS 조회는 도메인 자체 네임서버와 대형 리졸버 두 곳에서 받은 도메인의 모든 레코드를 세부 정보와 함께 보여 줍니다. 전파 확인은 전 세계 수십 개 리졸버에 레코드 유형 하나를 질의해 변경이 어디까지 도달했는지 봅니다. 먼저 여기서 실제 값과 캐시를 확인한 다음, 홈페이지의 DNS 전파 확인 도구로 전 세계 상황을 보세요.

이 DNS 조회는 무료인가요? 조회한 내용을 저장하나요?

무료이며 계정도 CAPTCHA도 필요 없습니다. 질의 대상 서버를 보호하기 위해 하나의 네트워크에서는 1분에 20회까지 조회할 수 있습니다. 조회는 Cloudflare 네트워크에 있는 저희 서버에서 실행되므로, 도메인의 네임서버에는 사용자의 주소가 아니라 저희 주소가 보입니다. 결과를 캐시하지 않아 매번 새로 질의합니다. 누가 무엇을 조회했는지 기록하지 않습니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기