DNS 내부: 주소창에 google.com을 치면?

                    . (Root)
                   /    \
              .com      .kr
             /    \       \
        google   naver   go.kr
         /
       www

사용자 브라우저
    │
    ▼ ① naver.com?
OS Stub Resolver (로컬 캐시 확인)
    │  캐시 miss
    ▼ ② naver.com?
Local DNS (ISP/사내 Resolver)
    │  캐시 miss
    ▼ ③ .com이 어디에?      → Root Server (전세계 13 클러스터)
    ▼ ④ naver.com이 어디에? → .com TLD Server
    ▼ ⑤ naver.com A 레코드?  → Naver Authoritative NS
    │
    ▼ ⑥ 223.130.195.200 (TTL=300)
사용자 브라우저
    │
    ▼ TCP 연결 시작

# CNAME은 다른 레코드와 공존할 수 없음
# ❌ 잘못된 설정
example.com   CNAME  lb.example.com
example.com   MX     mail.example.com    # CNAME과 충돌!

# ✅ 올바른 설정 — Zone Apex(루트 도메인)에는 A/AAAA 사용
example.com   A      203.0.113.10
example.com   MX     mail.example.com
www.example.com  CNAME  example.com       # 서브도메인은 CNAME OK

[평상시]    example.com  A  1.1.1.1  TTL=3600
                ↓
[배포 24시간 전]  TTL을 60으로 낮춤 (기존 캐시가 만료되길 기다림)
                ↓
[배포 시점]    IP를 2.2.2.2로 변경 → 60초 내 전파
                ↓
[안정 확인 후]  TTL을 다시 3600으로 올림

1. 브라우저 캐시 (chrome://net-internals/#dns)
2. OS 캐시 (macOS: scutil --dns, Linux: systemd-resolved)
3. 로컬 DNS 서버 캐시 (ISP/사내 Resolver)
4. 중간 Resolver 캐시 (Cloudflare 1.1.1.1, Google 8.8.8.8)

[질의] example.com A?

[DNSSEC 응답]
  example.com   A     93.184.216.34
  example.com   RRSIG A  (서명값: Zone Signing Key로 서명)

  ↑ 이 서명을 검증하려면
    example.com   DNSKEY  (Zone Signing Key 공개키)
    example.com   DS      (Key Signing Key의 해시 — 상위 Zone에 등록됨)

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

# 응답에 "ad" 플래그가 있으면 DNSSEC 검증 통과
;; flags: qr rd ra ad;
#                    ^^ Authenticated Data

# DoH로 질의 (Cloudflare)
curl -s 'https://1.1.1.1/dns-query?name=google.com&type=A' \
  -H 'Accept: application/dns-json' | jq

# 응답
{
  "Answer": [
    { "name": "google.com", "type": 1, "TTL": 187, "data": "142.250.206.206" }
  ]
}

# Docker 컨테이너 내부
cat /etc/resolv.conf
# nameserver 127.0.0.11   ← Docker 내장 DNS 서버

# 같은 네트워크의 다른 컨테이너를 이름으로 접근
curl http://redis:6379

# ❌ 흔한 실수 — 서비스 시작 순서와 DNS 해석 시점
services:
  app:
    depends_on:
      - db
    environment:
      DB_HOST: db   # db 컨테이너가 아직 ready가 아닐 수 있음

# Pod 내부
cat /etc/resolv.conf
# nameserver 10.96.0.10        ← kube-dns/CoreDNS ClusterIP
# search default.svc.cluster.local svc.cluster.local cluster.local
# ndots: 5

# 같은 네임스페이스
curl http://order-service:8080

# 전체 FQDN
curl http://order-service.production.svc.cluster.local:8080

# 해석 순서 (ndots=5일 때, 점이 5개 미만이면 search 도메인을 먼저 시도)
order-service
  → order-service.default.svc.cluster.local (1차)
  → order-service.svc.cluster.local          (2차)
  → order-service.cluster.local              (3차)
  → order-service                            (최종 — 외부 DNS)

api.stripe.com.default.svc.cluster.local     (NXDOMAIN)
api.stripe.com.svc.cluster.local              (NXDOMAIN)
api.stripe.com.cluster.local                  (NXDOMAIN)
api.stripe.com                                (성공!)

# Pod spec에서 ndots 조정
spec:
  dnsConfig:
    options:
      - name: ndots
        value: "2"   # 점이 2개 이상이면 search 도메인 건너뜀

// FQDN 명시 (마지막 . 이 있으면 search 도메인 시도 안 함)
String stripeApi = "api.stripe.com.";

한국 사용자 → DNS 질의 → GSLB
  └─ Source IP: 203.0.113.x (한국 ISP)
  └─ 응답: 서울 리전 IP (1.1.1.1)

미국 사용자 → DNS 질의 → GSLB
  └─ Source IP: 198.51.100.x (미국 ISP)
  └─ 응답: 버지니아 리전 IP (2.2.2.2)

GSLB는 각 리전 서버에 주기적으로 Health Check를 보냄
  서울 서버: 200 OK ✓
  도쿄 서버: 200 OK ✓
  싱가포르 서버: 503 (장애) ✗

→ 싱가포르 사용자 → 도쿄 서버로 리다이렉션

# 기본 질의
dig google.com

# 특정 레코드 타입
dig google.com AAAA     # IPv6
dig google.com MX       # 메일 서버
dig google.com TXT      # SPF/DKIM
dig google.com NS       # 네임서버
dig google.com CAA      # 인증서 발급 허용 CA

# 특정 DNS 서버에게 질의
dig @8.8.8.8 google.com        # Google Public DNS
dig @1.1.1.1 google.com        # Cloudflare DNS

$ dig +trace naver.com

;; Received 228 bytes from 8.8.8.8 in 15 ms    ← Root
.                  518400 IN NS a.root-servers.net.

;; Received 745 bytes from 192.5.6.30 in 42 ms  ← .com TLD
com.               172800 IN NS a.gtld-servers.net.

;; Received 219 bytes from 192.26.92.30 in 8 ms ← Naver NS
naver.com.         300    IN A  223.130.195.200

문제: "도메인이 안 풀린다"

1) dig @8.8.8.8 example.com
   → 응답 있음? → 로컬 DNS/캐시 문제
   → NXDOMAIN? → 2번으로

