DNS Resolution

Serial-number : Ini adalah nomor versi Zone dan akan terus bertambah dengan setiap pembaruan file Zone.

Time-to-refresh : Nilai ini menunjukkan waktu tunggu untuk memeriksa pembaruan nomor seri. Ini terutama diperlukan ketika Anda memiliki dns atau dns cluster sekunder yang perlu memeriksa pembaruan pada file master dan perlu dicopy yang terbaru ke server lain di cluster. Hanya berlaku untuk mereka yang memiliki dns sekunder atau pengaturan cluster.

Time-to-retry : Ini menentukan berapa lama server nama harus menunggu untuk mencoba refresh jika upaya terakhir gagal. Hanya berlaku untuk mereka yang memiliki dns sekunder atau penyiapan cluster.

Time-to-expire : menentukan berapa lama kita harus menunggu sebelum menganggap data dari server nama klaster sekunder atau lainnya tidak valid dan berhenti merespons kueri untuk zona masing-masing.

minimum-TTL : Berapa lama server nama atau resolver harus men-cache respons negatif.

2. TTL (Time to Live) Value

Nilai TTL adalah waktu dalam detik bahwa catatan dns akan di-cache oleh server dns luar atau server nama dan setelah itu harus me-refresh cache dan memiliki nilai terbaru. Kepentingan utama ini adalah saat Anda merencanakan migrasi, dan memerlukan perubahan dns tanpa waktu henti dns. Perubahan pada server nama selalu dapat menyebabkan waktu henti karena kami tidak memiliki kendali atas itu. Jadi sebelum migrasi biasanya kita ubah nilai TTL menjadi 300 detik 1 – 2 hari sebelumnya sehingga setelah migrasi kita akan mengubah ip nameserver di ujung registrar dan juga akan mengubah IP semua file zona di server lama ke ip baru sehingga akan mulai menyelesaikan ke server baru dalam kedua kasus yaitu jika dns sampai ke server lama, maka itu akan mengarahkan domain dari server itu ke server baru dan jika server nama yang baru diperbarui diambil,

Jika tidak ada nilai ttl yang tidak disebutkan, maka ini akan menjadi nilai default utama untuk semua catatan dns kecuali kita memiliki nilai lain yang ditentukan dalam catatan.

Sample entry
 $TTL 14400

3. A Record

Catatan juga dikenal sebagai Catatan Alamat atau Catatan Host. Ini terutama digunakan untuk mengarahkan domain/Subdomain dll ke alamat ip server. Catatan hanya diselesaikan ke alamat ip dan tidak ada argumen/variabel lain di catatan A. Catatan A hanya digunakan untuk menunjuk ke alamat IPv4.

Sample A Record is the below one
 domain.com.   14400  IN     A      192.168.1.1

Kami juga dapat menggunakan catatan dns wildcard yang akan memuat semua subdomain ke satu ip

*.domain.com   14400 IN A       192.168.1.1

4. AAAA Record

Catatan AAAA sama dengan Catatan di atas dan tujuan serta useran catatan ini semuanya sama. Satu-satunya perbedaan adalah ini digunakan untuk mengarahkan domain ke IP IPV6 dan jika domain juga memiliki versi IPv6, maka kita perlu memiliki catatan A ini juga menunjuk.

Contoh Catatan AAAA adalah di bawah ini

domain.com     14400  IN AAAA   0133:4237:89bc:cddf:0123:4267:89ab:cddf

5. NS (Name Server) Record

Situasi yang ideal adalah Nameserver pada level registrar dan file zona dns sama dan catatan ns yang tidak cocok dapat menyebabkan beberapa masalah dengan beberapa ISP tetapi biasanya ketidakcocokan itu tidak menjadi masalah. Jadi catatan server nama utama harus ada di registrar dan file zona dns di server yang disebutkan di registrar.

Sample Entry
 domain.com.   86400  IN     NS     ns1.maindomain.com.
 domain.com.   86400  IN     NS     ns2.maindomain.com.

Ketika Anda memiliki server nama untuk domain yang sama, pastikan Anda menambahkan catatan A untuk server nama ini. Dalam contoh di atas, server nama terdaftar lainnya seperti ns1.maindomain.com. Tetapi jika Anda ingin menggunakan ns1.domain.com itu sendiri sebagai nameeserver di registrar dan server, Anda perlu mengatur catatan HOST di registrar (yang merupakan Catatan LEM) dan perlu menambahkan catatan A di bawah ini juga

ns1    14400  IN     A      192.168.1.1
 ns2    14400  IN     A      192.168.1.1

6. MX (Mail Exchange ) Record

Ini adalah catatan dns penting lainnya yang menentukan nasib email masuk Anda ke domain. Ketika seseorang mengirim email ke akun email di bawah domain, server jarak jauh akan mengirim email ke server yang disebutkan da
lam catatan MX dan ke dengan nilai prioritas terendah yang sebenarnya memiliki prioritas tertinggi

Contoh data MX

domain.com      14400      IN MX      10  mail_1.domain.com
 domain.com      14400      IN MX      20  mail_2.domain.com
 domain.com      14400      IN MX      30  mail_3.domain.com

Dalam contoh ini, jika mail_1.domain.com tidak aktif, email akan dikirim ke mail_2.domain.com. Jika mail_2.example.com juga tidak aktif, email akan dikirim ke mail_3.domain.com. Ini terutama digunakan saat Anda memiliki domain yang ditambahkan di beberapa server dan email telah dikonfigurasi di server tersebut. Tetapi surat-surat itu akan tersebar ke server-server itu dan Anda mungkin harus memeriksanya secara manual.

