DNS 동작 및 확인 로직

DNS(도메인 이름 시스템)는 웹을 뒷받침하며 백그라운드에서 투명하게 작동하여 사람이 읽을 수 있는 웹사이트 이름을 컴퓨터가 읽을 수 있는 숫자 IP 주소로 변환합니다. 이러한 주소는 인터넷의 RFC 1918(IPv4)및 RFC 4193(IPv6 ) 지침을 따릅니다. 간단히 말해, DNS 서버는 ibm.com 과 같은 도메인 이름을 해당 IP 주소와 연결해 주는데, 대부분의 사람들은 이 IP 주소를 알 필요가 전혀 없습니다.

이 변환을 수행하기 위해 DNS 시스템은 인터넷을 통해 상호 연결된 DNS 서버 네트워크를 쿼리합니다. 이 과정은 전화번호부나 지도를 사용하여 특정 위치를 찾는 것과 유사합니다.

이름 서버

네임 서버는 디렉터리에 대한 쿼리에 응답하여 의미 있는 텍스트 기반 웹 또는 호스트 이름을 IP 주소로 변환하는 서비스를 제공합니다.

네임 서버 위임은 도메인의 네임 서버가 하위 도메인의 레코드 요청을 받으면 요청자를 하위 도메인을 관리하는 위임된 네임 서버로 참조하여 응답하는 방식으로 이루어집니다. 이 프로세스를 통해 ibm.com 와 같은 대규모 도메인을 분산 관리할 수 있습니다.

사용자 지정 도메인 이름 서버를 사용하면, DNS 제공업체의 서버를 자신의 도메인에 맞춰 지정한 참조 이름과 함께 사용할 수 있습니다. 예를 들어 공급업체의 기본값인 ns1.acme.com 대신 네임 서버를 ns1.cloud.ibm.com 로 정의할 수 있습니다.

DNS 레코드 및 글로벌 로드 밸런서 프록싱

CIS 글로벌 로드 밸런서 및 DNS 레코드에 대한 프록시 기능을 지원합니다. 레코드 또는 로드 밸런서가 프록시 처리되면, 해당 트래픽은 CIS 을 통해 직접 전달됩니다.

현재 A, AAAA 또는 CNAME 유형의 DNS 레코드가 프록싱될 수 있습니다. 자세한 내용은 DNS 레코드 유형을 참조하세요.

프록시 모드 설정

로드 밸런서 및 DNS 레코드는 DNS 전용 및 HTTP 프록시 모드를 지원합니다. 동일한 CIS 인스턴스에 HTTP 프록시 및 DNS 전용 도메인을 가질 수 있지만 트래픽 라우팅 동작이 다릅니다. 프록시된 레코드의 트래픽은 CIS 을 통해 흐르고, 프록시되지 않은 레코드의 트래픽(DNS 전용 모드)은 클라이언트에서 오리진으로 직접 흐릅니다.

HTTP 프록시 모드

HTTP 의 프록시 모드에서는 CIS 이 IBM IP 주소를 외부로 공개하지만, 사용자의 오리진 서버 IP 주소는 보호(마스킹)합니다. 알려진 IP 주소 레코드에는 자동 TTL이 있습니다. 트래픽은 CIS 을 통과하며, 이곳에서 방화벽 규칙 및 캐싱과 같은 모든 보안, 성능 및 안정성 기능이 적용됩니다. "자동" TTL(5분)은 CIS 에 대한 권한 있는 쿼리 횟수도 줄여줍니다.

DNS 전용 모드

DNS 전용 모드에서는 레코드가 원본 IP로 확인되며, 레코드의 TTL을 사용자 지정할 수 있습니다. 글로벌 로드 밸런서의 경우, CIS 은 정상 작동 중인 오리진 서버의 주소를 직접 제공하지만, 짧은 TTL을 준수하는 DNS 리졸버를 통해 CIS DNS에 다시 쿼리를 보내 정상 작동 중인 주소의 최신 목록을 조회합니다.

