Reverse Connection

       

Ketika Internet Tidak Lagi Ramah dari Arah Masuk

Beberapa tahun lalu, membangun server kecil di rumah itu terasa sederhana.
Cukup punya modem, router, lalu aktifkan port forwarding, maka server web, CCTV, atau remote desktop langsung bisa diakses dari luar. Namun hari ini, banyak orang mengalami situasi seperti ini:

  • Port forwarding sudah disetting benar, tapi tetap tidak bisa diakses
  • IP di router berbeda dengan IP yang terlihat di internet
  • Game online menunjukkan NAT Type Strict
  • CCTV hanya bisa diakses dari jaringan lokal

Jika kamu pernah mengalami hal-hal yang saya sebutkan di atas, besar kemungkinan kamu sedang berada di balik sebuah sistem yang bernama CGNAT (Carrier Grade NAT). Untuk mengetahui apa itu CGNAT silahkan KLIK DISINI

Di sinilah reverse connection muncul—not sebagai trik aneh, tapi sebagai pendekatan logis yang lahir dari keterbatasan internet modern berbasis IPv4.

Masalah Intinya: Koneksi Masuk vs Koneksi Keluar

Sebelum masuk ke reverse connection, kita perlu memahami satu fakta penting:

Internet modern sangat ketat terhadap koneksi masuk,
tetapi sangat longgar terhadap koneksi keluar.

Mari kita sederhanakan.

Koneksi Keluar (Outbound)

  • Device di rumah → internet
  • Hampir selalu diizinkan
Router dan ISP sangat “ramah”

Koneksi Masuk (Inbound)

    Koneksi dari Internet ke device server kita di rumah Hampir selalu diblokir,Terutama jika:

  • Menggunakan NAT
  • Menggunakan CGNAT
  • Tidak punya IP public

Secara default, internet tidak bisa “mengetuk pintu” rumah kita.

Analogi Dasar: Apartemen Tanpa Nomor Pintu

Bayangkan kamu tinggal di sebuah apartemen besar:

  • Gedungnya punya satu alamat resmi
  • Setiap penghuni tidak punya nomor pintu yang bisa diakses publik
  • Satpam hanya mengizinkan penghuni keluar, bukan tamu masuk sembarangan

Kondisinya seperti ini:

  • Kamu bisa keluar gedung kapan saja
  • Tapi orang luar tidak bisa langsung datang ke unitmu
Pada analogi tersebut apartemen ini adalah Router + NAT + CGNAT.  Dan kamu adalah Server atau device di jaringan lokal

Lalu, Apa Itu Reverse Connection?

Reverse connection adalah pendekatan di mana:

Bukan internet yang mencoba masuk ke jaringan kita,
melainkan jaringan kita yang lebih dulu membuka koneksi ke internet.

Koneksi tersebut:

  • Dibuat dari dalam ke luar
  • Dijaga tetap aktif
  • Digunakan dua arah

Secara konsep, kita membalik arah komunikasi.

Reverse Connection dalam Satu Kalimat

Reverse connection adalah teknik mengakses layanan di balik NAT/CGNAT dengan cara membiarkan server lokal terlebih dahulu “menghubungi dunia luar”.

Analogi Lanjutan: Menelpon Balik Lewat Resepsionis

Kembali ke analogi apartemen.

Kamu ingin orang luar bisa menghubungimu, tapi:

  • Mereka tidak bisa masuk
  • Tidak ada nomor unit publik

Solusinya:

  1. Kamu menelpon seorang teman yang tinggal di rumah dengan alamat jelas
  2. Kamu tetap berada di jalur telepon itu
  3. Jika ada orang yang ingin bicara denganmu:
    • Mereka menelpon temanmu
    • Temanmu menyambungkan pembicaraan ke kamu
    • Temanmu ini adalah:

Server publik (VPS / cloud / relay)

Struktur Dasar Reverse Connection

Secara arsitektur, selalu ada tiga pihak:

[Client Internet]
        ↓
[Server Publik / VPS]
        ↓  (koneksi yang dibuka dari dalam)
[Server Lokal / Device Rumah]

Poin penting:

  • Tidak ada koneksi langsung dari internet ke rumah
  • Semua komunikasi melewati jalur yang sudah dibuka dari dalam

Bagaimana Reverse Connection Bekerja (Step-by-Step)

1. Server Lokal Membuka Koneksi Keluar

Misalnya:

  • Server di rumah
  • CCTV
  • Raspberry Pi
  • PC kantor kecil

Device ini:

  • Menghubungi server publik (VPS / cloud)
  • Membuat koneksi keluar (TCP atau UDP)

Router & CGNAT akan berkata:

“Oh ini koneksi keluar? Silakan.”

2. Koneksi Dijaga Tetap Hidup

Koneksi ini:

  • Tidak ditutup
  • Diberi keepalive
  • NAT table tetap aktif

Inilah “jalur rahasia” yang nanti dipakai bolak-balik.

3. Client Internet Mengakses Server Publik

Client (HP, laptop, browser):

https://alamat-server-publik

Server publik:

  • Tidak menghubungi rumah
  • Tapi mengirim data lewat jalur yang sudah ada

4. Data Sampai ke Server Lokal

Dari sudut pandang server lokal:

“Saya hanya membalas koneksi yang sudah saya buat sendiri.”

Tidak ada inbound connection baru.
Tidak ada port forwarding.
Tidak ada konflik dengan CGNAT.

Jenis-Jenis Reverse Connection yang Umum Dipakai

1. Reverse SSH Tunnel

Teknik klasik, sederhana, dan sangat edukatif. Cocok untuk:

  • Administrator
  • Akses sementara
  • Troubleshooting

Namun:

  • Kurang stabil untuk produksi
  • Bergantung session SSH

2. VPN Client ke Server (Reverse VPN)

Pendekatan paling fleksibel dan rapi. Ciri-ciri nya adalah:

  • Server lokal bertindak sebagai VPN client
  • VPS sebagai VPN server
  • Setelah terhubung, jaringan lokal bisa diakses lewat tunnel

Contoh teknologi:

  • WireGuard
  • OpenVPN
  • Tailscale

3. Cloud Tunnel (Modern & Praktis)

Pendekatan yang kini paling populer. Ciri-ciri nya adalah:

  • Agent kecil di server lokal
  • Menghubungi cloud provider
  • Cloud menyediakan domain publik

Contoh:

  • Cloudflare Tunnel
  • ngrok
Konsep Cloudfare Tunnel (SUMBER)


Kenapa Reverse Connection Sangat Relevan Saat Ini?

Karena realitanya:

  • IPv4 sudah habis
  • CGNAT tidak bisa dihindari
  • Port forwarding bukan lagi solusi universal
  • Banyak layanan butuh akses jarak jauh

Reverse connection bukan solusi darurat tapi pola desain jaringan modern.

Bahkan:

  • IoT
  • Smart device
  • Remote management
  • Zero Trust Network

Semuanya mengandalkan konsep ini.

Kelebihan Reverse Connection

  • Tidak butuh IP public
  • Bekerja di balik CGNAT
  • Lebih aman (tidak expose port)
  • Lebih fleksibel

