[LOCAL LOGO 1] Studi Kasus: ID*NIC DOM-REG 2756
Rahmat M. Samik-Ibrahim
vLSM.org
[LOCAL LOGO 2]
WHAT's NEW | HOME | vv BOTTOM vv | NEXT>>>

| Mukadimah | ID*NIC | DNS | Catatan |
<<<PREV | ^^TOP^^ | NEXT>>>

Mukadimah

Perinternetan Indonesia masih dalam keadaan yang mengkhawatirkan berhubung dengan jumlah pengguna yang masih sedikit, serta biaya akses yang luar biasa mahal. Perlu diikhtiarkan berbagai cara mencapai momentum jumlah pengguna sehingga internet dapat berkembang secara reaksi rantai. Artinya, orang akan menggunakan internet karena yang lain juga menggunakannya. Dengan demikian, sebaiknya DTT-ID sebaiknya dijadikan alat perangsang pertumbuhan dari pada menjadi alat penghambat.

Apa bila ingin mengembangkan sebuah Network Information Center (NIC), perlu secara jelas mengungkapkan tujuannya. Hal ini juga berlaku untuk apa yang menamakan dirinya dengan ID*NIC. Berdasarkan tujuan yang jelas, akan didapatkan kejelasan atas tempat kedudukan, status hukum, hubungan dengan APJII, tugas, serta hubungannya dengan gTLD-MoU.

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

ID*NIC

ID*NIC yang sekarang, masih perlu lebih mempromosikan dirinya, lebih memperlihatkan keindependenannya, serta menjalankan kebijaksanaan berdasarkan ketentuan yang jelas, dan bukan petunjuk dari atas. Semua aktifitas ID*NIC harus tercatat secara rapih. Peranan LOG ini untuk memudahkan peng-audit-an, terutama untuk memantau permintaan-permintaan seperti petunjuk, minta kekhususan, minta prioritas, dst. dari MTTM. Dalam pembentukan ID*NIC, ada baiknya juga mendengar pendapat dari pihak-pihak berikut seperti APJII, BAKOTAN, BPPT, Deperindag, DRN, IPKIN, Kadin, Perguruan Tinggi, SekNeg, wakil pengguna, YKLI.

