Announcing Foundation DNS - Cloudflare’s new premium DNS offering

Hari ini, kami mengumumkan Foundation DNS, penawaran DNS premium terbaru Cloudflare yang memberikan keandalan tak tertandingi, kinerja unggul, dan mampu memenuhi persyaratan paling kompleks dari tim infrastruktur.

Mari membahas biayanya terlebih dahulu

Saat Anda menandatangani kesepakatan DNS perusahaan, biasanya penyedia DNS meminta tiga masukan dari Anda untuk menghasilkan penawaran:

  • Jumlah zona
  • Total kueri DNS per bulan
  • Total catatan DNS di semua zona

Beberapa jauh lebih rumit dan banyak yang memiliki kalkulator harga atau penetapan harga "Hubungi Kami" yang kurang jelas. Merencanakan anggaran seputar cara Anda bertumbuh menghadirkan kerumitan yang tak perlu, dan kami yakin dapat melakukannya dengan lebih baik. Mengapa tidak membuatnya lebih sederhana? Ini dia: Kami memutuskan untuk menagih Foundation DNS berdasarkan satu masukan bagi pelanggan perusahaan kami: Total kueri DNS per bulan. Dengan cara ini, kami berharap dapat menghemat uang perusahaan dan bahkan yang lebih penting, menghilangkan kerumitan dari tagihan DNS mereka.

Dan jangan khawatir, seperti produk lain kami, mitigasi DDoS masih belum terukur. Tak akan ada biaya tambahan tersembunyi jika nameserver Anda terkena serangan DDoS atau jumlah kueri DNS melebihi kuota Anda selama satu atau dua bulan.

Mengapa DNS begitu penting?

Sistem Nama Domain (DNS) hampir sama tuanya dengan Internet. Sistem ini awalnya didefinisikan dalam RFC882 dan RFC883 pada 1983 karena kebutuhan untuk membuat pemetaan antara nama host dan alamat IP. Saat itu, para penemu dengan bijak menyatakan: “[Internet] adalah sistem yang besar dan mungkin akan berkembang jauh lebih besar.” [RFC882]. Saat ini, ada hampir 160 Juta nama domain yang menggunakan .com, salah satu Domain Tingkat Atas (TLD) terbesar [sumber].

DNS dimaksudkan sebagai sistem hierarkis dan sangat terdistribusi, tetapi sebagai pengguna akhir, Anda biasanya hanya berkomunikasi dengan resolver (1) yang ditetapkan atau dioperasikan oleh Penyedia Layanan Internet (ISP) ataupun dikonfigurasikan langsung oleh perusahaan Anda atau Anda sendiri. Resolver berkomunikasi dengan salah satu server root (2), server TLD yang bertanggung jawab (3), dan nameserver otoritatif (4) dari domain terkait. Dalam banyak kasus, keempatnya ini dioperasikan oleh entitas yang berbeda dan berlokasi di wilayah, bahkan mungkin benua, yang berbeda.

Seperti yang telah kita lihat sebelumnya, jika infrastruktur DNS Anda rusak, Anda berada dalam masalah serius, dan itu mungkin akan menghabiskan banyak biaya serta berpotensi merusak reputasi Anda. Jadi sebagai pemilik domain, Anda ingin pencarian DNS ke domain Anda senantiasa dijawab 100% dan idealnya secepat mungkin. Jadi apa yang bisa Anda lakukan? Anda tidak dapat memengaruhi resolver mana yang telah dikonfigurasi pengguna Anda. Anda tidak dapat mempengaruhi server root. Anda dapat memilih server TLD yang digunakan dengan memilih nama domain menggunakan TLD masing-masing. Tetapi, jika Anda terikat pada TLD tertentu karena alasan lain, itu juga di luar kendali Anda. Hal yang mudah Anda pengaruhi adalah penyedia nameserver otoritatif Anda. Jadi, mari membahas lebih lanjut tentang penawaran DNS otoritatif Cloudflare.

Melihat DNS Otoritatif Cloudflare

DNS Otoritatif adalah salah satu produk tertua kami, dan kami telah menghabiskan banyak waktu untuk menjadikannya hebat. Semua kueri DNS dijawab dari jaringan anycast global kami yang hadir di lebih dari 250 kota. Dengan cara ini, kami dapat memberikan kinerja unggul sambil selalu menjamin ketersediaan global. Dan tentunya, kami memanfaatkan pengalaman luas kami dalam memitigasi serangan DDoS untuk mencegah siapa pun meruntuhkan nameserver kami dan domain pelanggan kami.

