Domain Name System

Domain Name System

DNS(Domain Name System) 는 인터넷의 전화번호부와 같은 역할을 한다. 사람이 읽고 이해할 수 있는 도메인 이름 (예: <www.example.com>) 을 컴퓨터가 이해할 수 있는 IP 주소 (예: 192.0.2.1) 로 변환해주는 시스템이다. 이 변환 과정은 사용자가 인터넷에서 웹사이트나 API 에 접근할 때 필수적인 단계이다.

DNS 의 작동 방식

DNS 변환 과정은 여러 단계로 이루어지는 분산 시스템이다.

이 과정을 “DNS 조회 " 또는 “DNS 해석 " 이라고 부른다.

DNS 조회 과정

1. 사용자 입력: 사용자가 브라우저에 도메인 이름 (api.example.com) 을 입력한다.
2. 로컬 DNS 캐시 확인: 브라우저와 운영체제는 먼저 자체 캐시를 확인하여 최근에 방문한 도메인의 IP 주소를 찾는다.
3. 리커시브 DNS 서버 질의: 캐시에서 찾지 못하면, 요청은 일반적으로 ISP(인터넷 서비스 제공업체) 가 제공하는 리커시브 DNS 서버로 전달된다.
4. 루트 DNS 서버 질의: 리커시브 서버는 전 세계에 분산된 루트 DNS 서버에 질의한다. 루트 서버는 최상위 도메인 (TLD) 서버의 위치를 알려준다.
5. TLD DNS 서버 질의: 리커시브 서버는 TLD 서버 (예:.com,.org,.net) 에 질의하여 해당 도메인의 권한 있는 네임서버의 위치를 알아낸다.
6. 권한 있는 네임서버 질의: 리커시브 서버는 권한 있는 네임서버에 도메인 이름에 대한 IP 주소를 요청한다.
7. 응답 반환: IP 주소는 리커시브 서버를 통해 사용자의 컴퓨터로 반환된다. 이 정보는 일정 기간 동안 캐시된다.
8. 연결 설정: 브라우저는 이제 해당 IP 주소를 사용하여 웹 서버 또는 API 서버에 연결한다.

DNS(도메인 네임 시스템) 는 인터넷 및 네트워크에서 도메인 명을 IP 주소로 변환하는 분산형 네임 서비스로, 브라우저 등 응용 프로그램이 사람 친화적인 도메인 명을 네트워크 자원 (서버) 으로 연결할 수 있도록 지원한다. 이는 계층적 구조로 설계되어 전 세계에 분산된 수많은 DNS 서버가 협력해 트래픽 분산, 보안, 확장성을 실현하며, 인터넷 서비스의 접근성과 신뢰성, 확장성을 높이는 필수적인 시스템 컴포넌트이다.

핵심 개념

DNS 는 계층적 (hierarchical), 분산형 (distributed) 네이밍 시스템으로, 사용자가 입력하는 도메인 명을 인터넷이 사용하는 IP 주소로 변환하는 역할을 담당한다.
루트 도메인에서 시작해, TLD(Top-Level Domain), 권한 네임서버 (Authoritative Name Server) 등 계층적으로 관리된다.
각 도메인에 대한 관리권한과 네임 레코드가 위임 (Delegation) 구조로 분산된다.

기본 개념

DNS 의 핵심 개념들은 다음과 같다:

1. 도메인 이름 공간 (Domain Name Space): 계층적 트리 구조로 구성된 전체 도메인 이름의 집합
2. 네임 서버 (Name Server): 도메인 이름과 IP 주소 매핑 정보를 저장하고 제공하는 서버
3. 리졸버 (Resolver): 클라이언트를 대신해 DNS 쿼리를 수행하는 구성 요소
4. 리소스 레코드 (Resource Record): DNS 데이터베이스에 저장되는 정보의 기본 단위
5. 위임 (Delegation): 상위 도메인에서 하위 도메인의 관리 권한을 위임하는 메커니즘
6. 캐싱 (Caching): 성능 향상을 위해 조회 결과를 임시 저장하는 메커니즘

실무 구현을 위한 연관성

