네트워크 DNS & 보안 (Q13-Q18)

DNS & 보안 (13~18번)

Q13. DNS 해석 과정과 Recursive vs Iterative Query 차이는?

전체 DNS 해석 과정:

1. Client: "www.example.com의 IP 주소는?"
   ↓
2. Local DNS Cache 확인 (/etc/hosts, 브라우저 캐시)
   ↓ (캐시 미스)
3. Recursive DNS 서버 (ISP DNS, 8.8.8.8)
   ↓
4. Root DNS 서버 → ".com TLD DNS 서버 위치는 192.5.6.30"
   ↓
5. TLD DNS 서버 → "example.com의 권한 DNS는 ns1.example.com"
   ↓
6. Authoritative DNS → "www.example.com은 93.184.216.34"
   ↓
7. 응답 캐싱 (TTL 동안 유효)
   ↓
8. Client: TCP 연결 (93.184.216.34:80)

Recursive Query (재귀 질의):

Client → Recursive DNS: "www.example.com 주소 알려줘"
Recursive DNS: "알았어, 내가 다 찾아서 최종 답을 줄게"

Recursive DNS → Root
Recursive DNS → TLD
Recursive DNS → Authoritative
Recursive DNS → Client: "93.184.216.34야!"

클라이언트는 한 번만 요청
Recursive DNS가 모든 작업 수행
ISP DNS, Public DNS (8.8.8.8, 1.1.1.1)가 이 방식 사용

Iterative Query (반복 질의):

Client → Root DNS: "www.example.com 주소는?"
Root DNS → Client: "모르겠고, .com TLD는 192.5.6.30에 물어봐"

Client → TLD DNS: "www.example.com 주소는?"
TLD DNS → Client: "모르겠고, ns1.example.com(203.0.113.1)에 물어봐"

Client → Authoritative DNS: "www.example.com 주소는?"
Authoritative DNS → Client: "93.184.216.34야!"

클라이언트가 여러 번 요청
각 DNS 서버는 참조 정보만 제공
Recursive DNS 서버가 Root/TLD 조회 시 사용

실무에서:

End User → Recursive DNS: Recursive Query
Recursive DNS → Root/TLD/Authoritative: Iterative Query

Q14. DNS 캐시 포이즈닝 공격과 DNSSEC 동작 원리는?

DNS Cache Poisoning (Kaminsky Attack):

정상 흐름:
Client → Recursive DNS: "bank.com은?"
Recursive DNS → Authoritative DNS
Authoritative DNS → Recursive DNS: "1.2.3.4"

공격 흐름:
Attacker: Recursive DNS에 대량 쿼리 발송 (xyz123.bank.com)
Attacker: 위조된 응답 전송 (bank.com → Attacker IP)
Recursive DNS: 위조 응답 먼저 도착 → 캐시 오염
→ 모든 사용자가 공격자 사이트로 유도 (피싱)

공격 조건:

DNS Query ID 맞춰야 함 (16-bit, 65536 가지)
Source Port 맞춰야 함 (랜덤화로 방어)
TTL 만료 전 공격 성공 필요

방어 방법:

1. Source Port Randomization:

기존: 고정 포트 53
개선: 랜덤 포트 (10000~65535)
→ 예측 난이도 증가 (16-bit * 16-bit = 2^32)

2. DNSSEC (DNS Security Extensions):

DNSSEC 동작 원리:

Zone Signing:
example.com Zone
  ├─ RRSIG (Resource Record Signature)
  ├─ DNSKEY (Public Key)
  └─ DS (Delegation Signer) → 상위 TLD에 등록

검증 과정:
1. Client: "www.example.com A 레코드 + RRSIG 요청"
2. Authoritative DNS: A 레코드 + RRSIG 반환
3. Client: DNSKEY로 RRSIG 검증
4. DNSKEY가 신뢰할 수 있는지 DS 레코드로 확인
5. 신뢰 체인: Root → TLD → example.com

DNSSEC 레코드 타입:

RRSIG: 디지털 서명 (Zone의 Private Key로 서명)
DNSKEY: 공개키
DS (Delegation Signer): 하위 Zone의 DNSKEY 해시 (상위 Zone에 저장)
NSEC/NSEC3: 존재하지 않는 도메인 증명 (NXDOMAIN 검증)

DNSSEC 한계:

암호화 X, 무결성만 보장 (DoH/DoT로 암호화)
배포 복잡도 높음
Zone Walking 가능 (NSEC3로 완화)

3. DNS over HTTPS (DoH) / DNS over TLS (DoT):