DNS sangat penting untuk Cloudflare karena sebelum dirilisnya Magic Transit, DNS adalah cara setiap pengguna di Internet diarahkan ke Cloudflare untuk melindungi dan mempercepat aplikasi pelanggan kami. Jika jawaban DNS kami lambat, Cloudflare juga lambat. Jika jawaban DNS kami tidak tersedia, Cloudflare pun tidak tersedia. Kecepatan dan keandalan DNS otoritatif kami sangat penting untuk kecepatan dan keandalan Cloudflare, seperti halnya pelanggan kami. Kami juga meminta pelanggan kami mendorong infrastruktur DNS kami seiring mereka berkembang bersama Cloudflare. Hari ini, zona pelanggan terbesar kami memiliki lebih dari 3 juta catatan dan 5 zona teratas mencapai hampir 10 juta catatan gabungan. Pelanggan ini mengandalkan Cloudflare untuk mendorong pembaruan catatan DNS baru ke edge kami dalam hitungan detik, bukan menit. Karena pentingnya hal ini dan kebutuhan pelanggan kami, selama bertahun-tahun kami telah mengembangkan tim rekayasa DNS khusus yang berfokus menjaga agar tumpukan DNS kami tetap cepat dan andal.

Keamanan ekosistem DNS juga penting. Cloudflare selalu mendukung DNSSEC. Menandatangani dan memvalidasi jawaban DNS melalui DNSSEC memastikan penyerang on-path tidak dapat membajak jawaban dan mengalihkan traffic. Cloudflare selalu menawarkan DNSSEC secara cuma-cuma pada semua level paket, dan akan terus menjadi opsi gratis bagi Foundation DNS. Bagi pelanggan yang juga memilih untuk menggunakan Cloudflare sebagai registrar, penerapan DNSSEC satu klik yang sederhana adalah fitur utama lain yang memastikan domain pelanggan kami tidak dibajak, dan penggunanya terlindungi. Kami juga mendukung RFC 8078 untuk penerapan satu klik pada registrar eksternal.

Tetapi ada masalah lain yang dapat menghentikan sebagian Internet dan kebanyakan berada di luar kendali kami: kebocoran rute atau bahkan lebih buruk, pembajakan rute. Meski DNSSEC dapat membantu mengurangi pembajakan rute, sayangnya tidak semua resolver rekursif akan memvalidasi DNSSEC. Dan sekalipun resolver memvalidasinya, kebocoran rute atau pembajakan nameserver Anda masih akan mengakibatkan waktu henti. Jika semua IP nameserver Anda terdampak oleh peristiwa tersebut, domain Anda menjadi tidak dapat diselesaikan.

Dengan banyaknya penyedia, setiap nameserver Anda biasanya hanya memperbarui satu alamat IPv4 dan satu alamat IPv6. Jika alamat IP tersebut tidak dapat dijangkau — misalnya karena kemacetan jaringan atau, lebih buruk lagi, kebocoran rute — seluruh nameserver menjadi tidak tersedia, sehingga domain Anda tidak dapat diperbarui. Lebih buruk lagi, beberapa penyedia bahkan menggunakan subnet IP yang sama untuk semua nameserver mereka. Jadi jika terjadi masalah terhadap subnet tersebut, semua nameserver tidak aktif.

Mari melihat contohnya:

$ 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

Semua IP nameserver adalah bagian dari 205.251.192.0/21. Untungnya, AWS sekarang menandatangani rentang mereka melalui RPKI dan ini menjadikan kemungkinan kebocoran lebih kecil… selama ISP resolver memvalidasi RPKI. Tetapi jika ISP resolver tidak memvalidasi RPKI dan jika subnet ini bocor atau dibajak, resolver tidak akan dapat menjangkau nameserver mana pun dan aws.com akan menjadi tidak dapat diperbarui.

Tak perlu diragukan lagi bahwa Cloudflare menandatangani semua rute kami dan mendorong seluruh Internet demi meminimalkan dampak kebocoran rute, tetapi apa lagi yang dapat kami lakukan untuk memastikan sistem DNS kami tetap tangguh saat mengatasi kebocoran rute selagi menunggu RPKI untuk diterapkan secara luas?