• 분산 시스템 설계: DNS 의 계층적 구조는 마이크로서비스 아키텍처의 서비스 디스커버리 패턴과 유사
• 캐싱 전략: DNS 캐싱은 애플리케이션 레벨 캐싱 설계의 참고 모델
• 부하 분산: DNS 의 Round Robin 방식은 로드 밸런싱 구현에 활용
• 장애 복구: DNS 의 다중 네임 서버 구조는 고가용성 시스템 설계의 기본 원리

등장 배경 및 발전 과정

초기 인터넷 시대의 문제:
1970 년대 ARPANET 에서는 HOSTS.TXT 파일을 사용하여 호스트 이름과 IP 주소를 매핑했다. 그러나 인터넷이 성장하면서 다음과 같은 문제가 발생했다:

• 확장성 문제: 네트워크가 커질수록 HOSTS.TXT 파일 크기가 기하급수적으로 증가
• 중앙 집중식 관리: 모든 변경사항이 중앙에서 관리되어 병목 현상 발생
• 일관성 문제: 모든 호스트에 동일한 파일을 배포하기 어려움
• 실시간 업데이트 불가: 새로운 호스트 추가 시 모든 호스트의 파일 업데이트 필요

DNS 개발 동기:
1983 년 Paul Mockapetris 가 RFC 882 와 RFC 883 에서 DNS 를 제안한 배경은 위 문제들을 해결하기 위함이었다.

발전 흐름

• 1983: DNS 설계 및 초기 도입
• 1990s: 대규모 상업적 인터넷 환경으로 확장
• 2000s: DNSSEC, Anycast 기반 분산 확산
• 2010s~현재: DNS over HTTPS (DoH), DNS over TLS (DoT) 도입

주요 기능 및 역할

주요 기능:

1. 이름 해석 (Name Resolution)

   • Forward lookup: 도메인 이름 → IP 주소
   • Reverse lookup: IP 주소 → 도메인 이름

2. 분산 데이터베이스 관리

   • 계층적 네임스페이스 관리
   • 권한 위임을 통한 분산 관리

3. 캐싱 및 성능 최적화

   • 쿼리 결과 임시 저장
   • TTL(Time To Live) 기반 캐시 관리

4. 서비스 디스커버리

   • SRV 레코드를 통한 서비스 위치 정보 제공
   • 메일 서버, 웹 서버 등 특정 서비스 탐색

주요 역할:

1. 인터넷 인프라 역할: 모든 인터넷 통신의 첫 번째 단계
2. 추상화 계층 역할: 물리적 네트워크 위치와 논리적 서비스 이름 분리
3. 중개자 역할: 클라이언트와 서버 간의 연결 중개
4. 분산 시스템 코디네이터: 전 세계 분산된 리소스의 통합 관리

기능과 역할의 관계:
DNS 의 이름 해석 기능이 인터넷 인프라 역할을 가능하게 하며, 분산 데이터베이스 관리 기능이 추상화 계층 역할을 지원한다. 캐싱 기능은 성능 최적화를 통해 중개자 역할의 효율성을 높인다.

특징

핵심 원칙

• 일관성 (Consistency): 모든 네임 레코드는 최종 관리자가 소유하고 authoritative 서버가 공식 정보 제공.
• 권한 위임 (Delegation): 상위 네임서버가 하위 네임서버에게 권한을 위임.
• 분산 관리 (Distributed Management): 글로벌 분산 서버가 협조적으로 동작.
• 표준 프로토콜 준수 (Protocol Compliance): UDP, TCP, DNSSEC, DoH 등 공식 스펙 준수.
• 성능 최적화: 캐싱, Anycast 등 네트워크 성능 극대화 원칙 적용.

주요 원리

1. 재귀 질의 (Recursive Query): 클라이언트가 DNS 리졸버에 질의하면, 리졸버가 전체 해석을 담당.
2. 반복 질의 (Iterative Query): 리졸버가 각각의 네임서버에 질의하며 다음 서버의 정보를 받아옴.
3. 캐싱 원리: TTL 을 기준으로 결과를 저장하여, 중복 질의시 성능 최적화.
4. 위임 원리: 루트서버는 TLD 에 위임하고, TLD 는 각 도메인의 권한 서버에 위임.

