[LOCAL LOGO 1] Serbaneka DNS -- Domain Name System
Rahmat M. Samik-Ibrahim -- vLSM.org
[LOCAL LOGO 2]

WHAT's NEW | HOME | vv BOTTOM vv | NEXT>>>

| Mukadimah| Non Teknis| Teknis| IN-ADDR.ARPA| Rujukan| Ucapan Terimakasih|
<<<PREV | ^^TOP^^ | NEXT>>>

Mukadimah

Tulisan ini merupakan ilustrasi dari RFC-2181 (Clarifications to the DNS Specification), RFC-2182 (Selection and Operation of Secondary DNS Servers), dan RFC-2317 (Classless IN-ADDR.ARPA delegation). Contoh-contoh betulan, akan diambil dari situs si Dullatip yaitu zones.conf, zone vlsm.org, dan IN-ADDR.ARPA. Sebagai kelanjutan Ah Beng Learns to Manage a Domain, mudah-mudahan tulisan ini membantu untuk mengatasi beberapa kekeliruan dalam mengelola DNS (Domain Name System). Berikut ini akan dibahas perihal Aspek Non Teknis, Aspek Teknis, Pendelegasian Classless IN-ADDR.ARPA, serta Penggunaan RR PTR Majemuk.

<<<PREV | ^^TOP^^ | NEXT>>>

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@geocities.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@geocities.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.

<<<PREV | ^^TOP^^ | NEXT>>>

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@geocities.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)
    

<<<PREV | ^^TOP^^ | NEXT>>>

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.
    
<<<PREV | ^^TOP^^ | NEXT>>>

Rujukan

<<<PREV | ^^TOP^^ | NEXT>>>

Ucapan Terimakasih

Terimakasih kepada rekan-rekan seperti -- XYZZY, et. al. yang telah memberikan masukan secara langsung atau pun tidak langsung atas tulisan ini.

<<<PREV | ^^TOP^^
[LOCAL LOGO 1] Copyright © 2000-2014 Rahmat M. Samik-Ibrahim . Provided AS-IS with no LIABILITY. Permission is granted to copy, distribute, and/or modify this webpage provided this notice is preserved. MIRRORS of this site: Fusilkom-UI - BisnisWeb. File revision: 9.3 2002/11/07 07:33:4 -- E-CONTACT. Special thanks for this webspace provider. [LOCAL LOGO 2]