Keterbatasannya

  • Bergantung koneksi keluar
  • Latensi bertambah satu hop
  • Perlu server publik sebagai perantara

Namun ini trade-off yang realistis di dunia IPv4 saat ini.

Penutup: Bukan Trik, Tapi Evolusi Pola Pikir

Reverse connection sering dianggap “akal-akalan”. Padahal sebenarnya, ini adalah:

Cara paling jujur untuk berdamai dengan NAT dan CGNAT.

Alih-alih melawan batasan jaringan modern, reverse connection mengikuti aturannya dan memanfaatkannya. Dan justru karena itu, teknik ini:

  • Stabil
  • Aman
  • Dipakai luas di sistem modern

Pada akhirnya, reverse connection mengajarkan satu hal penting:

Kadang, untuk bisa diakses dunia,
kita harus berani melangkah keluar terlebih dahulu.

Continue Reading →

Cara Menggunakan PuTTY di Windows 11

    ,    

Tutorial Menggunakan PuTTY di Windows 11 untuk Akses SSH Hosting

PuTTY adalah salah satu aplikasi SSH client paling populer di Windows. Tool ini sering digunakan oleh pengguna hosting, administrator server, maupun web developer untuk mengakses server melalui command line secara aman.

Pada postingan tutorial ini, kita akan membahas cara menggunakan PuTTY di Windows 11 secara step by step, khususnya untuk hosting berbasis cPanel yang mengizinkan koneksi SSH meskipun tanpa full/root access. Tutorial ini ditulis dengan alur yang rapi agar mudah diikuti, bahkan oleh pemula.

1. Apa Itu PuTTY dan Mengapa Digunakan?

PuTTY adalah aplikasi gratis dan open-source yang berfungsi sebagai:

  • SSH Client
  • Telnet Client
  • Serial Console Client

Dalam konteks hosting dan server, PuTTY paling sering digunakan untuk koneksi SSH (Secure Shell). SSH memungkinkan kita:

  • Mengakses server dari jarak jauh
  • Menjalankan perintah terminal
  • Mengelola file website
  • Melakukan troubleshooting

Semua aktivitas tersebut dilakukan dengan koneksi terenkripsi, sehingga lebih aman dibandingkan metode lama seperti FTP biasa.

2. Gambaran Akses SSH di Hosting cPanel

Sebelum masuk ke praktik, penting memahami jenis akses yang biasanya diberikan oleh hosting berbasis cPanel:

Karakteristik SSH di Shared Hosting

  • Tidak memiliki akses root (sudo)
  • Terbatas pada direktori home user
  • Tidak bisa menginstal paket sistem
  • Tetap bisa menjalankan perintah dasar Linux

Walaupun terbatas, akses SSH ini sangat berguna untuk:

  • Edit file lebih cepat
  • Menjalankan script PHP
  • Menggunakan Git (jika diizinkan)
  • Manajemen file skala besar

PuTTY sudah lebih dari cukup untuk kebutuhan tersebut.

3. Cara Download dan Install PuTTY di Windows 11

Langkah 1: Download PuTTY

  • Buka browser (Chrome, Edge, atau lainnya)
  • Kunjungi situs resmi PuTTY: putty.org
  • Klik menu Download PuTTY
  • Pilih file:
            putty-64bit-<versi>-installer.msi

Disarankan selalu download dari situs resmi untuk menghindari malware.

Langkah 2: Install PuTTY

  1. Double-click file .msi yang sudah diunduh
  2. Klik Next
  3. Biarkan semua opsi default
  4. Klik Install
  5. Tunggu hingga proses selesai
  6. Klik Finish

Setelah itu, PuTTY sudah terpasang di Windows 11 Anda.

4. Menyiapkan Data SSH dari cPanel Hosting

Agar bisa login menggunakan PuTTY, Anda memerlukan beberapa data penting dari hosting.

Aktifkan SSH Access

  1. Login ke cPanel
  2. Masuk ke menu Security
  3. Klik SSH Access
  4. Jika tersedia tombol Enable SSH Access, klik tombol tersebut

Beberapa hosting mengaktifkan SSH secara otomatis tanpa perlu enable manual.

Data yang Harus Disiapkan

Catat informasi berikut:

  • Hostname / Server Address
  • Port SSH (biasanya 22)
  • Username cPanel
  • Password cPanel

Informasi ini biasanya terdapat di:

  • Halaman SSH Access
  • Email detail akun hosting
  • Menu Server Information

5. Konfigurasi PuTTY untuk Koneksi SSH

Langkah 1: Buka PuTTY

  • Klik Start Menu
  • Ketik PuTTY
  • Jalankan aplikasi PuTTY

Akan muncul jendela PuTTY Configuration.

Langkah 2: Isi Konfigurasi Dasar

Pada halaman utama:

1    Host Name (or IP address)
      Isi dengan domain atau hostname server, bisa juga dengan IP Server Hosting
2    Port
      Isi 22 (kecuali hosting Anda menggunakan port lain)
3    Connection Type
      Pilih SSH

Langkah 3: Simpan Session (Opsional tapi Disarankan)

Agar tidak perlu mengisi ulang setiap kali:

  • Isi kolom Saved Sessions dengan nama, misalnya Hosting-SSH
  • Klik Save

Session ini bisa digunakan kembali kapan saja.

Tampilan awal putty


6. Login ke Hosting Menggunakan PuTTY

Langkah 1: Mulai Koneksi

  • Klik Open
  • Jika muncul peringatan PuTTY Security Alert, klik Accept

Peringatan ini normal dan hanya muncul saat pertama kali koneksi.

Langkah 2: Masukkan Username dan Password

Di jendela terminal:

  • Ketik username cPanel → Enter
  • Ketik password cPanel → Enter

Catatan:

  • Password tidak akan terlihat saat diketik
  • Ini adalah mekanisme keamanan Linux

Jika berhasil, Anda akan melihat prompt seperti:

username@server:~$

Artinya Anda sudah berhasil login via SSH. 

Tampilan ketika berhasil connect ke server hosting via SSH


7. Perintah Dasar yang Perlu Diketahui

Setelah login, berikut beberapa perintah dasar yang sering digunakan:

  • pwd → melihat direktori saat ini
  • ls → melihat isi folder
  • cd nama_folder → pindah folder
  • php -v → cek versi PHP
  • nano file.php → edit file .php

Perintah-perintah ini aman digunakan di shared hosting.

8. Batasan Akses SSH di Hosting cPanel

Penting untuk memahami batasannya agar tidak bingung.

Yang Bisa Dilakukan

  • Mengelola file website
  • Edit konfigurasi aplikasi
  • Menjalankan script CLI terbatas
  • Menggunakan Git (jika diaktifkan)

Yang Tidak Bisa Dilakukan

  • Menggunakan sudo
  • Install paket sistem
  • Mengubah konfigurasi server global
  • Mengakses direktori sistem

Semua batasan ini normal dan wajar di shared hosting.

9. Kesimpulan