Kini, ketika Anda menggunakan DNS Cloudflare pada paket Gratis, Pro, Bisnis, atau Perusahaan, domain Anda mendapatkan dua nameserver dari struktur <name>.ns.cloudflare.com, dengan <name> adalah nama depan acak.

$ dig isbgpsafeyet.com ns +short
tom.ns.cloudflare.com.
kami.ns.cloudflare.com.

Sekarang, seperti yang kita pelajari sebelumnya, agar domain tersedia, nameserver harus tersedia. Inilah sebabnya masing-masing nameserver ini diperbarui ke 3 alamat IPv4 anycast dan 3 alamat IPv6 anycast.

$ 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

Detail penting yang perlu diperhatikan di sini adalah masing-masing dari 3 alamat IPv4 dan 3 alamat IPv6 berasal dari blok /8 IPv4 (/45 untuk IPv6) yang berbeda. Jadi agar nameserver Anda tidak tersedia melalui IPv4, kebocoran rute harus tepat memengaruhi subnet yang sesuai di ketiga blok /8 IPv4. Meskipun teorinya ini mungkin terjadi, nyatanya ini hampir mustahil.

Bagaimana ini bisa lebih ditingkatkan?

Pelanggan yang menggunakan Foundation DNS akan diberi satu set nameserver lanjutan baru yang dihosting di foundationdns.com dan foundationdns.net. Nameserver ini bahkan akan lebih tangguh daripada nameserver default Cloudflare. Kami akan mengumumkan detail lebih lanjut tentang cara kami mencapai hal ini awal tahun depan, jadi simaklah terus. Semua domain Cloudflare eksternal (seperti cloudflare.com) akan beralih ke nameserver ini pada tahun baru.

Masih ada lebih banyak

Dengan senang hati kami mengumumkan bahwa kami meluncurkan dua fitur yang sangat diminati:

  • Dukungan untuk transfer zona keluar bagi DNS Sekunder
  • Logpush untuk kueri DNS otoritatif dan sekunder

Keduanya akan tersedia sebagai bagian dari Foundation DNS dan tanpa biaya tambahan bagi pelanggan perusahaan. Mari mengamati masing-masing lebih lanjut dan melihat caranya menjadikan penawaran DNS kami jauh lebih baik.

Dukungan untuk transfer zona keluar bagi DNS Sekunder

Apa itu DNS Sekunder, dan mengapa itu penting? Banyak perusahaan besar perlu menggunakan lebih dari satu penyedia DNS untuk redundansi jika satu penyedia tidak tersedia. Mereka melakukannya dengan menambahkan catatan DNS domain mereka pada dua platform independen dan secara manual menjaga sinkronisasi file zona — ini disebut sebagai penyiapan "multi-primer". Dengan DNS Sekunder, ada dua mekanisme cara mengotomatiskan hal ini menggunakan pengaturan "primer-sekunder":

  • PEMBERITAHUAN DNS: Nameserver utama memberi tahu nameserver sekunder atas setiap perubahan pada zona. Setelah nameserver sekunder menerima PEMBERITAHUAN, mereka mengirimkan permintaan transfer zona ke nameserver primer untuk menyinkronkannya.
  • Kueri SOA: Di sini, nameserver sekunder secara teratur menanyakan catatan SOA zona dan memeriksa jika nomor seri yang dapat ditemukan pada catatan SOA sama dengan nomor seri terbaru yang disimpan oleh nameserver sekunder dalam catatan SOA zona tersebut. Jika tersedia versi baru dari zona, mereka mengirimkan permintaan transfer zona ke nameserver primer untuk mendapatkan perubahan tersebut.

Alex Fattouche telah menulis postingan blog menarik tentang cara kerja DNS Sekunder di belakang layar jika Anda ingin mempelajari lebih lanjut tentangnya. Fungsi lain dari pengaturan primer-sekunder adalah menyembunyikan zona primer, sehingga disebut sebagai "zona primer tersembunyi". Perbedaan pengaturan ini adalah bahwa hanya nameserver sekunder yang otoritatif — dengan kata lain dikonfigurasikan di registrar domain. Diagram di bawah menggambarkan pengaturan yang berbeda.

Sejak 2018, kami telah mendukung pengaturan primer-sekunder saat Cloudflare berperan sebagai nameserver sekunder. Ini berarti dari sudut pandang kami, kami menerima transfer zona masuk dari nameserver primer.