Tingkatan prioritas dapat dibagi menjadi tiga: "genting","penting", serta "bukan genting atau penting". Problem operasional DTD pada umumnya, DTD-(AC,CO,MIL,NET,OR).ID pada khususnya merupakan hal yang paling genting. Setelah hal tersebut dapat distabilkan, perlu segera memulai pembuatan panduan kebijaksanaan PDTT-ID beserta PDTD-nya. Mungkin, hal-hal berikut yang perlu mendapatkan perhatian:

  • memperkenalkan dan mempromosikan ID*NIC melalui beberapa milis, serta pembenahan http://www.idnic.net.id/. Webserver ID*NIC seharusnya tidak down lebih dari satu hari. ID*NIC harus menunjukan bahwa mampu mengelola DTD, serta DITERIMA oleh masyarakat. Di abad globalisai ini, agak sulit kalau cuma mengandalkan petunjuk dan autoritas satu arah.
  • (untuk sementara ?) membuka DT3 k12.ac.id untuk menampung aspirasi pemain internet untuk pendidikan dasar dan menengah, serta DT3 dx.ac.id untuk pendidikan tinggi non 4 tahun.
  • draft rencana keja PDTD "AC,CO,NET,MIL,OR" ID
  • BOF "tm.id" (TradeMark), "sm.id" (ServiceMark), "dki.id" (DKI), dan "bdg.id" (Bandung).
  • jaminan pengelolaan (QA) bermutu tinggi untuk perangkat lunak, keras, dan SDM. Proses backup serta pengarsip harus mendapatkan perhatian lebih sungguh-sungguh. Ini tidak terbatas pada syslog, namun juga log dari radius, router (paket), httplog, accounting, formulir pendaftaran, basis data, arsip e-mail untuk *master - abuse - alert - dst, beberapa posting usenet news, Demikian pula, harus ditentukan jangka waktu pengarsipannya (5 tahun offline ?). Perlu ada pertanggungan-jawaban penanggulangan bencana down di atas 15 menit, analisa kapasitas sistem, dst ... dst ... Sepertinya sistem dibawah 128 Mbyte tidak memadai yah ? Setiap masalah mestinya dapat ditanggulangi dengan menggunakan metoda berikut:
    1. mengetahui bahwa ada masalah
    2. mengidentifikasikan masalah yang ada
    3. membuat rencana kerja
    4. melaksanakan rencana kerja, dengan iterasi memperbaiki rencana kerja.
    Keadaan dapat dikatakan tetap mengkhawatirkan, hingga tahap #3 dilaksanakan!

    Ada baiknya, dilakukan penyempurnaan dokumentasi mengenai segala hal yang berhubungan dengan pengelolaan domain. Dengan demikian, akan menjadi referensi, sehingga pertanyaan yang itu-itu juga dapat terhindari. Mungkin perlu mengikuti filosofi ISO-9000 yang entah saya baca dari mana (sorry :-):

    • write down what you do
    • do what you write down
    • verify what you write and what you do!
  • implementasi secondary DTD-ID di semua PJI: walau pun tidak semua akan didaftar dalam NS, namun setiap PJI harus siap menjadi secondary. Secondary DTT-ID yang nantinya akan segera jadi primary, plus kontak teknis-nya.
  • mengambil inisiatif pembentukan IAHC (Indonesian Ad Hoc Committee) untuk membuat MoU DTT-ID dengan mengundang semua pihak yang tertarik.
  • menata ulang / pendaftaran ulang, terutama untuk domain yang didaftar sebelum 1996. Domain-domain yang mati agar diumumkan kepada publik bahwa akan dihapus dalam jangka waktu (umpamanya) 6 bulan.
  • apa pun yang dilakukan harus dicatat dan diarsip, dikonfirmasikan kepada PDTD, serta DIBERI TENGGANG WAKTU YANG CUKUP. Jadi, sebaiknya tidak main mendadakan, termasuk jika ingin mengumumkan harga.
  • Ini semuanya membutuhkan biaya. Namun, ini tidak berarti PDTD semena-mena secara sepihak menentukan ongkos pencatatan domain! Semua perlu dibuat penjelasannya, serta perlu dipertanggung-jawabkan. Pada dasarnya, SDM yang mengurus pendaftaran domain tidak boleh ditindas hingga menderita pindah dari satu rumah kontrakan ke rumah kontrakan lainnya, serta hilir mudik menggunakan kendaraan umum. Dilain pihak, biaya tersebut harus kompetitif.
  • Masih banyak biaya lain yang dibutuhkan. Mungkin perlu meminta bantuan pakar ahli hukum, dst. Tingkat kehandalan sistem harus sangat tinggi, serta menggunakan prosedur yang baku. Sudah tidak lagi zamannya, melakukan pendaftaran domain berdasarkan kebaikan hati pihak-pihak tertentu.

Maraknya jumlah PJI yang ada, menyebabkan terjadinya kemungkinan bahwa para pelanggan memilih lebih dari satu PJI, berpindah PJI, dan seterusnya. Oleh sebab maka dari itu, mohon kiranya diperhatikan hal-hal berikut:

  • Pada dasarnya, domain merupakan milik dari pemilik identitas bersangkutan, serta BUKAN milik PJI, atau APJII, atau PDTT-ID, atau PDTD-*, atau warisan nenek moyang, dst.
  • Pemilik identitas mempercayakan urusan domain kepada kontak-adminnya. Sedangkan, kontak-admin mendelegasikan semua urusan kepada kontak-teknisnya.
  • Kontak teknis harus memahami aspek teknis dari DNS, serta mempersiapkan zone di name-servernya. Biasanya NameServer-nya berada di PJI yang bersangkutan. Namun, ini tidak berarti bahwa domain tersebut menjadi milik dari PJI!
  • Ada kesan, bahwa para PJI kurang memberikan informasi lengkap kepada pelanggannya. Akibatnya, pelanggan berkesan bahwa PJI memiliki kuasa atas domainnya. Ini masalah serius, serta seharusnya semua pihak lebih tanggap terhadap hal ini.
  • Ini sebetulnya sebuah peluang bisnis untuk membuat "PT DNS Jaya", dengan bekerja sama dengan beberapa PJI. P.T. DNS Jaya akan mempermudah para pelanggan untuk pindah PJI.
  • Peranan registry tidak lebih dari mencatat glue resource record NS, agar zone tersebut dikenal secara luas. Selama glue record tersebut tidak berubah, tidak perlu melapor kepada PDTD. Kecuali, ada perubahan alamat, identitas, dst.
  • Pembuat zone sebaiknya selalu menyimpan arsip pendaftaran domain. Ini akan memudahkan melakukan update. Status DNS yang jelas: terutama jika pelanggan berhenti dari sebuah PJI. Seharusnya ada klausal tenggang waktu yang jelas dalam pengaturan hal ini.
  • Pelanggan dengan lebih dari satu PJI, TIDAK perlu memiliki banyak domain. Satu nama domain cukup untuk satu perusahaan.
  • Adalah merupakan tugas PJI untuk mendidik/meyakinkan pelanggannya, bahwa domain terkait merupakan milik dan tanggung-jawab perusahaan, dan bukannya PJI.
  • PJI yang mengirimkan formulir penghapusan domain agar mengkonsultasikan hal tersebut kepada pemilik domain terkait (cc:). Yang dihapus, sebaiknya hanya record NS saja,