PuTTY adalah tool sederhana namun sangat powerful untuk mengakses hosting melalui SSH di Windows 11. Meskipun hosting hanya memberikan akses terbatas (non-root), PuTTY tetap sangat membantu dalam:

  • Efisiensi kerja
  • Manajemen file
  • Administrasi website

Dengan mengikuti langkah-langkah di atas, Anda sudah memiliki fondasi kuat untuk menggunakan SSH dalam pengelolaan hosting berbasis cPanel.

Semoga tutorial ini bermanfaat dan bisa menjadi panduan praktis bagi Anda yang ingin mulai menggunakan SSH dengan PuTTY.

Continue Reading →

Proses Dan Teknologi Di Balik Large Language Model (LLM)

       

Sebagai seorang yang cukup lama mengamati dunia teknologi—khususnya AI dan Large Language Model (LLM)—saya sering menemui satu pola yang sama: banyak orang tertarik dengan LLM, tapi berhenti di level “pakainya saja”. Padahal, justru bagian paling menarik dari LLM itu ada di balik layarnya 

Di postingan kali ini, saya ingin mengajak Anda berjalan pelan-pelan, agak santai tapi tetap teknis, membedah bagaimana LLM dilatih, dijalankan, dan mengapa teknologi di baliknya begitu mahal sekaligus menakjubkan. Di beberapa bagian, saya akan menyelipkan analogi agar konsep yang berat terasa lebih membumi.

1. Bagaimana Proses Training LLM Dilakukan dari Awal

Training LLM sebenarnya adalah melatih sebuah mode Artificial Intelligence dengan input berupa teks dalam jumlah luar biasa besar.

a. Pengumpulan Data

Proses dimulai dari pengumpulan data teks: buku, artikel, forum, dokumentasi teknis, hingga percakapan publik. Data ini tidak langsung digunakan, melainkan melalui proses kurasi, pembersihan, dan penyaringan.

Analogi sederhana: bayangkan Anda ingin belajar memasak. Anda tentu tidak akan mencampur resep dari buku masak berkualitas dengan catatan dapur yang kotor dan tidak jelas ukurannya.

b. Tokenisasi

Teks dipecah menjadi unit kecil bernama token. Token bisa berupa kata, potongan kata, atau simbol.

Contoh:

"LLM itu pintar" → [LL, M, itu, pintar]

c. Training dengan Objective Prediksi

Model dilatih untuk menebak token berikutnya berdasarkan token sebelumnya. Inilah inti dari training LLM.

Secara matematis, model belajar meminimalkan loss function (biasanya cross-entropy) menggunakan teknik backpropagation dan gradient descent.

Proses ini dilakukan jutaan hingga triliunan kali iterasi, menggunakan ribuan GPU yang bekerja paralel.

LLM Training (image from: Research gate.net)

2. Pre-training vs Fine-tuning vs Instruction Tuning

Banyak orang mengira training LLM itu satu tahap saja. Padahal ada beberapa fase penting.

Pre-training

Ini adalah fase “sekolah dasar sampai universitas”. Model membaca teks dalam skala besar tanpa tujuan spesifik. Ciri utamanya adalah:

  • Data sangat besar
  • Biaya sangat mahal
  • Dilakukan sekali

Fine-tuning

Di tahap ini, model dipersempit ke domain tertentu.

Contoh:

  • LLM umum → LLM medis
  • LLM umum → LLM hukum
Analogi: setelah lulus kuliah umum, Anda ikut kursus spesialis.

Instruction Tuning

Ini tahap yang membuat LLM terlihat pintar dan sopan saat diajak bicara.

Model dilatih menggunakan pasangan:

  • Instruction (perintah)
  • Response (jawaban ideal)

Tanpa instruction tuning, LLM memang pintar… tapi kurang bisa diajak ngobrol dengan baik.

3. Model LLM Populer: GPT, LLaMA, Falcon, Gemini

Mari kita bahas beberapa pemain besar di dunia LLM.

GPT (OpenAI)

  • Closed-source (sebagian)
  • Sangat kuat dalam reasoning dan bahasa alami
  • Digunakan di ChatGPT

LLaMA (Meta)
  • Open-weight
  • Populer di komunitas riset dan self-hosted AI
  • Efisien untuk fine-tuning

Falcon

  • Dikembangkan oleh TII (UEA)
  • Fokus pada efisiensi dan performa
  • Open model dengan lisensi cukup longgar

Gemini (Google)

  • Terintegrasi kuat dengan ekosistem Google
  • Multimodal sejak awal (teks, gambar, audio)
  • Berjalan di atas TPU
saya melihat tren yang jelas: model open-source semakin matang dan kompetitif.

4. Apa itu Embedding dan Mengapa Penting untuk Search AI

Embedding adalah cara mengubah teks menjadi vektor angka. Contoh:

"server down" → [0.12, -0.88, 1.42, ...]

Dengan embedding:

  • Makna bisa diukur
  • Kemiripan bisa dihitung
  • Search menjadi berbasis konteks, bukan kata kunci
Jadi, analogi Embedding itu seperti rak buku otomatis tanpa label
Bayangkan:
  • Ada jutaan buku
  • Tidak ada judul, kategori, atau indeks
  • AI membaca semuanya
  • Lalu menyusunnya di rak berdasarkan kemiripan isi

Hasilnya:
Buku tentang:  “DNS”, “TCP/IP”, “Routing”
→ berdekatan

Buku tentang:  “Bodybuilding”, “Protein”, “Hypertrophy”
→ rak lain

Buku “WiFi Security”
→ bisa dekat ke “networking” dan “cyber security”

Inilah fondasi dari:

  • Semantic Search
  • RAG (Retrieval Augmented Generation)
  • Chatbot berbasis dokumen

5. Context Window Panjang: Tantangan dan Solusinya

Context window adalah berapa banyak token yang bisa diingat LLM dalam satu sesi.

Masalahnya:

  • Semakin panjang konteks → komputasi semakin mahal
  • Attention bersifat O(n²)

Analogi: membaca satu buku tipis vs membaca satu perpustakaan sambil disuruh meringkas isinya sekaligus.

Solusi yang Digunakan:

  • Sliding window
  • Chunking + embedding
  • Sparse attention
  • Ring attention & FlashAttention

Tren terbaru menunjukkan context window bisa mencapai 100k+ token, tapi dengan optimasi serius.

6. Inference vs Training: Mana yang Lebih Mahal?

Jawaban singkatnya: training lebih mahal, inference lebih sering.

Training

  • Biaya di awal sangat besar
  • Butuh ribuan GPU
  • Bisa mencapai jutaan dolar

Inference

  • Lebih murah per request
  • Tapi skalanya masif
  • Biaya operasional jangka panjang
Training itu seperti membangun sebuah pabrik, inference itu biaya listrik dan operasional hariannya.

7. Peran GPU, TPU, dan NPU dalam LLM

    GPU
    -Fleksibel
    -Dominan di training dan inference
    -NVIDIA masih merajai
    TPU
    -Khusus matrix operation
    -Sangat efisien untuk skala besar
    -Digunakan Google
          NPU
          -Fokus ke edge device
          -Laptop, smartphone, IoT
          -Untuk inference ringan