2) dig example.com NS
   → NS 레코드 있음? → Authoritative 서버 문제
   → SERVFAIL? → 3번으로

3) dig +trace example.com
   → 어디서 끊기는지 확인 (TLD? NS 위임?)

4) 최근 DNS 변경 이력 확인
   → TTL이 긴데 변경 직후? → 캐시 만료 대기

# macOS — DNS 캐시 초기화
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — systemd-resolved 캐시 확인
resolvectl statistics
resolvectl flush-caches

# 역방향 DNS (IP → 도메인)
dig -x 223.130.195.200

# 간결한 출력 (스크립트에 유용)
dig +short google.com
# 142.250.206.206

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

# Zone: example.com

# 루트 도메인 → 로드밸런서
example.com.       300  IN  A       203.0.113.10
example.com.       300  IN  AAAA    2001:db8::10

# www → 루트 도메인으로
www.example.com.   300  IN  CNAME   example.com.

# API 서브도메인 → 별도 서버
api.example.com.   300  IN  A       203.0.113.20

# 메일 서버
example.com.       300  IN  MX  10  mail.example.com.
example.com.       300  IN  MX  20  mail-backup.example.com.

# 메일 보안 (SPF + DKIM + DMARC)
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"

# 인증서 발급 제한
example.com.       300  IN  CAA  0 issue "letsencrypt.org"

# 현재: Blue 환경 활성
app.example.com.  60  IN  CNAME  blue.example.com.

# 전환: Green 환경으로 변경
app.example.com.  60  IN  CNAME  green.example.com.

# TTL=60이므로 최대 1분 내 전환 완료
# 롤백: 다시 blue로 CNAME 변경

<!-- 브라우저가 미리 DNS 해석 -->
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="dns-prefetch" href="//api.example.com">
<link rel="preconnect" href="https://fonts.googleapis.com">

A 질의:    google.com → 142.250.206.206 (IPv4)
AAAA 질의: google.com → 2404:6800:...   (IPv6)

→ 두 연결을 동시에 시도 → 먼저 성공한 쪽 사용