DNS 조회
무료 DNS 조회 도구로 도메인, 호스트, IP 주소의 DNS 레코드를 확인하세요. 도메인 자체 네임서버에서 받은 모든 DNS 레코드를 Google과 Cloudflare가 캐시한 값과 나란히 보여 주므로, 변경 사항이 모든 사람에게 반영되었는지 바로 알 수 있습니다.
도메인, 호스트, 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이 끝날 때까지 유지합니다. 결과에는 어느 리졸버인지, 어떤 값을 아직 제공하는지, 갱신까지 얼마나 남았는지 표시됩니다.
경로루트 서버에서 도메인의 TLD, 그리고 도메인 자체 네임서버까지 각 서버의 응답과 응답 속도를 보여 줍니다.최신 값과 캐시레코드 유형마다 도메인 네임서버의 값을 Google과 Cloudflare의 사본 및 남은 시간과 나란히 보여 줍니다.레코드별 설명값의 의미를 말로 풀어 줍니다: 메일 우선순위, SOA 타이머, CAA 규칙, TXT 토큰 뒤의 서비스.DNSSEC와 이메일응답이 서명되고 검증되었는지, 도메인의 MX, SPF, DMARC 설정은 어떤지 보여 줍니다.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대
- .COMa.gtld-servers.netVerisign · 150 ms · 위임: ns1–ns2.example.com
- 네임서버ns1.example.comexample.com · 203.0.113.53 · 20 ms권한 있는 응답(AA) · TCP 연결 하나로 유형 11개
- 응답레코드 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
왜 아직 이전 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}