작동 방식

sequenceDiagram
    participant C as 클라이언트
    participant R as 리졸버
    participant Root as 루트 서버
    participant TLD as TLD 서버
    participant Auth as 권한 서버
    
    C->>R: example.com IP 주소 요청
    R->>Root: example.com 쿼리
    Root->>R: .com TLD 서버 정보 반환
    R->>TLD: example.com 쿼리
    TLD->>R: example.com 권한 서버 정보 반환
    R->>Auth: example.com 쿼리
    Auth->>R: example.com IP 주소 반환
    R->>C: IP 주소 전달

작동 방식:

1. 재귀적 쿼리 (Recursive Query)

   • 클라이언트가 리졸버에게 완전한 답변을 요청
   • 리졸버가 모든 중간 단계를 처리

2. 반복적 쿼리 (Iterative Query)

   • 각 네임 서버가 다음 단계의 네임 서버 정보만 제공
   • 리졸버가 단계별로 쿼리 수행

3. 캐싱 메커니즘

   • 각 단계의 결과를 TTL 동안 캐시
   • 동일한 쿼리에 대해 빠른 응답 제공

구조 및 아키텍처

graph TD
    Client["클라이언트 (브라우저/앱)"]
    Recursive[재귀 리졸버]
    Root[루트 서버]
    TLD["TLD 서버 (.com)"]
    Authoritative[권한 네임서버]
    Cache[캐시 서버]

    Client --> Recursive
    Recursive --> Cache
    Recursive --> Root
    Root --> TLD
    TLD --> Authoritative
    Authoritative --> Recursive
    Recursive --> Client

• DNS 구조는 계층적, 분산적, 위임 기반으로 설계됨
• 보안이나 성능을 고려해 DoH/DoT, Anycast, 캐시 서버 등을 선택적으로 포함

구성 요소

DNS 데이터 구조

DNS 는 계층적 분산 데이터베이스로 구성되어 있다.

도메인 이름은 점 (.) 으로 구분된 계층적 구조를 가진다:

1

api.service.example.com.

이 이름은 다음과 같이 해석된다:

• com: 최상위 도메인 (TLD)
• example: 두 번째 수준 도메인
• service: 서브도메인
• api: 서브 - 서브도메인

이러한 계층 구조는 DNS 가 전 세계적으로 분산되어 있으면서도 효율적으로 작동할 수 있게 해준다.

구현 기법 및 방법

Zone 파일 기반 구현

정의: DNS 도메인 정보를 텍스트 파일로 관리하는 전통적인 방법
구성: SOA, NS, A, CNAME, MX 등의 리소스 레코드
목적: 도메인 정보의 구조적 관리 및 백업

실제 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

$TTL 86400
@       IN SOA  ns1.example.com. admin.example.com. (
                2023071801  ; Serial
                3600        ; Refresh
                1800        ; Retry
                604800      ; Expire
                86400       ; Minimum TTL
                )
        IN NS   ns1.example.com.
        IN NS   ns2.example.com.
        IN A    192.0.2.1
www     IN A    192.0.2.2
mail    IN A    192.0.2.3

동적 DNS (Dynamic DNS)

정의: DNS 레코드를 동적으로 업데이트할 수 있는 메커니즘
구성: DNS UPDATE 프로토콜, 인증 메커니즘, 자동 업데이트 클라이언트
목적: 동적 IP 환경에서의 도메인 이름 유지

시나리오: 가정용 서버가 유동 IP 를 사용하는 경우, DDNS 클라이언트가 IP 변경을 감지하고 자동으로 DNS 레코드 업데이트

DNS 로드 밸런싱

정의: DNS 를 이용한 트래픽 분산 기법
구성: 다중 A 레코드, 가중치 기반 라우팅, 헬스 체크
목적: 서버 부하 분산 및 가용성 향상

시스템 구성:

• 웹 서버 클러스터: 3 대 서버
• DNS 라운드 로빈: 순차적 IP 반환
• 헬스 체크: 장애 서버 자동 제외

DNSSEC (DNS Security Extensions)

