DNS 완전 정복: 네임서버, DDNS, nslookup 실전 가이드 — 도메인 등록부터 트러블슈팅까지

사용자 입력: www.example.com
     ↓
DNS Resolution
     ↓
IP 주소: 93.184.216.34
     ↓
서버에 HTTP 요청

          .  (Root)
         / \
      com   org   net   kr   jp  ...   (TLD - Top Level Domain)
       |
    example                             (SLD - Second Level Domain)
     / \
   www  mail  api                       (Subdomain)

[사용자 PC] → 재귀적 쿼리 → [재귀 리졸버 (ISP/8.8.8.8)]
                                    |
                              반복적 쿼리 시작
                                    |
                    ┌───────────────┼───────────────┐
                    ↓               ↓               ↓
             [Root Server]   [TLD Server]   [Authoritative NS]
             "com은 여기"    "example.com     "IP는 93.x.x.x"
                             은 여기"

[브라우저 캐시] → [OS 캐시] → [재귀 리졸버 캐시] → [각 네임서버 응답의 TTL]

Chrome: chrome://net-internals/#dns 에서 확인 가능
Windows: ipconfig /displaydns
Linux: systemd-resolve --statistics
macOS: sudo dscacheutil -flushcache

example.com.    3600    IN    A    93.184.216.34
                 ↑
              TTL = 3600초 (1시간)

[Primary NS] ──Zone Transfer──→ [Secondary NS]
  (읽기/쓰기)                     (읽기 전용)

  원본 존 파일 관리                Primary 장애 시 백업
  레코드 추가/수정/삭제            부하 분산 역할

# AXFR 테스트 (보안상 외부에서는 차단되어야 함)
dig @ns1.example.com example.com AXFR

# SOA 레코드의 Serial로 동기화 여부 확인
dig @ns1.example.com example.com SOA +short
# 2024032301 ns1.example.com. admin.example.com. ...

Q: example.com의 IP는?
→ example.com의 네임서버는 ns1.example.com
→ ns1.example.com의 IP는?
→ example.com의 네임서버에게 물어봐야 하는데...
→ 순환 참조 발생!

;; .com TLD 서버의 위임 레코드
example.com.    IN    NS    ns1.example.com.
example.com.    IN    NS    ns2.example.com.

;; 글루 레코드 (Additional Section)
ns1.example.com.    IN    A    203.0.113.1
ns2.example.com.    IN    A    203.0.113.2

# CoreDNS Corefile 예시
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}

# Pod에서 서비스 접근 시
my-service                          → my-service.default.svc.cluster.local
my-service.other-ns                 → my-service.other-ns.svc.cluster.local
my-service.other-ns.svc.cluster.local → 완전한 FQDN

# Pod의 /etc/resolv.conf
nameserver 10.96.0.10          # CoreDNS ClusterIP
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5                # 점(.) 5개 미만이면 search 도메인 추가

# OK - 서브도메인에 CNAME
www.example.com.    IN    CNAME    example.com.

# BAD - 루트 도메인(Apex)에 CNAME 사용 불가!
# example.com.       IN    CNAME    other.com.    (RFC 위반)

# 해결: ALIAS/ANAME (비표준) 또는 Cloudflare의 CNAME Flattening

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"

$TTL 3600
$ORIGIN example.com.

@       IN  SOA   ns1.example.com. admin.example.com. (
                  2026032301  ; Serial (YYYYMMDDNN)
                  3600        ; Refresh (1시간)
                  900         ; Retry (15분)
                  1209600     ; Expire (2주)
                  86400       ; Minimum TTL (1일)
                  )

; 네임서버
@       IN  NS    ns1.example.com.
@       IN  NS    ns2.example.com.

; A 레코드
@       IN  A     203.0.113.10
www     IN  A     203.0.113.10
api     IN  A     203.0.113.20

; AAAA 레코드
@       IN  AAAA  2001:db8::10

; CNAME
blog    IN  CNAME example.github.io.
docs    IN  CNAME readthedocs.io.

; MX 레코드 (우선순위 낮은 숫자가 높은 우선순위)
@       IN  MX    10 mail.example.com.
@       IN  MX    20 mail2.example.com.
mail    IN  A     203.0.113.30