Mulai hari ini, kami juga mendukung transfer zona keluar, yang berarti kami berperan sebagai nameserver primer dengan satu atau beberapa nameserver sekunder eksternal yang menerima transfer zona dari Cloudflare. Persis untuk transfer masuk, kami mendukung

  • transfer zona melalui AXFR dan IXFR
  • notifikasi otomatis melalui PEMBERITAHUAN DNS untuk memicu transfer zona pada setiap perubahan
  • transfer yang ditandatangani menggunakan TSIG akan memastikan file zona diautentikasi selama transfer

Logpush untuk DNS otoritatif dan sekunder

Di Cloudflare, kami menyukai log. Pada K3 2021, kami memproses rata-rata 28 Juta permintaan HTTP per detik dan 13,6 Juta kueri DNS per detik serta memblokir 76 Miliar ancaman setiap hari. Semua peristiwa ini disimpan sebagai log selama jangka waktu terbatas guna menyediakan analisis hampir secara waktu riil di dasbor kepada pengguna kami. Bagi pelanggan yang ingin — atau harus — menyimpan log ini secara permanen, kami telah membuat Logpush pada 2019. Logpush memungkinkan Anda melakukan streaming log hampir secara waktu riil ke salah satu mitra analitik kami, yakni Microsoft Azure Sentinel, Splunk, Datadog, dan Sumo Logic atau ke tujuan penyimpanan cloud apa pun dengan API yang kompatibel dengan R2.

Hari ini, kami menambahkan satu kumpulan data tambahan bagi Logpush: log DNS. Untuk mengonfigurasi Logpush dan melakukan streaming log DNS bagi domain Anda, cukup buka dasbor Cloudflare, buat pekerjaan Logpush baru, pilih log DNS, dan konfigurasikan bidang log yang Anda minati:

Lihat dokumentasi pengembang kami untuk mendapatkan petunjuk terperinci tentang cara melakukannya melalui API dan melihat deskripsi menyeluruh tentang bidang log DNS baru.

Satu (atau dua) hal lagi...

Saat melihat keseluruhan DNS dalam infrastruktur Anda, penting untuk meninjau alur traffic Anda melalui sistem Anda dan perilaku traffic tersebut. Pada akhirnya, ketersediaan kekuatan pemrosesan, memori, kapasitas server, dan sumber daya komputasi keseluruhan memang terbatas. Salah satu alat terbaik dan penting yang kami miliki adalah Load Balancing dan Pemantau Kesehatan!

Cloudflare telah menyediakan solusi Load Balancing sejak 2016, mendukung pelanggan agar memanfaatkan sumber daya yang ada dengan cara terukur dan cerdas. Tetapi Load Balancer kami terbatas pada log A, AAAA, dan CNAME. Ini mencakup berbagai kasus penggunaan utama yang dibutuhkan oleh pelanggan, tetapi tidak mencakup semuanya. Banyak pelanggan memiliki lebih banyak kebutuhan, seperti load balancing MX atau traffic server email, catatan SRV untuk menyatakan port dan bobot mana yang harus dilalui setiap traffic untuk layanan tertentu, catatan HTTPS untuk memastikan setiap traffic menggunakan protokol yang aman, terlepas dari portnya, dan banyak lagi. Kami ingin memastikan kebutuhan pelanggan kami terpenuhi dan mendukung kemampuan mereka guna menyelaraskan tujuan bisnis dengan implementasi teknis.

Dengan senang hati kami mengumumkan bahwa kami telah menambahkan metode Pemantauan Kesehatan tambahan untuk mendukung traffic catatan Load Balancing MX, SRV, HTTPS, dan TXT tanpa perlu konfigurasi tambahan. Buat catatan DNS Anda masing-masing di Cloudflare dan atur Load Balancer Anda sebagai tujuan...semudah itu! Dengan memanfaatkan metode ICMP Ping, SMTP, dan UDP-ICMP, pelanggan akan selalu mengetahui kesehatan server mereka dan dapat menerapkan keputusan pengarahan yang cerdas berdasarkan informasi kesehatan masing-masing.