정의: DNS 응답의 무결성과 인증을 보장하는 보안 확장
구성: 디지털 서명, 공개키 암호화, 신뢰 체인
목적: DNS 스푸핑 및 캐시 포이즈닝 공격 방어

구현 요소:

• RRSIG: 리소스 레코드 서명
• DNSKEY: 공개키 저장
• DS: 하위 도메인 키 해시
• NSEC/NSEC3: 존재하지 않는 도메인 증명

장점

단점과 문제점 그리고 해결방안

단점

문제점

도전 과제

분류 기준에 따른 종류 및 유형

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

API 디자인에서 DNS 의 중요성

DNS 는 API 디자인 및 아키텍처에서 여러 중요한 역할을 한다:

1. API 엔드포인트 접근성
   DNS 는 사용자가 API 엔드포인트에 쉽게 접근할 수 있게 해준다. 기억하기 쉬운 도메인 이름 (api.example.com) 을 사용하면 개발자가 API 를 더 쉽게 사용할 수 있다.

2. API 버전 관리
   DNS 를 활용하여 API 버전을 관리할 수 있다:

   1 2	api-v1.example.com api-v2.example.com

   또는 서브도메인을 사용할 수도 있다:

   1 2	v1.api.example.com v2.api.example.com

   이는 버전별로 다른 인프라나 서버로 트래픽을 라우팅할 수 있게 해준다.

3. 지리적 로드 밸런싱
   지리적으로 분산된 API 서버를 DNS 를 통해 관리할 수 있다. GeoDNS 를 사용하면 사용자의 위치에 따라 가장 가까운 API 서버로 라우팅할 수 있다.

   1 2 3 4 5 6 7 8

   # 미국 사용자용 us.api.example.com IN A 203.0.113.1 # 유럽 사용자용 eu.api.example.com IN A 203.0.113.2 # 아시아 사용자용 asia.api.example.com IN A 203.0.113.3

4. 블루 - 그린 배포
   DNS 를 사용하여 API 의 새 버전을 무중단으로 배포할 수 있다. CNAME 레코드나 A 레코드를 변경하여 트래픽을 새 서버로 전환할 수 있다.

   1 2 3 4 5

   # 기존 배포 api.example.com. IN A 203.0.113.1 # 새 배포 후 api.example.com. IN A 203.0.113.2

5. 서비스 디스커버리
   DNS SRV 레코드는 마이크로서비스 환경에서 서비스 디스커버리에 사용될 수 있다.

   1 2	_api._tcp.example.com. IN SRV 10 60 443 api1.example.com. _api._tcp.example.com. IN SRV 20 60 443 api2.example.com.

   클라이언트는 이 정보를 사용하여 사용 가능한 API 서버를 찾고 우선순위에 따라 연결할 수 있다.

API 개발자를 위한 DNS 고려사항

1. DNS 전파 시간 (TTL)
   DNS 레코드에는 TTL(Time To Live) 이라는 값이 있다.
   이 값은 DNS 정보가 캐시에 얼마나 오래 저장될지를 결정한다.

   1	api.example.com. 3600 IN A 192.0.2.1

   이 예에서 TTL 은 3600 초 (1 시간) 이다. API 인프라를 변경할 계획이 있다면, 먼저 TTL 을 낮게 설정하여 변경사항이 더 빨리 전파되게 할 수 있다.

2. DNS 장애 대비
   DNS 는 API 의 가용성에 중요한 요소이다. DNS 장애가 발생하면 사용자는 API 에 접근할 수 없게 된다. 따라서 다음과 같은 대비책이 필요하다:

   1. 다중 DNS 제공업체 사용: 주 DNS 서비스와 백업 DNS 서비스를 구성한다.
   2. 보조 네임서버 설정: 도메인에 대해 여러 권한 있는 네임서버를 구성한다.
   3. DNS 모니터링: DNS 해석 시간과 가용성을 모니터링한다.