Jika Anda menggunakan data MX yang memiliki nama domain yang sama, Anda perlu menambahkan data dns A yang tepat. Seperti di bawah ini. Tetapi jika Anda menggunakan aplikasi google, outlook dll, maka tidak perlu menambahkan catatan A tambahan untuk mereka karena Anda tidak memiliki kendali atas itu dan itu harus ditambahkan oleh penyedia tersebut.

mail_1      14400  IN     A      192.168.1.1
 mail_2       14400  IN     A      192.168.1.2
 mail_3       14400  IN     A      192.168.1.3

7. TXT (Text) Record

Catatan TXT atau catatan teks sebenarnya tidak memiliki peran apa pun pada fungsionalitas domain dan biasanya digunakan untuk menampilkan beberapa info atau digunakan untuk beberapa verifikasi seperti ketika Anda mendaftar dengan aplikasi google atau service Outlook Mail, maka mereka akan meminta Anda untuk menambahkan Catatan TXT yang mereka minta (kode unik) sehingga mereka dapat memverifikasi kepemilikan domain. Catatan SPF/DKIM juga didasarkan pada TXT tetapi memiliki fungsi untuk dijalankan. Ini juga dapat digunakan sebagai opsi untuk mengotentikasi kepemilikan Anda sambil menambahkan ke akun webmaster google dan service terkait google lainnya juga.

Di bawah ini adalah contoh entri dns untuk verifikasi google

domain.com. 300  IN   TXT google-site-verification=gBmnBtGTIz_esMKJBKT-PxLH50M

8. SPF ( Sender Policy Framework ) Record

Catatan SPF pada dasarnya adalah catatan TXT, yang biasanya mempublikasikan semua server email yang ditunjuk untuk domain atau subdomain. Penggunaan utama dari catatan ini adalah untuk membuktikan keabsahan surat dan mencegah surat palsu. Server surat tujuan dapat menolak surat jika itu bukan dari server surat yang terdaftar atau disebutkan berdasarkan catatan ini.

Sample Entry
 domain.com. IN TXT "v=spf1 +a +mx +ip4:192.168.1.5 -all"

Ini mengatakan domain ini akan mengirimkan email yang sah hanya dari A record, MX record server, dan juga dari ip 192.168.1.5 dan semua yang lain dapat ditolak. Dengan catatan SPF di atas, server penerima akan memeriksa semua server dan alamat ipad yang disebutkan dalam SPF. Jika alamat ip cocok, pemeriksaan akan dilewati, dan jika tidak maka akan gagal (pesan akan ditolak secara otomatis) dan jika kita menggunakan “~all” yang merupakan kegagalan lunak yang pesannya akan ditandai sebagai GAGAL tetapi tidak akan ditolak.

Anda dapat merujuk lebih banyak sytanx dari tautan ini.

9. DKIM (DomainKeys Identified Mail)Record

Ini juga merupakan catatan TXT yang merupakan protokol otentikasi email juga yang sedikit lebih rumit daripada SPF. Catatan ini dibuat untuk subdomain yang memiliki pemilih unik untuk kunci dan kemudian akan memiliki “.” Dengan menambahkan catatan seperti itu, itu akan menambahkan tanda tangan digital ke header pesan email. Tanda tangan ini divalidasi menggunakan kunci publik yang diterbitkan data DKIM. Ini agak rumit dan jika Anda berada di cpanel, mereka menyediakan opsi untuk menyelesaikan ini dengan mudah menggunakan opsi aktifkan satu klik.

Sample Entry
 default._domainkey   14400  IN     TXT    "v=DKIM1; k=rsa;
 p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmDb9e2q41oLc0ZDtSNo2Ik4khVMUMkv98N1Y0
 FehUCcFUIUIUIUIUIuiuicfhdyeytrytrryuytytfyfyfytrytrytrtyrytrytrytrytrytdyBQ3XatuaEj
 qGR0zfaY6RSU++gqGF8ZRpjJd+O3AcqRZT4ZT8d7Uhye6Ctgcv3kQEd5I2dTSpodIzWey8reysHJMdCvulRJYdP"
 UWj5PrHfkwY7ec0ZNggTOpmlByXIPRx0Q/oBS9TLlAs785XJMNWjubyyjC6V5JUQ+tRyhwa28TWM/l6/EIcYNBZE
 fWx8oHQsBFLT0dNsRhq9ExX0UDMmbddD0zWoKtx+Wb7ItG0HPPVqne8jWkeXQIDAQAB;

10. DMARC Record

Data DMARC hanya berfungsi jika ada data SPF dan SKIM yang tepat. Ini adalah kebijakan dari proses otentikasi emailnya dan bagaimana server penerima harus menangani email jika ini melanggar kebijakan. Ketika email masuk datang di server jauh, itu akan meminta catatan DMARC-nya dan memastikan mereka menanyakan pertanyaan di bawah ini:

> Apakah surat masuk tanda tangan DKIM sudah benar?
> Apakah pesan tersebut berasal dari nama host ip/server resmi seperti yang disebutkan oleh catatan SPF.
> Apakah header email masuk memiliki keselarasan prpoper sesuai RFC 5322.

Contoh Entri

_dmarc.domain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected];
 ruf=mailto:[email protected]; pct=100"

Sample entry :
 newdomain.com  14400    IN     CNAME   domain.com.
 mail  14400 IN    CNAME mail.domain.com.

_sipfederationtls._tcp.  3600 IN   SRV  100  1  5061  sipfed.online.lync.com.
 _service._protocol.example.com 3600  IN SRV  10  0 5060  service.example.com
 _service._proto.name. TTL class SRV priority weight port target.

domain.com. 300 IN DNSKEY 257 3 5 Z10wdRIHGJGGIUGIUGKUOIKHpouptYRSyrsYRDfYTpoPO
 ipoEUofZcndFN2aVd==
 
 Name ttl class  RRtype flags_filed Protocol Algorithm public_key