도구 모음

DNS 조회

도메인 이름만 DNS 조회에 쓰입니다. 입력한 도메인과, 그 도메인의 DNS 레코드가 가리키는 이름(선택자·include 대상 등)이 Cloudflare DNS(1.1.1.1)에 조회됩니다. 그 밖에는 아무것도 전송되지 않습니다. 익명 방문 통계만 집계합니다.

도메인, URL, 이메일 주소 모두 됩니다. 한글 도메인은 퓨니코드로 바꿔 조회합니다.

예시

사용법

  1. 조회할 도메인을 입력합니다. naver.com 처럼 도메인만 넣어도 되고, 주소창의 URL 이나 이메일 주소를 붙여넣으면 호스트 이름만 떼어 조회합니다. 한글 도메인은 퓨니코드(xn--)로 바꾸고, 대문자와 끝의 점은 정리한 뒤 무엇을 바꿨는지 알려 줍니다.
  2. "조회"를 누르면 A·AAAA·CNAME·MX·NS·TXT·CAA·SOA 여덟 유형을 Cloudflare DNS(1.1.1.1)에 동시에 물어봅니다. 브라우저가 DNS-over-HTTPS 로 직접 묻고, microlab 서버는 거치지 않습니다.
  3. 맨 위 요약표에서 유형별로 레코드가 있는지 보고, 아래에서 값과 TTL(캐시 유지 시간)을 확인합니다. 별칭(CNAME)을 따라간 경우 체인이 함께 나오고, MX 는 우선순위 순, SOA 와 CAA 는 필드별로 풀어서 보여 줍니다. 값 옆 "복사"로 하나씩 복사할 수 있습니다.
  4. "없음"이 보이면 종류를 확인합니다. 도메인 자체가 없으면 NXDOMAIN, 이름은 있는데 그 유형만 없으면 "레코드 없음", 리졸버가 답을 얻지 못하면 SERVFAIL 로 구분해 표시합니다. 셋은 뜻이 전혀 다릅니다.
  5. 결과를 다른 사람과 보려면 "링크 복사"를 누릅니다. 도메인은 주소의 # 뒤에 실려 이 사이트 서버로는 전송되지 않습니다. 각 유형의 "원응답 JSON"을 펼치면 Cloudflare 가 돌려준 답을 그대로 볼 수 있어 다른 도구의 결과와 대조할 수 있습니다.

자주 묻는 질문

NXDOMAIN, "레코드 없음", SERVFAIL 은 어떻게 다른가요?

NXDOMAIN 은 "그런 이름이 DNS 에 아예 없다"는 답입니다(RFC 1035 §4.1.1 의 RCODE 3, RFC 2308 §2.1). 철자가 틀렸거나 등록·위임이 끝나지 않은 경우입니다. "레코드 없음"은 이름은 있지만 물어본 유형이 없다는 뜻입니다 — 응답 코드는 정상(NOERROR)인데 답이 0개인 경우로, RFC 2308 §2.2 에서 NODATA 라고 부릅니다. 예를 들어 웹사이트만 있고 메일은 받지 않는 도메인은 A 는 있고 MX 는 "없음"으로 나옵니다. SERVFAIL(RCODE 2)은 리졸버가 답을 얻지 못했다는 뜻이지 레코드가 없다는 뜻이 아닙니다. 권한 네임서버가 응답하지 않거나 DNSSEC 서명 검증에 실패하면 이렇게 되고, Cloudflare 가 붙여 준 확장 오류 문구(EDE, RFC 8914)가 있으면 함께 보여 줍니다.

방금 바꾼 레코드가 왜 예전 값으로 나오나요?

DNS 답은 TTL 동안 리졸버 캐시에 남습니다. 이 도구는 브라우저 캐시는 쓰지 않지만(매번 새로 요청) Cloudflare 리졸버에 이미 캐시된 답은 TTL 이 끝날 때까지 그대로 돌아옵니다. 표의 TTL 은 그 캐시에 남은 시간이라 조회할 때마다 줄어듭니다. "없음" 답도 캐시된다는 점을 흔히 놓칩니다 — 레코드를 만들기 전에 한 번 조회했다면 SOA 의 minimum 값과 SOA 레코드 TTL 중 작은 쪽만큼 "없음"이 유지될 수 있습니다(RFC 2308 §5). NXDOMAIN 이 나오면 남은 시간을 함께 보여 줍니다. 네임서버(NS)를 옮긴 경우에는 상위 영역의 위임 TTL 때문에 더 오래 걸릴 수 있습니다.