3. DNS 기반 보안
   DNS 는 API 보안에도 중요한 역할을 한다:

   1. DNSSEC (DNS Security Extensions)
      DNSSEC 는 DNS 응답의 신뢰성을 보장하는 일련의 확장 기능이다. 이는 DNS 스푸핑이나 캐시 오염과 같은 공격을 방지하는 데 도움이 된다.

      1	example.com. IN DNSKEY 256 3 8 AwEAAb…

   2. DNS over HTTPS (DoH) 및 DNS over TLS (DoT)
      이 프로토콜들은 DNS 쿼리를 암호화하여 프라이버시와 보안을 강화한다. API 클라이언트는 이러한 보안 DNS 프로토콜을 사용하여 DNS 데이터의 무결성을 보호할 수 있다.

API 설계에서 DNS 모범 사례

1. 명확한 도메인 구조 설계
   API 를 위한 도메인 구조를 신중하게 계획한다:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   # 주 API api.example.com # 버전별 API v1.api.example.com v2.api.example.com # 환경별 API dev.api.example.com staging.api.example.com prod.api.example.com # 지역별 API us.api.example.com eu.api.example.com

2. 적절한 TTL 관리

   • 일반 상황: 1 시간 (3600 초) 에서 24 시간 (86400 초) 사이의 TTL 사용
   • 배포 계획 시: 배포 전 TTL 을 5 분 (300 초) 또는 그 이하로 감소
   • 배포 후: 모든 것이 안정적으로 작동하면 TTL 을 정상 값으로 복원

3. DNS 장애 대비 클라이언트 구현
   API 클라이언트가 DNS 장애에 대응할 수 있도록 설계:

   1. DNS 캐싱: 클라이언트가 이전 DNS 결과를 캐시하도록 구현
   2. 다중 엔드포인트: 백업 API 엔드포인트 제공
   3. 지수 백오프 재시도: DNS 조회 실패 시 재시도 간격을 늘려가며 시도

4. API 게이트웨이와 DNS 통합
   API 게이트웨이를 DNS 와 통합하여 라우팅을 단순화:

   1. 단일 진입점: 모든 API 트래픽을 api.example.com 으로 라우팅
   2. 백엔드 라우팅: API 게이트웨이가 내부적으로 적절한 마이크로서비스로 라우팅
   3. 인증 및 제한: 게이트웨이 수준에서 인증 및 속도 제한 구현

실무 사용 예시

활용 사례

사례 1: 사용자 위치 기반의 트래픽 최적화와 고가용성 장애 대응

시나리오:
글로벌 웹 서비스 기업이 www.example.com 도메인에 대해 사용자 위치 기반의 트래픽 최적화와 고가용성 장애 대응을 요구.

시스템 구성:

• 사용자는 전 세계 어디에서나 동일한 도메인 (www.example.com) 으로 접속
• DNS 는 Anycast 기반으로 사용자에게 가장 가까운 DNS 서버 응답
• 장애 발생 시 헬스체크를 통해 자동으로 리전 전환

graph TD
    사용자1[사용자 - 일본]
    사용자2[사용자 - 미국]
    DNS1["DNS 서버 (Anycast, 도쿄)"]
    DNS2["DNS 서버 (Anycast, 버지니아)"]
    LoadBalancerJP[JP 리전 로드밸런서]
    LoadBalancerUS[US 리전 로드밸런서]
    WebJP[Web 서버 - 도쿄]
    WebUS[Web 서버 - 버지니아]

    사용자1 --> DNS1
    사용자2 --> DNS2
    DNS1 --> LoadBalancerJP
    DNS2 --> LoadBalancerUS
    LoadBalancerJP --> WebJP
    LoadBalancerUS --> WebUS

Workflow:

1. 클라이언트가 www.example.com 접속 요청
2. DNS Anycast 를 통해 지리적으로 가장 가까운 DNS 서버 응답
3. DNS 응답은 각 리전에 있는 로드밸런서로 전달
4. 각 로드밸런서는 실제 서비스 가능한 웹 서버로 트래픽 분배

역할:

• DNS: 사용자 위치 기반 서버 라우팅
• 로드밸런서: 리전 내 트래픽 분산
• 헬스체크 시스템: 서버 상태 모니터링 및 Failover 유도

유무에 따른 차이점:

구현 예시:

• Node.js 기반 - 클라이언트에서 DNS 조회 및 장애 대체 예

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

const dns = require('dns');

// 사용자가 접속할 도메인
const domain = 'www.example.com';

