KR_Net_DNS_Security

네트워크 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로 돌아가기