Mukadimah

Aspek Non-Teknis

Aspek non-teknis merupakan masalah utama dalam pengelolaan DNS. Mengingat banyak pihak/ institusi yang terkait, sering terjadi ketidak-jelasan perihal siapa yang musti mengerjakan apa. Untuk itu, perlu dilakukan pencatatan dan pengarsip secara cermat perihal peranan pihak-pihak berikut:

• pihak "pemilik" domain "organisasi.dom"
  Pemilik organisasi merupakan "pemilik" -- atau lebih tepatnya "penerima amanat" -- dari domain tersebut. Kepemilikan ini pada umumnya diurus oleh bagian Sistem Informasi. Bagian ini kemudian menunjuk pihak yang akan menjadi kontak admin, kontak teknis, mau pun kontak tagih. Kontak admin merupakan pihak yang memahami kebijaksanaan dari organisasi tersebut, namun perlu pula memahami sedikit seluk-beluk teknis DNS. Kegiatan pengelolaan harian DNS, dapat diwakilkan kepada kontak teknis; sedangkan hal-hal yang berhubungan dengan pembiayaan diwakilkan kepada kontak tagih.
  Proses pendaftaran DNS dapat melibatkan beberapa pihak, seperti Penyelenggara Jasa Interent (PJI), atau Pengelenggara Jasa Web (PJW). Namun, pihak-pihak tersebut bukan pemilik domain yang sangkutan! Untuk itu, jangan mau dikadalin oleh pihak-pihak tersebut! Demikian pula, tidak perlu mengganti nama domain. jika mengganti PJI/PJW,

  Secara berkala (6-12 bulan) perlu dilakukan pemeriksaan daftar kontak-kontak tersebut, mengingat sering terjadi mutasi kepegawaian.

• pihak penyedia DNS server dan secondary-nya
  Informasi rinci perihal pemilihan secondary server dapat dibaca di RFC-2182. Bagian 3.1 dari RFC tersebut menganjurkan agar memilih secondary server yang tidak dalam satu segmen. Inga... inga..., ini merupakan aspek yang sering sekali terlupakan!!!
  Masalah menjadi lebih kompleks, mengingat secondary server eksternal tersebut biasanya dikelola oleh pihak/ organisasi lain. Untuk itu, perlu diyakinkan bahwa kedua belah pihak -- pemberi dan penerima -- amanat; menjalin kontak secara teratur baik dalam tingkatan pribadi mau pun dalam tingkatan resmi/ organisasi.

  Secara berkala (6-12 bulan) perlu dilakukan pemeriksaan secondary, baik secara administratif mau pun secara teknis. Apakah kontak secondary anda masih ingat amanat anda? Apakah kontak secondary anda masih bekerja di sana? Apakah secondary masih berfungsi, atau sudah jadi lamer? Lihat juga contoh catatannya Dullatip.

• pihak pendelegasi domain
  Pendelegasian domain seperti ".com", ".net", ".org", dst. berasal dari pihak yang ditunjuk oleh para registri (seperti InterNIC) dan lain sebagainya. Tulisan ini tidak akan membahas aspek ini lebih lanjut. Untuk informasi lebih lengkap, silakan hubungi sang PJI/ PJW/ konsultan anda.

  Secara berkala (6-12 bulan) perlu dilakukan pemeriksaan apakah terjadi perubahan alamat, tarif, serta kebijaksanaan lainnya dari pihak pendelegasi tersebut.

  Sekali lagi ditekankan bahwa pemilik domain berkewajiban dan bertanggung-jawab untuk mencatat dan mengarsip aspek ini. Terutama, mengingat pengelolaan DNS sangat jarang dilakukan (mungkin sekali setahun, bahkan lebih jarang lagi), arsip tersebut harus mudah dapat ditemukan kembali pada saat dibutuhkan!

  Salah satu cara praktis pengarsipan ialah dengan membuat RR (Resource Record) "TXT" pada berkas konfigurasinya. Namun, cara ini hanya cocok untuk pengelolaan berskala kecil. Umpamanya, pada record "dns.vlsm.org" (lihat juga RR dns.vlsm.org), diberikan catatan sebagai berikut:

  dns	TXT	"DNS:RMS46:19990923:19991003:rms46@oocities.com"
  	TXT	"Percontohan DNS-101"
  

  Pada baris pertama, "RMS46" merupakan inisial dari pembuat record, "19990923" merupakan tanggal pembuatan, "19991003" merupakan tanggal update terakhir, dan "rms46@oocities.com" ialah alamat dari yang dapat dihubungi untuk keterangan lebih lanjut (belum tentu sama dengan pembuat record).

  Sisipkan catatan anda sedekat mungkin dengan berkas zone anda (umpama di direktori /var/named). Lihat juga catatannya si Dullatip.

Aspek Teknis

Penjelasan rinci dari aspek teknis dapat dibaca di RFC-2181 (Clarifications to the DNS Specification). Berikut ini merupakan ilustrasi dari RFC tersebut.

