Pengenalan Istilah, Komponen dan Konsep DNS

Domain Name System (DNS) bagi saya adalah bagian yang cukup sulit untuk dipelajari, khususnya ketika saya mengkonfigurasi VPS. Memahami konsep DNS serta cara kerjanya akan membantu Anda dalam melakukan diagnosis masalah seperti pada konfigurasi web dan juga akan memperluas pemahaman Anda.

Dalam panduan ini, saya akan membahas beberapa konsep DNS fundamental (dasar). Diharapkan setelah menyelesaikan panduan ini, Anda dapat memahami script atau istilah yang biasa ada pada DNS serta cara kerjanya.

Sebelum kita masuk ke konfigurasi teknis, sebaiknya Anda memahami konsep dasar tentang istilah-istilah DNS dan bagaimana DNS bekerja.

 

Istilah-istilah pada Domain

Kita mulai dengan mendefinisikan setiap istilah, agar kedepannya kita dapat mengerti apa yang dimaksud.

Let’s start easy:

Domain Name System

Biasa disingkat menjadi DNS, yaitu sistem pada jaringan yang memungkinkan penamaan yang human-friendly pada alamat yang unik. Seperti contoh nairpaa.me memiliki alamat IP 206.189.92.66, facebook.com memiliki alamat 31.13.78.35 dan google.com memiliki alamat 74.125.68.139. Jika tidak ada DNS, maka kita harus menghafal setiap alamat IP yang akan kita tuju, untuk itulah DNS diperlukan agar mudah diingat oleh kita.

 

Domain Name

Sebelumnya telah dijelaskan, nama domain adalah penamaan yang human-friendly ketika kita menggunakan jaringan (ex. internet). Sebagai contoh sebelumnya yaitu google.com yang merupakan nama domain.

Nama domain google.com terkait dengan server yang dimiliki Google Inc. Domain Name System memungkinkan kita terhubung dengan Google server ketika kita mengetikkan “google.com” pada web browser.

 

Alamat IP

Alamat IP adalah pengalamatan perangkat pada jaringan yang dimana alamat tersebut harus unik (tidak sama dengan yang lainnya). Ketika kita mengakses website, sebenarnya kita sedang menggunakan pengalamatan jaringan ini.

IPv4 adalah pengalamatan yang paling umum saat ini, dengan ciri-ciri memiliki 4 oktet, setiap oktet bisa sampai 3 digit, setiap oktet dipisah dengan titik (.).  Sebagai contoh alamat IPv4 adalah 111.222.111.222, dengan adanya DNS kita dapat memetakan nama domain ke alamat tersebut, sehingga kita tidak perlu mengingat setiap alamat IP yang ingin kita kunjungi.

 

Top-Level Domain

Biasa disingkat menjadi TLD, yaitu bagian yang paling umum pada domain. Top-level domain berada paling kanan pada domain (dipisahkan oleh titik). Contohnya yaitu com, net, id, org, dll.

Top-level domain berada di puncak hirarki pada domain. Pihak-pihak tertentu diberikan kontrol manajemen atas TLD oleh ICANN (Internet Corporation for Assigned Names and Numbers). Pihak-pihak tersebut kemudian dapat mendistribusikan nama domain di bawah TLD (seperti, example.com), yang biasanya melalui registrar domain.

 

Host

Dalam sebuah domain, pemilik domain dapat mendefinisikan host individual, yang merujuk ke komputer atau layanan terpisah yang dapat diakses melalui domain. Misalnya, banyak pemilik domain yang membuat web server mereka dapat di akses melalui bare domain (example.com) atau juga melalui “host” yang didefinisikan “www” ( www.example.com).

Contoh definisi host lainnya adalah jika Anda memiliki API dan dapat diakses melalui host “api” (api.example.com) atau Anda memiliki layanan FTP server dengan mendefinisikan host bernama “ftp” (ftp.example.com) atau juga jika Anda memiliki Mail server dan host didefinisikan bernama “mail” (mail.example.com). Nama host tersebut dapat Anda atur sesuai keinginan Anda.

 