; TXT 레코드
@       IN  TXT   "v=spf1 include:_spf.google.com -all"
_dmarc  IN  TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; SRV 레코드
_sip._tcp  IN  SRV  10 60 5060 sip.example.com.

; CAA 레코드
@       IN  CAA   0 issue "letsencrypt.org"
@       IN  CAA   0 issuewild "letsencrypt.org"

[ICANN] ──관리──→ [레지스트리] ──위임──→ [레지스트라] ──판매──→ [리셀러]
                  (Verisign 등)        (가비아, Namecheap 등)    (호스팅 업체 등)

레지스트리(Registry): TLD 전체를 관리 (예: .com은 Verisign)
레지스트라(Registrar): ICANN 인가를 받아 도메인 등록을 대행
리셀러(Reseller): 레지스트라의 재판매 파트너

1. 현재 레지스트라에서 Transfer Lock(도메인 잠금) 해제
2. Auth Code(인증 코드 / EPP 코드) 발급
3. 새 레지스트라에서 Transfer 신청 + Auth Code 입력
4. 기존 레지스트라의 승인 메일 확인 (5~7일 대기)
5. 이전 완료 후 DNS 설정 확인

주의사항:
- 등록/이전 후 60일간 재이전 불가 (ICANN 60-Day Lock)
- 만료 15일 이내의 도메인은 이전 불가
- .kr 도메인은 별도 절차 (KISA 규정)

# Whois 조회
whois example.com

# RDAP (Whois 후속, JSON 기반)
curl -s "https://rdap.verisign.com/com/v1/domain/example.com" | jq .

문제:
  집 서버 IP: 211.xxx.xxx.100 (어제)
  집 서버 IP: 211.xxx.xxx.200 (오늘) ← IP 변경됨!

  DNS: myserver.example.com → 211.xxx.xxx.100 (어제 등록)
  → 접속 불가!

해결 (DDNS):
  IP 변경 감지 → 자동으로 DNS 레코드 업데이트
  myserver.example.com → 211.xxx.xxx.200 (자동 갱신)

# 설치
sudo apt install ddclient

# /etc/ddclient.conf 설정 (Cloudflare 예시)
protocol=cloudflare
use=web, web=https://api.ipify.org
zone=example.com
login=your-email@example.com
password=your-cloudflare-api-token
myserver.example.com

# 서비스 시작
sudo systemctl enable ddclient
sudo systemctl start ddclient

# 상태 확인
sudo systemctl status ddclient
sudo ddclient -query

#!/bin/bash
# cloudflare-ddns.sh

# 설정
CF_API_TOKEN="your-api-token-here"
CF_ZONE_ID="your-zone-id-here"
CF_RECORD_NAME="myserver.example.com"
CF_RECORD_ID="your-record-id-here"