DoH: HTTPS (443) 포트로 DNS 쿼리 암호화
DoT: TLS (853) 포트로 DNS 쿼리 암호화
→ ISP의 DNS 스니핑 방지

Q15. DNS 로드밸런싱 기법과 GeoDNS 동작 원리는?

DNS Round Robin:

DNS Query: www.example.com

Response:
www.example.com  300  IN  A  1.2.3.4
www.example.com  300  IN  A  1.2.3.5
www.example.com  300  IN  A  1.2.3.6

→ 클라이언트는 첫 번째 IP 선택 (순서는 로테이션)

장점:

구현 간단
추가 비용 없음

단점:

Health Check 없음 (장애 서버도 반환)
클라이언트 캐싱으로 불균등 분산
TTL 동안 트래픽 변경 불가

Weighted Round Robin (AWS Route 53):

www.example.com  A  1.2.3.4  Weight=70
www.example.com  A  1.2.3.5  Weight=30

→ 70:30 비율로 트래픽 분산
→ Blue-Green 배포, Canary 배포 가능

GeoDNS (Geo-Location Routing):

Query from Korea:
www.example.com → Seoul Region (ap-northeast-2)

Query from USA:
www.example.com → Virginia Region (us-east-1)

Query from Europe:
www.example.com → Ireland Region (eu-west-1)

동작 원리:

1. DNS 서버가 클라이언트 IP의 GeoIP Database 조회
2. 국가/대륙 정보 추출
3. 가장 가까운 리전의 IP 반환
4. 레이턴시 감소 + 규제 준수 (GDPR)

Latency-Based Routing (AWS Route 53):

실제 네트워크 레이턴시 측정
→ 가장 낮은 레이턴시 엔드포인트 반환

us-east-1: 150ms
ap-northeast-2: 50ms
→ Seoul IP 반환 (GeoDNS보다 정확)

Failover Routing:

Primary: Health Check OK → Primary IP 반환
Primary: Health Check Failed → Secondary IP 반환

Health Check:
- HTTP/HTTPS Endpoint 상태 확인 (200 OK)
- TCP 연결 확인
- String Matching (응답 본문 검증)
- CloudWatch Alarm 연동

Multi-Value Answer:

Health Check가 통과한 IP만 최대 8개 반환
www.example.com  A  1.2.3.4 (Healthy)
www.example.com  A  1.2.3.5 (Healthy)
www.example.com  A  1.2.3.6 (Unhealthy) → 제외

→ 클라이언트가 재시도 시 다른 IP 선택

실무 설정 예시 (Route 53):

1. GeoDNS: 대륙별 리전 분리
2. Latency-Based: 리전 내 최적 AZ 선택
3. Weighted: Blue-Green 배포 (90:10 → 50:50 → 0:100)
4. Failover: DR(Disaster Recovery) 사이트 자동 전환

Q16. Reverse Proxy의 성능 최적화와 캐싱 전략은?

Nginx Reverse Proxy 최적화:

1. Connection Pooling (Upstream Keepalive):

upstream backend {
    server backend1.example.com:8080;
    server backend2.example.com:8080;
    
    keepalive 32;  # 최대 32개 연결 유지
    keepalive_requests 100;  # 연결당 100개 요청 처리
    keepalive_timeout 60s;  # 60초 유휴 시 종료
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;  # HTTP/1.1 필수
        proxy_set_header Connection "";  # Connection 헤더 제거
    }
}

→ TCP Handshake 오버헤드 제거 (3-Way Handshake 생략)

2. HTTP/2 to HTTP/1.1 Conversion:

server {
    listen 443 ssl http2;  # 클라이언트는 HTTP/2
    
    location / {
        proxy_pass http://backend;  # 백엔드는 HTTP/1.1
        proxy_http_version 1.1;
    }
}

→ 클라이언트 Multiplexing 이점 + 백엔드 호환성

3. Gzip Compression:

gzip on;
gzip_vary on;
gzip_min_length 1024;  # 1KB 이상만 압축
gzip_comp_level 6;  # 압축 레벨 (1~9, 높을수록 CPU 사용)
gzip_types text/plain text/css application/json application/javascript;
gzip_proxied any;  # 프록시 응답도 압축

→ 대역폭 70~80% 절감 (텍스트 기반 콘텐츠)

4. Caching 전략:

Static Content Caching:

proxy_cache_path /var/cache/nginx 
    levels=1:2 
    keys_zone=static_cache:10m 
    max_size=1g 
    inactive=60m;

server {
    location ~* \.(jpg|jpeg|png|gif|css|js)$ {
        proxy_cache static_cache;
        proxy_cache_valid 200 1h;
        proxy_cache_valid 404 1m;
        proxy_cache_key $scheme$proxy_host$request_uri;
        add_header X-Cache-Status $upstream_cache_status;
    }
}