• Log... log... log...
  Banyak kesalahan dapat dihindari, jika para pengelola lebih rajin memeriksa log setelah melakukan perubahan DNS. Lain Padang, lain Belawan, lain pula Lubuk Linggau: Pemeriksaan ini dapat dilakukan dengan 1001 cara menurut kepercayaan dan keyakinan masing-masing. Namun, yang mana dari pada, oleh sebab maka dari itu, justru musti dilakukan! Jadi, mengapa masih banyak yang tidak melakukan? Survey menunjukkan, banyak error yang didiamkan selama berbulan-bulan bahkan bertahun-tahun.
  Berikut merupakan sebuah shell script sederhana yang melakukan restart "named" (ndc reload) pada sebuah sistem linux. Log named tersebut ada di /var/log/named/default. Dengan menggunakan perintah "tail -f", silakan memantau log untuk beberapa saat (10 - 120 detiks).

  #!/bin/sh
  # Sat Apr 22 15:48:10 SGT 2000
  # RMS46
  # sudo       -- not directly using the superuser account
  # named log  -- /var/log/named/default
  # ndc reload -- "kill -1 named"
  
  PATH="/blah/blah/blah"
  
  sudo /etc/init.d/ndc reload
  tail -f /var/log/named/default
  
  exit 0
  exit 0
  

• Membaca Log... log... log...

  Membaca log merupakan sebuah seni tersendiri. Pada awalnya mungkin membingungkan, namun lama-lama (mudah-mudahan) bisa terbiasa. Berikut merupakan sebuah ilustrasi log beneran, tapi nama zone aslinya disamarkan.

  ---

  22-Apr-2000 03:56:27.196 load: warning: Zone "error.dom" 
      (file error.dom): No default TTL set using SOA minimum instead
  

  ---

  Ini merupakan "peringatan" (warning) karena revisi BIND belakang ini mengharapkan directive "$TTL" pada awal berkas "error.dom". Silakan mengintip baris awal dari berkas zone vlsm.org untuk contoh penggunaan directive tersebut.

  ---

  22-Apr-2000 03:56:27.198 db: info: error.dom  has CNAME 
      and other data (invalid)
  22-Apr-2000 03:56:27.199 load: notice: 
      error.dom:20:error.dom: CNAME and OTHER data error
  

  ---

  Masalah CNAME (Canonical NAME) tersebut merupakan penyakit kronis :-(. Singkatnya, RR CNAME tidak boleh dicampur-adukkan dengan "MX", "NS", "TXT", apalagi "A"! Silakan membaca bagian 10.1 dari RFC-2181. Sebagai ilustrasi, perhatikan bahwa RR "ahbeng" menunjuk ke CNAME, serta RR berikutnya ialah "ahbengTXT"; pada RR berikut:

  abbeng		CNAME www-serv-base-nawala.net.
  ahbengTXT	TXT   ":RMS46:19990923:19991003:rms46@oocities.com"
                  TXT   "Tan Ah Beng -- Singaparna -- T-em-asikmalaya"
  

  OK, walau pun berikut ini cuman "warning", tapi malu-malu-in lah!

  ---

  22-Apr-2000 03:56:27.199 load: warning: 
      master zone "error.dom" (IN) rejected due to errors (serial 2000042200)
  

  ---

Pendelegasian Classless IN-ADDR.ARPA

Karena satu dan lain hal, pendelegasian in-addr.arpa. sering kurang mendapatkan perhatian yang cukup. Berikut merupakan ilustrasi dari RFC-2317 (Classless IN-ADDR.ARPA delegation), yaitu pendelegasian ke organisasi yang alamat IP yang kecil (dibawah /24 atau class C):

• zone vlsm.org.

  $ORIGIN dns.vlsm.org.
  coba1       A    192.168.0.1
  coba2       A    192.168.0.2
  ...
  coba65      A    192.168.0.65
  coba66      A    192.168.0.66
  ...
  

• zone 0.168.192.in-addr.arpa.

  $ORIGIN 0.168.192.in-addr.arpa.
  
  1           CNAME 1.0-26
  2           CNAME 2.0-26
  ...
  65          CNAME 65.0-26
  66          CNAME 66.0-26
  ...
  

• zone 0-26.0.168.192.in-addr.arpa.

  $ORIGIN 0-26.0.168.192.in-addr.arpa.
  
  1            PTR  coba1.dns.vlsm.org.
  2            PTR  coba2.dns.vlsm.org.
  ...
  

• zone 64-27.0.168.192.in-addr.arpa.

  $ORIGIN 64-27.0.168.192.in-addr.arpa.
  
  64           PTR  coba64.dns.vlsm.org.
  65           PTR  coba65.dns.vlsm.org.
  ...
  

Penggunaan RR PTR Majemuk

Contoh terakhir ialah penggunaan RR PTR majemuk.

• zone vlsm.org.

  $ORIGIN vlsm.org.
  
          A   207.106.122.248
  ftp     A   207.106.122.248
  mail    A   207.106.122.248
  www     A   207.106.122.248
  

• zone 248-29.122.106.207.in-addr.arpa.

  $ORIGIN 248-29.122.106.207.in-addr.arpa.
  
  248	PTR   vlsm.org.
          PTR   mail.vlsm.org.
          PTR   ftp.vlsm.org.
          PTR   www.vlsm.org.
  

Rujukan

• RFC-2181 -- Clarifications to the DNS Specification
• RFC-2182 -- Selection and Operation of Secondary DNS Servers
• RFC-2317 -- Classless IN-ADDR.ARPA delegation
• Dullatip -- and his README file.
• zones.conf -- a BIND configuration example.
• vlsm.org, 0.168.192.in-addr.arpa zone examples.
• Ah Beng Learns to Manage a Domain -- a bried introduction to DNS.
• BIND -- an implementation of the DNS protocol.
• InterNIC -- to provide the public information regarding Internet domain registration services.

Ucapan Terimakasih