Saya melihat masa depan LLM akan semakin terdistribusi, tidak hanya di data center.

8. Mengapa VRAM Menjadi Faktor Kritis dalam LLM

VRAM menentukan:

  • Ukuran model yang bisa dijalankan
  • Panjang context window
  • Batch size

Model 7B saja bisa butuh:

  • ~14 GB VRAM (FP16)

  • Lebih hemat dengan quantization

Analogi: VRAM itu meja kerja. jika meja itu besar, anda bisa melakukan beberapa pekerjaan sekaligus. Namun semakin kecil mejanya, semakin sering Anda harus bolak-balik merapikan barang sehingga membutuhkan energi tambahan untuk mengerjakan pekerjaan yang tidak efisien

Inilah alasan:

  • GPU 24GB sangat populer
  • Quantization (INT8, INT4) makin penting
  • Offloading ke RAM jadi solusi kompromi

Penutup

LLM bukan sekadar "AI yang bisa ngobrol". Ia sebenarnya adalah hasil dari:

  • Operasi Matematika
  • Komputasi skala besar
  • Optimasi ekstrem

Sebagai seorang yang mencintai teknologi, saya selalu percaya: teknologi yang dipahami akan terasa lebih manusiawi.

Semoga tulisan ini membantu Anda melihat LLM bukan sebagai kotak hitam, tapi sebagai sistem cerdas yang bisa kita pahami, eksplorasi, dan manfaatkan dengan bijak

Continue Reading →

Network Security untuk Pengguna Internet PART 3

       

Serangan Jaringan yang Paling Umum: MitM, Sniffing, dan Spoofing

Pada dua artikel sebelumnya ( PART 3 ), kita telah membahas fondasi network security serta bagaimana data bergerak di internet melalui berbagai lapisan jaringan. Kini, pada artikel ketiga, kita akan masuk lebih dalam ke ancaman nyata di level jaringan yang sering dimanfaatkan oleh penyerang, bahkan dengan peralatan dan teknik yang relatif sederhana.

Serangan jaringan (network-based attacks) memiliki karakteristik unik: ia tidak selalu menargetkan aplikasi, melainkan jalur komunikasi. Artinya, meskipun sebuah aplikasi aman dan diperbarui, data tetap bisa bocor jika jaringan tempat data tersebut lewat tidak aman.

Artikel ini membahas empat serangan jaringan yang paling umum dan fundamental:

  • Man-in-the-Middle (MitM)
  • Packet sniffing
  • ARP spoofing
  • DNS spoofing

Pembahasan akan dinaikkan sedikit level teknisnya, dilengkapi dengan diagram ASCII untuk mempermudah visualisasi, serta contoh konkret serangan di jaringan lokal dan Wi-Fi publik.

1. Man-in-the-Middle (MitM)

1.1 Konsep Dasar MitM

Man-in-the-Middle (MitM) adalah kondisi di mana penyerang berhasil memposisikan dirinya di jalur komunikasi antara dua pihak yang seharusnya berkomunikasi langsung. Dalam kondisi ini, penyerang dapat bersifat:

  • Pasif: hanya mengamati lalu lintas
  • Aktif: memodifikasi, memblokir, atau menyisipkan data

Diagram sederhana:

[Client] <----> [Server]

Tanpa serangan

Dengan MitM:

[Client] <--> [Attacker] <--> [Server]

Seluruh paket data melewati penyerang terlebih dahulu.

1.2 MitM di Layer Jaringan

MitM tidak selalu terjadi di layer aplikasi. Dalam banyak kasus, MitM terjadi di:

  • Layer 2 (ARP spoofing)
  • Layer 3 (IP spoofing, routing manipulation)
  • Layer 4 (session hijacking)

Inilah alasan mengapa MitM sering tidak terdeteksi oleh aplikasi.

2. Packet Sniffing

2.1 Apa Itu Packet Sniffing?

Packet sniffing adalah teknik menangkap paket data mentah yang lewat di sebuah jaringan. Secara teknis, semua kartu jaringan (Network Interface Card / NIC) mampu menangkap paket, tetapi dalam kondisi normal hanya paket yang ditujukan kepadanya yang diproses.

Dalam mode tertentu (promiscuous mode), NIC dapat menangkap seluruh paket yang lewat.

2.2 Sniffing di Jaringan Lokal

Pada jaringan berbasis Wi-Fi atau hub:

[Client A] )))))
))))) (Media bersama)
[Client B] )))))
)))))
[Attacker] ))))) <-- menangkap paket

Karena media bersifat broadcast, paket dapat disadap oleh perangkat lain.

Pada jaringan switch modern, sniffing sering dikombinasikan dengan ARP spoofing agar lalu lintas korban diarahkan ke penyerang.

2.3 Dampak Packet Sniffing

Jika lalu lintas tidak terenkripsi ( non HTTPS) sniffing dapat mengungkap:

  • Kredensial login (Username dan Password)
  • Cookie sesi
  • Data formulir
  • Konten email

Jika terenkripsi (HTTPS, TLS):

  • Header masih terlihat
  • Isi payload tidak dapat dibaca

Tampilan Wireshark. Aplikasi untuk menangkap paket internet SUMBER


3. ARP Spoofing

3.1 Cara Kerja ARP

ARP (Address Resolution Protocol) bekerja di jaringan lokal untuk memetakan IP address ke MAC address.

Contoh alur normal:

Client: "Siapa pemilik IP 192.168.1.1?"
Router: "Saya, MAC saya AA:AA:AA:AA:AA:AA"

Client kemudian menyimpan informasi ini di ARP table.

3.2 Kelemahan Fundamental ARP

ARP tidak memiliki:

  • Autentikasi
  • Enkripsi
  • Validasi sumber

Akibatnya, setiap ARP reply dipercaya, meskipun tidak diminta.

3.3 Mekanisme ARP Spoofing

Penyerang mengirim ARP reply palsu:
Attacker : " IP 192.168.1.1 itu MAC saya "

ARP table korban berubah:
192.168.1.1 -> MAC_Attacker

Diagram alur:
[Victim] ---> [Attacker] ---> [Router] ---> Internet

Dengan posisi ini, penyerang dapat:

  • Menyadap lalu lintas
  • Melakukan MitM
  • Memutus koneksi (DoS lokal)

ARP spoofing adalah pondasi utama MitM di jaringan lokal.

4. DNS Spoofing

4.1 Cara Kerja DNS Normal

DNS menerjemahkan nama domain menjadi alamat IP.

User -> DNS Server -> IP Address -> Server

4.2 Mekanisme DNS Spoofing

Dalam DNS spoofing, penyerang memanipulasi hasil resolusi DNS:

User -> DNS Palsu -> IP Attacker

Diagram:

[User]
|
| jurnal.my.id?
|
[Fake DNS] ----> IP Server Palsu

Browser tetap menampilkan nama domain yang benar, sehingga korban tidak curiga.

4.3 Dampak DNS Spoofing

  • Phishing tingkat lanjut
  • Penyebaran malware
  • Pengalihan trafik massal

