위임 및 DNS 전체를 진단하는 종합 리포트
DNS 및 레코드
DNS 조회 모든 도메인의 전체 DNS 레코드 A 레코드 조회 도메인의 IPv4 주소 AAAA 레코드 조회 도메인의 IPv6 주소 MX 조회 도메인의 메일 서버 NS 조회 권한 있는 네임 서버 TXT 조회 TXT 레코드, SPF, 인증 CNAME 조회 정규 이름(별칭) 레코드 SOA 조회 Start of Authority 레코드 SRV 조회 서비스 위치 레코드 CAA 조회 어떤 CA가 인증서를 발급할 수 있는지 역방향 DNS (PTR) IP 주소에서 호스트명으로 DNSSEC 점검 도메인이 서명되고 검증되는가? DNS 헬스 체크 위임 및 DNS 전체를 진단하는 종합 리포트이메일 전달성
SPF 점검 Sender Policy Framework 레코드 검증 DMARC 점검 DMARC 정책 검사 및 등급 평가 DKIM 점검 DKIM 공개 키 찾기 및 검증 블랙리스트 점검 이메일 차단 목록(DNSBL)에 대해 IP 점검 SMTP 테스트 메일 서버에 연결하여 STARTTLS 점검 MTA-STS 점검 수신 메일에 대한 강제 TLS 정책 BIMI 점검 이메일용 브랜드 로고 레코드 TLS-RPT 점검 SMTP TLS 보고 정책네트워크 및 웹
SSL 인증서 점검 사이트의 TLS 인증서 및 만료 검사 HTTP 헤더 점검 응답 헤더, 리디렉션 및 보안 검사 핑 (TCP) TCP를 통한 도달성 및 지연 시간 포트 점검 어떤 일반 포트가 열려 있는지도메인
WHOIS 조회 도메인, IP 및 ASN의 등록 데이터DNS 헬스 체크는 단일 레코드 유형만이 아니라 도메인이 어떻게 위임되고 구성되어 있는지를 처음부터 끝까지 점검합니다. 먼저 상위(TLD) 서버에 도메인에 대해 무엇을 게시하는지 묻고, 그다음 사용자의 네임서버에 직접 질의해 둘을 비교합니다. 상위와 사용자의 서버 사이의 불일치 — glue 누락, NS 목록 불일치, 동기화되지 않은 SOA 시리얼, lame 또는 개방형 재귀 네임서버 — 가 바로 DNS를 느리거나 간헐적이거나 소리 없이 고장 나게 만드는 문제들입니다. IPeek는 모든 검사를 실행하고 각 항목이 왜 중요한지, 어떻게 고치는지를 알기 쉬운 말로 알려 줍니다.
도메인에 대한 모든 조회는 상위 영역 — TLD 레지스트리(예: .kr 또는 .com) — 에서 시작되며, 이곳은 리졸버를 사용자의 네임서버로 안내하는 NS 레코드를 보관합니다. 그 네임서버가 사용자 자신의 도메인 안에 있다면 상위는 그 IP 주소도 "glue"로 게시해야 하며, 그렇지 않으면 리졸버는 닭과 달걀의 순환에 빠집니다. 건강한 위임은 상위와 사용자의 서버가 동일한 NS 집합에 일치하고, 필요한 곳에 glue가 있는 상태입니다. 둘이 일치하지 않으면 일부 리졸버는 오래된 정보를 따르게 되어 변경 사항이 일부 사용자에게는 적용되고 다른 사용자에게는 적용되지 않는 것처럼 보입니다.
RFC 2182는 단일 장애가 도메인을 오프라인으로 만들지 않도록 서로 다른 네트워크에 여러 네임서버를 둘 것을 권장합니다. 각 서버는 사용자의 영역에 대해 권한 있게 응답해야 하며, 그렇지 못한 "lame" 서버는 소리 없는 신뢰성 구멍입니다. 권한 네임서버는 또한 낯선 이의 재귀를 거부해야 합니다. 개방형 재귀 네임서버는 캐시 포이즈닝과 DDoS 증폭에 악용될 수 있습니다. IPeek는 사용자의 각 네임서버에 직접 질의해 응답 여부, 권한 있는 응답 여부, 서로 간의 일치, TCP 지원, 그리고 재귀가 닫혀 있는지를 확인합니다.
SOA 레코드는 영역의 시리얼 번호와 타이밍 값을 담고 있습니다. 모든 네임서버가 동일한 시리얼을 보고해야 하며, 그렇지 않으면 영역이 동기화되지 않아 변경 사항이 고르지 않게 전파됩니다. 시리얼은 YYYYMMDDnn 관례를 따라야 하고, refresh/retry/expire/minimum 타이머는 RFC 권장 범위 안에 있어야 합니다. 메일 측에서는 MX 레코드가 공인 주소로 확인되는 호스트명이어야 하며, 단독 IP나 CNAME이어서는 안 됩니다. 마지막으로 apex(도메인 자체)는 주소를 게시하되 CNAME은 게시하지 않아야 하며, RFC 1912는 다른 레코드와 함께 있는 CNAME을 금지합니다.
DNS 조회는 재귀 리졸버를 통해 보이는 레코드를 보여 줍니다. 헬스 체크는 한 걸음 더 나아가 상위 TLD 서버와 사용자의 각 네임서버에 직접 질의한 뒤 둘을 비교합니다. 덕분에 일반 조회가 감추는 위임 문제 — glue 누락, 상위/하위 NS 불일치, lame 또는 서로 다른 응답을 하는 네임서버, 동기화되지 않은 SOA 시리얼 — 를 잡아낼 수 있습니다.
glue는 네임서버의 IP 주소로, 상위 영역이 NS 레코드와 함께 게시합니다. 네임서버가 자신이 서비스하는 도메인과 같은 도메인 안에 있을 때(예: example.com을 서비스하는 ns1.example.com) 필수인데, 그렇지 않으면 리졸버는 무언가를 확인하기 전에 먼저 그 네임서버를 확인해야 하기 때문입니다. 이 경우 glue가 없으면 확인이 깨집니다. 네임서버가 다른 도메인에 있다면 glue는 선택 사항이며 조회 한 번을 줄여 줄 뿐입니다.
권한 네임서버는 자신이 호스팅하는 영역에 대해서만 응답해야 합니다. 누구에게나 재귀를 수행하는 네임서버("개방형 리졸버")는 DNS 증폭 DDoS 공격에 악용될 수 있고 캐시 포이즈닝에 더 노출됩니다. 헬스 체크가 개방형 재귀를 표시하면 권한 서버에서 재귀를 비활성화하거나, 권한 역할과 재귀 역할을 서로 다른 호스트로 분리하세요.
SOA 시리얼은 영역의 버전 번호입니다. 네임서버들이 서로 다른 시리얼을 보고하면 최소한 하나는 오래된 데이터를 제공하고 있다는 뜻이며, 보통 기본 서버에서 최신 영역을 전송받지 못한 보조 서버입니다. 그 결과 리졸버가 어느 서버에 닿느냐에 따라 응답이 달라집니다. 영역 전송(AXFR/IXFR), 기본 서버의 NOTIFY 설정, SOA refresh 타이머를 확인하세요.
둘 다 오류는 아니지만 모두 단일 장애 지점입니다. MX가 하나면 그 서버가 충분히 오래 다운될 경우 메일이 유실될 수 있으며, 백업 MX가 복원력을 더해 줍니다. 네임서버 둘은 RFC 2182상 허용되지만, 서로 다른 네트워크에 셋 이상 두는 편이 더 안전합니다. 헬스 체크는 이를 실패가 아닌 경고로 표시합니다. 응급 상황이 아니라 개선할 가치가 있는 항목입니다.