Fully Qualified Domain Name (FQDN)

FQDN didefinisikan nama lengkap yang valid untuk suatu host yang menentukan lokasi pastinya dalam suatu hirarki DNS. Untuk lebih jelasnya, perhatikan contoh berikut:

  • Nama host: mail
  • Nama domain: example.com
  • FQDN: mail.example.com

Nah sederhana kan? 😀 Anda dapat juga menyebutnya sebagai subdomain. Tapi intinya FQDN itu mengarahkan ke resource (sumber daya) spesifik yang terhubung ke internet.

 

Subdomain

DNS bekerja dalam hirarki. TLD punya banyak domain di bawahnya. Misalnya, TLD com memiliki google.com dan facebook.com di bawahnya. Itu adalah contoh dari subdomain (tetapi 1x di bawah TLD biasa disebut SLD), yaitu merujuk ke domain apapun yang merupakan bagian dari domain yang lebih besar.

Sebenarnya ini sama dengan FQDN (Anda bisa baca ini), Host adalah subdomain tetapi istilahnya biasa dibedakan. Kenapa ini dibedakan? menurut saya ini hanya membedakan fungsi/layanan saja. Jadi jika FQDN biasanya mendefinisikan layanannya (web, mail, ftp, dsb) sedangkan subdomain biasa digunakan sebagai istilah memperluas (extend) domain induk.

Sebagai contoh Anda memiliki SLD (Second Level Domain) example.com dan Anda ingin membuat blog tetapi tidak pada SLD, jadi Anda membuat subdomain (disini bernama “blog”) blog.example.com atau jika Anda ingin ditambahkan host “www” menjadi www.blog.example.com.

 

Name Server

Name Server adalah komputer yang ditujukan untuk menerjemahkan nama domain ke alamat IP. Server-server ini melakukan sebagian besar pekerjaan dalam sistem DNS. Karena jumlah total terjemahan domain terlalu banyak untuk satu server, setiap server dapat mengalihkan permintaan ke Name Server lain atau mendelegasikan tanggung jawab untuk subdomain yang menjadi tanggung jawabnya.

Berikut adalah contoh Name Server yang dimiliki oleh digitalocean.com:

  • Name Server 1 : ns1.digitalocean.com
  • Name Server 2 : ns2.digitalocean.com
  • Name Server 3 : ns3.digitalocean.com

Name Server dapat “authoritative”, yang berarti bahwa mereka memberikan jawaban atas pertanyaan tentang domain di bawah kendali mereka. Jika tidak, mereka mungkin menunjuk ke server lain, atau menyalin salinan cache data dari Name Server lain.

 

Zone File

Zone File adalah file teks sederhana (simple text file) yang berisi pemetaan antara nama domain dan alamat IP. Dengan ini sistem DNS akhirnya mengetahui alamat IP mana yang harus dihubungi ketika seorang pemohon me-request nama domain tertentu.

Zone File berada di Name Server dan umumnya menentukan resource yang tersedia di bawah domain tertentu, atau tempat yang dapat dikunjungi untuk mendapatkan informasi tersebut.

 

Records

Dalam zone file, records disimpan. Record pada dasarnya adalah pemetaan tunggal antara resource dan nama domain. Dengan record kita dapat memetakan nama domain ke alamat IP, menentukan Name Server untuk domain, menentukan Mail Server untuk domain, dll.

Jadi ini adalah isi dari zone file, berisi records (catatan/script) yang digunakan untuk memetakan domain. 😀

 

Bagaimana DNS Bekerja…

Sekarang Anda sudah mengenal beberapa istilah (terminologi) pada DNS, lalu bagaimana DNS tersebut bisa bekerja?

Sistem ini sangat simple jika digambarkan secara umum, tetapi sebenarnya ini sangat rumit ketika Anda ingin mempelajarinya secara detail 🙂 .

 

Root Servers