DNS spoofing sering dikombinasikan dengan MitM dan HTTPS downgrade attack.

5. Mengapa Wi-Fi Publik Sangat Berbahaya?

Karakteristik Wi-Fi publik:

  • Banyak pengguna anonim

  • Satu broadcast domain

  • Minim monitoring

Diagram situasi kafe:

[Victim] [Victim]
\ /
\ /
[ Access Point ]
|
[Attacker]

Dalam kondisi ini:

  • ARP spoofing mudah dilakukan

  • Packet sniffing efektif

  • Rogue access point sulit dibedakan

Satu penyerang dapat memonitor puluhan korban sekaligus.

6. Ilustrasi Serangan Terintegrasi di Jaringan Lokal

Skenario serangan:

  1. Penyerang masuk ke Wi-Fi publik

  2. Melakukan ARP spoofing

  3. Mengalihkan lalu lintas korban

  4. Menjalankan packet sniffing

  5. Melakukan MitM pada koneksi HTTP

Diagram ringkas:

Victim -> Attacker -> Router -> Internet

Tanpa enkripsi atau VPN, serangan ini sangat efektif.

7. Mengapa Serangan Ini Sulit Dideteksi?

Beberapa alasan utama:

  • Tidak ada indikasi visual

  • Koneksi tetap berjalan normal

  • Serangan terjadi di layer bawah

Sebagian besar pengguna baru menyadari setelah terjadi penyalahgunaan akun.

Penutup

MitM, packet sniffing, ARP spoofing, dan DNS spoofing adalah serangan jaringan klasik yang hingga hari ini masih sangat relevan. Serangan-serangan ini mengeksploitasi kelemahan fundamental pada desain protokol dan rendahnya kesadaran keamanan jaringan.

Dengan memahami cara kerja teknis serangan ini, pengguna tidak hanya menjadi lebih waspada, tetapi juga mampu memahami mengapa teknologi seperti HTTPS, TLS, VPN, dan segmentasi jaringan menjadi sangat penting.

Pada artikel berikutnya, kita akan membahas bagaimana enkripsi jaringan—khususnya HTTPS dan TLS—bekerja sebagai mekanisme utama untuk melindungi data dari serangan-serangan jaringan yang telah kita bahas di artikel ini.

Continue Reading →

Mengenal Large Language Model (LLM)

       

Dasar, Cara Kerja, dan Rahasianya

Halo! Kalau kamu belakangan ini sering mendengar kata ChatGPT, AI, atau LLM, tapi masih merasa konsepnya agak “abu-abu”, tenang saja — kamu tidak sendirian. Di artikel ini, saya akan mengajak kamu ngobrol santai namun tetap runtut dan teknis secukupnya tentang Large Language Model (LLM).  Anggap saja kita sedang duduk di kafe sore hari, membahas teknologi canggih dengan bahasa yang manusiawi 

1. Apa itu Large Language Model (LLM)?

Large Language Model (LLM) adalah jenis model kecerdasan buatan yang dirancang khusus untuk memahami dan menghasilkan teks dalam bahasa manusia. Disebut large karena:

  • Jumlah data latihnya sangat besar (bisa miliaran hingga triliunan kata)
  • Memiliki parameter dalam jumlah masif (ratusan juta sampai ratusan miliar)

Contoh LLM yang populer antara lain:

  • ChatGPT (keluarga GPT)
  • Gemini
  • LLaMA
  • Mistral

LLM mampu melakukan banyak hal sekaligus:

  • Menjawab pertanyaan
  • Menulis artikel
  • Meringkas dokumen
  • Membantu coding
  • Menerjemahkan bahasa

Namun penting diingat: LLM tidak “berpikir” seperti manusia, ia bekerja berdasarkan pola statistik bahasa.

LLM Training

2. Perbedaan AI, Machine Learning, Deep Learning, dan LLM

Banyak orang mencampuradukkan istilah-istilah ini. Mari kita luruskan dengan analogi sederhana.

1. Artificial Intelligence (AI)
Konsep besar tentang mesin yang meniru kecerdasan manusia

2. Machine Learning (ML)
Cabang AI yang belajar dari data

3. Deep Learning (DL)
ML dengan jaringan saraf berlapis-lapis (deep neural network)

4. Large Language Model (LLM)
Salah satu penerapan Deep Learning yang fokus pada bahasa

Urutannya bisa dibayangkan seperti ini:
    AI → Machine Learning → Deep Learning → LLM
Jadi, semua LLM adalah AI, tapi tidak semua AI adalah LLM.

3. Bagaimana LLM “Memahami” Bahasa Manusia? (Mitos vs Fakta)

Di sinilah bagian yang sering disalahpahami.

❌ Mitos : LLM memahami makna kata seperti manusia

✅ Fakta : LLM mempelajari pola hubungan antar kata berdasarkan probabilitas

LLM bekerja dengan cara:

  • Melihat urutan kata
  • Menghitung kemungkinan kata berikutnya
  • Memilih kata dengan probabilitas paling masuk akal

Contohnya:

“Saya minum kopi di pagi …”

LLM tahu bahwa kata hari atau ini jauh lebih mungkin muncul dibandingkan sepeda.

Jadi ketika jawabannya terlihat “pintar”, itu karena pola bahasanya sangat kuat, bukan karena ia benar-benar paham.

4. Sejarah Singkat LLM: Dari N-gram hingga Transformer

Perjalanan LLM tidak instan, ia melalui evolusi panjang:

1. N-gram model
  • Menghitung kemungkinan kata berdasarkan 1–3 kata sebelumnya
  • Sangat terbatas
2. Statistical Language Model
    Mulai menggunakan probabilitas lebih kompleks

3. Neural Network Language Model
    Memanfaatkan jaringan saraf

4. RNN & LSTM
    Bisa mengingat urutan kata, tapi sulit diskalakan

5. Transformer (2017)Revolusi besar
    Inilah fondasi LLM modern

Sejak transformer diperkenalkan, perkembangan LLM melesat sangat cepat.

5. Apa itu Token, Context Window, dan Parameter?

Tiga istilah ini sering muncul dan penting untuk dipahami.

Token

Token adalah potongan teks yang dibaca model.

  • Bisa berupa kata

  • Bisa potongan kata

  • Bisa tanda baca

Contoh:

“Belajar AI itu seru”

Bisa dipecah menjadi beberapa token.

Context Window

Adalah jumlah token maksimum yang bisa diingat model dalam satu percakapan.

Semakin besar context window:

  • Model bisa memahami konteks panjang

  • Tapi butuh resource lebih besar

Parameter

Parameter adalah “ingatan” internal model.

Semakin banyak parameter:

  • Semakin kompleks pola yang bisa dipelajari

  • Semakin mahal biaya training dan inference

6. Mengapa LLM Membutuhkan Data Sangat Besar?

Bahasa manusia itu:

  • Kaya konteks

  • Ambigu

  • Penuh variasi

Untuk mempelajari semua itu, LLM perlu:

  • Artikel

  • Buku

  • Dokumentasi

  • Percakapan

  • Kode program