# 현재 공인 IP 확인
CURRENT_IP=$(curl -s https://api.ipify.org)

# DNS에 등록된 IP 확인
DNS_IP=$(dig +short "$CF_RECORD_NAME" @1.1.1.1)

# IP가 변경되었으면 업데이트
if [ "$CURRENT_IP" != "$DNS_IP" ]; then
    echo "IP changed: $DNS_IP -> $CURRENT_IP"

    curl -s -X PUT \
        "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/dns_records/$CF_RECORD_ID" \
        -H "Authorization: Bearer $CF_API_TOKEN" \
        -H "Content-Type: application/json" \
        --data "{\"type\":\"A\",\"name\":\"$CF_RECORD_NAME\",\"content\":\"$CURRENT_IP\",\"ttl\":60,\"proxied\":false}"

    echo "DNS updated successfully"
else
    echo "IP unchanged: $CURRENT_IP"
fi

# crontab에 등록 (5분마다 실행)
crontab -e
# */5 * * * * /home/user/cloudflare-ddns.sh >> /var/log/ddns.log 2>&1

# docker-compose.yml
version: '3'
services:
  cloudflare-ddns:
    image: oznu/cloudflare-ddns:latest
    restart: always
    environment:
      - API_KEY=your-cloudflare-api-token
      - ZONE=example.com
      - SUBDOMAIN=myserver
      - PROXIED=false
      - RRTYPE=A
      - DELETE_ON_STOP=false
      - DNS_SERVER=1.1.1.1

docker-compose up -d

[인터넷] → [공유기 포트포워딩] → [Nginx Proxy Manager] → [서비스들]
                                        |
                                  Let's Encrypt
                                  자동 SSL 발급

# docker-compose.yml - 홈서버 스택
version: '3'
services:
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81' # 관리 패널
    volumes:
      - ./npm-data:/data
      - ./npm-letsencrypt:/etc/letsencrypt

  cloudflare-ddns:
    image: oznu/cloudflare-ddns:latest
    restart: always
    environment:
      - API_KEY=your-cf-token
      - ZONE=example.com
      - SUBDOMAIN=home

공유기 설정:
  외부 80 → 내부 192.168.1.100:80
  외부 443 → 내부 192.168.1.100:443

Linux 방화벽 (UFW):
  sudo ufw allow 80/tcp
  sudo ufw allow 443/tcp
  sudo ufw enable

# 기본 조회
nslookup example.com
# Server:  8.8.8.8
# Address: 8.8.8.8#53
#
# Non-authoritative answer:
# Name:    example.com
# Address: 93.184.216.34

# 특정 DNS 서버로 조회
nslookup example.com 1.1.1.1

# MX 레코드 (메일 서버)
nslookup -type=mx gmail.com
# gmail.com  mail exchanger = 5 gmail-smtp-in.l.google.com.
# gmail.com  mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.

# AAAA 레코드 (IPv6)
nslookup -type=aaaa google.com

# TXT 레코드 (SPF, DKIM 등)
nslookup -type=txt example.com

# NS 레코드 (네임서버)
nslookup -type=ns example.com

# SOA 레코드 (존 정보)
nslookup -type=soa example.com

# CAA 레코드 (인증서 발급 권한)
nslookup -type=caa example.com

# SRV 레코드 (서비스 위치)
nslookup -type=srv _sip._tcp.example.com

# ANY (모든 레코드 - 일부 서버는 차단)
nslookup -type=any example.com

nslookup
> server 8.8.8.8          # DNS 서버 변경
> set type=mx              # 레코드 타입 설정
> gmail.com                # 조회
> set type=txt
> example.com
> set debug                # 디버그 모드 ON
> example.com              # 상세 정보 출력
> set d2                   # 더 상세한 디버그
> exit

# IP → 도메인 조회
nslookup 8.8.8.8
# 8.8.8.8.in-addr.arpa  name = dns.google.

nslookup 1.1.1.1
# 1.1.1.1.in-addr.arpa  name = one.one.one.one.

# 1. 특정 도메인의 네임서버 확인
nslookup -type=ns example.com

# 2. 메일 서버 확인 (이메일 문제 디버깅)
nslookup -type=mx company.com

# 3. SPF 레코드 확인 (이메일 스팸 문제)
nslookup -type=txt example.com

# 4. Google DNS vs Cloudflare DNS 비교
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# 5. IPv6 주소 확인
nslookup -type=aaaa facebook.com

# 6. 와일드카드 서브도메인 테스트
nslookup nonexistent-sub.example.com

# 7. CAA 레코드 확인 (SSL 인증서 발급 전)
nslookup -type=caa example.com

# 8. 역방향 DNS 확인 (IP 소유자 파악)
nslookup 203.0.113.1

# 9. CNAME 체인 추적
nslookup -type=cname www.example.com

# 10. SOA 레코드로 DNS 관리자 확인
nslookup -type=soa example.com

# 기본 조회
dig example.com

# 출력 구조:
# ;; QUESTION SECTION:    ← 질문
# ;example.com.           IN  A
#
# ;; ANSWER SECTION:      ← 응답
# example.com.      3600  IN  A  93.184.216.34
#
# ;; AUTHORITY SECTION:   ← 권한 있는 네임서버
# example.com.      3600  IN  NS  a.iana-servers.net.
#
# ;; ADDITIONAL SECTION:  ← 추가 정보
# a.iana-servers.net. 3600 IN  A  199.43.135.53
#
# ;; Query time: 23 msec
# ;; SERVER: 8.8.8.8#53(8.8.8.8)

# 짧은 출력 (IP만)
dig +short example.com
# 93.184.216.34

# 특정 레코드 타입
dig example.com MX
dig example.com AAAA
dig example.com TXT
dig example.com NS
dig example.com SOA
dig example.com CAA

# 특정 DNS 서버 지정
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# 응답 시간만 확인
dig example.com | grep "Query time"
# ;; Query time: 23 msec

# DNS 해석 전체 과정을 Root부터 추적
dig +trace example.com

# 출력 (요약):
# .                   518400  IN  NS  a.root-servers.net.  ← Root
# com.                172800  IN  NS  a.gtld-servers.net.  ← TLD
# example.com.         86400  IN  NS  a.iana-servers.net.  ← Authoritative
# example.com.          3600  IN  A   93.184.216.34        ← 최종 답

# DNSSEC 서명 정보 확인
dig +dnssec example.com

# DNSSEC 유효성 검증
dig +sigchase +trusted-key=/etc/trusted-key.key example.com

# DNSSEC 관련 레코드 직접 조회
dig example.com DNSKEY
dig example.com DS
dig example.com RRSIG
dig example.com NSEC

# domains.txt 파일의 모든 도메인 한 번에 조회
cat domains.txt
# example.com
# google.com
# github.com

dig -f domains.txt +short

# 특정 레코드 타입으로 배치 조회
dig -f domains.txt MX +short

# TCP 모드로 조회 (UDP 대신)
dig +tcp example.com

# 응답의 특정 섹션만 출력
dig +noall +answer example.com    # 응답만
dig +noall +authority example.com  # 권한 섹션만
dig +noall +stats example.com     # 통계만

# TTL 포함 축약 출력
dig +nocmd +noall +answer +ttlid example.com

# 역방향 조회
dig -x 8.8.8.8
# 8.8.8.8.in-addr.arpa.  IN  PTR  dns.google.

# CHAOS 클래스로 DNS 서버 버전 확인
dig @ns1.example.com version.bind CHAOS TXT

# EDNS Client Subnet 테스트
dig +subnet=203.0.113.0/24 example.com @8.8.8.8

# 1. 특정 네임서버에서 권한 있는 응답 확인
dig @ns1.example.com example.com +norecurse

# 2. DNS 전파 확인 (여러 DNS 서버 비교)
for dns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo "=== $dns ==="
  dig @$dns example.com +short
done

# 3. CNAME 체인 전체 추적
dig +trace +nodnssec www.example.com CNAME

# 4. MX 레코드 우선순위 확인
dig example.com MX +short | sort -n

# 5. SPF 레코드 확인
dig example.com TXT +short | grep spf

# 6. DKIM 레코드 확인
dig selector1._domainkey.example.com TXT +short

# 7. DMARC 정책 확인
dig _dmarc.example.com TXT +short

# 8. CAA 레코드 확인 (SSL 발급 전)
dig example.com CAA +short

# 9. SOA 레코드의 시리얼 번호 확인 (존 전송 동기화)
dig example.com SOA +short

# 10. 응답 시간 비교 (DNS 성능 테스트)
for i in $(seq 1 10); do
  dig example.com @8.8.8.8 | grep "Query time"
done

# 11. IPv6 레코드 확인
dig example.com AAAA +short

# 12. 와일드카드 DNS 확인
dig random-subdomain.example.com +short

# 13. NSEC/NSEC3 레코드로 DNSSEC 부정 존재 증명
dig nonexistent.example.com NSEC

# 14. DNS 응답 크기 확인 (DDoS 증폭 테스트)
dig example.com ANY +bufsize=4096

# 15. 전체 존 내보내기 시도 (보안 감사)
dig @ns1.example.com example.com AXFR

정상: 리졸버 → Authoritative NS → 정확한 IP
공격: 공격자가 가짜 응답을 리졸버 캐시에 주입
결과: 사용자가 피싱 사이트로 유도됨

방어: DNSSEC, 랜덤 소스 포트, 0x20 인코딩

공격 방식:
1. 공격자가 피해자 IP로 소스 주소를 위조 (IP Spoofing)
2. 오픈 리졸버에 큰 응답을 유발하는 쿼리 전송 (ANY 타입)
3. 작은 쿼리 → 큰 응답 = 증폭 효과 (50~70배)
4. 모든 응답이 피해자에게 집중

방어: BCP38(소스 주소 검증), RRL(Response Rate Limiting)

방식 1: 라우터/ISP 수준에서 DNS 응답 변조
방식 2: 레지스트라 계정 탈취 → 네임서버 변경
방식 3: 악성코드가 시스템 DNS 설정 변경

방어: DNSSEC, 레지스트라 계정 2FA, DNS 모니터링

목적: DNS 프로토콜을 악용하여 데이터 유출/원격 제어
방식: DNS 쿼리/응답에 인코딩된 데이터를 숨김

예: malicious-data.encoded.evil.com 으로 TXT 쿼리
→ 방화벽은 정상 DNS 트래픽으로 인식

방어: DNS 쿼리 길이/빈도 모니터링, DNS 방화벽

신뢰의 체인 (Chain of Trust):
  Root (.) → .com → example.com

  각 레벨에서:
  1. DNSKEY: 존의 공개키
  2. RRSIG: 각 레코드의 전자 서명
  3. DS: 하위 존의 공개키 해시 (상위 존에 저장)
  4. NSEC/NSEC3: "이 이름은 존재하지 않음"의 증명

# DNSSEC 검증 확인
dig +dnssec example.com

# 응답에 'ad' 플래그가 있으면 DNSSEC 검증 성공
# flags: qr rd ra ad; QUERY: 1, ANSWER: 2

# DNSKEY 조회
dig example.com DNSKEY +short

# DS 레코드 조회 (상위 존에서)
dig example.com DS +short

# DoH로 DNS 조회 (curl)
curl -s -H "accept: application/dns-json" \
  "https://1.1.1.1/dns-query?name=example.com&type=A" | jq .

# DoH 서비스
# Cloudflare: https://1.1.1.1/dns-query
# Google: https://dns.google/dns-query
# Quad9: https://dns.quad9.net/dns-query

# DoT 테스트 (kdig 사용)
kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com

[디바이스] → [DNS 필터] → [허용된 쿼리만 통과] → [인터넷]
                 |
           광고/악성 도메인 차단
           트래커 차단
           성인 콘텐츠 필터링

RPZ (Response Policy Zone):
  DNS 방화벽에서 특정 도메인에 대한 응답을 재정의하는 기술

예시 (BIND RPZ):
; rpz.db
evil-domain.com        CNAME  .           ; NXDOMAIN 응답
malware-c2.com         CNAME  .           ; 차단
phishing-site.com      A      10.0.0.1    ; 경고 페이지로 리다이렉트

# 진단
# 1. 권한 있는 네임서버에서 직접 확인 (이것이 되면 설정은 정상)
dig @ns1.your-dns-provider.com yourdomain.com A +short

# 2. 여러 공개 DNS로 전파 상태 확인
dig @8.8.8.8 yourdomain.com +short
dig @1.1.1.1 yourdomain.com +short
dig @9.9.9.9 yourdomain.com +short

# 3. 온라인 도구로 전 세계 전파 확인
# https://www.whatsmydns.net/

# 진단: CAA 레코드 확인
dig yourdomain.com CAA +short
# 0 issue "digicert.com"   ← Let's Encrypt가 허용 목록에 없음!

# 해결: CAA 레코드 추가 또는 수정
# yourdomain.com. IN CAA 0 issue "letsencrypt.org"
# yourdomain.com. IN CAA 0 issuewild "letsencrypt.org"

# CAA 레코드가 없으면 모든 CA가 발급 가능 (기본값)
dig yourdomain.com CAA +short
# (빈 응답 = 제한 없음)

# 진단 1: SPF 레코드 확인
dig yourdomain.com TXT +short | grep spf
# "v=spf1 include:_spf.google.com -all"

# 진단 2: DKIM 레코드 확인 (selector는 이메일 헤더에서 확인)
dig google._domainkey.yourdomain.com TXT +short

# 진단 3: DMARC 정책 확인
dig _dmarc.yourdomain.com TXT +short
# "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

# 해결 체크리스트:
# 1. SPF에 메일 발송 서버 IP/도메인 포함 확인
# 2. DKIM 서명 키 등록 확인
# 3. DMARC 정책 설정 (처음엔 p=none으로 모니터링)
# 4. DMARC 보고서 분석 후 p=quarantine → p=reject 순서로 강화

# 진단: 해당 서브도메인 레코드 존재 여부 확인
dig staging.example.com A +short
# (빈 응답 = 레코드 없음)

dig api.example.com A +short
# 203.0.113.20  (정상)

# 와일드카드 레코드 확인
dig *.example.com A +short

# 진단: 각 DNS 서버의 캐시 상태 확인
dig @8.8.8.8 example.com +short    # Google DNS
dig @1.1.1.1 example.com +short    # Cloudflare DNS
dig @168.126.63.1 example.com +short  # KT DNS

# TTL 확인
dig example.com | grep -A1 "ANSWER SECTION"
# example.com.  1800  IN  A  203.0.113.10
#                ↑ 남은 TTL이 아직 높음

# 진단 1: hosts 파일 확인
cat /etc/hosts          # Linux/macOS
type C:\Windows\System32\drivers\etc\hosts  # Windows

# 진단 2: 브라우저 DNS 캐시 확인
# Chrome: chrome://net-internals/#dns → Clear host cache

# 진단 3: HSTS 문제 확인
# Chrome: chrome://net-internals/#hsts
# 도메인 삭제 후 재시도

# 진단 4: 프록시/VPN 설정 확인
# 브라우저 프록시 설정이 DNS를 우회할 수 있음

# 진단 5: DNS over HTTPS 설정 확인
# Chrome 설정 → 개인 정보 보호 및 보안 → 보안 DNS 사용

# 진단: 현재 네임서버 확인
dig example.com NS +short
# 이전 레지스트라의 네임서버가 보이면 아직 업데이트 안 됨

# 해결 순서:
# 1. 새 레지스트라에서 DNS 레코드를 먼저 설정
# 2. 이전 전에 모든 레코드를 새 곳에 복제
# 3. 네임서버 변경
# 4. 이전 네임서버는 최소 48시간 유지

# 진단 1: Pod 내에서 DNS 해석 테스트
kubectl exec -it debug-pod -- nslookup api.external.com

# 진단 2: resolv.conf 확인
kubectl exec -it debug-pod -- cat /etc/resolv.conf
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.local
# options ndots:5

# 진단 3: CoreDNS 로그 확인
kubectl logs -n kube-system -l k8s-app=kube-dns

# 문제: ndots:5 때문에 api.external.com (점 2개)이
# api.external.com.default.svc.cluster.local 등을 먼저 시도

# 방법 1: FQDN 사용 (마지막에 점 추가)
# 코드에서 api.external.com. 으로 호출

# 방법 2: Pod의 dnsConfig 설정
apiVersion: v1
kind: Pod
spec:
  dnsConfig:
    options:
      - name: ndots
        value: '2'

# 진단: 프록시되지 않는 레코드 확인
# Cloudflare 대시보드에서 주황색 구름(프록시 활성)이 아닌
# 회색 구름(DNS Only) 레코드가 있는지 확인

# 서브도메인 스캔으로 노출 여부 확인
dig direct.example.com +short     # 원본 IP 노출?
dig mail.example.com +short       # MX용 A레코드에 원본 IP?
dig ftp.example.com +short        # FTP 서브도메인에 원본 IP?

# 진단 1: 현재 공인 IP 확인
curl -s https://api.ipify.org

# 진단 2: DNS에 등록된 IP 확인
dig myserver.example.com +short

# 진단 3: DDNS 클라이언트 로그 확인
sudo journalctl -u ddclient -n 50

# 진단 4: API 토큰 유효성 확인
curl -s -X GET "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  -H "Authorization: Bearer YOUR_TOKEN" | jq .

# 일반적인 원인:
# 1. API 토큰 만료 또는 권한 부족
# 2. Zone ID 또는 Record ID 오류
# 3. 방화벽이 DDNS 클라이언트의 외부 통신 차단
# 4. cron 작업이 비활성화됨
# 5. IP 확인 서비스(ipify 등) 접속 불가