// 비동기로 A 레코드 조회
dns.resolve4(domain, (err, addresses) => {
  if (err) {
    console.error(`DNS 조회 실패: ${err.message}`);
    // 예외 처리: 대체 도메인 또는 백업 서버 접근 로직
    return fallbackToBackup();
  }

  console.log(`도메인 ${domain}의 IP 주소:`, addresses);
  // 주소 사용하여 실제 HTTP 요청 처리 가능
});

function fallbackToBackup() {
  console.log('백업 서버로 전환: backup.example.com 사용');
  // HTTP 요청 대체 로직
}

사례 2: 사용자 위치 기반 캐시 서버

시나리오: CDN(Content Delivery Network) 에서 사용자의 위치에 따라 가장 가까운 캐시 서버로 웹 트래픽을 분산

시스템 구성:

• 클라이언트 (웹 브라우저)
• 리졸버 (Resolver)
• 루트/ TLD/ 권한 네임서버
• CDN 의 DNS 네임서버 (GeoDNS)
• CDN 에지 서버 (Edge Server)

graph TD
    Client[Client / Browser] --> Resolver
    Resolver --> Root
    Root --> TLD
    TLD --> CDN-DNS
    CDN-DNS --> Edge1[Edge Server 1]
    CDN-DNS --> Edge2[Edge Server 2]
    CDN-DNS --> EdgeN[Edge Server N]

Workflow:

• 클라이언트가 <www.cdnsite.com> 접근 요청
• 로컬 리졸버를 거쳐 루트→TLD→CDN DNS 네임서버로 질의
• GeoDNS 가 클라이언트 위치/상황 기반 최적의 에지 서버 IP 반환
• 클라이언트가 반환된 에지 서버로 접속, 빠른 콘텐츠 제공

역할:

• DNS: 위치 인식, 트래픽 분산, 최적 서버 결정
• CDN: 콘텐츠 복제 및 글로벌 분산 제공

유무에 따른 차이점:

• DNS 미활용 시 전용 IP 만 사용, 트래픽 집중 및 부하 분산 불가
• DNS 활용 시 위치기반 서비스, 복수 서버 운영, 빠른 장애 대응 가능

구현 예시 (Python):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import dns.resolver

def get_best_cdn_edge(domain):
    # 클라이언트 위치 기반으로 DNS 질의 실행
    try:
        answer = dns.resolver.resolve(domain, 'A')  # IPv4 주소 요청
        for ip in answer:
            print(f"CDN 에지 서버 IP: {ip.to_text()}")
    except Exception as e:
        print(f"DNS 질의 실패: {e}")

# 사용 예시
get_best_cdn_edge('www.cdnsite.com')

사례 3: 글로벌 E- 커머스 플랫폼의 DNS 기반 서비스

시나리오: 글로벌 e- 커머스 플랫폼의 DNS 기반 서비스 디스커버리 및 로드 밸런싱

시스템 구성:

• 권한 DNS 서버 (Primary/Secondary)
• GeoDNS 서비스
• CDN 연동 시스템
• 헬스 체크 모니터링
• 다중 지역 데이터센터

graph TB
    User[사용자] --> DNS[GeoDNS 서비스]
    DNS --> |아시아 사용자| AS[아시아 서버 클러스터]
    DNS --> |유럽 사용자| EU[유럽 서버 클러스터]
    DNS --> |미국 사용자| US[미국 서버 클러스터]
    
    AS --> AS1[Asia-Web-01]
    AS --> AS2[Asia-Web-02]
    EU --> EU1[EU-Web-01]
    EU --> EU2[EU-Web-02]
    US --> US1[US-Web-01]
    US --> US2[US-Web-02]
    
    Monitor[헬스 체크] --> AS1
    Monitor --> AS2
    Monitor --> EU1
    Monitor --> EU2
    Monitor --> US1
    Monitor --> US2
    
    Monitor --> DNS

Workflow:

1. 사용자가 shop.example.com 접속 시도
2. GeoDNS 가 사용자 위치 기반으로 최적 서버 선택
3. 헬스 체크 결과를 바탕으로 정상 서버만 응답에 포함
4. Round Robin 방식으로 서버 부하 분산
5. CDN 을 통한 정적 콘텐츠 가속화