Semakin banyak data:

  • Semakin halus pemahaman pola bahasa

  • Semakin kecil kemungkinan jawaban aneh

Namun, data besar juga membawa tantangan etika dan privasi.

7. Transformer Architecture: Inti dari Semua LLM Modern

Transformer adalah arsitektur yang memungkinkan model:

  • Memproses kata secara paralel

  • Memahami hubungan jarak jauh dalam kalimat

Komponen utama transformer:

  • Encoder

  • Decoder

  • Self-attention

  • Feed-forward network

Tanpa transformer, LLM seperti yang kita kenal sekarang hampir mustahil tercipta.

8. Attention Mechanism: Cara Model “Fokus” pada Kata yang Tepat

Attention mechanism memungkinkan model menjawab pertanyaan:

Kata mana yang paling penting dalam kalimat ini?

Contoh kalimat:

“Ani memberi buku kepada Budi karena dia sedang belajar.”

Kata dia mengacu ke siapa?

Attention membantu model menimbang hubungan antar kata sehingga jawabannya lebih masuk akal.

Inilah alasan mengapa LLM terasa sangat kontekstual.

Studi Kasus Singkat: Mengapa ChatGPT Terlihat "Pintar"?

Mari kita ambil contoh sederhana yang sering kita alami.

Ketika kamu bertanya:

"Tolong jelaskan LLM dengan bahasa sederhana"

LLM tidak mengambil jawaban dari satu dokumen tertentu. Yang terjadi sebenarnya adalah:

  1. Pertanyaan diubah menjadi token

  2. Model membaca konteks sebelumnya

  3. Attention mechanism menentukan kata mana yang paling relevan

  4. Model memprediksi kata demi kata yang paling masuk akal

  5. Jawaban dibangun secara bertahap, bukan sekaligus

Karena model telah dilatih dengan jutaan contoh penjelasan serupa, hasil akhirnya terasa alami dan runtut.

Inilah mengapa:

  • Jawaban bisa berbeda tiap kali

  • Tidak ada jawaban yang benar-benar "disimpan"

  • LLM sangat bergantung pada kualitas prompt

Keterbatasan LLM yang Perlu Kita Sadari

Sebagus apa pun LLM, ia tetap memiliki batasan.

Beberapa keterbatasan utama:

  • Halusinasi informasi Model bisa terdengar meyakinkan meski informasinya salah

  • Tidak memiliki pemahaman dunia nyata LLM tidak punya pengalaman, emosi, atau intuisi

  • Bergantung pada data latih Jika data latihnya bias, hasilnya pun bisa bias

  • Context terbatas Jika percakapan terlalu panjang, konteks awal bisa hilang

Memahami keterbatasan ini justru membuat kita lebih bijak menggunakan AI.

Mengapa Pemahaman Dasar LLM Penting untuk Semua Orang?

Bukan hanya developer atau peneliti AI yang perlu memahami LLM.

Bagi pengguna umum:

  • Agar tidak mudah percaya sepenuhnya pada jawaban AI
  • Bisa memanfaatkan AI secara maksimal

Bagi profesional IT:

  • Membantu desain sistem yang lebih realistis
  • Menghindari ekspektasi berlebihan dari klien

Bagi pembuat konten:

  • Bisa berkolaborasi dengan AI, bukan bersaing

LLM adalah alat bantu, bukan pengganti nalar manusia.


Large Language Model bukan sekadar tren sesaat atau mainan teknologi. Ia adalah hasil dari perjalanan panjang riset kecerdasan buatan, data berskala besar, dan inovasi arsitektur yang cerdas.

Dengan memahami konsep dasarnya — mulai dari token, attention, hingga transformer — kita tidak hanya menjadi pengguna, tapi pengguna yang sadar dan kritis.

Di artikel berikutnya, kita akan mulai membahas topik yang lebih praktis seperti prompt engineering, RAG, dan bagaimana LLM diterapkan di aplikasi dunia nyata.


Continue Reading →

Mengenal DNS Zone

       

Fondasi Penting di Balik Akses Website dan Internet

Ketika kita mengetik alamat website seperti jurnal.my.id di browser, jarang sekali kita berpikir tentang proses kompleks yang terjadi di balik layar. Padahal, sebelum halaman website tampil, ada satu sistem penting yang bekerja tanpa henti: DNS (Domain Name System).
Di dalam DNS, terdapat komponen krusial yang disebut DNS Zone.

Artikel ini akan membahas secara menyeluruh apa itu DNS Zone, bagaimana cara kerjanya, jenis-jenis DNS record beserta fungsinya, analogi sederhana untuk memudahkan pemahaman, dan ditutup dengan kesimpulan yang komprehensif.

Apa Itu DNS Zone?

DNS Zone adalah bagian dari sistem DNS yang berisi kumpulan konfigurasi dan catatan (record) untuk sebuah domain.
DNS Zone disimpan dan dikelola pada DNS Server, dan bertugas menjawab pertanyaan seperti:

  • Ke mana domain ini harus diarahkan?
  • Server mana yang menangani email?
  • Subdomain ini mengarah ke mana?
  • Apakah domain ini aman untuk email?

Secara sederhana:

DNS Zone adalah “buku petunjuk resmi” sebuah domain di internet.

Fungsi Utama DNS Zone

DNS Zone memiliki beberapa fungsi penting, antara lain:

  1. Menerjemahkan nama domain ke alamat IP
  2. Mengatur arah lalu lintas website dan email
  3. Menentukan server yang berwenang
  4. Mendukung keamanan email dan domain
  5. Mengatur subdomain dan layanan tambahan

Tanpa DNS Zone yang benar, domain bisa:

  • Tidak bisa diakses
  • Email gagal terkirim
  • Website mengarah ke server yang salah
  • Rentan terhadap spoofing dan penyalahgunaan

Jenis-Jenis DNS Record dan Fungsinya

Di dalam DNS Zone terdapat berbagai DNS Record. Setiap record memiliki peran spesifik.

1. A Record (Address Record)

Fungsi:
Menghubungkan nama domain ke alamat IP IPv4.

Contoh:

jurnal.my.id → 216.239.34.21

Analogi:

A Record seperti alamat rumah.
Jika nama domain adalah nama orang, maka IP address adalah alamat rumah tempat orang tersebut tinggal.

2. AAAA Record

Fungsi:
Menghubungkan domain ke alamat IP IPv6.

Analogi:

Sama seperti A Record, tetapi ini adalah alamat rumah versi baru, lebih panjang dan modern.

3. CNAME Record (Canonical Name)

Fungsi:
Menghubungkan satu domain ke domain lain (alias). Contoh:

www.jurnal.my.id → jurnal.my.id

Analogi:

CNAME seperti nama panggilan.
Seseorang bisa dipanggil “Budi”, “Pak Budi”, atau “Mas Budi”, tapi orangnya tetap sama.

4. MX Record (Mail Exchange)

Fungsi:
Menentukan server email yang bertanggung jawab menerima email domain. Contoh:

jurnal.my.id → mail.jurnal.my.id

Analogi:

