인기 도구

테마

DNS 상태 검사

레지스트리의 위임부터 직접 질의한 모든 네임서버, SOA, DNSSEC, 메일 레코드까지 DNS를 확인하는 도메인 검증 도구입니다. 검사 40개마다 해결 방법을 알려 드립니다.

수준은 Zonemaster와 RFC 기준 · 모든 네임서버에 TCP로 질의 · Google Public DNS · RDAP

루트 서버에서 .nl 레지스트리까지 따라간 뒤, sidn.nl의 각 네임서버에 직접 묻습니다 · 검사 40개 · 약 3초.nl 레지스트리 → 모든 네임서버 · 검사 40개

예시
예시2026년 10월 23일 기록 · 저희 서버에서.nlNS 3개DNSSEC 서명됨

sidn.nl 도메인은 실행된 모든 검사를 DNSSEC까지 통과했습니다

등록대행자: SIDN·2.9초

통과 40건

A+: 정보 수준을 넘는 지적 없음. 모든 네임서버가 권한 있게 응답하고 서로 일치하며, 타이머는 Zonemaster의 범위 안에 있고, Google Public DNS가 루트부터 DNSSEC 신뢰 체인을 검증합니다.

문제 먼저

Cloudflare 엣지에 있는 저희 서버에서 TCP로 질의합니다: 루트, .nl 레지스트리, 모든 네임서버에는 직접, 메일 레코드와 검증에는 Google Public DNS와 Cloudflare를 사용합니다. 확인한 내용의 로그는 남기지 않습니다.

DNS 상태 검사로 무엇을 확인하나요?

DNS 상태 검사는 리졸버가 도메인을 찾는 순서대로 따라가며 모든 단계를 테스트합니다: 레지스트리의 위임, 직접 질의한 각 네임서버, 서버들이 서로 일치하는지, SOA 레코드, DNSSEC, 메일 레코드. 이 DNS 확인 도구는 7개 그룹에서 40개 검사를 실행하고, 각 검사를 근거 기준이 정한 수준으로 평가합니다.

대부분의 검사 도구는 리졸버에 묻고 돌아온 결과를 평가합니다. 그러면 그 뒤에 있는 서버가 가려집니다: 리졸버는 작동하는 네임서버 중 하나에서 응답을 받으므로, 고장 난 서버는 다른 서버까지 고장 날 때까지 드러나지 않습니다. 여기서는 모든 네임서버에 재귀 없이 TCP로 질의하고, 레지스트리에 있는 NS 레코드 사본을 존 자체의 것과 비교하며, DNSSEC 체인을 레지스트리의 DS부터 존 안의 서명까지 검증합니다.

변경한 뒤에는 DNS 감사로 활용하세요: 웹사이트가 열리는지뿐 아니라 도메인이 의존하는 DNS 레코드를 확인합니다(사이트 자체는 사이트 접속 확인에서 살펴봅니다). 보고서 복사를 누르면 결과가 티켓에 붙여 넣을 수 있는 일반 텍스트 DNS 보고서가 됩니다.

루트h.root-servers.net
.com.com 레지스트리h.gtld-servers.net
네임서버 8대Route 53 + NS1
존github.com
  • DNSSEC검사 7개루트부터의 신뢰 체인: github.com: .com에서 멈춤(DS 없음)
  • 상위와 위임검사 6개레지스트리의 위임 응답: 이름 8개 · 295바이트 · 글루 불필요
  • 네임서버검사 14개각 서버에 직접 질의: 8대 중 8대 권한 있음 · TCP로 · EDNS · 재귀 없음
  • 일관성검사 3개서버들이 일치하는지: SOA 시리얼 2개, DNS 호스트마다 하나 · 같은 MX와 SPF
  • SOA검사 4개Zonemaster 하한보다 낮은 타이머: 알림
  • CAA검사 1개레코드 7개 · 허용된 CA 4곳
  • 메일 DNS검사 5개MX: Microsoft 365 · SPF 조회 10회 중 10회 · DMARC quarantine
