오늘 우리는 비할 데 없는 신뢰성과 최고의 성능을 제공하며 인프라 팀의 가장 복잡한 요구사항을 충족할 수 있는 Cloudflare의 새로운 프리미엄 DNS 오퍼링인 Foundation DNS를 발표하려고 합니다.
먼저 비용 측면을 얘기해 보겠습니다
귀사가 엔터프라이즈 DNS 계약에 서명할 때 일반적으로 DNS 제공자는 견적을 내기 위해 다음 세 가지를 입력해줄 것을 요청합니다.
- 구역 수
- 월별 총 DNS 쿼리
- 모든 구역의 총 DNS 레코드
어떤 업체는 상당히 복잡하고 어떤 업체는 가격 계산기나 불분명한 “문의 요망” 가격이 있습니다. 어떻게 성장할 것인가를 중심으로 귀사에서 예산을 책정하는 것은 불필요한 복잡성이 초래되며, 우리가 더 잘할 수 있다고 생각합니다. 왜 이것을 더 간단하게 만들면 안 될까요? 여기에 답이 있습니다. 우리는 기업 고객의 단 한 가지 입력을 바탕으로 Foundation DNS 사용료를 청구하기로 결정했습니다. 그 입력은 월별 총 DNS 쿼리입니다. 이에 따라 기업의 비용이 절감되고 더 중요하게는 DNS 청구서가 더 단순화되리라고 기대할 수 있습니다.
걱정 마세요. 우리의 다른 제품과 마찬가지로 DDoS 완화는 계속 계량되지 않습니다. 귀사의 이름 서버가 DDoS 공격을 받거나 DNS 쿼리가 한두 달 한도를 초과할 경우에도 숨겨진 초과 요금이 없습니다.
DNS는 왜 그렇게 중요할까요?
도메인 네임 시스템(DNS)은 거의 인터넷 자체만큼 오래되었습니다. 이것은 호스트 이름과 IP 주소 간의 매핑을 제공할 목적으로 원래 1983년 RFC882와 RFC883에 정의된 것입니다. 그때 작성자들은 현명하게도 다음과 같이 말했습니다. “[인터넷]은 거대한 시스템으로, 훨씬 더 커질 가능성이 높다.” [RFC882]. 오늘날 가장 큰 최상위 수준 도메인(TLD) 가운데 하나인 .com 아래에만 1억 6천만여 개의 도메인 이름이 있습니다[출처].
DNS는 설계상 계층적이며 매우 분산된 시스템이지만, 일반적으로 최종 사용자는 인터넷 서비스 공급자(ISP)가 지정하거나 운영하거나 고용주나 사용자 자신이 직접 구성하는 리졸버(1)와만 통신합니다. 리졸버는 루트 서버(2) 중 하나, 담당 TLD 서버(3), 그리고 해당 도메인의 권한 있는 이름 서버(4)와 통신합니다. 많은 경우 이 네 가지는 모두 다른 기관에서 운영하며 다른 지역(대륙일 수도 있음)에 위치합니다.
최근에 보았듯이, DNS 인프라가 다운되면 곤란에 처하게 되며 많은 비용이 유발되고 평판이 훼손될 수도 있습니다. 그래서 도메인 소유자는 자신의 도메인에 대한 DNS 룩업이 항상 그리고 이상적일 경우 최대한 빨리 응답되기를 원합니다. 그러면 무엇을 할 수 있을까요? 사용자들이 구성한 리졸버에 영향을 줄 수는 없습니다. 루트 서버에도 영향을 줄 수 없습니다. 각각의 TLD를 가지는 도메인 네임을 선택하여 관계된 TLD 서버를 선택할 수 있습니다. 하지만 어떤 이유로 특정 TLD에 묶여 있다면 이것도 통제권 밖에 있습니다. 쉽게 영향을 줄 수 있는 것은 권한 있는 이름 서버의 공급자입니다. 그러면 Cloudflare의 권한 있는 DNS를 더 자세히 살펴보겠습니다.
Cloudflare의 권한 있는 DNS 살펴보기
권한 있는 DNS는 당사의 가장 오래된 제품 중 하나로, 이 제품을 개선하는 데 많은 시간을 들였습니다. 모든 DNS 쿼리가 250개 이상의 도시에 있는 당사의 전역 Anycast 네트워크로부터 응답됩니다. 이런 식으로 최고의 성능을 제공하면서 항상 글로벌 가용성을 보장할 수 있습니다. 당연히, 당사는 DDoS 공격 완화에 대한 풍부한 경험을 활용하여 누구도 우리의 이름 서버와 고객들의 도메인을 다운시키지 못하게 합니다.
Magic Transit이 출시되기 전까지, DNS는 고객 응용 프로그램을 보호하고 가속화하기 위해 인터넷의 모든 사용자를 Cloudflare에 안내하는 방법이었기 때문에 Cloudflare에게 매우 중요합니다. 우리의 DNS 응답이 느렸다면 Cloudflare도 느렸습니다. 우리의 DNS 응답을 사용할 수 없었다면 Cloudflare도 사용할 수 없었습니다. 권한 있는 DNS의 속도와 신뢰성은 Cloudflare의 속도와 신뢰성에 가장 중요하며 고객들에게도 마찬가지입니다. 또한 우리는 고객들이 Cloudflare와 함께 성장함에 따라 우리의 DNS 인프라를 발전시키도록 했습니다. 현재 우리의 최대 고객 존에는 3백만 개 이상의 레코드가 있고 상위 5곳의 레코드를 합하면 거의 천만 개에 달합니다. 이 고객들은 Cloudflare에 의지하여 몇 분이 아닌 몇 초만에 새로운 DNS 레코드 업데이트를 우리 쪽으로 보냅니다. 이러한 중요성과 고객들의 필요 때문에 우리는 지난 수년 간DNS 스택의 속도와 신뢰성을 유지하는 데 초점을 맞춘 전담 DNS 엔지니어링 팀을 성장시켜 왔습니다.
DNS 생태계의 보안 역시 중요합니다. Cloudflare는 항상 DNSSEC을 지지해 왔습니다. DNSSEC을 통해 DNS 응답을 서명하고 확인하면 경로상 공격자가 응답을 가로채서 트래픽을 재지정할 수 없게 됩니다. Cloudflare는 항상 모든 요금제 수준에서 DNSSEC을 무료로 제공해 왔으며 앞으로도 Foundation DNS에 대해서 유료 옵션은 없을 것입니다. Cloudflare를 등록 기관으로도 사용하는 고객들의 경우, DNSSEC의 간단한 원클릭 배치는 고객 도메인이 오용되지 않게 하고 사용자를 보호하는 또 다른 핵심 특징입니다. 우리는 외부 등록 기관에의 원클릭 배치를 위한 RFC 8078도 지원합니다.
하지만 인터넷의 각 부분을 정지시킬 수 있는 다른 문제들이 있으며 이 문제들은 대부분 통제를 벗어나 있는데, 경로 유출이나 더 나쁠 경우 경로 가로채기가 그것입니다. DNSSEC은 경로 가로채기를 완화하는 데 도움을 줄 수 있지만, 아쉽게도 모든 재귀 리졸버가 DNSSEC을 확인하는 것은 아닙니다. 그리고 리졸버가 확인할 경우에도 경로 유출이나 이름 서버 가로채기는 여전히 정지 시간을 초래합니다. 귀사의 이름 서버 IP 모두가 이런 이벤트의 영향을 받는다면 귀사의 도메인을 리졸빙할 수 없게 됩니다.
많은 공급자의 경우 일반적으로 귀사의 이름 서버 각각이 단 하나의 IPv4 및 IPv6 주소로 리졸빙됩니다. 해당 IP 주소에 도달할 수 없다면 — 예를 들면 망 혼잡이나 더 나쁠 경우 경로 유출이 원인일 텐데 — 전체 이름 서버를 사용할 수 없게 되어 도메인을 리졸빙할 수 없게 됩니다. 설상가상으로 일부 공급자는 모든 이름 서버에 동일한 IP 서브넷을 사용하기도 합니다. 따라서 해당 서브넷에 문제가 있으면 모든 이름 서버가 다운됩니다.
예를 들어보겠습니다.
$ dig aws.com ns +short
$ dig aws.com ns +short
ns-1500.awsdns-59.org.
ns-164.awsdns-20.com.
ns-2028.awsdns-61.co.uk.
ns-917.awsdns-50.net.
$ dig ns-1500.awsdns-59.org. +short
205.251.197.220
$ dig ns-164.awsdns-20.com. +short
205.251.192.164
$ dig ns-2028.awsdns-61.co.uk. +short
205.251.199.236
$ dig ns-917.awsdns-50.net. +short
205.251.195.149
모든 이름 서버 IP는 205.251.192.0/21의 일부입니다. 다행스럽게도, AWS는 이제 RPKI를 통해 범위에 서명하고 있어서 유출 가능성이 적어집니다(단, 리졸버 ISP가 RPKI를 확인해야 합니다). 하지만 리졸버 ISP가 RPKI를 확인하지 않아서 해당 서브넷이 유출되거나 가로채기를 당한다면 리졸버가 이름 서버에 도달할 수 없게 되고 aws.com을 리졸빙할 수 없게 될 것입니다.
Cloudflare가 우리의 모든 경로에 서명하고 인터넷의 나머지 부분이 경로 유출의 영향을 최소화하도록 도울 것이라는 점은 두말할 필요도 없지만 RPKI가 보편적으로 배치될 때까지 우리의 DNS 시스템이 경로 유출 시 회복력을 유지하도록 하려면 그 밖에 또 무엇을 할 수 있을까요?
현재 Free, Pro, Business, Enterprise 요금제로 Cloudflare DNS를 사용하고 계신다면 귀사 도메인에 2개의 이름 서버가 제공되는데, 구조는 <name>.ns.cloudflare.com이 되고 여기서 <name>은 무작위 이름입니다.
$ dig isbgpsafeyet.com ns +short
tom.ns.cloudflare.com.
kami.ns.cloudflare.com.
이제, 앞에서 보았듯이 도메인을 사용할 수 있으려면 도메인의 이름 서버를 사용할 수 있어야 합니다. 그래서 이런 이름 서버 각각이 3개의 Anycast IPv4 주소와 3개의 Anycast IPv6 주소로 리졸빙됩니다.
$ dig tom.ns.cloudflare.com a +short
173.245.59.147
108.162.193.147
172.64.33.147
$ dig tom.ns.cloudflare.com aaaa +short
2606:4700:58::adf5:3b93
2803:f800:50::6ca2:c193
2a06:98c1:50::ac40:2193
여기서 주목해야 할 필수 사항은 이 3개의 IPv4 주소와 3개의 IPv6 주소 각각이 다른 /8 IPv4(IPv6는 /45) 블록에서 나온다는 점입니다. 따라서 IPv4를 통해 귀사의 이름 서버를 사용할 수 없게 되려면 경로 유출이 정확히 3개의 /8 IPv4 블록 모두에 대한 해당 서브넷에 영향을 줘야 할 것입니다. 이런 종류의 이벤트는 이론상으로는 가능하지만 실제로는 거의 불가능합니다.
이것을 어떻게 하면 더 개선할 수 있을까요?
Foundation DNS를 사용하는 고객들에게는 foundationdns.com과 foundationdns.net에 호스팅되는 새로운 고급 이름 서버 세트가 할당됩니다. 이 이름 서버들은 기본 Cloudflare 이름 서버들보다 훨씬 더 회복력이 좋습니다. 내년 초에 이 기술을 어떻게 달성할 것인지 자세한 내용을 발표할 예정이니 계속 관심을 가져주시기 바랍니다. 모든 외부 Cloudflare 도메인(예: cloudflare.com)은 내년에 이 이름 서버들로 이전됩니다.
이것으로 끝이 아닙니다
요청이 쇄도했던 두 가지 기능의 출시를 발표하게 되어 기쁩니다.
- 보조 DNS에 대한 발신 존 이전 지원
- 권한 있는 보조 DNS 쿼리에 대한 로그 푸시
둘 다 Foundation DNS의 일부로 제공될 것이며 Enterprise 고객에게는 추가 비용이 없습니다. 이 기능들 각각과 이것들이 어떻게 우리의 DNS 오퍼링을 훨씬 더 좋게 만드는지 자세히 알아보겠습니다.
보조 DNS에 대한 발신 존 이전 지원
보조 DNS는 무엇이고 왜 중요할까요? 많은 대기업은 한 공급자를 이용할 수 없을 경우에 대비하여 중복성을 위해 둘 이상의 DNS 공급자를 사용할 필요가 있습니다. 대기업은 자사 도메인의 DNS 레코드를 2개의 독립된 플랫폼에 추가하고 수동으로 존 파일을 동기화하는데, 이것을 “다중-주요” 설정이라고 합니다. 보조 DNS에 대해서는 두 가지 메커니즘을 통해 “주요-보조” 설정을 사용하여 이것을 자동화할 수 있습니다.
- DNS 알림: 주요 이름 서버가 보조 서버에게 존의 모든 변경 사항을 알립니다. 보조 서버가 알림을 수신하면 주요 서버에 존 이전 요청을 보내서 주요 서버와 동기화합니다.
- SOA 쿼리: 여기서는, 보조 이름 서버가 정기적으로 존의 SOA 레코드를 쿼리하고 SOA 레코드에서 찾을 수 있는 일련번호가 보조 서버가 자신의 존 SOA 레코드에 저장한 최근 일련번호와 동일한지 확인합니다. 존의 새 버전을 사용할 수 있는 경우 주요 서버에 존 이전 요청을 보내서 해당 변경 사항을 받습니다.
자세한 내용이 궁금하시면 보조 DNS가 이면에서 작동하는 방식에 관한 알렉스 파투셰의 아주 통찰력 있는 블로그 게시물을 참조하시기 바랍니다. 주요-보조 설정의 또 다른 장점은 주요 서버를 숨기는 것인데 이것을 “주요 서버 은폐”라고 합니다. 이 설정의 차이점은 보조 이름 서버만 권한을 가진다는 것, 다시 말해 해당 도메인의 등록 기관에 구성된다는 것입니다. 아래 그림은 이 서로 다른 설정을 나타냅니다.
2018년부터 우리는 Cloudflare가 보조 이름 서버 역할을 하는 주요-보조 설정을 지원하고 있습니다. 우리의 관점에서 이것은 우리가 주요 이름 서버의 착신 존 이전을 받아들인다는 의미입니다.
오늘부로 우리는 발신 존 이전도 지원하며, 이것은 주요 이름 서버 역할을 하여 하나 이상의 외부 보조 이름 서버가 Cloudflare의 존 이전을 수신할 수 있도록 한다는 의미입니다. 착신 이전과 마찬가지로 우리는 다음을 지원합니다
- AXFR 및 IXFR을 통한 존 이전
- 변경 시마다 존 이전을 트리거하기 위한 DNS NOTIFY를 통한 자동 알림
- 이전 시 존 파일이 인증되도록 하기 위한 TSIG를 통한 서명된 이전
권한 있는 보조 DNS에 대한 로그 푸시
Cloudflare는 로그를 좋아합니다. 2021년 3분기에, 우리는 평균적으로 초당 2천8백만 건의 HTTP 요청과 초당 1천3백6십만 건의 DNS 쿼리를 처리했고 매일 760억 건의 위협을 차단했습니다. 이런 이벤트를 전부 제한된 시간 동안 로그로 저장하여 사용자들에게 대시보드를 통한 실시간 분석을 제공합니다. 이런 로그를 영구적으로 저장하고 싶어하거나, 저장해야만 하는 고객들을 위해서 2019년에 로그 푸시를 만들었습니다. 로그 푸시를 사용하면 로그를 거의 실시간으로 우리의 분석 파트너인 Microsoft Azure Sentinel, Splunk, Datadog, Sumo Logic 중 한 곳이나 R2-호환 API를 지원하는 다른 클라우드 스토리지 목적지로 스트리밍할 수 있습니다.
현재 우리는 로그 푸시를 위한 추가 데이터 세트 하나를 추가하고 있는데 DNS 로그가 그것입니다. 귀사의 도메인에 대한 로그 푸시를 구성하고 DNS 로그를 스트리밍하려면 Cloudflare 대시보드로 이동하여 새 로그 푸시 작업을 생성하고 DNS 로그를 선택하고 관심 있는 로그 필드를 구성하면 됩니다.
API를 통해 이 작업을 수행하는 방법과 새로운 DNS 로그 필드에 대한 상세한 설명은 당사 개발자 문서를 참조하시기 바랍니다.
하나 더 있습니다(어쩌면 두 개일지도...)
귀사 인프라 내의 전체 DNS를 살펴볼 때는 트래픽이 시스템을 통해 어떻게 흘러가고 해당 트래픽이 어떻게 동작하는지 검토하는 것이 중요합니다. 결국 가장 중요한 것은 너무 많은 처리 능력, 메모리, 서버 용량, 그리고 전반적인 컴퓨팅 자원을 사용할 수 있다는 것입니다. 여기에 사용할 수 있는 가장 중요한 최고의 도구 중 하나가 바로 Load Balancing과 상태 모니터링입니다!
Cloudflare는 2016년부터 Load Balancing 솔루션을 제공하여 고객들이 확장성 있게 지능적으로 기존 자원을 활용하도록 지원하고 있습니다. 하지만 당사의 Load Balancer는 A, AAAA, CNAME 레코드로 제한되었습니다. 여기에는 고객들이 요구하는 많은 주요 사용 사례가 포함되었지만 이들 모두를 다루지는 못했습니다. 많은 고객들에게는 Load Balancing MX나 이메일 서버 트래픽, 특정 서비스에 대해 각각의 트래픽이 이동해야 하는 포트와 웨이트를 선언하기 위한 SRV 레코드, 각각의 트래픽이 포트와 상관없이 보안 프로토콜을 사용하도록 보장하기 위한 HTTPS 레코드 등 더 많은 요구사항이 있습니다. 우리는 고객들의 요구사항을 충족하고 고객들의 비즈니스 목표를 기술적 구현과 일치시킬 수 있는 능력을 지원하려고 합니다.
추가적인 구성 없이 Load Balancing MX, SRV, HTTPS, TXT 레코드 트래픽을 지원하기 위한 상태 모니터링 방법을 추가했음을 알려드리게 되어 기쁘게 생각합니다. Cloudflare에 각각의 DNS 레코드를 생성하고 귀사의 Load Balancer를 도착지로 설정하세요. 그 정도로 간단합니다! 고객들은 ICMP Ping, SMTP, UDP-ICMP 메시지를 활용하여 항상 서버 상태를 감지하고 각각의 상태 정보에 따라 지능적인 조정 결정을 적용할 수 있습니다.
지능적 조정을 고려할 때 만능의 해법은 없습니다. 특히 전 세계에서 서버가 위치한 지역과 고객들이 있는 위치를 고려하면 기업별로 요구사항이 다릅니다. 일반적으로 준수해야 하는 경험 법칙은 고객이 있는 곳에 서버를 배치하는 것입니다. 이렇게 하면 가장 성능 기준에 맞고 가장 지역화된 체험이 가능해집니다. 한 가지 일반적인 시나리오는 최종 사용자 요청이 출발하는 위치에 따라 트래픽을 조정하고 해당 지역에 가장 가까운 서버에 매핑을 하는 것입니다. Cloudflare의 지리적 조정 능력은 고객들이 풀에 대한 지역 매핑을 쉽게 만들 수 있도록 하므로 우리가 동유럽에서 오는 요청을 보게 된다면 해당 요청을 처리할 수 있는 적절한 서버로 보낼 수 있습니다. 그러나 때로는 지역이 상당히 넓어서 해당 매핑을 원하는 만큼 밀접하게 결합할 수 없다는 문제가 생길 수 있습니다.
오늘 우리의 지리적 조정 기능 안에서 국가 지원을 발표하게 되어 매우 기쁘게 생각합니다. 이제, 고객들은 13개 지역 중 하나를 선택하거나 자사의 풀을 매핑하기 위한 특정 국가를 선택할 수 있게 되므로 고객 트래픽이 시스템을 통해 이동할 때 작동하는 방식에 대한 추가적인 입도와 통제력이 보장됩니다. 2022년 1월에는 국가 수준 조정과 더 많은 DNS 레코드의 로드 밸런싱을 지원하기 위한 새로운 상태 모니터링 방법을 사용할 수 있습니다!
DNS 생태계 발전시키기
또한, 몇 가지 흥미로운 소식도 알려드립니다. 우리는 다중 서명자 DNSSEC(RFC8901) 작업을 마무리하고 있으며 2022년 1분기에 출시할 예정입니다. 이것이 왜 중요할까요? 대기업의 두 가지 흔한 요구사항은 다음과 같습니다.
- 중복성: 고객 도메인에 대해 권한 있는 응답을 제공하는 여러 DNS 공급자를 확보하는 것입니다
- 진본성: DNS 응답을 적절히 인증할 수 있도록 DNSSEC을 배치하는 것입니다
주요 이름 서버가 도메인에 서명하고 그 DNS 레코드와 레코드 서명을 보조 이름 서버에 이전하도록 하여 둘 다를 달성할 수 있습니다. 현재 이 설정은 Cloudflare 보조 DNS로 지원하고 있습니다. 미리 서명된 존을 이전할 때 지원할 수 없는 것은 국가 수준 조정과 같은 비표준 DNS 기능들입니다. 바로 여기에 다중 서명자 DNSSEC이 개입합니다. 두 DNS 공급자는 다른 쪽 공급자의 서명 키를 알고 자신만의 온라인(또는 온더플라이) 서명을 수행해야 합니다. 다중 서명자 DNSSEC의 작동 방식이 궁금하시면 APNIC에서 작성한 이 훌륭한 블로그 게시물을 확인해보시기 바랍니다.
마지막이지만 똑같이 중요한 것으로, Cloudflare는 DNS-OARC(DNS Operations, Analysis, and Research Center)에 골드 회원으로 가입되어 있습니다. 우리는 DNS 인프라의 연구자 및 운영자들과 함께 가장 힘든 문제를 처리하고 새로운 표준과 기능의 구현 작업을 지속하려고 합니다.
"DNS는 소비자가 성능과 신뢰성을 요구하는 가장자리에 위치하는 콘텐츠의 관리와 전달에 매우 중요한 도구입니다. Cloudflare는 DNS 공동체의 중요한 일원으로, 수년 간 OARC 워크숍에 꾸준히 참여하여 DNS에 관심 있는 청중에게 자사의 혁신과 운영 결과를 소개해 왔습니다. Cloudflare가 우리 공동체의 풀 멤버로 참여하게 된 것을 기쁜 마음으로 환영하며 OARC 골드 회원일 때와 같이 특별한 기여를 확대해주시길 기대합니다."
- 키스 미첼, OARC 소장
Cloudflare는 출발부터 DNS 분야에 참여해 왔지만 아직도 이제 막 시작한 것과 같습니다. 우리는 미래의 고객들이 요구할 보다 미세하고 구체적인 기능들이 있다는 것을 알고 있으며 DNS의 모든 레벨에 투자를 지속하고 지구에서 가장 기능이 풍부한 기업용 DNS 플랫폼을 구축할 것이라는 점에서 Foundation DNS의 출시에 이해관계가 있습니다. DNS 공급자가 이렇게 해주었으면 하고 생각하신 아이디어가 있으시면 언제든지 알려주시기 바랍니다. 이러한 기능을 구축하는 데 기여하실 수 있다면 채용 기회가 있습니다.