Cache Bypass:

location / {
    proxy_cache static_cache;
    proxy_cache_bypass $http_pragma $http_authorization;
    proxy_no_cache $cookie_nocache;
    
    # 관리자는 캐시 우회
    if ($http_user_agent ~* "AdminBot") {
        set $bypass 1;
    }
    proxy_cache_bypass $bypass;
}

Microcaching (Dynamic Content):

location / {
    proxy_cache dynamic_cache;
    proxy_cache_valid 200 1s;  # 1초만 캐싱
    proxy_cache_lock on;  # 동시 요청 시 하나만 upstream 전달
    proxy_cache_lock_timeout 5s;
    proxy_cache_use_stale updating;  # 갱신 중에는 stale 캐시 제공
}

→ Thundering Herd 방지 (동시 요청 폭주)

5. Load Balancing 고급 기법:

Least Connections:

upstream backend {
    least_conn;  # 연결 수 가장 적은 서버 선택
    server backend1.example.com;
    server backend2.example.com;
}

IP Hash (Session Affinity):

upstream backend {
    ip_hash;  # 클라이언트 IP 기반 해싱
    server backend1.example.com;
    server backend2.example.com;
}

Health Check (Nginx Plus):

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    
    health_check interval=5s fails=3 passes=2;
    # 5초마다 체크, 3번 실패 시 제외, 2번 성공 시 복구
}

6. Rate Limiting:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    # 초당 10 요청, burst 20까지 허용
    
    error_page 429 /rate_limit.html;
}

7. SSL Termination:

server {
    listen 443 ssl http2;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_stapling on;
    ssl_stapling_verify on;
    
    location / {
        proxy_pass http://backend;  # 백엔드는 HTTP
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

→ SSL 오프로딩으로 백엔드 CPU 부하 감소

Q17. Service Mesh의 Traffic Management와 Circuit Breaker 패턴은?

Istio Traffic Management:

1. Virtual Service (라우팅 규칙):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2  # jason 사용자는 v2로
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90  # 90% → v1
    - destination:
        host: reviews
        subset: v2
      weight: 10  # 10% → v2 (Canary)

2. Destination Rule (서브셋 정의):

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        http2MaxRequests: 100
        maxRequestsPerConnection: 2
    loadBalancer:
      consistentHash:
        httpCookie:
          name: user
          ttl: 0s  # Session Affinity
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

3. Circuit Breaker 패턴:

동작 원리:

Closed (정상) → Open (장애 감지) → Half-Open (복구 시도) → Closed

Closed:
  요청 정상 처리
  오류율 모니터링

Open:
  즉시 실패 응답 (Fail Fast)
  업스트림 호출 차단
  타임아웃까지 대기

Half-Open:
  일부 요청만 허용
  성공 시 Closed로 전환
  실패 시 다시 Open

Istio Circuit Breaker 설정:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-cb
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 1
        http2MaxRequests: 100
        maxRequestsPerConnection: 1
    outlierDetection:  # Circuit Breaker
      consecutiveErrors: 5  # 5번 연속 실패 시
      interval: 30s  # 30초 간격으로 체크
      baseEjectionTime: 30s  # 30초 동안 제외
      maxEjectionPercent: 50  # 최대 50% Pod만 제외
      minHealthPercent: 25  # 최소 25% Pod는 유지

4. Retry & Timeout:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
    timeout: 5s  # 전체 타임아웃
    retries:
      attempts: 3  # 최대 3번 재시도
      perTryTimeout: 2s  # 시도당 2초
      retryOn: 5xx,reset,connect-failure,refused-stream

5. Fault Injection (카오스 엔지니어링):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1  # 10% 요청에
        fixedDelay: 5s  # 5초 지연 주입
      abort:
        percentage:
          value: 0.1  # 10% 요청에
        httpStatus: 500  # 500 오류 주입
    route:
    - destination:
        host: ratings

6. mTLS (상호 TLS 인증):

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT  # 모든 통신 mTLS 강제

성능 모니터링:

Istio Metrics (Prometheus):
- istio_requests_total: 요청 수
- istio_request_duration_milliseconds: 레이턴시
- istio_request_bytes: 요청 크기
- istio_response_bytes: 응답 크기

Kiali Dashboard:
- 서비스 토폴로지 시각화
- 트래픽 흐름 추적
- Circuit Breaker 상태 모니터링

Q18. IPsec VPN vs SSL/TLS VPN의 실무 선택 기준은?

IPsec VPN (Site-to-Site):

OSI 계층:

IPsec은 OSI 3계층(네트워크 계층)에서 작동
→ IP 패킷 레벨에서 암호화
→ 상위 계층(TCP/UDP 등) 모든 프로토콜 투명하게 지원

아키텍처:

On-Premise DC ← IPsec Tunnel → AWS VPC
       ┌───────────┐            ┌───────────┐
       │  Router   │──────────  VGW/TGW   │
       │  (ASA)    │   IPsec    │  (AWS)    │
       └───────────┘            └───────────┘
         |                          |
    Private Subnet            Private Subnet

설정 (AWS Site-to-Site VPN):

1. Customer Gateway (CGW): On-Premise 공인 IP
2. Virtual Private Gateway (VGW) 또는 Transit Gateway
3. VPN Connection 생성:
   - IKEv2 (Internet Key Exchange)
   - AES-256-GCM 암호화
   - SHA-256 해싱
   - DH Group 14 이상
4. BGP 라우팅 (동적) 또는 Static 라우팅
5. Tunnel 이중화 (HA)

IPsec 동작 방식:

Transport Mode (전송 모드):
[IP Header | IPsec Header | Encrypted Payload]
→ IP 헤더는 평문, 페이로드만 암호화
→ Host-to-Host 통신에 사용

Tunnel Mode (터널 모드):
[New IP Header | IPsec Header | Encrypted [Original IP Header | Payload]]
→ 원본 IP 패킷 전체를 암호화 후 새로운 IP 헤더로 캡슐화
→ Site-to-Site VPN에 사용 (가장 일반적)

장점:

네트워크 레벨 투명성: 모든 프로토콜 지원 (TCP, UDP, ICMP, GRE 등)
고성능: 하드웨어 가속 지원 (ASA, Fortinet 등)
Site-to-Site 연결 최적: 두 네트워크를 하나처럼 연결
라우팅 통합: BGP로 동적 라우팅 가능

단점:

설정 복잡도 높음: Phase 1/2 협상, 암호화 스위트 매칭 필요
NAT Traversal 문제: NAT 환경에서 ESP 패킷 처리 어려움 (NAT-T로 해결)
클라이언트 소프트웨어 필요: 원격 사용자용 IPsec 클라이언트 설치 필수
방화벽 친화적이지 않음: UDP 500, 4500 포트 및 ESP(Protocol 50) 허용 필요

SSL/TLS VPN (Remote Access):

OSI 계층:

SSL/TLS는 OSI 5~6계층(세션 계층 ~ 표현 계층)에서 작동
→ 애플리케이션 데이터를 암호화
→ TCP 기반 (443 포트 사용)
→ HTTP, RDP, SSH 등 특정 애플리케이션 터널링

아키텍처:

Remote User (Laptop) ← SSL VPN → Corporate Network
       ┌─────────┐                 ┌───────────┐
       │ Browser │────HTTPS────────│ SSL VPN   │
       │(443 Port)│                │ Gateway   │
       └─────────┘                 └───────────┘
                                        |
                                   Internal Apps

SSL VPN 동작 방식:

1. 클라이언트가 HTTPS(443)로 SSL VPN Gateway 접속
2. TLS Handshake (인증서 검증, 세션 키 교환)
3. 두 가지 모드:

Portal Mode (Web-Based):
- 웹 브라우저만으로 접속
- HTML5/JavaScript로 애플리케이션 렌더링
- RDP, SSH 웹 클라이언트 제공
- 제한적 기능 (파일 전송, 특정 앱만)

Tunnel Mode (Full VPN):
- 경량 클라이언트 설치 (OpenVPN, Pulse Secure)
- 가상 네트워크 어댑터 생성 (tun0)
- 모든 트래픽 터널링 또는 Split Tunnel
- IPsec과 유사한 경험

설정 (OpenVPN):

1. CA 인증서 생성
2. 서버 인증서 발급
3. 클라이언트 인증서 발급
4. OpenVPN 서버 설정:
   proto tcp        # TCP 사용 (방화벽 친화적)
   port 443         # HTTPS 포트 (443)
   dev tun          # 터널 인터페이스
   cipher AES-256-CBC
   auth SHA256
   comp-lzo         # 압축
5. 클라이언트 프로파일 배포 (.ovpn)

장점:

웹 기반 접근: 브라우저만으로 가능 (Portal Mode)
NAT/Firewall 친화적: HTTPS(443) 포트로 거의 모든 방화벽 통과
세밀한 접근 제어: URL 기반, 애플리케이션별 권한 부여
설정 간단: 사용자 경험 우수, 클릭 몇 번으로 연결
Zero Trust 통합: Identity-Aware Proxy와 연동 용이

단점:

애플리케이션 레벨 제한: Portal Mode는 일부 프로토콜만 지원 (UDP 제한)
성능 오버헤드: TLS Handshake + TCP 캡슐화 (TCP over TCP 문제)
Tunnel Mode 한계: IPsec보다 처리량 낮음 (소프트웨어 암호화)

계층별 차이 요약:

OSI 계층 관점:

IPsec (Layer 3 - Network):
┌─────────────────────────────────┐
│ Application (7)                 │
│ Presentation (6)                │
│ Session (5)                     │
│ Transport (4) - TCP/UDP         │ ← 모두 암호화됨
│ Network (3) - IP [IPsec 작동]  │ ← IP 패킷 암호화
│ Data Link (2)                   │
│ Physical (1)                    │
└─────────────────────────────────┘

SSL/TLS (Layer 5-6 - Session/Presentation):
┌─────────────────────────────────┐
│ Application (7) - HTTPS         │ ← 애플리케이션 데이터 암호화
│ Presentation (6) [TLS 작동]    │ ← SSL/TLS 암호화
│ Session (5) [TLS 작동]         │ ← 세션 관리
│ Transport (4) - TCP             │ ← TCP는 평문 (헤더만)
│ Network (3) - IP                │ ← IP는 평문
│ Data Link (2)                   │
│ Physical (1)                    │
└─────────────────────────────────┘

실무 선택 기준:

요구사항	IPsec VPN	SSL/TLS VPN
Site-to-Site 연결	✅ 최적	❌ 비권장
원격 사용자 (BYOD)	❌ 복잡	✅ 최적
모든 프로토콜 지원	✅ 지원	⚠️ 제한적
NAT/Firewall 통과	⚠️ NAT-T 필요	✅ 쉬움 (443)
성능 (Throughput)	✅ 높음	⚠️ 중간
설정 복잡도	⚠️ 높음	✅ 낮음
접근 제어 세밀도	⚠️ IP 기반	✅ 앱 레벨
비용	⚠️ 하드웨어 필요	✅ 소프트웨어

하이브리드 접근:

IPsec VPN: 본사 ↔ AWS (Site-to-Site)
SSL VPN:   재택근무자 → AWS (Remote Access)

AWS Client VPN (Managed SSL VPN):
- OpenVPN 기반
- Active Directory 통합
- 자동 스케일링
- CloudWatch 모니터링

AWS Direct Connect + VPN:

Primary:   Direct Connect (전용선, 암호화 X)
Secondary: IPsec VPN over Internet (백업, 암호화 O)

→ 고성능 + 고가용성 + 보안

💡 용어 설명:

DNS 및 보안 관련 질문들(Q13-Q18)에서 사용된 용어들(DNS Recursive/Iterative Query, DNSSEC, GeoDNS, Reverse Proxy Caching, Circuit Breaker, IPsec/SSL VPN 등)에 대한

상세한 설명은 문서 상단의 주요 용어 통합 정리 > DNS, 프록시 & 로드밸런싱, 보안 & 암호화 섹션을 참고하세요.

참고 자료

← KR_네트워크.md로 돌아가기

KR_Net_DNS_Security - somaz94/DevOps-Engineer GitHub Wiki

네트워크 DNS & 보안 (Q13-Q18)

DNS & 보안 (13~18번)

Q13. DNS 해석 과정과 Recursive vs Iterative Query 차이는?

Q14. DNS 캐시 포이즈닝 공격과 DNSSEC 동작 원리는?

Q15. DNS 로드밸런싱 기법과 GeoDNS 동작 원리는?

Q16. Reverse Proxy의 성능 최적화와 캐싱 전략은?

Q17. Service Mesh의 Traffic Management와 Circuit Breaker 패턴은?

Q18. IPsec VPN vs SSL/TLS VPN의 실무 선택 기준은?

참고 자료

⚠️ GitHub.com Fallback ⚠️

KR_Net_DNS_Security - somaz94/DevOps-Engineer GitHub Wiki

네트워크 DNS & 보안 (Q13-Q18)

DNS & 보안 (13~18번)

Q13. DNS 해석 과정과 Recursive vs Iterative Query 차이는?

Q14. DNS 캐시 포이즈닝 공격과 DNSSEC 동작 원리는?

Q15. DNS 로드밸런싱 기법과 GeoDNS 동작 원리는?

Q16. Reverse Proxy의 성능 최적화와 캐싱 전략은?

Q17. Service Mesh의 Traffic Management와 Circuit Breaker 패턴은?

Q18. IPsec VPN vs SSL/TLS VPN의 실무 선택 기준은?

참고 자료

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️