Seperti yang telah dikatakan sebelumnya, DNS pada intinya menggunakan sistem hirarki. Pada bagain teratas sistem (top of system) ini biasa dikenal sebagai “Root server”. Server ini dikontrol oleh berbagai organisasi dan didelegasikan oleh otoritas ICANN (Internet Corporation for Assigned Names and Numbers).

Lalu apa yang dilakukan oleh Root server? Root server meng-handle (menangani) permintaan informasi tentang Top-level domains (com, net, org, dll). Jadi, jika ada permintaan masuk untuk sesuatu yang tidak dapat di-handle oleh Lower-level Name Server, sebuah query (pertanyaan) akan dibuat untuk Root server tentang informasi domain yang ingin dituju.

Root server tidak akan tahu dimana domain di-host (hosted). Namun, Root server akan dapat mengarahkan pemohon (requester) ke Name Server yang menangani Top-level domain (TLD Server) yang diminta secara khusus.

Jadi ketika ada yang me-request www.wikipedia.org ke Root server, Root server tidak dapat menemukannya. Karena ketika Root server memerika zone file-nya untuk mencari daftar (record) yang cocok dengan www.wikipedia.org tidak akan ditemukan.

Root server malah akan menemukan record untuk TLD org dan memberikan entitas alamat dari Name Server yang bertanggung jawab untuk domain org (TLD Server dari org).

 

TLD Servers

Pemohon tadi kemudian mengirim permintaan baru ke alamat IP (yang  diberikan oleh root server) yang bertanggung jawab untuk TLD org.

Jadi, pemohon akan mengirim permintaan ke Name Server yang bertanggung jawab untuk mengetahui tentang domain org, untuk melihat apakah ia tahu dimana www.wikipedia.org berada.

Sekali lagi, ketika TLD server mencari www.wikipedia.org di zone file-nya, ia tidak akan menemukanya. TLD server malah akan menemukan daftar record dan memberikan alamat IP dari Name Server yang bertanggung jawab untuk wikipedia.org (Domain-Level Name Server). Dengan ini kita semakin mendekati jawaban yang inginkan 😀 .

 

Domain-Level Name Servers

Pada tahap ini, pemohon telah memiliki alamat IP dari Name Server yang bertanggung jawab untuk mengetahui alamat IP yang sebenarnya dari resource (server dari domain yang ingin dituju). Pemohon nantinya mengirim permintaan baru ke Name Server ini yang dapat menyelesaikan www.wikipedia.org.

Name Server ini akan memeriksa zone file-nya dan menemukan daftar yang terkait dengan wikipedia.org. Di dalam zone file tersebut, terdapat record untuk host www. Record ini yang akan memberi tahu alamat IP tempat host ini berada. Lalu Name Server tersebut mengembalikan jawaban akhir kepada pemohon.

Nah, sampai di sini pemohon sudah dapat mengetahui alamat mana yang harus dituju dan user dapat mengakses domain tersebut (jika memang ada/ditemukan).

 

Apa itu Resolving Name Server?

Dalam skenario sebelumnya, kita mengacu pada “pemohon”. Apa sih permohon yang di maksud?

Hampir disemua kasus, pemohon akan menjadi apa yang kita sebut “resolving name server” yaitu yang bertugas untuk menanyakan pertanyaan kepada server lainnya (seperti contoh di atas).

Untuk lebih jelasnya, resolving name server adalah DNS yang digunakan untuk mencari tahu tentang domain. Resolving name server biasanya disediakan oleh ISP atau organisasi lain. Kita contohkan: Google menyediakan resolving DNS servers, yang memiliki alamat 8.8.8.8 dan 4.4.4.4. Ketika kita menggunakan DNS tersebut dan ingin mengakses domain, DNS Google tersebut lah yang menjadi “pemohon” pada kasus di atas.

 

Zone File

Sebelumnya kita membahas tentang zone file dan record.

Zone file adalah cara Name Server menyimpan informasi tentang domain yang mereka ketahui. Jadi, setiap domain yang diketahui oleh Name Server akan disimpan di zone file.