각 검사 그룹이 어디를 보는지 github.com의 실제 경로(2026년 10월 23일)로 보여 줍니다: 루트에서 .com 레지스트리를 거쳐 Route 53과 NS1에 있는 존의 네임서버까지입니다.
github.com의 DNS 상태 검사 결과: 등급 A, 7개 그룹 40개 검사, 루트에서 네임서버 8대까지의 경로github.com의 DNS 상태 검사 결과: 등급 A, 7개 그룹 40개 검사, 루트에서 네임서버 8대까지의 경로등급수준만으로 정해집니다: 심각 없음, 오류 없음, 경고 2건이면 A입니다. 링은 점수(100점 중 90점)를 보여 줍니다.검사 40개, 칸 하나씩페이지에 나열된 그룹 순서입니다. 주황색과 파란색 칸은 경고와 알림이고, 빗금 친 칸은 실행할 수 없었던 검사입니다.문제 먼저고칠 것이 있는 그룹이 위에 펼쳐지며, 각 행에 근거 기준과 해결 방법이 있습니다.경로루트 서버, Verisign이 운영하는 .com 레지스트리, 그리고 직접 질의한 모든 네임서버: 각 서버의 응답, 시리얼, EDNS.신뢰 체인경로 옆의 DNSSEC 레일입니다: 유지되는 곳은 녹색, 멈춘 곳은 점선, 끊어진 곳은 빨간색입니다.
github.com의 DNS 상태 검사 예시입니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

DNS 확인 결과의 등급은 어떻게 정해지나요?

등급은 실패한 항목의 수준으로만 정해지며 점수표는 쓰지 않습니다: 심각한 문제가 하나라도 있으면 F, 오류 2건 이상은 D, 오류 1건 또는 경고 5건 이상은 C, 경고 3~4건은 B, 경고 1~2건(또는 알림만)은 A, 정보 수준을 넘는 것이 없으면 A+입니다.

수준은 인용한 기준 자체의 것입니다: 테스트를 정의한 경우에는 Zonemaster의 기본 프로필, 그렇지 않으면 RFC의 MUST 또는 SHOULD입니다. 100점 만점의 점수는 같은 등급 안에서 도메인의 순위를 매길 뿐입니다(100에서 심각 1건마다 30, 오류마다 12, 경고마다 4, 알림마다 1을 뺍니다). 저희 서버에서 실행할 수 없는 검사는 도메인에 불리하게 작용하지 않습니다. 4분의 1 이상을 실행할 수 없으면 등급에 일부라고 표시됩니다.

  1. A+100정보 수준을 넘는 지적 없음INFO “결코 문제를 나타내지 않는다”sidn.nl100
  2. A90~99경고 1~2건 또는 알림만NOTICE “존 관리자가 알아 두어야 하지만 꼭 문제일 필요는 전혀 없다”github.com90example.com95bücher.de90
  3. B75~89경고 3~4건WARNING “어떤 상황에서는 문제가 되지만 일반 사용자가 알아차릴 가능성은 낮다”cloudflare.com87google.com83
  4. C60~74오류 1건 또는 경고 5건 이상ERROR “존의 기능에 부정적인 영향을 줄 가능성이 매우 높다(또는 확실하다)”표본에 없음
  5. D45~59오류 2건 이상dnssec-failed.org55
  6. F0~44심각한 문제가 하나라도 있음CRITICAL “존재하지 않는다고 봐도 무방하다”.com 도메인44

점수 = 100 − 30 × 심각 − 12 × 오류 − 4 × 경고 − 1 × 알림, 해당 등급의 범위 안으로 제한

일부검사의 4분의 1 이상을 저희 서버에서 실행할 수 없었으므로 등급에 그 사실을 표시합니다

등급 단계와, 2026년 10월 23일에 검사한 도메인을 기록된 등급에 따라 배치한 것입니다. 수준 설명은 Zonemaster의 심각도 정의에서 인용했습니다.

상위와 하위의 NS 레코드가 일치하나요?

일치해야 합니다: 레지스트리(상위)와 존(하위)은 각각 NS 집합을 게시하며, RFC 1912 §2.8은 둘을 같게 유지하라고 합니다. 레지스트리가 존에 응답하지 않는 서버를 가리키면 lame 위임입니다: 그 서버는 REFUSED로 응답하거나 권한(AA) 플래그 없이 응답합니다.