DNS 전용 모드에서는 CIS 의 보안, 안정성 및 성능 기능이 전혀 적용되지 않습니다.

루트 레코드 CNAME 플래트닝

CIS 의 "CNAME 플래트닝" 기능을 사용하면 루트 레코드가 IETF RFC 제한을 우회할 수 있습니다. 이 제한 사항에 따르면, 루트 레코드가 CNAME인 경우 해당 도메인에 대해 다른 레코드를 가질 수 없습니다. CIS 의 권한 서버는 CNAME 자체를 반환하는 대신 CNAME 대상에 해당하는 A records 을 반환함으로써 이 제한을 우회하며, 결과적으로 CNAME을 숨기게 됩니다. 이 기법을 사용하면 루트 레코드가 CNAME인 경우에도 MX 레코드와 같은 다른 레코드를 도메인에 추가할 수 있습니다.

보안 DNS

DNSSEC는 DNS 데이터에 디지털 “서명”을 부여하여 해당 데이터의 유효성을 신뢰할 수 있게 해주는 기술입니다. 인터넷의 취약점을 제거하려면, 루트 영역부터 최종 도메인 이름(예: www.icann.org)에 이르기까지 조회 과정의 각 단계에서 DNSSEC를 적용해야 합니다.

일괄 DNS 레코드 변경

CIS 는 일괄 DNS 레코드 변경을 지원하므로 한 번의 작업으로 여러 영역 레코드를 업데이트할 수 있습니다. 이 접근 방식은 수작업을 줄이고 마이그레이션, 환경 설정 또는 자동화 워크플로와 같은 도메인 관리 작업을 간소화합니다. CIS 콘솔은 개별 변경을 지원하지만, 일괄 작업은 API를 사용하는 것이 가장 좋습니다.

배치 DNS 레코드 API 엔드포인트를 사용하면 단일 요청으로 여러 개의 DELETES, PATCHES, PUTS, POSTS 을 수행할 수 있습니다.

/batch 요청 본문에 포함된 작업은 항상 다음 순서로 처리됩니다:

삭제
패치
PUT
게시물

각 작업 유형 내에서 개별 레코드 변경 사항은 처리되는 순서대로 적용됩니다. 작업 중 하나라도 실패하면 변경 사항이 적용되지 않고 API는 처음 발생하는 오류를 반환합니다.

배치 DNS 레코드에 대한 주요 고려 사항

배치 요청 본문에서 각 작업을 지정할 때 필수 필드와 지정되지 않은 필드가 처리되는 방식에 대한 다음 지침을 따르세요:

Deletes: 각 레코드 객체에는 id 필드만 필요합니다. 명확성을 위해 name 등의 추가 필드를 포함할 수 있지만 다른 모든 필드는 무시됩니다.
Patches: 각 레코드와는 별도로 id, 업데이트할 필드를 지정합니다. 지정되지 않은 모든 필드는 동일하게 유지됩니다.
Puts: 각 레코드의 id, content, name, type 을 지정합니다. 기본값이 아닌 다른 필드도 지정할 수 있습니다. 지정되지 않은 필드는 각 레코드 유형에 대한 기본값을 가정합니다. 이 작업은 덮어쓰기로 작동하므로 레코드의 모든 필드가 항상 영향을 받습니다.
Posts: 새 레코드를 만드는 데 사용됩니다. id 필드는 필수 입력 사항이 아닙니다. 필드 정의는 DNS 레코드 만들기 엔드포인트를 참조하고 요청 본문 사양에서 적절한 레코드 유형을 선택합니다.

요청 예제

이 예제에서 puts 에 나열된 첫 번째 레코드의 프록시 필드는 기본값 false 을 가정합니다.

{
  "deletes": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353"
    }
  ],
  "patches": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353",
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ],
  "posts": [
    {
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ],
  "puts": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353",
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ]
}