Jika dikonfigurasikan untuk meng-handle pertanyaan rekursif, resolving name server akan mencoba mencari tahu dan memberikan jawabannya, jika tidak ditemukan, ia akan memberi tahu pihak pemohon untuk bertanya kemana lagi  selanjutnya.

Semakin banyak zone file yang dimiliki oleh Name Server, semakin banyak permintaan yang dapat dijawab secara otoritatif (answer authoritatively).

Zone file mengambarkan “zona” DNS, yang pada dasarnya adalah bagian dari seluruh sistem penamaan DNS. Satu zone file biasanya digunakan untuk mengkonfigurasi satu domain saja. Zone file dapat berisi sejumlah record yang mentukan dimana resource dari domain yang dimaksud.

Zone $ORIGIN adalah parameter/variabel yang setara dengan  otoritas (authority) tingkat tertinggi pada zone secara default.

Jadi, jika zone file digunakan untuk mengkonfigurasikan domain example.com., $ORIGIN akan ditetapkan pada example.com.. Jadi nilai dari variabel $ORIGIN adalah example.com..

Baik dikonfigurasikan di bagian atas zone file atau didefinisikan pada file konfigurasi DNS server yang mereferensikan zone file. Jadi, parameter ini mengambarkan apa yang zone akan di authoritative-kan.

Demikian pula dengan parameter $TTL yaitu yang mengkonfigurasikan “time to live” dari informasi yang diberikannya. Pada dasarnya ini adalah timer. Nantinya Caching Name Server dapat menggunakan hasil query sebelumnya untuk menjawab pertanyaan hingga nilai TTL habis.

 

Jenis-Jenis Record

Di dalam zone file, terdapat banyak jenis record yang berbeda. Kali ini kita akan membahas beberapa jenis yang lebih umum (atau wajib) di sini.

SOA Records

Start of Authority (SOA) record adalah record wajib di semua zone file. Ini harus menjadi real record pertama dalam file (meskipun $ORIGIN atau $TTL muncul di atas). Record ini juga salah satu yang paling kompleks untuk dipahami.

SOA Record terlihat kurang lebih seperti berikut:

domain.com.  IN SOA ns1.domain.com. admin.domain.com. (
                                            12083   ; serial number
                                            3h      ; refresh interval
                                            30m     ; retry interval
                                            3w      ; expiry period
                                            1h      ; negative TTL
)

Mari kita bahas penjelasannya di bawah ini:

  • domain.com.: adalah sebagai root dari zone tersebut. Ini menentukan bahwa zone file tersebut untuk domain.com. Mungkin nantinya Anda akan sering melihat ini diganti dengan @, yang merupakan singkatan dari $ORIGIN yang kita pelajari di atas.
  • IN SOA: maksud “IN” yaitu berarti internet (dan akan ada dalam banyak record nantinya). “SOA” adalah indikator bahwa ini adalah sebuah record Start of Authority.
  • ns1.domain.com.: yaitu mendefinisikan primary master name server untuk domain ini. Name server dapat berupa master atau slave, dan jika dynamic DNS sudah dikonfigurasikan, salah satu server nantinya harus menjadi “primary master”, yang berjalan di sini. Tetapi jika dynamic DNS belum dikonfigurasikan, maka ini hanyalah salah satu master name server Anda.
  • admin.domain.com.: ini adalah alamat email dari administrator untuk zone ini. “@” diganti dengan titik pada email. Dan jika pada bagian nama dari alamat email mengandung titik di dalamnya, kita rubah dengan “\” (ex. your.name@domain.com menjadi your\name.domain.com).
  • 12083: yaitu serial number untuk zone file. Setiap kali Anda mengedit zone file, Anda harus menaikkan angka ini (+1/increment) agar zone file menyebar dengan benar. Slave server nantinya akan memeriksa apakah serial number master server untuk zone-nya lebih besar dibanding yang ada pada sistemnya. Jika iya, ia akan meminta zone file baru, jika tidak, ia akan terus menggunakan file sebelumnya (yang ia simpan).
  • 3h: yaitu refresh interval untuk zone tersebut. Ini adalah jumlah waktu yang slave nantinya akan menunggu sebelum polling master untuk perubahan zone file.
  • 30m: yaitu retry interval untuk zone tersebut. Jika slave tidak dapat terhubung ke master ketika periode refresh sudah habis, itu akan menunggu jumlah waktu ini dan mencoba lagi (retry) untuk polling master.
  • 3w: adalah waktu untuk periode kedaluwarsa (expiry period). Jika slave name server belum dapat menghubungi master untuk jumlah waktu ini, maka tidak lagi mengembalikan respon sebagai sumber otoritatif (authoritative) untuk zone ini.
  • 1h: adalah waktu untuk jumlah waktu name server akan menyimpan (cache) kesalahan nama jika tidak dapat menemukan nama yang diminta dalam file ini.

 