역할:

• GeoDNS: 지역별 최적 서버 라우팅
• 헬스 체크: 장애 서버 자동 제외
• Round Robin DNS: 트래픽 부하 분산
• TTL 관리: 빠른 장애 대응 및 성능 최적화

유무에 따른 차이점:

• DNS 없는 경우: IP 주소 직접 사용으로 인한 사용자 불편, 서버 변경 시 클라이언트 설정 수정 필요
• 기본 DNS 만 있는 경우: 지역별 최적화 불가, 장애 시 수동 대응 필요
• 고도화된 DNS 시스템: 자동화된 장애 대응, 지역별 성능 최적화, 투명한 서비스 운영

구현 예시:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158

# DNS 기반 서비스 디스커버리 구현 예시
import dns.resolver
import random
import requests
from typing import List, Optional

class DNSServiceDiscovery:
    def __init__(self, service_domain: str):
        """
        DNS 기반 서비스 디스커버리 초기화
        Args:
            service_domain: 서비스 도메인 (예: api.example.com)
        """
        self.service_domain = service_domain
        self.resolver = dns.resolver.Resolver()
        self.healthy_servers = []
        
    def discover_servers(self) -> List[str]:
        """
        DNS A 레코드를 통해 서버 목록 조회
        Returns:
            List[str]: 서버 IP 주소 목록
        """
        try:
            # A 레코드 조회
            answers = self.resolver.resolve(self.service_domain, 'A')
            servers = [str(answer) for answer in answers]
            print(f"Discovered servers: {servers}")
            return servers
        except Exception as e:
            print(f"DNS resolution failed: {e}")
            return []
    
    def health_check(self, server_ip: str, port: int = 80) -> bool:
        """
        서버 헬스 체크 수행
        Args:
            server_ip: 서버 IP 주소
            port: 서비스 포트
        Returns:
            bool: 서버 상태 (True: 정상, False: 장애)
        """
        try:
            response = requests.get(f"http://{server_ip}:{port}/health", 
                                  timeout=5)
            return response.status_code == 200
        except:
            return False
    
    def get_healthy_servers(self) -> List[str]:
        """
        정상 서버 목록 반환
        Returns:
            List[str]: 정상 서버 IP 목록
        """
        all_servers = self.discover_servers()
        healthy_servers = []
        
        for server in all_servers:
            if self.health_check(server):
                healthy_servers.append(server)
                print(f"Server {server} is healthy")
            else:
                print(f"Server {server} is unhealthy")
        
        self.healthy_servers = healthy_servers
        return healthy_servers
    
    def get_server(self, strategy: str = "round_robin") -> Optional[str]:
        """
        로드 밸런싱 전략에 따른 서버 선택
        Args:
            strategy: 선택 전략 ("round_robin", "random")
        Returns:
            Optional[str]: 선택된 서버 IP
        """
        healthy_servers = self.get_healthy_servers()
        
        if not healthy_servers:
            print("No healthy servers available")
            return None
        
        if strategy == "random":
            return random.choice(healthy_servers)
        elif strategy == "round_robin":
            # 간단한 라운드 로빈 구현
            if not hasattr(self, '_round_robin_index'):
                self._round_robin_index = 0
            
            server = healthy_servers[self._round_robin_index]
            self._round_robin_index = (self._round_robin_index + 1) % len(healthy_servers)
            return server
        
        return healthy_servers[0]

# SRV 레코드 기반 서비스 디스커버리
class SRVServiceDiscovery:
    def __init__(self, service: str, protocol: str, domain: str):
        """
        SRV 레코드 기반 서비스 디스커버리
        Args:
            service: 서비스 이름 (예: http)
            protocol: 프로토콜 (tcp/udp)
            domain: 도메인 (예: example.com)
        """
        self.srv_domain = f"_{service}._{protocol}.{domain}"
        self.resolver = dns.resolver.Resolver()
    
    def discover_services(self) -> List[dict]:
        """
        SRV 레코드를 통한 서비스 디스커버리
        Returns:
            List[dict]: 서비스 정보 목록
        """
        try:
            answers = self.resolver.resolve(self.srv_domain, 'SRV')
            services = []
            
            for answer in answers:
                service_info = {
                    'priority': answer.priority,
                    'weight': answer.weight,
                    'port': answer.port,
                    'target': str(answer.target).rstrip('.')
                }
                services.append(service_info)
            
            # 우선순위와 가중치로 정렬
            services.sort(key=lambda x: (x['priority'], -x['weight']))
            return services
            
        except Exception as e:
            print(f"SRV record resolution failed: {e}")
            return []