리졸버는 다음 서버로 넘어가므로 lame 서버 하나는 시간만 잡아먹지만, 나열된 모든 서버가 lame이면 도메인이 해석되지 않습니다. Zonemaster는 레지스트리에만 있는 이름을 오류(EXTRA_NAME_PARENT), 존에만 있는 이름을 알림, 작동하는 서버가 하나도 없는 상태를 심각으로 평가합니다.

github.com일치

레지스트리 .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
존
  • 같은 8대

8대 중 8대가 AA로 응답

.net 도메인불일치

레지스트리 .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
존
  • ns1.hover.com
  • ns2.hover.com

공통 이름 없음 · ns2.domaindirect.com: REFUSED · 오류 2건

.com 도메인lame 위임

레지스트리 .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
존
  • 아무도 응답 안 함SERVFAIL

모든 서버가 REFUSED · 리졸버는 SERVFAIL로 응답 · CRITICAL

2026년 10월 23일에 기록한 위임 세 가지입니다. 손상된 두 도메인은 이름을 가렸지만, 네임서버와 응답은 실제입니다.

도메인에 네임서버는 몇 대 필요한가요?

최소 2대, 권장은 3대입니다. RFC 1034 §4.1은 모든 존을 적어도 서버 2대에서 제공하도록 요구하고, RFC 2182 §5는 대부분의 조직 수준 존에 3대를 권장합니다. Zonemaster에서 네임서버 1대는 오류이고, 2대는 정보 메모와 함께 통과합니다.

대수보다 위치가 더 중요하므로, 이 네임서버 확인에서는 네트워크도 살펴봅니다. 한 네트워크에 있는 서버는 함께 멈춥니다: Zonemaster는 모든 주소가 하나의 자율 시스템(AS)에 있으면 경고합니다(IPV4_ONE_ASN). 주소마다 여러 지점에서 응답하는 Google, Cloudflare, Akamai 같은 애니캐스트 호스트도 마찬가지입니다. 애니캐스트는 부하를 분산하지만, 운영 주체는 여전히 하나입니다.

  • google.comNS 4개 · 네트워크 1개네트워크 하나
  • github.comNS 8개 · 네트워크 2개분산
  • sidn.nlNS 3개 · 네트워크 2개분산
  • cloudflare.comNS 5개 · 네트워크 1개네트워크 하나
  • nasa.govNS 6개 · 네트워크 1개네트워크 하나
  • example.comNS 2개 · 네트워크 1개네트워크 하나

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

“대부분의 조직 수준 존에는 서버 세 대를 제공하는 것이 권장되며, 그중 적어도 하나는 다른 서버들과 멀리 떨어져 있어야 합니다.” RFC 2182 §5
네임서버 하나에 점 하나이며, 주소를 알리는 네트워크(AS)별로 색을 칠했습니다(2026년 10월 23일에 기록한 실행 결과). 네트워크가 하나뿐이면 애니캐스트든 아니든 Zonemaster의 IPV4_ONE_ASN 경고입니다.

SOA 레코드 값은 올바른가요?

대형 DNS 호스트가 정한 값이라면, 검사 도구가 지적하더라도 거의 확실히 괜찮습니다. 갱신(refresh), 재시도(retry), 만료(expire)는 존 전송으로 존을 복사하는 보조 서버만 조정합니다. 네거티브 TTL(minimum)은 부정 응답 캐싱의 TTL(RFC 2308), 즉 리졸버가 어떤 이름이 존재하지 않는다는 사실을 기억하는 시간입니다.

RIPE-203(1999년)은 갱신 86400, 재시도 7200, 만료 3600000, 네거티브 TTL 172800을 권장하며, 마지막 값은 RFC 2308 이전의 것입니다. Zonemaster의 하한은 더 낮습니다: 갱신 14400과 재시도 3600(알림), 만료 604800(유일한 경고), 네거티브 TTL은 300에서 86400 사이(알림). Cloudflare, Route 53, Azure의 기본값은 갱신과 재시도의 하한보다 낮고, Google Cloud DNS의 3일 만료는 대형 호스트 중 유일한 경고입니다.