A dan AAAA Records

Kedua record ini berfungsi memetakan host dengan alamat IP. record “A” berfungsi untuk memetakan host dengan alamat IPv4, sedangkan record “AAAA” berfungsi untuk memetakan host dengan alamat IPv6.

Format umum yang digunakan kedua record ini adalah sebagai berikut:

host    IN      A      IPv4_address
host    IN      AAAA   IPv6_address

Jadi, ketika SOA record memanggil primary master server di “ns1.domain.com”, kita harus memetakan ini ke alamat IP dari “ns1.domain.com” yang berada dalam zone “domain.com”.

Recordnya bisa terlihat seperti berikut:

ns1     IN  A       111.222.111.222

Perhatikan bahwa kita tidak harus memberikan nama lengkap. Kita bisa hanya memberikankan nama host, tanpa FQDN dan DNS server akan mengisi sisanya dengan nilai $ORIGIN. Namun, kita bisa dengan mudah menggunkaan seluruh FQDN jika kita menginginkannya:

ns1.domain.com.     IN  A       111.222.111.222

Dalam banyak kasus, ini adalah tempat Anda mendefinisikan web server sebagai “www”:

www     IN  A       222.222.222.222

Kita juga harus mendefinisikan base domain resolves. Kita bisa melakukannya seperti ini:

domain.com.     IN  A       222.222.222.222

Kita bisa menggunakan “@” untuk merujuk ke base domain sebagai gantinya:

@       IN  A       222.222.222.222

Kita juga memiliki pilihan untuk me-resolving apapun yang ada di bawah domain ini yang tidak didefinisikan secara eksplisit ke server ini juga. Kita bisa menggunakan ini dengan wild card “*”:

*       IN  A       222.222.222.222

Semua contoh di atas memiliki cara kerja yang sama dengan record AAAA untuk alamat IPv6.

 

CNAME Records

Record CNAME menentukan alias canocial name untuk server Anda (yang ditentukan oleh record A atau AAAA).

Misalnya, kita bisa memiliki record A yang didefinisikan dengan host “server1” dan kemudian menggunakan “www” sebagai alias untuk host ini:

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

Perlu kita ketahui bahwa alias ini datang dengan beberapa kerugian kinerja, karena mereka memerlukan permintaan tambahan ke server. Sebagian besar waktu, hasil yang sama dapat dicapai dengan menggunakan record A atau AAAA tambahan.

Satu kasus ketika CNAME direkomendasikan adalah memberikan alias untuk resource di luar zone saat ini.

 

MX Records

Record MX digunakan untuk menentukan pertukaran email yang digunakan untuk domain. Ini membantu pesan email tiba di server email Anda dengan benar.

Tidak seperti banyak jenis record lainnya, mail record umumnya tidak memetakan host ke sesuatu, karena mereka berlaku untuk seluruh zone, Dengan demikian, mereka biasanya terlihat seperti ini:

        IN  MX  10   mail.domain.com.

Perhatikan, pada record tersebut tidak diawali dengan nama host.

Harus kita perhatikan juga bahwa terdapat nomor tambahan di sana. Ini adalah nomor prefrensi yang membantu komputer memutuskan server mana untuk mengirim email jika ada beberapa server email yang ditentukan. Angka yang lebih rendah memiliki prioritas lebih tinggi.