이 결과가 nslookup·dig 결과나 다른 사이트와 다른 이유는 무엇인가요?

어느 리졸버에 물었는지가 다르기 때문인 경우가 대부분입니다. 이 도구는 Cloudflare(1.1.1.1) 한 곳에 묻습니다. 회사·통신사 DNS 는 캐시 시점이 달라 바꾼 직후에는 옛 값과 새 값이 섞여 보입니다. 또 CDN·대형 포털처럼 접속 위치에 따라 다른 서버로 보내는 도메인은 묻는 리졸버에 따라 A·AAAA 값이 다르게 나오는 것이 정상입니다 — 어느 쪽이 틀린 것이 아닙니다. 값의 순서도 매번 섞여 나올 수 있어(RRset 안의 순서에는 의미가 없습니다, RFC 1034 §3.6) 순서 차이는 무시해도 됩니다.

CNAME 이 있으면 A·MX·TXT 결과가 왜 다른 이름으로 나오나요?

CNAME 은 "이 이름은 저 이름의 별칭"이라는 뜻이라, 리졸버는 별칭을 따라가 대상 이름의 레코드를 돌려줍니다. 예를 들어 www.naver.com 은 www.naver.com.nheos.com 의 별칭이어서 A 값은 대상 이름의 것입니다. CNAME 이 있는 이름에는 다른 레코드를 함께 둘 수 없으므로(RFC 2181 §10.1) MX·TXT 도 대상 이름 기준으로 나옵니다. 그래서 도메인 맨 앞(apex)에는 CNAME 을 두지 않는 것이 원칙입니다 — 거기에는 SOA·NS 가 반드시 있어야 하기 때문입니다. 별칭의 대상이 존재하지 않으면 "별칭이 가리키는 이름이 없습니다"라고 따로 알립니다.

CAA 레코드가 없으면 아무 인증기관이나 인증서를 발급할 수 있나요?

이름에 CAA 가 없으면 인증기관은 상위 이름으로 올라가며 처음 나오는 CAA 를 적용합니다(RFC 8659 §3). 그래서 www.example.com 에 CAA 가 없어도 example.com 의 CAA 가 발급을 제한할 수 있습니다. 이 도구는 이름에 CAA 가 없으면 상위 이름을 차례로 조회해 어디의 CAA 가 적용되는지, 또는 끝까지 없어서 CAA 로는 제한되지 않는지를 알려 줍니다. issue 는 일반 인증서, issuewild 는 와일드카드 인증서를 발급할 수 있는 기관이고, iodef 는 규칙 위반 요청을 알릴 연락처입니다(RFC 8659 §4.2~4.4).

이 도구가 확인하지 않는 것은 무엇인가요? (한계)

여덟 가지 유형(A·AAAA·CNAME·MX·NS·TXT·CAA·SOA)만 조회합니다. SRV·PTR(IP 역방향) 등 다른 유형, WHOIS(등록 정보), 권한 네임서버에 직접 묻는 조회, 여러 지역 리졸버 비교는 하지 않습니다. DNSSEC 은 직접 검증하지 않고, Cloudflare 가 검증에 성공했다고 표시한 AD 비트만 그대로 보여 줍니다(RFC 4035 §3.2.3). 결과는 조회한 순간 Cloudflare 가 가진 답이며, 권한 네임서버의 현재 값과 TTL 만큼 차이가 날 수 있습니다. 조회 하나는 8초, 전체는 30초가 지나면 멈추고 그렇게 알려 줍니다. 메일 설정(SPF·DKIM·DMARC)의 해석은 같은 그룹의 메일 인증 점검 도구가 맡습니다.

입력한 도메인은 어디로 가나요?

입력한 도메인은 브라우저에서 Cloudflare DNS(cloudflare-dns.com, 1.1.1.1 서비스)로 바로 조회됩니다. 이름에 CAA 가 없으면 적용되는 CAA 를 찾으려고 그 상위 이름(예: www.example.com 이면 example.com, com)도 조회합니다. microlab 서버나 scan-api 는 거치지 않고, 그 밖에는 아무것도 전송되지 않습니다. 공유 링크에 담기는 도메인은 주소의 # 뒤(해시)에 있어 브라우저가 이 사이트 서버로 보내지 않습니다. 익명 방문 통계만 집계합니다. 회사 방화벽이나 광고 차단 확장이 cloudflare-dns.com 을 막으면 조회가 실패하고, 그 경우 오류 문구로 알려 줍니다.