Apa pun yang akan dirancang, ujung-ujungnya duit! Sistem yang dikelola secara sukarela agak sulit dijamin kelangsungnya. Biaya untuk pendaftaran domain harus benar-benar mencerminkan biaya yang dibutuhkan untuk keperluan tersebut. Ini harus terlepas dari apakah para pendaftar setuju atau tidak! Namun, apa bila biaya pendaftaran DTD-ID tidak kompetitif dibandingkan dengan biaya pendaftaran pada DTT-COM, DTT-ORG, dst, maka para pendaftar akan pada lari. Taraf pelayanan pun perlu diperhatikan dengan sungguh-sungguh.

Biaya untuk proses biaya itu sendiri dapat lebih mahal daripada biaya proses setup DNS. Untuk keperluan tersebut, perlu jadi merchant VISA, punya akuntan, sekretariat, dst. Perlu ada analisa mengenenai kondisi pendaftaran sekarang: Berapa pun tarif yang dikeluarkan ID*NIC, pasti akan ada yang "mengklaim" bisa mengerjakan 50%.

Salah satu kiat peningkatan efektifitas dan efisiensi ialah dengan melakukan outsourcing. Terdapat kemungkinan, bahwa fungsi pendaftaran domain ini dapat di-outsource 100 %. Hal ini sejalan dengan upaya memanfaatkan DTT-ID dalam kiat mempopulerkan penggunaan internet di Indonesia.

Dalam hal ini, diasumsikan bahwa penghuni DTD-NET.ID pada umumnya -- PJI pada khususnya -- menyadari tanggung-jawabnya dalam aspek domain ini. Pada dasarnya, pelaksana pendaftaran domain tidak dianjurkan memiliki mesin sendiri; serta seharusnya menggunakan mesin DNS yang disediakan para PJI. Dengan demikian, biaya untuk pengadaan mesin DNS, pemeliharaan, update, upgrade, backup, link internet, modem, dan telepon, ditanggung langsung oleh PJI. Tentunya, harus dibuatkan sebuah kode etik administratur: memiliki password superuser tidak otomatis berarti berhak melakukan pendaftaran domain, seperti halnya memiliki batu tidak otomatis berarti punya hak untuk melempar kaca.

Komponen biaya SDM (Sumber Daya Manusia) sangat dominan dalam proses pendaftaran domain dan perubahan. Biaya ini dapat ditekan, jika melakukan pengisian formulir secara benar dan tepat. Para pendaftar seharusnya benar-benar sudah siap menggunakan internet. Sangat diharapkan bantuan dari PJI dan para konsultan internet untuk memberikan penyuluhan sejelas- jelasnya kepada para calon pendaftar domain. Biaya Pendaftaran seharusnya termasuk biaya penghapusan domain.

Komponen pemeliharan data domain berupa perangkat lunak, perangkat keras, dan konektifitas internet. Diharapkan, bahwa sebagian dari biaya ini berasal dari sponsor yaitu para PJI, Vendor, dst.

Administrasi penarikan biaya pendaftaran domain pun dapat di-outsource-kan kepada pihak yang biasa melakukan penagihan (umpama PJI). Proses ini, termasuk pembukuan, basis data pelanggan, dst. Penarikan biaya dapat berbasis komisi yaitu sesuai dengan jumlah pelanggan yang diproses.

Kegiatan terakhir, yaitu update zone baru pun dapat di-outsource berbasis komisi. Tentunya, semua ini membutuhkan perancangan dan persiapan yang matang.

  • jumlah man-hour dibutuhkan untuk satu transaksi
  • jumlah transaksi per minggu
  • jumlah penolakan per minggu
  • dst.