MX Record seperti kantor pos utama.
Semua surat (email) akan dikirim ke kantor pos ini terlebih dahulu.

5. TXT Record

Fungsi:
Menyimpan informasi teks untuk keperluan verifikasi dan keamanan.

Biasanya digunakan untuk:

  • SPF
  • DKIM
  • DMARC
  • Verifikasi Google, Microsoft, dll

Analogi:

TXT Record seperti catatan resmi atau surat keterangan yang ditempel di kantor, berisi aturan dan pernyataan resmi.

6. SPF Record (via TXT)

Fungsi:
Menentukan server mana yang boleh mengirim email atas nama domain.

Analogi:

SPF seperti daftar pegawai resmi.
Jika email dikirim oleh orang yang tidak ada di daftar, maka dianggap mencurigakan.

7. DKIM Record

Fungsi:
Memberi tanda tangan digital pada email agar tidak dimodifikasi di tengah jalan.

Analogi:

DKIM seperti segel dan tanda tangan di amplop surat.
Jika segel rusak, penerima tahu surat telah diutak-atik.

8. DMARC Record

Fungsi:
Memberi kebijakan apa yang harus dilakukan jika email gagal SPF atau DKIM.

Analogi:

DMARC seperti instruksi keamanan:
 Jika ada surat palsu, apakah harus dibuang, ditolak, atau hanya dilaporkan?

9. NS Record (Name Server)

Fungsi:
Menentukan DNS Server yang berwenang untuk domain tersebut.

Analogi:

NS Record seperti kantor catatan sipil.
Jika ingin tahu data resmi sebuah domain, tanya ke kantor ini.

10. SOA Record (Start of Authority)

Fungsi:
Menandai informasi utama DNS Zone, termasuk:

  • Primary DNS
  • Email admin
  • Serial number
  • Interval sinkronisasi

Analogi:

SOA adalah akta kelahiran domain.
Di sinilah informasi inti dan otoritas domain ditetapkan.

11. PTR Record (Reverse DNS)

Fungsi:
Menghubungkan IP Address ke nama domain (kebalikan A Record).

Analogi:

Jika A Record adalah mencari alamat dari nama,
PTR Record adalah mencari nama dari alamat.

12. SRV Record

Fungsi:
Menentukan layanan tertentu seperti:

VoIP, Chat server dan Game server

Analogi:

SRV seperti papan petunjuk di gedung:
Layanan A di lantai 2, layanan B di lantai 5.

Posisi menu Zone Editor di cpanel


Hubungan DNS Zone dengan Hosting dan cPanel

Dalam konteks hosting (terutama cPanel):

  • DNS Zone biasanya otomatis dibuat
  • Bisa diedit melalui Zone Editor
  • Setiap kesalahan kecil bisa berdampak besar

Contohnya:

  • Salah MX → email tidak masuk
  • Salah A Record → website down
  • Salah TXT → email masuk spam

Contoh record-record pada domain


Contoh record-record pada domain


Kesimpulan Penutup

DNS Zone adalah fondasi utama yang menopang seluruh aktivitas domain di internet. Tanpa DNS Zone yang benar dan terkonfigurasi dengan baik, website dan email tidak akan berfungsi sebagaimana mestinya.

Setiap DNS Record memiliki peran yang spesifik:

  • A & AAAA menentukan tujuan utama domain
  • CNAME mempermudah pengelolaan alias
  • MX memastikan email sampai ke tujuan
  • TXT, SPF, DKIM, DMARC menjaga reputasi dan keamanan
  • NS & SOA memastikan otoritas dan konsistensi
  • SRV & PTR mendukung layanan lanjutan dan kepercayaan server

Jika diibaratkan, DNS Zone adalah peta kota, DNS Record adalah rambu dan alamat, dan DNS Server adalah petugas informasi.
Tanpa peta yang jelas dan rambu yang benar, semua orang akan tersesat.

Memahami DNS Zone bukan hanya penting bagi administrator server, tetapi juga bagi pemilik website, blogger, dan siapa pun yang ingin serius membangun kehadiran di internet secara profesional dan aman.

Continue Reading →

Memahami Propagasi DNS

       

Mengapa Perubahan Domain Tidak Pernah Instan?

Bagi sebagian orang, dunia domain dan DNS sering kali terasa seperti “kotak hitam”. Kita membeli domain, mengubah beberapa pengaturan, lalu berharap semuanya langsung berjalan sempurna. Namun ketika kenyataan tidak seindah harapan—misalnya website belum bisa diakses, masih mengarah ke server lama, atau HTTPS belum aktif—muncullah satu istilah yang hampir selalu disebut: propagasi DNS.

Sayangnya, istilah ini sering dipahami secara keliru. Banyak yang mengira propagasi adalah proses misterius di server tertentu, atau bahkan kesalahan dari penyedia hosting. Padahal, propagasi DNS adalah konsekuensi alami dari cara kerja sistem DNS global itu sendiri.

Tulisan ini akan membahas propagasi DNS secara menyeluruh: mulai dari latar belakang, urgensinya, proses teknis dari awal hingga akhir, hingga kesimpulan yang merangkum pemahaman secara utuh. Beberapa analogi akan digunakan agar konsep teknis tetap mudah dicerna, tanpa mengorbankan akurasi.

Latar Belakang: Mengapa DNS Diciptakan?

Untuk memahami propagasi DNS, kita perlu mundur sedikit ke belakang.

Internet pada dasarnya bekerja dengan alamat numerik, yang kita kenal sebagai IP address. Contohnya:

142.250.4.121

Masalahnya, manusia sangat buruk dalam mengingat angka. Bayangkan jika setiap kali ingin membuka sebuah website, kita harus mengetikkan deretan angka seperti di atas. Tentu tidak praktis.

Di sinilah Domain Name System (DNS) berperan. DNS berfungsi sebagai penerjemah antara:

nama domain → IP address

Dengan DNS, kita cukup mengetik:

example.com

dan sistem DNS akan menerjemahkannya ke IP server tujuan.

DNS sering disebut sebagai “buku telepon internet”, meskipun analogi ini sebenarnya sudah sedikit usang. DNS modern jauh lebih kompleks, terdistribusi, dan berlapis.

Mengapa Sistem DNS Harus Terdistribusi?

Pertanyaan penting berikutnya adalah:
Mengapa DNS tidak dibuat satu pusat saja?

Jawabannya sederhana: skalabilitas dan ketahanan.

Bayangkan jika seluruh dunia hanya bergantung pada satu server DNS pusat. Jika server tersebut mati, maka Internet global lumpuh, Tidak ada domain yang bisa diakses dan Dampaknya berskala internasional

Karena itulah DNS dirancang sebagai sistem terdistribusi global, yang terdiri dari:

  • Root DNS Server
  • TLD Server (.com  .id  .net  .org  dll)
  • Authoritative DNS Server
  • Resolver DNS (ISP, publik, dll)

Struktur terdistribusi inilah yang menjadi akar dari konsep propagasi DNS.

Apa Itu Propagasi DNS?