갱신Zonemaster 기준 ≥ 4시간 · ◆ 1일재시도Zonemaster 기준 ≥ 1시간 · ◆ 2시간만료Zonemaster 기준 ≥ 7일 · ◆ 41.7일네거티브 TTLZonemaster 기준 5분~1일 · ◆ 2일
Cloudflare2.8시간40분7일30분알림 2건
Amazon Route 532시간15분14일1일알림 2건
Google Cloud DNS6시간1시간3일5분경고 1건
Azure DNS1시간5분28일5분알림 2건
GoDaddy8시간2시간7일1시간통과
Namecheap BasicDNS12시간1시간7일1시간통과
google.com(자체 설정)15분15분30분1분경고 1건 · 알림 3건

Zonemaster 하한 미만통과알림경고RIPE-203(1999년)

각 호스트의 값은 2026년 10월 23일에 그 호스트의 존이 dig로 제공한 값입니다. Cloudflare, Route 53, Google Cloud DNS는 문서와 일치합니다. GoDaddy의 도움말 페이지는 네거티브 TTL을 600이라고 하지만 예시 존은 3600을 제공합니다. Azure DNS와 Namecheap BasicDNS는 공개된 기본값을 찾지 못해 존의 값을 표시했습니다. 1분부터 6주까지의 로그 눈금입니다.

DNSSEC 확인: DS, DNSKEY, 서명

DNSSEC 확인은 신뢰 체인을 따라갑니다: 레지스트리의 DS 레코드는 존에 있는 키(DNSKEY)의 다이제스트여야 하고, 그 키가 존의 키 집합에 서명해야 하며, 모든 서명(RRSIG)이 검증되고 유효 기간 안에 있어야 합니다. 이 검사는 다이제스트를 직접 계산하고 각 서명을 검증한 다음, Google Public DNS에도 검증되는지 묻습니다.

어느 고리든 끊어지면 검증 리졸버가 SERVFAIL로 응답합니다: 그 리졸버를 쓰는 모든 사람에게 도메인이 사라집니다. 일부러 손상된 상태로 유지하는 테스트 존 dnssec-failed.org에서는 두 군데가 동시에 끊어진 모습을 볼 수 있습니다. 알고리즘은 IANA 레지스트리(RFC 9904)로 판단합니다: 8, 13, 15가 권장되며, SHA-1로 서명하는 5와 7은 더 이상 사용해서는 안 되고(RFC 9905) Zonemaster는 오류로 평가합니다.

cloudflare.com검증됨

  1. .com의 DS 2371알고리즘 13 · SHA-256 · 329968…26F2B9
  2. 다이제스트 일치: 키 2371
  3. DNSKEY 2371 · KSK플래그 257 · ECDSA P-256 (13)
  4. 키 집합에 서명 · 61일 중 50.8일 남음
  5. DNSKEY 34505 · ZSK플래그 256 · ECDSA P-256 (13)
  6. 레코드에 서명 · SOA: 2일 중 1일 남음
  7. Google Public DNSAD 플래그 설정: 검증됨

dnssec-failed.org검증 실패

  1. .org의 DS 42069알고리즘 13 · SHA-256
  2. 존에 키 42069 없음
  3. DNSKEY 50719 · KSK존의 실제 키 서명 키
  4. 키 집합 서명이 112일 전에 만료
  5. DNSKEY 32784 · ZSKSOA에 서명: 유효, 7일 중 5.7일 남음
  6. 신뢰할 수 있는 것이 닿지 않음
  7. Google Public DNSSERVFAIL, CD를 설정하면 응답: 검증 실패(bogus)