Dalam formulir pendaftaran domain yang sekarang, diungkapkan ada 3 komponen biaya. Komponen biaya utama ialah SDM untuk proses pendaftaran domain. Umpama, biaya pendaftaran / update / hapus domain ialah Rp. 25.000 per transaksi. Namun, proses administrasinya mungkin lebih dari Rp. 25.000.

Untuk itu diusulkan pendaftaran domain dilakukan melalui "agen pendaftaran", umpama para PJI. Setiap agen menyetor Rp. 1.000.000 sebagai biaya pendaftaran, plus Rp. 1.000.000 sebagai deposit. Deposit tersebut bisa untuk 100 transaksi: baru/ubah/hapus. Kalau deposit habis, harus segera diisi kembali. Para agen boleh "ngutang" hingga Rp. 100.000 / 1 bulan. Lebih dari itu, harus daftar ulang.

Untuk menghindari monopoli, kesempatan untuk menjadi agen harus dibuka selebar mungkin. Agen boleh "menjual" jasa pendaftaran sebebasnya. Bisa gratis, bisa Rp. 100.000.-. Namun, pengelola domain tetap membuka kesempatan untuk mendaftar domain non-agen pun tetap dibuka, umpamanya Rp. 250.000.-

SDM merupakan komponen paling mahal dalam sebuah sistem informasi modern. Untuk itu, jumlah SDM yang dibutuhkan perlu dibuat seefektif dan seoptimum mungkin. Hal ini juga perlu dikaitkan dengan omset dari sistem tersebut.

Pembuat sistem berbahasa Inggris, sebaiknya tidak menjadi prioritas utama. Ini berdasarkan asumsi, bahwa semuanya harus mengerti bahasa Indonsia.

Mengingat hal ini, sebaiknya KONTAK ADMIN dari DTD-AC.CO.NET.MIL.OR-ID digabung, serta diserahkan kepada ID*NIC. ID*NIC dipersilakan untuk bergerak dalam bidang lain, seperti gTLD-MoU, IIX, IP address, dst, namun kegiatan tersebut dilur konteks gagasan 30 September ini. Dalam hal menjalankan tugas ini, ID*NIC bertanggung jawab kepada PDTD terkait.

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

DNS

  • Sangat dianjurkan agar primary dari DTT-ID menjadi secondary dari seluruh DTD-nya dengan menggunakan STUB. Mungkin bisa juga dipertimbangkan, jika primary dari DTD juga menjadi secondary dari DT3-nya. Selain menambah kehandalan DNS, bisa dijadikan alasan untuk iuran domain. Namun, perlu dianalisa mengenai kemampuan teknis sebuah DNS, terutama jumlah maksimum domain yang bisa di layani.

    Ini berarti, bahwa informasi alamat transfer zone harus akurat. Jika ada perubahan, mesti sebelumnya di konfirmasikan kepada semua pihak yang bersangkutan dengan transfer zone. Tidak cukup hanya mengumumkan namun harus cek dan re-cek.

    Jangan lupa, bahwa NS tidak boleh berbentuk CNAME, serta sebaiknya memiliki reverse in-addr.arpa yang sama.

  • Mengumumkan tidak sama dengan mengaku. Mengumumkan berarti informasi tersebut dapat terakses secara luas, atau secara explisit tercantum dalam database sebuah zone.
  • siapa yang akan melihara perangkat keras / lunak ?
  • siapa yang akan update ?
  • siapa yang melakukan pemeliharaan harian
  • siapa yang akan melakukan reinstall kalau crash ?
  • siapa yang menangani sistem pada saat hari raya ?
  • bagimana status log crash, security, reboot ?
  • UPS tahan berapa lama ?
  • konfirmasi secondaries
  • perioda DNS-WALK ?
  • waktu maksimum sebelum sistem pulih berapa jam?
  • waktu maksimum sebelum link pulih berapa jam?
  • berapa hit perjam pada DNS ?
  • kontak teknis ?
  • kontak admin dari DTD ?
  • sisdur P3K: crash, backup, pantau, link, dst.
<<<PREV | ^^TOP^^ | NEXT>>>

Catatan

:
<<<PREV | ^^TOP^^
[LOCAL LOGO 1] Copyright © 1996-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: BisnisWeb - Fusilkom-UI. File revision: 9.3 2003/07/21 05:09:5 -- E-CONTACT. Special thanks for this webspace provider. [LOCAL LOGO 2]