# 사용 예시
def main():
    # A 레코드 기반 서비스 디스커버리
    service_discovery = DNSServiceDiscovery("api.example.com")
    
    # 서버 선택 및 요청 처리
    for _ in range(5):
        server = service_discovery.get_server("round_robin")
        if server:
            print(f"Routing request to server: {server}")
        else:
            print("Service unavailable")
    
    # SRV 레코드 기반 디스커버리
    srv_discovery = SRVServiceDiscovery("http", "tcp", "example.com")
    services = srv_discovery.discover_services()
    
    for service in services:
        print(f"Service: {service['target']}:{service['port']} "
              f"(Priority: {service['priority']}, Weight: {service['weight']})")

if __name__ == "__main__":
    main()

사례 4: 글로벌 결제 API 사례

글로벌 결제 API 는 다음과 같은 DNS 구조를 사용할 수 있다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 메인 API 엔드포인트
api.payment.example.com    IN    CNAME    global.payment.example.com.

# 지역별 엔드포인트
us.payment.example.com     IN    A        203.0.113.1
eu.payment.example.com     IN    A        203.0.113.2
asia.payment.example.com   IN    A        203.0.113.3

# 장애 조치를 위한 지리적 라우팅
global.payment.example.com는 GeoDNS를 사용하여 사용자를 가장 가까운 리전으로 라우팅

이 구조는 다음과 같은 이점을 제공한다:

• 사용자에게 가장 가까운 API 엔드포인트로 라우팅
• 리전별 장애 격리
• 단일 엔드포인트를 통한 간소화된 개발자 경험

사례 5: 마이크로서비스 아키텍처의 DNS

마이크로서비스 환경에서 DNS 는 서비스 디스커버리의 중요한 부분이다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# API 게이트웨이
api.example.com             IN    A        203.0.113.10

# 내부 서비스 디스커버리
auth.internal.example.com   IN    A        10.0.0.1
users.internal.example.com  IN    A        10.0.0.2
orders.internal.example.com IN    A        10.0.0.3

# 서비스 디스커버리를 위한 SRV 레코드
_auth._tcp.example.com      IN    SRV      10 60 8080 auth.internal.example.com.
_users._tcp.example.com     IN    SRV      10 60 8081 users.internal.example.com.
_orders._tcp.example.com    IN    SRV      10 60 8082 orders.internal.example.com.

주제와 관련하여 주목할 내용

반드시 학습해야 할 내용

용어 정리

참고 및 출처

DNS 개요 및 기본 개념

• Cloudflare – What is DNS?
• Fortinet – What is DNS?
• IBM – DNS 개요
• Wikipedia – Domain Name System
• TutorialsPoint – Internet DNS 구조 설명

DNS 아키텍처, 동작 원리 및 서버 유형

• Cloudflare – DNS Server Types
• Cloud Infrastructure Services – DNS 아키텍처 계층 구조
• UltaHost – DNS 서버의 기능, 유형, 역할

DNS 레코드

• Cloudflare – DNS Records

DNS 보안 및 최신 기술

• Cloudflare – DNS Over HTTPS (DoH)
• DNSSEC 공식 문서
• CIS – DNS Security Best Practices

DNS 실무 과제 및 운영 이슈

• APNIC Blog – 현대 DNS 과제
• DomainSure – DNS 통합 관리 도전 과제

공개 DNS 및 실습 리소스

• Google – Google Public DNS 소개
• ISC – BIND9 공식 문서

공식 기술 표준 문서 (RFC)

• RFC 1034 – Domain Names Concepts
• RFC 1035 – Domain Names Implementation and Specification

산업 동향 및 통계

• Verisign – DNS Industry Brief