Record MX umumnya harus menujuk ke host yang ditentukan oleh data A atau AAAA, dan bukan yang ditentukan oleh CNAME.

Jadi, katahalah kita memiliki dua server email. Harus ada record yang terlihat seperti berikut:

        IN  MX  10  mail1.domain.com.
        IN  MX  50  mail2.domain.com.
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

Dalam contoh ini, host “mail1” adalah server pertukaran email yang diprioritaskan.

Kita juga dapat menuliskan seperti berikut:

        IN  MX  10  mail1
        IN  MX  50  mail2
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

 

NS Records

Jenis record ini mendefinisikan name server yang digunakan untuk zone.

Anda mungkin bertanya-tanya, “jika zone file berada di name server, mengapa harus mereferensikan diri sendiri?”. Bagian dari apa yang membuat DNS sangat sukses adalah karena berbagai tingkatan caching-nya. Salah satu alasan untuk mendefinisikan name server dalam zone file adalah bahwa mungkin sebenarnya sedang dilayani dari salinan cache pada name server lain. Sebenarnya ada alasan lain kenapa name server perlu direfensikan pada diri sendiri, tetapi kita tidak akan membahasnya di sini.

Seperti halnya record MX, record NS adalah parameter zone-wide, jadi record NS juga tidak menggunakan host. Secara umum, record NS terlihat seperti berikut:

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.

Most DNS server software considers a zone file to be invalid if there is only a single name server.

Anda harus memiliki setidaknya dua name server yang ditentukan di setiap zone file agar dapat beroperasi dengan benar jika ada masalah dengan salah satu servernya. Sebagian besar perangkat lunak DNS server menganggap zone file tidak valid jika hanya ada satu name server.

Seperti biasa, sertakan pemetaan untuk host dengan record A atau AAAA:

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.
ns1     IN  A      111.222.111.111
ns2     IN  A      123.211.111.233

Ada beberapa jenis record lain yang dapat Anda gunakan, tetapi ini mungkin jenis paling umum yang akan Anda temui.

 

PTR Records

Record PTR digunakan untuk menentukan nama yang terkait dengan alamat IP. record PTR adalah kebalikan dari record A atau AAAA. Record PTR itu unik karena mereka memulai di .arpa root dan didelegasikan kepada pemilik alamat IP. Regional Internet Registries (RIRs) mengelola delegasi alamat IP untuk organisasi dan penyedia layanan. Regional Internet Registries termasuk APNIC, ARIN, RIPE NCC, LACNIC, dan AFRINIC.

Di sini kita contohkan, sebuah record PTR untuk 111.222.111.222 bisa terlihat seperti berikut:

222.111.222.111.in-addr.arpa.   33692   IN  PTR host.example.com.

Contoh dari record PTR untuk alamat IPv6 ini memperlihatkan nibble format dari kebalikannya alamat IPv6 DNS server Google, yaitu 2001:4860:4860::8888.

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

Perintah tool dig dengan flag -x dapat digunakan untuk mencari reverse DNS name dari alamat IP.

Berikut ini adalah contoh dari perintah dig dengan tambahan +short untuk mengurangi output dari reverse DNS name.

$ dig -x 8.8.4.4 +short

Output dari perintah di atas akan menghasilkan nama domain pada record PTR untuk alamat IP 8.8.4.4:

google-public-dns-b.google.com.

Server-server yang ada di Internet menggunakan record PTR untuk menempatkan nama domain pada log entires, membuat keputusan penanganan spam yang terinformasi, dan menampilkan informasi detail yang mudah dibaca tentang perangkat lain.

E-mail Server yang paling sering digunakan akan mencari record PTR dari alamat IP yang diterimanya email. Jika alamat IP sumber tidak memiliki record PTR yang terkait dengannya, email yang dikirim dapat diperlakukan sebagai spam dan ditolak. Tidak penting bahwa FQDN dalam PTR telah sesuai dengan nama domain dari email yang dikirim. Yang penting adalah bahwa ada record PTR yang valid dengan record A yang sesuai dan cocok.

