Back

DNS 레코드 분석기

DNS(도메인 이름 시스템) 레코드는 도메인 이름을 IP 주소에 매핑하고 이메일 라우팅을 구성합니다. 이 도구는 dig 또는 BIND의 영역 파일 출력을 파싱하고, 이메일 인증 레코드(SPF, DMARC, DKIM, BIMI)를 분석하며, 일반적인 구성 오류에 대해 경고합니다.

사양

주요 사용 사례

  • 문제 해결을 위한 dig 또는 host 명령 출력 분석
  • 마이그레이션 전 도메인 DNS 구성 감사
  • 이메일 인증 설정 확인 (SPF, DMARC, DKIM)
  • 이메일 전달 문제 디버깅
  • 규정 준수를 위한 도메인 DNS 레코드 문서화
  • SSL 인증서 요청 전 CAA 레코드 확인

기능

  • BIND/dig 영역 파일 출력 파싱
  • A, AAAA, NS, MX, TXT, CNAME, SOA, SRV, CAA, TLSA 레코드 표시
  • 사람이 읽을 수 있는 TTL 형식 (5m, 2h, 1d)
  • 메커니즘 설명과 함께 SPF 레코드 자동 감지 및 분석
  • DMARC 정책 및 보고 구성 분석
  • DKIM 레코드 분석 (키 유형, 셀렉터, 유효성, 테스트 모드)
  • BIMI 레코드 분석 (VMC 존재 여부, 유효성)
  • DNSSEC 지원 (DNSKEY, DS, RRSIG 레코드 및 만료)
  • TLSA/DANE 인증서 고정 표시
  • SPF DNS 조회 수 검증 (RFC 7208에 따라 최대 10회)
  • 이메일 인증 구성 오류 경고

예제

영역 파일 출력

사용해 보기 →

다양한 레코드 유형을 보여주는 dig 출력.

example.com.             300     IN      A       192.0.2.1
example.com.             172800  IN      NS      ns1.example.com.
example.com.             172800  IN      NS      ns2.example.com.
example.com.             300     IN      MX      10 mail.example.com.
example.com.             300     IN      TXT     "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com.      300     IN      TXT     "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

SPF 레코드

사용해 보기 →

Google과 Mailgun의 이메일 발송을 승인하는 SPF 레코드.

v=spf1 include:_spf.google.com include:mailgun.org ip4:192.168.1.0/24 ~all

DMARC 레코드

사용해 보기 →

집계 및 포렌식 보고가 포함된 엄격한 DMARC 정책.

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s; pct=100

팁

  • 모든 레코드 가져오기: dig example.com ANY +noall +answer
  • SPF는 최대 10회 DNS 조회를 허용합니다. "include"를 아껴서 사용하세요.
  • DMARC p=reject가 가장 강력하지만, p=none과 rua 보고로 시작하세요.
  • CAA 레코드는 도메인에 대해 어떤 CA가 인증서를 발급할 수 있는지 제한합니다.
  • TLSA 레코드는 인증서 검증을 위한 DANE을 활성화합니다.

이해하기 DNS 레코드 분석기

도메인 이름 시스템(DNS)은 인터넷의 디렉토리 서비스로, 사람이 읽을 수 있는 도메인 이름을 IP 주소로 변환하고 기타 중요한 매핑을 제공합니다. DNS 레코드는 권한 있는 네임서버의 영역 파일에 저장되며, 각각 이름, 유형, 클래스, TTL(수명), 유형별 데이터를 가집니다.

가장 기본적인 레코드 유형은 이름 확인을 처리합니다. A 레코드는 도메인을 IPv4 주소에 매핑하고, AAAA 레코드는 IPv6에 매핑합니다. CNAME 레코드는 하나의 이름을 다른 이름으로 가리키는 별칭을 생성합니다. NS 레코드는 하위 도메인을 특정 네임서버에 위임합니다. MX 레코드는 우선순위 값과 함께 이메일을 메일 서버로 전달합니다. SOA 레코드는 기본 네임서버와 일련 번호를 포함한 영역 메타데이터를 담습니다.

TXT 레코드는 이메일 인증 데이터를 전달합니다. SPF 레코드(v=spf1 ...)는 승인된 이메일 발신자를 지정합니다. DMARC 레코드(v=DMARC1; ...)는 수신자에게 SPF/DKIM 실패를 처리하는 방법을 알려줍니다. DKIM 레코드는 이메일 서명 검증을 위한 공개 키를 저장합니다. 잘못 구성된 이메일 인증은 전달 문제의 주요 원인입니다.

TTL 값은 리졸버가 응답을 캐시하는 시간을 제어합니다. 높은 TTL(86400초 = 1일)은 DNS 트래픽을 줄이지만 변경 전파가 느립니다. 낮은 TTL(300초 = 5분)은 빠른 업데이트를 가능하게 하지만 쿼리 볼륨이 증가합니다. 마이그레이션 전에 TTL을 미리 낮추면 이전 값이 빨리 만료됩니다.

DNS는 실제로 "전파"라는 용어가 의미하는 방식으로 전파되지 않습니다. 레코드가 변경되면 리졸버는 TTL이 만료될 때까지 캐시된 이전 값을 계속 제공하고, 그 후 권한 있는 서버에서 새 값을 가져옵니다. TTL이 86400(24시간)이었다면 변경이 모든 곳에서 보이기까지 최대 24시간이 걸릴 수 있습니다. 변경을 빠르게 하려면 미리 TTL을 충분히 낮추고(예: 마이그레이션 48시간 전에 300초로), 업데이트를 수행한 후 TTL을 다시 올리세요.

A 레코드는 도메인을 IPv4 주소에 직접 매핑하는 반면, CNAME은 다른 도메인 이름을 가리키는 별칭을 생성합니다. 리졸버는 최종 A 레코드까지 체인을 따릅니다. CNAME은 영역 정점(example.com 같은 기본 도메인)에서 사용할 수 없습니다. 정점에 필요한 SOA 및 NS 레코드와 충돌하기 때문입니다. 일부 DNS 공급자는 이 제한을 해결하기 위해 독자적인 ALIAS 또는 ANAME 레코드 유형을 제공합니다.

이메일 인증 설정은 세 개의 DNS 레코드가 필요합니다. SPF의 경우, "v=spf1" 뒤에 승인된 발신자가 오는 TXT 레코드를 추가합니다. DKIM의 경우, 이메일 서비스에서 제공한 공개 키가 포함된 셀렉터 하위 도메인에 TXT 레코드를 추가합니다. DMARC의 경우, 정책(none, quarantine 또는 reject)과 보고 주소를 지정하여 _dmarc.yourdomain.com에 TXT 레코드를 추가합니다. p=none으로 시작하면 적용 전에 정렬을 모니터링할 수 있습니다. SPF 실패는 일반적으로 10회 DNS 조회 제한 초과, 발신 서비스 승인 누락, 모든 발신자가 확인되기 전에 -all(하드 실패) 사용, 동일 도메인에 여러 SPF 레코드가 있는 경우에 발생합니다. v=spf1 레코드는 하나만 허용되며, 여러 레코드는 영구 오류를 유발합니다.

← 전체 도구로 돌아가기