Saat memikirkan tentang pengarahan cerdas, tidak ada satu jawaban yang cocok untuk semua. Bisnis yang berbeda memiliki kebutuhan yang berbeda, terutama ketika melihat lokasi server Anda di seluruh dunia, dan tempat pelanggan Anda berada. Aturan umum yang harus diikuti adalah menempatkan server di tempat pelanggan Anda berada. Ini memastikan mereka memiliki pengalaman yang dilokalkan dengan kinerja terbaik. Salah satu skenario umum adalah mengarahkan traffic Anda berdasarkan asal permintaan pengguna akhir Anda dan membuat pemetaan ke server terdekat dengan area tersebut. Kemampuan pengarahan geografis Cloudflare memungkinkan pelanggan kami melakukannya — mempermudah pembuatan pemetaan wilayah ke kumpulan, yang memastikan jika kami melihat permintaan berasal dari Eropa Timur, kami akan mengirimkan permintaan tersebut ke server yang sesuai untuk memenuhi permintaan tersebut. Namun terkadang, wilayahnya mungkin sangat besar dan menimbulkan masalah ketidakmampuan untuk menggabungkan pemetaan tersebut sedekat mungkin dengan yang diinginkan.

Hari ini, kami sangat senang mengumumkan dukungan negara dalam fungsi Pengarahan Geografis kami. Sekarang, pelanggan akan dapat memilih satu dari tiga belas wilayah kami, atau negara tertentu untuk dipetakan terhadap kumpulan mereka guna memberikan granularitas dan kontrol lebih lanjut tentang cara perilaku traffic pelanggan saat melewati sistem mereka. Pengarahan tingkat negara dan metode pemantauan kesehatan baru kami untuk mendukung load balancing pada lebih banyak catatan DNS akan tersedia pada Januari 2022!

Memajukan Ekosistem DNS

Selain itu, kami akan membagikan beberapa kabar menarik lain: Kami sedang menyelesaikan Multi-Signer DNSSEC (RFC8901) dan berencana untuk meluncurkannya pada K1 2022. Mengapa ini penting? Dua kebutuhan umum perusahaan besar adalah:

  • Redundansi: Memiliki beberapa penyedia DNS yang menanggapi secara otoritatif untuk domain mereka
  • Keaslian: Menerapkan DNSSEC untuk memastikan tanggapan DNS dapat diautentikasi dengan benar

Keduanya dapat dicapai dengan meminta nameserver primer mendaftarkan domain dan mentransfer catatan DNSnya ditambah tanda tangan catatan ke nameserver sekunder yang akan melayani keduanya apa adanya. Kini pengaturan ini didukung dengan DNS Sekunder Cloudflare. Hal yang tidak dapat didukung saat mentransfer zona yang telah ditandatangani sebelumnya adalah fitur DNS non-standar, seperti pengarahan tingkat negara. Di sinilah Multi-Signer DNSSEC akan berperan. Kedua penyedia DNS perlu mengetahui kunci penandatanganan dari penyedia lain dan melakukan penandatanganan online (atau selagi bergerak) mereka sendiri. Jika Anda penasaran untuk mempelajari lebih lanjut tentang cara kerja Multi-Signer DNSSEC, tengok postingan blog hebat ini yang diterbitkan oleh APNIC.

Terakhir, tapi tak kalah penting, Cloudflare bergabung dengan Pusat Operasi, Analisis, dan Penelitian DNS (DNS-OARC) sebagai anggota emas. Bersama peneliti dan operator infrastruktur DNS lainnya, kami ingin mengatasi masalah yang paling menantang serta terus berupaya menerapkan standar dan fitur baru.

"DNS adalah alat penting untuk pengelolaan dan pengiriman konten di edge saat konsumen menuntut kinerja dan keandalan. Cloudflare adalah anggota penting dalam komunitas DNS, serta telah rutin mengikuti lokakarya OARC selama bertahun-tahun dengan menghadirkan inovasi dan temuan operasional bagi khalayak kami yang berfokus pada DNS. Senang rasanya menyambut mereka saat ini sebagai Anggota penuh komunitas kami, dan kami berharap dapat menindaklanjuti kontribusi unik mereka sebagai Anggota Emas OARC."
- Keith Mitchell, Presiden OARC

Meski kami telah menggunakan DNS sejak hari pertama Cloudflare dibentuk, kami masih baru memulai. Kami tahu ada fitur lebih terperinci dan spesifik yang akan diminta oleh pelanggan masa depan kami, serta peluncuran Foundation DNS adalah langkah besar yang akan terus kami investasikan di semua tingkat DNS sembari membangun platform DNS perusahaan yang paling kaya fitur di muka bumi. Jika Anda memiliki ide, sampaikanlah hal yang selalu Anda impikan untuk dilakukan oleh penyedia DNS Anda. Jika Anda ingin membantu membangun fitur ini, kami sedang melakukan perekrutan.