Biasanya network routers di internet diberi record PTR yang sesuai dengan lokasi fisiknya. Misalnya Anda mungkin melihat referensi ke ‘NYC’ atau ‘CHI’ untuk router di New York City atau Chicago. Ini berguna ketika menjalankan traceroute atau MTR dan meninjau kembali jalur lalu lintas internet.

Sebagian besar penyedia layanan yang menawarkan dedicated server atau VPS akan memberi user kemampuan untuk menetapkan record PTR untuk alamat IP mereka. DigitalOcean akan secara otomatis menetapkan record PTR pada setiap Droplet ketika Droplet tersebut dinamai dengan nama domain. Nama dari Droplet telah ditetapkan selama pembuatan awal dan dapat dirubah oleh user dengan menggunakan halaman pengaturan Droplet control panel.

Note: Harus kita perhatikan, bahwa FQDN dalam record PTR memiliki record A yang sesuai dan cocok. Contoh: 111.222.111.222 memiliki PTR server.example.com dan server.example.com adalah data A yang mengarah ke 111.222.111.222.

 

CCA Records

Otherwise, only the specified CAs may issue certificates

Record CCA digunakan untuk menentukan Certificate Authorities (CAs) mana yang diizinkan untuk mengeluarkan sertifikat SSL/TLS untuk domain Anda. Mulai 8 September 2017, semua CA diminta untuk memeriksa record ini sebelum mengeluarkan sertifikat. Jika tidak ada record ini, setiap CA dapat mengeluarkan sertifikat. Sebaliknya, jika ada, hanya CA yang ditentukan yang dapat mengeluarkan sertifikat. Record CAA dapat diterapkan ke salah satu host atau seluruh domain.

Sebuah contoh dari record CAA adalah seperti berikut:

example.com.    IN  CAA 0 issue "letsencrypt.org"

Host IN dan jenis record (CAA) adalah DNS fields yang umum. Informasi khusus CAA di atas adalah bagian 0 issue "letsencrypt.org" yang terdiri dari tiga bagian, yaitu: flags (0), tags (issue), dan values ("letsencrypt.org").

  • Flags adalah sebuah integer (bilangan bulat) yang menujukkan bagaimana CA harus menangani tag yang tidak dipahami. Jika flag bernilai 0, record akan diabaikan. Sedangkan jika bernilai 1, CA harus menolak mengeluarkan certificate.
  • Tags adalah string yang menunjukkan tujuan dari record CAA. Contoh di atas adalah issue yang meng-authorize CA untuk membuat sertifikat pada nama host tertentu, sedangkan jika issuewild untuk meng-authorize sertifikat wildcard, atau jika iodef untuk menentukan URL di mana CA dapat melaporkan pelanggaran kebijakan.
  • Values adalah string yang dikatikan dengan record tag. Untuk issue dan issuewild, ini biasanya adalah domain dari CA yang Anda berikan izinnya. Untuk iodef ini mungkin URL dari contact form, atau tautan mailto: untuk email feedback.

 

Anda dapat menggunakan dig untuk mengambil record CAA menggunakan perintah seperti berikut:

dig example.com type257

Untuk informasi lebih tentang record CAA, Anda dapat membaca RFC 6844, atau tutorial ini How To Create and Manage CAA Records Using DigitalOcean DNS.

 

Kesimpulan

Setelah membaca panduan ini Anda telah memiliki fondasi yang kuat untuk mempelajari DNS kedepannya. Mungkin ini masih menjadi sesuatu yang sulit bagi administrator yang belum berpengalaman, tetapi dengan membaca panduan ini dan terbiasa mempraktekannya nanti, insyaAllah Anda akan bisa memahami dan menguasai pemahaman tentang DNS. 🙂

Untuk lebih memahami panduan ini, baca juga: Cara Mengatur Domain di Control Panel DigitalOcean.

 

 

Baca juga:

Leave a Comment