서명 알고리즘(IANA 레지스트리, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519이것을 사용
  • MAY14 ECDSAP384SHA384 · 16 ED448허용
  • NOT RECOMMENDED10 RSASHA512Zonemaster에서는 WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster에서는 ERROR

위의 두 체인은 모두 13으로 서명

2026년 10월 23일에 기록한 두 체인입니다. cloudflare.com의 체인은 유지되고, dnssec-failed.org의 체인은 DS에서, 그리고 만료된 서명에서 다시 끊어집니다.

메일 DNS: MX, SPF, DMARC

메일 검사는 받는 서버가 읽는 것을 읽습니다: MX 레코드(또는 도메인이 메일을 받지 않는다고 밝히는 null MX, RFC 7505), RFC 7208의 한도인 DNS 조회 10회 안에 드는 SPF 레코드 하나, 그리고 DMARC 정책(2026년 5월에 RFC 7489를 대체한 RFC 9989).

SPF는 찾기만 하는 것이 아니라 평가합니다: 모든 include를 따라가며 셉니다. github.com의 레코드는 정확히 10회의 조회와 1회의 void 조회가 필요합니다: 유효하지만 여유가 없습니다. 메일을 전혀 보내지 않는 도메인은 그렇게 밝혀야 합니다: example.com은 파킹용 세트인 null MX, v=spf1 -all, p=reject를 게시합니다. 자세한 내용은 SPF 레코드 확인과 DMARC 확인에서 더 살펴볼 수 있습니다.

github.com메일 송수신

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 호스트 1개 · 별칭 아님
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~allDNS 조회 10회 중 10회void 조회 2회 중 1회 · 유효, 여유 없음
DMARC
p=quarantine; sp=reject주소 1개로 보고서 전송 · 서브도메인: reject

example.com파킹용 세트

MX
0 .null MX: 메일을 받지 않음(RFC 7505)
SPF
v=spf1 -all메일을 보내지 않음 · 조회 0회
DMARC
p=reject; sp=rejectexample.com 도메인을 사칭하는 것은 모두 거부
2026년 10월 23일 기준으로 게시된 github.com과 example.com의 레코드입니다.

명령줄에서 DNS와 네임서버 확인하기(dig)

dig와 delv를 사용하는 네 단계로 이 검사의 핵심을 재현할 수 있습니다: 루트부터 위임을 따라가기, 재귀 없이 네임서버 하나에 직접 묻기, 레지스트리의 DS와 존의 키 비교하기, 검증 리졸버가 체인을 판단하게 하기.

저희 서버가 보는 것을 보려면 +tcp를 붙이세요. 붙이지 않으면 UDP를 테스트할 수 있는데, 이는 Cloudflare 네트워크의 웹 도구로는 할 수 없는 일입니다. 응답 헤더에서 aa는 권한 있는 응답을 뜻합니다. 레지스트리가 나열한 서버가 REFUSED로 응답하거나 aa 플래그 없이 응답하면 lame 위임입니다.

터미널 · dig 9.20

$ dig +trace +tcp github.com NS
;; (생략)
com.          172800 IN NS a.gtld-servers.net.   ;; h.root-servers.net에서 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; h.gtld-servers.net에서: NS 8개 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; DS 없음: 미서명 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. 루트가 .com을 13대의 서버로 위임합니다
  2. github.com에 대한 레지스트리의 NS 집합, 2일 동안 보관
  3. aa: 캐시가 아닌 권한 있는 응답
  4. SOA: 시리얼 1, 이어서 갱신, 재시도, 만료, 네거티브 TTL
  5. .com에 DS 없음: DNSSEC가 검증할 것이 없음
  6. delv가 루트부터 신뢰 체인을 검증했습니다
github.com과 cloudflare.com의 실제 응답(2026년 10월 23일)을 줄여서 보여 줍니다. 번호 표시는 메모와 대응합니다.

DNS 확인 도구마다 결과가 다른 이유는?

기준으로 삼는 수치가 다르기 때문입니다. 전통적인 검사 도구는 제공업체의 기본값을 지적합니다: intoDNS는 google.com의 만료 1800초를 “NOT OK”라고 하고 github.com의 시리얼 두 개를 오류로 보는데, 이는 DNS 호스트 두 곳을 쓰면 정상입니다. Zonemaster는 시리얼을 경고로 평가하고 null MX를 인식합니다. 저희의 첫 번째 버전은 둘 다 제대로 하지 못했습니다.

또한 네트워크를 보는 위치도 다릅니다. Zonemaster(AFNIC과 스웨덴 인터넷 재단)는 UDP와 TCP, IPv4와 IPv6로 질의합니다. 이 검사는 Cloudflare 엣지에서 실행되어 TCP로만 질의하고, IPv6로 연결하지 않으며, Cloudflare 자체 주소에는 연결할 수 없으므로, 그 서버들은 1.1.1.1을 통해 읽고 해당 검사는 실패가 아니라 테스트 안 함으로 표시합니다. intoDNS 대안으로서, 단순한 OK나 NOT OK 대신 모든 수준의 근거 기준을 보여 줍니다.

사례intoDNSZonemasterDNS Robot v1이 검사
github.comSOA 시리얼 2개(DNS 호스트 2곳)오류“Looks like your nameservers do not agree on the SOA serial.”경고MULTIPLE_SOA_SERIALS실패“Serial mismatch detected: 1656468023 vs 1.”경고설명함: DNS 호스트마다 시리얼 하나
google.comSOA 만료 1,800초부적합“Your SOA EXPIRE number is: 1800. That is NOT OK”경고EXPIRE_MINIMUM_VALUE_LOWER실패“too low (min recommended: 14 days)”경고만료가 영향을 주는 범위와 함께
example.comnull MX(0 .)오류“0 No A Record (no glue either)”정보Z09_VALID_NULL_MX통과“Found 1 MX record(s)”통과null MX 인식
cloudflare.comSOA 재시도 2,400초—인용 없음알림RETRY_MINIMUM_VALUE_LOWER실패“too high (max recommended: 15min)”알림Cloudflare의 기본값
cloudflare.comDNSSEC로 서명됨확인 안 함DNSSEC 테스트 없음통과DNSSEC02 · 05 · 08: 체인 검증됨주의“DNSSEC does not appear to be enabled for this domain.”통과DS → KSK → RRSIG 검증, Google도 검증
같은 도메인을 네 가지 검사 도구로 비교했습니다. intoDNS와 v1의 결과는 2026년 10월 22일 ~ 23일의 페이지와 응답에서 인용했고, Zonemaster의 수준은 테스트 명세에 따른 것입니다. 마지막 열이 이 검사입니다: 각 지적 사항을 근거 기준이 정한 수준으로 평가하는 intoDNS 대안입니다.

DNS 상태 검사: 자주 묻는 질문

DNS 상태 검사란 무엇인가요?

DNS 상태 검사, 즉 DNS 검증은 인터넷 어디에서나 도메인에 접속할 수 있도록 DNS가 설정되어 있는지 테스트합니다: 레지스트리의 위임, 모든 네임서버, SOA 레코드, DNSSEC, 메일 레코드. 각 지적 사항은 피해 정도에 따라 정보부터 심각까지 평가되며, 이 DNS 검증 도구는 적용한 규칙(Zonemaster 테스트 또는 RFC 조항)과 해결 방법을 보여 줍니다.

도메인 검증과 DNS 상태 검사는 같은 것인가요?

항상 그렇지는 않습니다. ‘도메인 검증’은 인증 기관이 DV 인증서를 발급하기 전에 하는 확인이나, 도메인 소유를 증명하기 위해 Google Workspace나 Microsoft 365가 요구하는 TXT 레코드를 가리키기도 합니다. 이 도메인 검증 도구는 도메인의 DNS를 검사합니다: 위임, 네임서버, SOA, DNSSEC, 메일 레코드. 인증서는 SSL 인증서 확인을 이용하세요.

lame 위임이란 무엇이며 어떻게 해결하나요?

lame 위임은 레지스트리에는 나열되어 있지만 여러분의 도메인에 응답하지 않는 네임서버를 말합니다: REFUSED로 응답하거나 권한 없이 응답합니다. 불일치가 있는 쪽에서 고치세요: 그 DNS 호스트에 존을 추가하거나, 등록대행자에서 네임서버를 존이 있는 서버로 변경하세요. 나열된 서버가 모두 lame이면 도메인이 전혀 해석되지 않습니다.

DNS 호스트가 애니캐스트인데 왜 네트워크 하나에 대한 경고가 뜨나요?

운영 주체가 하나면 장애 범위도 하나이기 때문입니다. 애니캐스트는 각 주소가 여러 지점에서 응답하게 해 한 지점의 중단은 막아 주지만, 제공업체 자체의 장애나 설정 실수는 막지 못합니다. 그래서 Zonemaster는 IPV4_ONE_ASN을 경고로 유지하며, RFC 2182도 서로 다른 네트워크에 서버를 두라고 요구합니다. 다른 네트워크에 두 번째 DNS 호스트를 두면 해소됩니다.

SOA 타이머가 지적되었습니다. 바꿔야 하나요?

보통은 아닙니다. 갱신, 재시도, 만료는 존 전송으로 존을 복사하는 보조 서버에만 의미가 있습니다. Cloudflare나 Route 53 같은 대형 호스트는 여러분의 존에 이 값을 쓰지 않으며, 기본값으로 충분합니다. Zonemaster가 경고로 보는 것은 1주 미만의 만료뿐입니다. 주 서버와 보조 서버를 직접 운영하는 경우에만 값을 바꾸세요.

일부 검사가 ‘테스트 안 함’으로 표시되는 이유는?

문제가 있어서가 아니라 저희 서버에서 실행할 수 없었기 때문입니다. 저희 서버는 Cloudflare 네트워크에서 실행되어 Cloudflare 자체 주소에는 연결할 수 없고, TCP로만 질의하며 IPv6로 연결하지 않습니다. 그런 서버는 대신 Cloudflare 리졸버 1.1.1.1을 통해 읽습니다. 테스트 안 함 검사는 등급을 낮추지 않으며, 4분의 1 이상이면 등급에 ‘일부’로 표시됩니다.

네임서버마다 SOA 시리얼이 다른 이유는?

보조 서버가 아직 변경을 따라잡지 못했거나, 도메인이 서로 존을 전송하지 않는 DNS 호스트 두 곳을 써서 각자 자체 시리얼을 유지하기 때문입니다. 후자는 정상입니다: github.com의 Route 53 서버는 1, NS1 서버는 1656468023을 반환합니다. Zonemaster는 어떤 차이든 경고로 표시하며, 저희는 어느 경우인지 설명합니다.

DNSSEC 확인 도구인가요? DNSSEC가 없으면 등급이 낮아지나요?

네. 레지스트리의 DS를 존의 키와 대조하고 모든 서명을 검증한 다음 Google Public DNS에도 묻습니다. 서명되지 않은 존은 Zonemaster 경고 1건(DS07_NOT_SIGNED)이므로 등급은 최대 A에 머뭅니다. 끊어진 체인은 없는 것보다 훨씬 나쁩니다: 검증 리졸버가 도메인을 거부하며, 이 오류로 등급이 C 이하로 떨어집니다.

DNS 상태 검사는 얼마나 자주 해야 하나요?

네임서버, DNSSEC, 메일 레코드를 바꿀 때마다, 그리고 새 DNS 호스트나 등록대행자로 옮기기 전후에 실행하세요. 그 밖에는 한 달에 한 번이면 만료가 다가오는 서명, 응답을 멈춘 네임서버, 직접 하지 않은 레지스트리 변경을 잡아내기에 충분합니다. 결과마다 고유한 링크가 있으므로 실행 결과를 비교할 수 있습니다.

확인한 도메인을 저장하나요?

아니요. 검사는 Cloudflare 엣지에 있는 저희 서버에서 실행되며 루트, 레지스트리, 여러분의 네임서버, Google Public DNS, Cloudflare 리졸버에 질의합니다. 여러분의 주소와 함께 기록하는 것은 없습니다. 끝난 실행 결과는 다시 실행하거나 공유 링크를 열 때 바로 응답할 수 있도록 10분 동안 보관한 뒤 삭제합니다. 여러분의 네임서버는 실행 한 번에 저희 서버로부터 약 20개의 질의를 받습니다.

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

관련 도구