Propagasi DNS adalah waktu yang dibutuhkan agar perubahan DNS dikenali dan digunakan oleh seluruh sistem DNS di dunia. Perlu digarisbawahi:
  • Tidak ada tombol “sebar DNS”
  • Tidak ada proses pengiriman aktif
  • Propagasi adalah efek dari cache DNS yang tersebar

Dengan kata lain, propagasi DNS bukan bug, melainkan fitur desain.

Mengapa Propagasi DNS Itu Penting (Urgensi)

Propagasi DNS menjadi sangat krusial dalam beberapa kondisi berikut:

  1. Mengganti server hosting
  2. Mengubah IP address
  3. Mengganti nameserver
  4. Menghubungkan domain ke layanan pihak ketiga (Blogspot, GitHub Pages, Cloudflare, dll)
  5. Mengaktifkan atau memperbaiki SSL
  6. Mengatur email (MX record, SPF, DKIM, DMARC)
Halaman propagasi di dnschecker.org


Proses DNS: Dari Awal Sampai Akhir

Bagian ini adalah inti teknis dari pembahasan.

Mari kita bayangkan seseorang membuka browser dan mengetik:

jurnal.my.id

1. Browser Bertanya ke DNS Resolver

Langkah pertama:

  • Browser tidak langsung tahu IP tujuan
  • Browser bertanya ke DNS resolver

Resolver ini bisa berupa:

  • DNS milik ISP
  • DNS Google (8.8.8.8)
  • DNS Cloudflare (1.1.1.1)
  • DNS lokal router

Resolver inilah yang berperan besar dalam propagasi karena resolver menyimpan cache.

2. Cache Resolver Dicek

Resolver akan bertanya:

“Apakah saya sudah tahu IP jurnal.my.id?”
  • Jika Ya, dan TTL belum habis → resolver  akan langsung menjawab
  • Jika Tidak → maka resolver bertanya ke DNS global

Di sinilah perubahan DNS sering “tidak terasa”, karena resolver tidak mau bertanya ulang sebelum TTL habis.

3. Resolver Bertanya ke Root DNS

Jika cache kosong atau expired:

  1. Resolver bertanya ke Root DNS
  2. Root DNS menjawab:
            “Saya tidak tahu IP-nya, tapi saya tahu siapa yang mengelola .id”

Root DNS tidak menyimpan IP domain, hanya petunjuk ke tingkat berikutnya.

4. Resolver Bertanya ke TLD DNS (.id → my.id)

Selanjutnya:

  • Resolver bertanya ke DNS untuk .id
  • Lalu ke DNS untuk my.id

Jawabannya:

“Nameserver jurnal.my.id adalah srv1.ubuntuserver.com”

Sekali lagi, belum ada IP website di sini.

5. Resolver Bertanya ke Authoritative DNS

Sekarang resolver tahu harus bertanya ke mana:

  • srv1.ubuntuserver.com

Di sinilah DNS zone Anda disimpan:

Yaitu: A record, CNAME, MX, TXT, dan lain-lain

srv1.ubuntuserver.com menjawab:

"IP = server Google (Blogspot)"

6. Resolver Menyimpan Cache (TTL)

Setelah mendapat jawaban:

  • Resolver menyimpan IP tersebut

  • Selama TTL belum habis, resolver tidak akan bertanya ulang

📌 Inilah penyebab utama propagasi DNS.

TTL: Komponen Kecil dengan Dampak Besar

TTL (Time To Live) menentukan:

Berapa lama sebuah record DNS boleh disimpan di cache

Contoh:

  • TTL 300 → 5 menit

  • TTL 3600 → 1 jam

  • TTL 86400 → 24 jam

Jika Anda mengubah IP tetapi TTL lama masih aktif:

  • Resolver tetap menggunakan data lama

  • Website bisa mengarah ke server lama

  • SSL bisa gagal

  • Email bisa tersendat

TTL adalah kompromi antara kecepatan update dan efisiensi jaringan.

Analogi: Propagasi DNS seperti Peta Kota

Bayangkan sebuah kota besar dengan jutaan penduduk.

  • Domain = nama gedung

  • DNS = peta kota

  • Resolver = fotokopi peta

  • TTL = masa berlaku peta

Ketika sebuah gedung pindah alamat:

  • Tidak semua orang langsung punya peta terbaru

  • Orang-orang baru akan tahu setelah peta lama kedaluwarsa

  • Selama itu, ada yang tersesat, ada yang sudah sampai tujuan

Tidak ada yang salah dengan gedungnya.
Yang terjadi hanyalah peta belum diperbarui di semua tempat.

Propagasi Saat Ganti Nameserver

Saat mengganti nameserver, efek propagasi biasanya lebih terasa, karena:

  • Informasi nameserver disimpan di level TLD

  • Resolver harus memperbarui rute DNS dari tingkat atas

Akibatnya:

  • Sebagian resolver masih bertanya ke DNS lama

  • Sebagian sudah ke DNS baru

Ini sebabnya pergantian nameserver sering memakan waktu lebih lama dibanding sekadar ganti A record.

Propagasi dan HTTPS (SSL)

Banyak orang mengira SSL gagal karena:

  • Server error

  • Sertifikat belum dibuat

  • Konfigurasi salah

Padahal sering kali penyebabnya:

  • DNS belum konsisten ke server yang sama

Jika:

  • Sebagian resolver ke server lama

  • Sebagian ke server baru

Maka sistem SSL (misalnya Let’s Encrypt atau Blogspot) tidak bisa memverifikasi domain secara konsisten.

Inilah alasan mengapa:

  • HTTPS baru aktif setelah propagasi selesai

  • Sertifikat bisa “nyangkut” sementara

Hal yang Perlu Dipahami (Kesalahan Umum)

  1. Propagasi bukan kesalahan

  2. Tidak bisa dipercepat secara paksa

  3. Mengganti DNS berulang justru memperparah

  4. “Di saya sudah bisa” ≠ “di semua orang sudah bisa”

Setiap resolver punya cache masing-masing.

contoh Tampilan jawaban DNS Server


Kesimpulan

Propagasi DNS bukanlah sesuatu yang perlu ditakuti, tetapi perlu dipahami.

Ia muncul bukan karena sistem DNS lemah, melainkan karena:

  • DNS dirancang terdistribusi

  • DNS mengandalkan cache

  • Cache adalah kunci efisiensi internet global

Setiap kali Anda:

  • Mengganti IP

  • Mengubah nameserver

  • Menghubungkan domain ke layanan baru

Maka yang sebenarnya Anda lakukan adalah:

Menunggu hingga seluruh “peta internet” diperbarui secara alami.

Dengan pemahaman ini, kita bisa:

  • Lebih sabar

  • Lebih tenang

  • Lebih tepat dalam troubleshooting

Dan yang terpenting:
tidak menyalahkan sistem yang sebenarnya sedang bekerja dengan benar.


Continue Reading →
Langganan: Komentar (Atom)

Memahami Propagasi DNS

Keluarga Ubuntu

Keluarga Ubuntu

Perbedaan Sistem File Linux dan Windows

Perbedaan Sistem File Linux dan Windows
⬆