Enterprise 고객의 복잡한 요구 사항을 충족하기 위해 새로운 고급 네임서버, 더욱 향상된 복원력, 고급 분석 기능을 갖춘 Foundation DNS의 공식 릴리스를 발표하게 되어 매우 기쁩니다. Foundation DNS는 2010년 릴리스 이후 Cloudflare의 권한 있는 DNS 제품에서 가장 큰 도약을 이룬 제품 중 하나입니다. 저희는 고객이 최고 수준의 성능, 안정성, 보안, 유연성, 고급 분석 기능을 갖춘 엔터프라이즈급 권한 있는 DNS 서비스에 관심을 갖고 있다는 점을 잘 알고 있습니다.
오늘부터, 권한 있는 DNS가 포함된 모든 신규 계약을 체결한 기업에서는 Foundation DNS 기능 세트에 액세스할 수 있게 됩니다. 기존 기업 고객은 올해 Foundation DNS 기능을 사용할 수 있습니다. Cloudflare의 권한 있는 DNS 서비스를 이미 사용하고 있는 기존 기업 고객 중 Foundation DNS를 더 일찍 사용하는 데 관심이 있는 고객은 계정 팀에 연락하시면 사용할 수 있습니다. 이제 시작하겠습니다...
DNS는 왜 그렇게 중요할까요?
최종 사용자 관점에서 보면, DNS는 인터넷을 사용 가능하게 해줍니다. DNS는 www.cloudflare.com과 같은 호스트 이름을 브라우저, 앱, 장치가 서비스에 연결할 때 사용하는 IP 주소로 변환하는 인터넷의 전화번호부입니다. DNS가 없다면 사용자는 모바일 장치나 데스크톱에서 웹 사이트를 방문할 때마다 108.162.193.147 또는 2606:4700:58::adf5:3b93과 같은 IP 주소를 기억해야 합니다. www.cloudflare.com대신 이런 주소를 기억해야 한다고 상상해 보세요. DNS는 소셜 미디어부터 은행 업무, 의료 포털에 이르기까지 인터넷의 모든 최종 사용자 앱에서 사용됩니다. 사람들의 인터넷 사용은 전적으로 DNS에 의존합니다.
비즈니스 관점에서 보면 DNS는 웹 사이트에 도달하고 앱에 연결하는 첫 번째 단계입니다. 장치에서는 어디에 연결해야 하는지 알아야만 서비스에 도달하고, 사용자를 인증하며, 요청되는 정보를 제공할 수 있습니다. DNS 쿼리를 신속하게 해결하는 것은 웹사이트나 앱이 응답성이 있는 것으로 인식되는지 여부를 결정할 수 있으며 사용자 경험에 실질적인 영향을 미칠 수 있습니다.
DNS 중단이 발생하면 그 영향은 명백합니다. 자주 이용하는 전자 상거래 사이트에서, 2016년 Dyn에서 발생한 가동 중단으로 인해 인기 전자 상거래 사이트 여러 사이트가 다운된 것과 마찬가지로 로딩이 되지 않는다고 상상해 보세요. 또는 귀하가 회사에 속해 있고 고객이 귀하가 판매하는 상품이나 서비스를 구매하기 위해 귀하의 웹사이트에 접속할 수 없는 경우 DNS 중단으로 인해 말 그대로 돈을 잃게 됩니다. DNS는 종종 당연한 것으로 여겨지지만, 당연한 게 아닙니다. 제대로 작동하지 않을 때 그 진가를 알게 되니까요. 다행히 Cloudflare의 권한 있는 DNS를 사용한다면 이러한 문제에 대해 크게 걱정하지 않아도 됩니다.
개선의 여지는 항상 있습니다
Cloudflare에서는 10여 년간 권한 있는 DNS 서비스를 제공해 왔습니다. Cloudflare의 권한 있는 DNS 서비스는 다양한 최상위 도메인(TLD)에 걸쳐 수백만 개의 도메인을 호스팅합니다. Cloudflare에서는 레코드 수가 적은 단일 도메인부터 여러 도메인에 수천만 개의 레코드가 분산되어 있는 고객에 이르기까지 모든 규모의 고객을 보유하고 있습니다. Cloudflare의 Enterprise 고객이 DNS 서비스에 대하여 상세한 분석과 더불어 최고 수준의 성능, 안정성, 보안, 유연성을 요구하는 건 당연한 일입니다. 저희 고객은 권한 있는 DNS를 좋아하지만, 저희는 일부 범주에는 항상 개선할 수 있는 여지가 있다는 것을 알고 있습니다. 이를 위해 저희는 구조적 변화와 함께 새로운 기능으로 DNS 아키텍처를 크게 개선했습니다. 이 개선된 서비스를 Foundation DNS라고 부르게 된 것을 자랑스럽게 생각합니다.
Foundation DNS를 만나보세요
Cloudflare의 새로운 엔터프라이즈급 권한 있는 DNS 오퍼링인 Foundation DNS는 기존의 권한 있는 DNS 서비스의 안정성, 보안, 유연성, 분석을 개선하도록 설계되었습니다. Foundation DNS의 자세한 내용을 살펴보기 전에, Foundation DNS가 Cloudflare의 권한 있는 DNS 제품에 제공하는 기능을 간략하게 요약해 보겠습니다.
고급 네임서버 덕분에 DNS 안정성이 한 단계 높아집니다.
새로운 영역 수준 DNS 설정을 이용하면 DNS 관련 설정을 보다 유연하게 구성할 수 있습니다.
계정 및 영역별로 고유한 DNSSEC 키를 이용하므로 DNSSEC에 추가 보안과 유연성이 제공됩니다.
GraphQL 기반 DNS 분석으로 DNS 쿼리에 대해 더 많은 인사이트가 제공됩니다.
새로운 릴리스 프로세스를 통해 Enterprise 요금제 고객은 최고의 안정성과 신뢰성을 누릴 수 있습니다.
더 많은 DNS 전용 영역 및 DNS 레코드 할당량이 주어지는 더 단순한 DNS 가격 정책.
이제 이 새로운 Foundation DNS의 기능을 자세히 살펴보겠습니다.
고급 네임서버
Cloludflare에서는 Foundation DNS를 통해 기업의 안정성을 높이는 데 특히 중점을 둔 고급 네임서버를 도입합니다. 여러분은 영역별로 페어를 이루어 제공되고 cloudflare.com 도메인 내의 이름을 사용하는 Cloudflare의 권한 네임서버에는 익숙할 것입니다. 예를 들면 다음과 같습니다.
이제 Foundation DNS 고급 네임서버를 사용하는 동일한 영역을 살펴보겠습니다.
$ dig mycoolwebpage.xyz ns +noall +answer
mycoolwebpage.xyz. 86400 IN NS kelly.ns.cloudflare.com.
mycoolwebpage.xyz. 86400 IN NS christian.ns.cloudflare.com.고급 네임서버의 안정성은 몇 가지 방식으로 개선됩니다. 첫 번째 개선점은 Foundation DNS 권한 서버가 여러 TLD에 걸쳐 분산되어 있다는 점입니다. 따라서 TLD 네임서버를 포함하여 트리 상위에 있는 DNS 인프라에 잠재적으로 영향을 미칠 수 있는 대규모 DNS 중단 및 DDoS 공격으로부터 보호됩니다. Foundation DNS 권한 네임서버는 이제 글로벌 DNS 트리 구조의 여러 분기에 걸쳐 위치하여 고객을 이러한 잠재적인 중단과 공격으로부터 더욱 안전하게 보호합니다.
$ dig mycoolwebpage.xyz ns +noall +answer
mycoolwebpage.xyz. 86400 IN NS blue.foundationdns.com.
mycoolwebpage.xyz. 86400 IN NS blue.foundationdns.net.
mycoolwebpage.xyz. 86400 IN NS blue.foundationdns.org.여러분은 Foundation DNS에 등록된 네임서버가 추가로 있다는 것을 알아차렸을 수도 있습니다. 이는 개선 사항이지만, 여러분이 생각하실 수 있는 이유 때문은 아닙니다. 이러한 네임서버 각각을 해당 IP 주소로 확인하면 조금 더 이해하기 쉬워집니다. 이제 Cloudflare의 표준 네임서버부터 설명하겠습니다.
두 네임서버에는 총 6개의 IP 주소가 있습니다. 실제로 DNS 확인자가 권한 네임서버를 쿼리할 때 가장 중요하게 여기는 것은 바로 이 부분입니다. DNS 확인자는 일반적으로 권한 있는 서버의 실제 도메인 이름을 추적하지 않습니다. 주어진 도메인에 대한 쿼리를 해결하는 데 사용할 수 있는 정렬되지 않은 IP 주소 목록을 유지하기만 합니다. 따라서 Cloudflare에서는 표준 권한 네임서버를 이용해 DNS 쿼리를 해결하는 데 사용할 수 있는 6개의 IP 주소를 확인자에게 제공합니다. 이제 Foundation DNS 고급 네임서버의 IP 주소를 살펴보겠습니다.
$ dig kelly.ns.cloudflare.com. +noall +answer
kelly.ns.cloudflare.com. 86353 IN A 108.162.194.91
kelly.ns.cloudflare.com. 86353 IN A 162.159.38.91
kelly.ns.cloudflare.com. 86353 IN A 172.64.34.91
$ dig christian.ns.cloudflare.com. +noall +answer
christian.ns.cloudflare.com. 86353 IN A 108.162.195.247
christian.ns.cloudflare.com. 86353 IN A 162.159.44.247
christian.ns.cloudflare.com. 86353 IN A 172.64.35.247자세히 보실까요? Foundation DNS는 특정 영역에 제공하는 것과 동일한 IP 주소를 권한 네임서버 각각에 제공합니다. 따라서 이 경우 확인자가 DNS 쿼리를 해결하는 데 사용할 수 있는 3개의 IP 주소만 제공했습니다. 그리고 여러분은 "6개가 3보다 낫지 않나요? 다운그레이드가 아닌가요?”라고 궁금해 하실 수 있습니다. 많다고 해서 항상 더 좋은 건 아닙니다. 이제 그 이유를 살펴보겠습니다.
$ dig blue.foundationdns.com. +noall +answer
blue.foundationdns.com. 300 IN A 108.162.198.1
blue.foundationdns.com. 300 IN A 162.159.60.1
blue.foundationdns.com. 300 IN A 172.64.40.1
$ dig blue.foundationdns.net. +noall +answer
blue.foundationdns.net. 300 IN A 108.162.198.1
blue.foundationdns.net. 300 IN A 162.159.60.1
blue.foundationdns.net. 300 IN A 172.64.40.1
$ dig blue.foundationdns.org. +noall +answer
blue.foundationdns.org. 300 IN A 108.162.198.1
blue.foundationdns.org. 300 IN A 162.159.60.1
blue.foundationdns.org. 300 IN A 172.64.40.1아마 여러분은 Cloudflare에서 Anycast를 사용한다는 것을 알고 계실 것입니다. 짐작하실 수 있듯이 저희 DNS 서비스는 Anycast를 활용하여 당사의 권한 있는 DNS 서버를 전 세계적으로 사용할 수 있고 인터넷을 통해 사용자 및 확인자에게 최대한 가깝게 사용할 수 있도록 보장합니다. 저희 표준 네임서버는 모두 단일 Anycast 그룹에서 모든 Cloudflare 데이터 센터에서 광고합니다. 유럽을 클로즈업해서 보면 표준 네임서버 배포에서 두 네임서버가 모든 데이터 센터에서 광고된다는 것을 알 수 있습니다.
위의 표준 네임서버에서 6개의 IP 주소를 가져와 "hostname.bind" TXT 레코드를 조회하면 DNS 쿼리가 확인되는 가장 가까운 데이터 센터의 공항 코드 또는 물리적 위치가 표시됩니다. 이 결과는 많다고 해서 항상 더 좋은 건 아닌 이유를 설명하는 데 도움이 됩니다.
보시다시피 런던 근처에서 쿼리하면 해당 IP 주소 6개가 모두 동일한 런던(LHR) 데이터 센터로 라우팅됩니다. 이는 런던에 있는 확인자가 Cloudflare의 표준 권한 DNS를 사용하여 도메인에 대한 DNS 쿼리를 확인하면 쿼리 중인 네임서버 IP 주소와 관계없이 항상 동일한 물리적 위치에 연결된다는 것을 의미합니다.
$ dig @108.162.194.91 ch txt hostname.bind +short
"LHR"
$ dig @162.159.38.91 ch txt hostname.bind +short
"LHR"
$ dig @172.64.34.91 ch txt hostname.bind +short
"LHR"
$ dig @108.162.195.247 ch txt hostname.bind +short
"LHR"
$ dig @162.159.44.247 ch txt hostname.bind +short
"LHR"
$ dig @172.64.35.247 ch txt hostname.bind +short
"LHR"여러분은 "그래서요? 그게 저한테 무슨 의미가 있나요?"라고 질문할 수 있습니다. 예를 들어 보겠습니다. 여러분이 런던의 Cloudflare 표준 네임서버를 사용하여 도메인을 확인하려고 하고 저도 런던에 있는 공용 확인자를 사용하고 있는 경우, 확인자는 연결하려는 네임서버와 관계없이 항상 Cloudflare LHR 데이터 센터에 연결합니다. Anycast 때문에 다른 옵션이 없습니다.
Anycast 때문에 LHR 데이터 센터가 완전히 오프라인 상태가 되더라도 LHR에 대한 모든 트래픽은 인근의 다른 데이터 센터로 라우팅되고 확인자는 계속해서 정상 작동합니다. 그러나 LHR 데이터 센터가 온라인이었지만 DNS 서비스가 DNS 쿼리에 응답할 수 없는 드문 시나리오에서는 확인자가 다른 데이터 센터에 접근할 수 없으므로 이러한 DNS 쿼리를 해결할 방법이 없습니다. 100개의 IP 주소가 있을 수 있었지만, 이 시나리오에는 도움이 되지 않습니다. 결국 캐시된 응답이 만료되고 도메인은 더 이상 확인되지 않게 됩니다.
Foundation DNS 고급 네임서버는 저희가 두 개의 Anycast 그룹을 활용하여 Anycast를 사용하는 방식을 바꾸고 있습니다. 이는 모든 데이터 센터에서 광고되는 모든 권한 네임서버 IP의 이전 패러다임을 깨뜨립니다. 두 개의 Anycast 그룹을 사용한다는 것은 Foundation DNS 권한 네임서버가 각 데이터 센터에서 모든 위치를 알리는 대신 실제로 서로 다른 물리적 위치를 가지고 있음을 의미합니다. 동일한 지역에서 두 개의 Anycast 그룹을 사용하면 다음과 같은 모습이 됩니다.
다시 돌아가서, Foundation DNS가 네임서버 광고를 위해 두 개의 Anycast 그룹을 사용하고 있다는 사실을 알게 되었으므로 표준 권한 DNS의 권한 있는 IP 주소 6개와 Foundation DNS의 IP 주소 3개의 비교를 마무리합니다. 이 예시를 위해 Foundation DNS 서버가 광고되는 위치를 살펴보겠습니다.
자세히 보시겠어요? 세 개의 네임서버 IP 주소 중 하나가 다른 데이터 센터인 맨체스터(MAN)에서 광고되고 있어 앞서 언급한 중단 시나리오에 대해 Foundation DNS를 더욱 안정적이고 탄력적으로 만들 수 있습니다. 일부 도시에서는 Cloudflare가 여러 데이터 센터에서 운영되므로 세 가지 쿼리가 모두 동일한 공항 코드를 반환한다는 점을 주목할 필요가 있습니다. 저희는 해당 IP 주소 중 적어도 하나가 다른 데이터 센터에서 광고되고 있음을 보장하지만, 일부 고객이 직접 테스트하고 싶어할 수도 있음을 이해합니다. 이러한 경우 추가 쿼리를 통해 IP 주소가 다른 데이터 센터에서 광고되고 있음이 표시될 수 있습니다.
$ dig @108.162.198.1 ch txt hostname.bind +short
"LHR"
$ dig @162.159.60.1 ch txt hostname.bind +short
"LHR"
$ dig @172.64.40.1 ch txt hostname.bind +short
"MAN"굵은 글자체로 표시된 텍스트에서 "m" 앞의 숫자는 쿼리에 응답한 데이터 센터를 나타냅니다. 세 가지 응답 중 하나에서 그 숫자가 다르면, Foundation DNS의 권한 네임서버 중 하나가 다른 물리적 위치에서 광고되고 있음을 알 수 있습니다.
$ dig @108.162.198.1 +nsid | grep NSID:
; NSID: 39 34 6d 33 39 ("94m39")두 개의 Anycast 그룹을 활용하는 Foundation DNS를 사용하면 이전 중단 시나리오를 원활하게 처리할 수 있습니다. DNS 확인자는 지정된 도메인에 대해 반환된 모든 권한 네임서버에 대한 요청을 모니터링하지만, 주로 가장 빠른 응답을 제공하는 네임서버를 사용합니다.
이 구성에서는 DNS 확인자가 두 개의 서로 다른 Cloudflare 데이터 센터에 요청을 보낼 수 있으므로, 물리적 위치 한 곳에서 장애가 발생하는 경우 쿼리를 자동으로 적절하게 해결할 수 있는 두 번째 데이터 센터로 전송합니다.
Foundation DNS 고급 네임서버는 기업 고객의 안정성을 크게 향상시킵니다. Enterprise 고객이 기존 영역에 대해 고급 네임서버를 활성화하는 것을 환영합니다. Foundation DNS로 마이그레이션하더라도 다운타임은 발생하지 않습니다. 왜냐하면 Foundation DNS 고급 네임서버가 영역에 대해 활성화된 후에도 이전의 표준 권한 DNS 네임서버가 계속 작동하고 해당 영역에 대한 쿼리에 응답하기 때문입니다. 고객은 Foundation DNS 고급 네임서버로 마이그레이션하기 위해 전환을 계획하거나 기타 서비스에 영향을 미치는 이벤트를 진행할 필요는 없습니다.
새로운 영역 수준 DNS 설정
지금까지 저희는 Enterprise 고객으로부터 보조 DNS 재정의를 활성화하는 등 API 또는 대시보드를 통해 노출되지 않은 특정 DNS 설정을 조정해 달라는 요청을 계속 받아왔습니다. 고객이 이러한 설정 조정을 원하려면 구성을 변경해 줄 계정팀에 연락해야 했습니다. Cloudflare에서는 Foundation DNS를 기반으로 API와 대시보드를 통해 가장 일반적으로 요청되는 설정을 노출하여 고객이 Cloudflare의 권한 있는 DNS 솔루션을 이용하여 더 많은 유연성을 얻도록 지원합니다.
이제 Enterprise 고객은 해당 영역에서 다음 DNS 설정을 구성할 수 있습니다.
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-buh4{background-color:#f9f9f9;text-align:left;vertical-align:top} .tg .tg-p7vi{background-color:#C9DAF8;font-weight:bold;text-align:left;vertical-align:top} .tg .tg-68av{background-color:#f9f9f9;color:#15C;text-align:left;vertical-align:top} .tg .tg-zb5k{color:#15C;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top}
| Setting | Zone Type | Description |
|---|---|---|
| Foundation DNS advanced nameservers | Primary and secondary zones | Allows you to enable advanced nameservers on your zone. |
| Secondary DNS override | Secondary zones | Allows you to enable Secondary DNS Override on your zone in order to proxy HTTP/S traffic through Cloudflare. |
| Multi-provider DNS | Primary and secondary zones | Allows you to have multiple authoritative DNS providers while using Cloudflare as a primary nameserver. |
설정
영역 유형
설명
기본 및 보조 영역
귀하의 영역에서 고급 네임서버를 활성화할 수 있습니다.
보조 영역
영역에서 보조 DNS 재정의를 활성화하여 Cloudflare를 통해 HTTP/S 트래픽을 프록시할 수 있습니다.
{
"query": "{
viewer {
zones(filter: { zoneTag: $zoneTag }) {
dnsAnalyticsAdaptiveGroups(
filter: $filter
limit: 10
orderBy: [datetime_ASC]
) {
avg {
processingTimeUs
}
quantiles {
processingTimeUsP90
}
dimensions {
datetimeFifteenMinutes
sourceIP
}
}
}
}
}",
"variables": {
"zoneTag": "<zone-tag>",
"filter": {
"datetime_geq": "2024-05-01T00:00:00Z",
"datetime_leq": "2024-06-01T00:00:00Z"
}
}
}기본 및 보조 영역
Cloudflare를 기본 네임서버로 사용하면서 권한 있는 DNS 공급자를 여러 곳 보유할 수 있습니다.
계정 및 영역별로 고유한 DNSSEC 키
도메인 네임 시스템 보안 확장(Domain Name System Security Extensions)을 의미하는 DNSSEC는 DNS 쿼리에 대해 수신하는 응답이 신뢰할 수 있고 수정되지 않았는지 확인하는 방법을 제공하여 도메인 또는 영역에 보안을 추가합니다. DNSSEC는 DNS 확인자가 올바른 IP 주소로 DNS 쿼리에 응답할 수 있도록 하는 DNS 캐시 포이즈닝(DNS 스푸핑)을 방지합니다.
Cloudflare에서는 2015년 범용 DNSSEC를 릴리스한 이래, 보조 영역 및 다중 서명자 DNSSEC를 위한 미리 서명된 DNSSEC에 대한 지원을 추가하는 등 몇 가지 개선 사항을 거쳤습니다. 기본적으로, Cloudflare에서는 DNS 쿼리에 응답할 때 즉시 DNS 레코드에 서명(라이브 서명)합니다. 이를 통해 Cloudflare에서는 DNSSEC로 보호되는 도메인을 호스팅하면서도 프록시 설정된 원본에 IP 주소를 동적으로 할당할 수 있습니다. 또한 이러한 경우 DNS 응답에서 제공되는 IP 주소가 스티어링에 따라 변경되므로 특정 부하 분산 사용 사례가 가능합니다.
Cloudflare에서는 현재 사용되는 대부분의 RSA 키보다 강력한 타원 곡선 알고리즘인 ECDSA P-256을 사용합니다. CPU를 덜 사용하여 서명을 생성하므로 즉석에서 더 효율적으로 생성할 수 있습니다. 일반적으로 DNSSEC의 일부로 영역 서명 키(ZSK)와 키 서명 키(KSK) 등 두 개가 사용됩니다. 가장 간단한 수준에서 ZSK는 쿼리에 대한 응답으로 제공되는 DNS 레코드에 서명하는 데 사용되며, KSK는 신뢰성을 보장하기 위해 ZSK를 포함한 DNSKEY에 서명하는 데 사용됩니다.
현재 Cloudflare는 모든 DNSSEC 서명에 ZSK와 KSK를 공유하고 있으며, 강력한 암호화 알고리즘을 사용하고 있으므로 이 키 집합이 얼마나 안전한지 알고 있으며, 정기적으로 ZSK나 KSK를 교체할 필요는 없습니다. KSK – 최소한 보안상의 이유로. 그러나 특정 간격으로 이러한 키를 교체하도록 요구하는 정책을 가진 고객이 있습니다. 이 때문에 필요에 따라 계정 또는 존별로 ZSK와 KSK를 모두 교체할 수 있는 새로운 Foundation DNS 고급 네임서버 기능을 추가했습니다. 이 기능은 먼저 API를 통해 제공되고, 이후 Cloudflare 대시보드를 통해서도 제공될 것입니다. 이제, DNSSEC 키 교체에 대한 엄격한 정책 요구 사항이 있는 고객은 Cloudflare Foundation DNS를 통해 이러한 요구 사항을 충족할 수 있습니다.
GraphQL 기반 DNS 분석
익숙하지 않은 분을 위해 설명하자면, GraphQL은 API용 쿼리 언어이자 해당 쿼리를 실행하기 위한 런타임입니다. 클라이언트가 더하지도 않고 덜하지도 않게 필요한 것을 정확히 요청할 수 있게 되므로, 단일 API 호출을 통해 여러 소스의 데이터를 집계할 수 있으며, 구독을 통해 실시간 업데이트를 지원할 수 있습니다.
아시겠지만, Cloudflare에서 GraphQL API를 지원한 지 꽤 오래되었지만, 이번에 Foundation DNS의 일부로 이 API에 새로운 DNS 데이터 세트를 추가하며, 이는 새로운 Foundation DNS 고급 네임서버를 통해서만 제공될 수 있습니다.
GraphQL API의 새로운 DNS 데이터 세트는 영역에서 수신한 DNS 쿼리에 대한 정보를 가져오는 데 사용할 수 있습니다. 현재의 DNS Analytics API를 대체하는 더 빠르고 강력한 솔루션을 사용하면, 제약이나 제한 시간 초과 없이 장기간의 데이터를 빠르고 효율적으로 쿼리할 수 있습니다. GraphQL API는 수락하는 쿼리와 관련하여 더 유연하며, DNS Analytics API보다 더 많은 정보를 노출합니다.
예를 들어, 이 쿼리를 실행하여 소스 IP 주소별로 그룹화된 쿼리의 평균 및 90번째 백분위수 처리 시간을 15분 버킷으로 가져올 수 있습니다. 이와 같은 쿼리는 지정된 시간 범위 동안 어떤 IPS가 레코드를 가장 자주 쿼리하는지 확인하는 데 유용합니다.
이전에는 이와 같은 쿼리가 여러 가지 이유로 불가능했습니다. 첫 번째 이유는 소스 IP와 같은 새로운 필드를 추가했기 때문에, 이를 사용하면 DNS 쿼리를 생성하는 클라이언트 IP 주소(일반적으로 확인자)를 기반으로 데이터를 필터링할 수 있다는 점입니다. 두 번째 이유는 GraphQL API 쿼리가 훨씬 더 긴 시간 범위의 데이터를 처리하고 반환할 수 있기 때문입니다. 충분히 많은 양의 쿼리를 가진 DNS 영역은 이전에는 며칠 동안만 트래픽을 쿼리할 수 있었지만, 새로운 GraphQL API는 최대 31일 동안의 데이터를 제공할 수 있습니다. 저희는 해당 범위를 추가로 개선할 계획이며, 기록 데이터를 더 오래 저장하고 쿼리할 방법을 모색하고 있습니다.
GraphQL API를 사용하면 새로운 DNS 분석 섹션을 Cloudflare 대시보드에 추가할 수도 있습니다. 고객은 가장 많이 쿼리된 레코드를 추적하고, 해당 쿼리에 응답하는 데이터 센터를 확인하며, 쿼리가 얼마나 많이 생성되는지 등을 확인할 수 있습니다.
Cloudflare GraphQL API의 새로운 DNS 데이터 세트와 새로운 DNS 분석 페이지가 함께 작동하므로 Cloudflare DNS 고객은 Foundation DNS 배포를 모니터링하고 분석하며 문제를 해결하는 데 도움을 받을 수 있습니다.
새로운 릴리스 프로세스
Cloudflare의 권한 있는 DNS 제품은 일주일에 한 번 꼴로 소프트웨어 업데이트를 받습니다. Cloudflare에서는 회귀가 프로덕션 트래픽에 영향을 주지 않게 해주는 정교한 릴리스 프로세스를 갖추고 있습니다. 흔하지는 않지만, 프로덕션 트래픽의 양과 고유성이 새 릴리스에 영향을 미칠 때에만 문제가 표면화될 수 있습니다.
Enterprise 고객은 새로운 기능보다 안정성을 더 원하므로 새로운 릴리스는 Foundation DNS 고급 네임서버를 업그레이드하기 전에 표준 네임서버에서 2주간의 흡수 시간을 거쳐야 합니다. 2주 동안 문제가 없으면, Foundation DNS 고급 네임서버도 업그레이드 됩니다.
Foundation DNS 고급 네임서버를 사용하는 영역에서는 새 소프트웨어 릴리스에서 회귀 방지 기능이 강화되어 안정성이 향상됩니다.
더 단순한 DNS 가격 정책
지금까지는 Cloudflare 월별 DNS 쿼리와 계정 내 도메인 수를 기반으로 권한 있는 DNS에 대하여 요금을 부과해 왔습니다. Enterprise DNS 고객은 Cloudflare에서 호스팅되는 DNS 영역인 DNS 전용 영역에 관심이 많은데, 이는 Cloudflare의 CDN, WAF, 봇 관리 등의 리버스 프록시(계층 7) 서비스를 사용하지 않는 DNS 영역입니다. Foundation DNS의 경우 기본적으로 10,000개의 DNS 전용 도메인을 포함하여 대다수 고객을 위한 가격 책정이 더 단순해집니다. 이러한 변경으로 인해 대부분의 고객은 사용한 DNS 쿼리 수에 대해서만 비용을 지불하게 됩니다.
또한 계정의 모든 도메인에 걸쳐 100만 개의 DNS 레코드가 포함됩니다. 하지만 그렇다고 해서 더 많은 지원을 받을 수 없는 것은 아닙니다. 실제로, Cloudflare 플랫폼의 가장 큰 단일 영역에는 390만 개 이상의 레코드가 있는 반면, 여러 영역에 분산되어 있는 가장 큰 DNS 계정은 3,000만 개에 조금 못 미칩니다. Cloudflare DNS를 사용하면 가장 큰 규모의 배포를 처리하는 데 문제가 없습니다.
앞으로 더 많은 기능을 발표합니다
이제 시작일 뿐이며, 향후 Foundation DNS 전용 기능을 더 추가할 예정입니다. 한 가지 예로, 요청이 많았던 레코드별 범위 API 토큰 및 사용자 권한 기능이 있습니다. 이를 통해 훨씬 더 세밀한 수준에서 권한을 구성할 수 있습니다. 예를 들어, 계정의 특정 회원이 TXT 및 MX 유형의 레코드만 생성하고 관리할 수 있도록 지정할 수 있으므로 도메인의 웹 트래픽에 영향을 미치는 주소 레코드가 실수로 삭제되거나 편집되는 일이 발생하지 않습니다. 또 하나의 예는 하위 도메인에 따라 권한을 지정하여 특정 사용자의 범위를 추가로 제한하는 것입니다.
Foundation DNS를 사용하고자 하는 기존 Enterprise 고객께서는 계정 팀에 연락하여 계정에 Foundation DNS를 프로비저닝하시기 바랍니다.