Sudah lama gue secara pribadi menggunaan “DNS Sinkhole” dari yang paling ekstrim memodifikasi berkas /etc/hosts di komputer, sampai ke menggunakan Pi-hole dan sekarang menggunakan AdGuardHome yang lebih ringan dan sederhana dari Pi-hole.
Ketika menggunakan DNS Sinkhole via Pi-hole, gue berpikir untuk tidak ingin menggunakan ini sendirian. Gue membuka akses Pi-holegue publik dengan meng-ekspos port 53. Namun sayangnya, pendekatan tersebut tidak efektif mengingat ISP tidak jarang mensabotase DNS query kita. Pendekatan selanjutnya adalah dengan menjalankan DoH Server dan menjadikan Pi-hole sebagai upstream. Lalu gue berpikir jika pendekatan ini kurang efektif, selain karena harus menjalankan 2 layanan juga karena terdapat 2 lapisan dalam melakukan DNS Query.
Lalu gue menemukan AdGuardHome dan sangat memenuhi kebutuhan gue. Dan bukan hanya mendukung DoH, melainkan DoT dan DoQ juga. Serta lebih ringan dari Pi-hole, dan gue tidak memiliki alasan untuk tidak menggunakan AdGuardHome.
Tentang Domain Name System
Setiap domain terdaftar di “top-level domain” seperti .com yang populer digunakan untuk hal-hal komersil dan .org untuk organisasi.
Tujuan utama dari penamaan menggunakan domain ini adalah agar pengguna internet tidak perlu ribet-ribet menghafal alamat IP 74.125.24.100 untuk dapat mengakses mesin pencari yang dijalankan oleh Google, cukup hafalkan google.com, and enjoy the ride. Selain itu, jika mesin yang memiliki alamat IP 74.125.24.100 sedang tidak bisa diakses, dengan menggunakan penamaan berbasis domain ini pengguna bisa mengakses mesin lainnya yang menjalankan layanan yang sama namun memiliki alamat IP berbeda, tanpa perlu menghafal (lagi) alamat IP tersebut.
Ada biaya untuk mendaftarkan alamat domain kamu. Pada dasarnya kita tidak pernah membeli domain, melainkan menyewanya. Seperti blog ini, gue menyewa nama faultable dari gTLD .dev yang dikelola oleh Google, dan setiap tahun ada biaya yang harus gue bayar.
Kepada siapa gue bayar?
Ke Google (sebagai registrar/pencatat sekaligus registry/pengelola dari gTLD .dev) dan ke ICANN sebesar $0.18 yang sudah menjadi kewajiban.
Karena penamaan domain ini yang selalu bergantung dengan gTLD, tidak jarang “perusahaan besar” membeli di beberapa gTLD lain menggunakan *brand *yang sama seperti google.com, google.co.id, google.co dan sebagainya untuk melindungi merek mereka.
Ya, domain adalah tentang merek/brand sesuatu di internet.
Dan bukan alasan mengapa sekarang ada gTLD yang unik per-merek seperti .google untuk Google, .apple untuk Apple, dsb agar tidak perlu pusing-pusing memelihara banyak domain demi alasan keamanan :))
Apakah kita bisa membuat gTLD sendiri, sehingga, kita tidak perlu membeli:
- rizaldy.com
- rizaldy.co
- rizaldy.io
Dsb melainkan hanya:
- .rizaldy
Untuk melindungi “brand” kita sebagaimana yang dilakukan oleh pemain besar seperti Google dan Apple? Tentu bisa, dan tentu tidak mudah apalagi murah.
Meskipun DNS pada esensinya adalah sistem yang “ter-desentralisasi” (misal seperti setiap orang dapat menjalankan DNS Resolver nya sendiri) namun sistem DNS sekarang adalah ter-sentralisasi. Pada dasarnya ada 3 level dalam hierarki DNS:
- Root server (.)
- gTLD atau generic Top-level domain (.com, .io, .id, dll)
- Domain anda disini! (faultable.dev, faultable.blog, dll)
Sejauh ini ada 13 root server yang ada, {a-m}.root-servers.{net,org}, silahkan jalankan dig(1) tanpa parameter apapun untuk memverifikasi. 13 root server tersebut dikelola oleh ICANN, yang meskipun ICANN adalah organisasi non-profit, namun yang sedang kita bicarakan adalah tentang “sentralisasi” dan “desentralisasi”, bukan?
DNS Censorship
Beberapa ada yang membahas tentang DNS Censorship, namun apa maksud dari itu?
Misal, begini.
Gue menyewa alamat faultable.dev dari Google, dan gue memiliki A Record yang mengarah ke komputer yang memiliki alamat IP 143.198.198.198. Misal, jika lo menggunakan DNS Resolver nya Cloudflare (1.1.1.1), ketika komputer ingin mengetahui alamat IP dari faultable.dev, besar kemungkinan jawabannya adalah 143.198.198.198 jika tidak ada “censorship”.
Bagaimana 1.1.1.1 bisa tau **dan yakin **bahwa faultable.dev memiliki alamat IP tersebut?
- Pertama dia akan bertanya ke root server siapa penanggung jawab
.dev - Lalu ke
.devdia akan bertanya siapa penanggung jawabfaultable.dev - Penanggung jawab
faultable.devadalahns0{1-4}.edgyscale.host(authoritative nameserver), maka dia akan bertanya kesana - Authoritative nameserver bilang kalau
faultable.devmemiliki alamat IP 143.198.198.198
Gue beli domain faultable.dev di domains.google dan berarti registry/pencatat yang bertanggung jawab adalah Google Registry. Gue bilang ke Google Registry bahwa Authoritative Nameserver yang gue gunakan adalah .edgyscale.host. Cara sederhana untuk “mengetahui” apakah tidak ada censorship terkait faultable.dev tersebut dengan menggunakan DNSSEC yang akan gue bahas lebih lanjut nanti.
Jika ingin mempelajari sedikit tentang DNSSEC, bisa baca di halaman CloudFlare ini.
Dengan DNSSEC, singkatnya kita dapat dengan lebih mudah memvalidasi apakah terdapat censorship. Akhir-akhir ini raidforums.com diblokir di Indonesia, dan domain tersebut menggunakan DNSSEC. Untuk pengguna internet dari ISP Biznet situs tidak dapat diakses demi mengikuti aturan pemerintah.
Mengakses raidforums.com
Disitu terlihat bahwa konten yang ada di raidforums.com hanyalah meta tag untuk melakukan *redirect *ke “Safe Surf” nya Biznet. Dan juga disitu terlihat bahwa alamat IP dari raidforums.com adalah 202.169.44.80 yang padahal itu adalah miliki Biznet. Bagaimana bisa kita mendapatkan alamat IP tersebut? Mari kita tanyakan ke Authoritative Name Server nya!
dig raidforums.com NS
Disitu terlihat bahwa Start of Authority (SOA) nya adalah rpz.zone.porn yang padahal seharusnya adalah elliot.ns.cloudflare.com dan dns.cloudflare.com.
RPZ diatas adalah singkatan dari Response Policy Zone yang singkatnya biasa digunakan untuk melakukan “filtering” misal seperti pencegahan ketika mencoba mengakses situs yang dianggap “phising”.
Berdasarkan kasus diatas, DNS query yang ada tidak bertanya ke Authoritative Name Server yang digunakan oleh raidforums.com. Sistem DNS seperti ini rentan dengan censorship, terlebih setiap entitas bisa dengan bebas menjawab DNS Query apapun selagi memiliki kontrol terhadap jaringan.
Dan kasus diatas hanyalah satu contoh untuk *censorship *di level pemerintah yang diterapkan oleh ISP. Yang menjadi pertanyaan, bagaimana bila suatu saat Google mematikan gTLD .dev nya? Bagaimana bila suatu saat faultable.dev diblokir oleh Google misal karena gue membenci Google? Tidak ada yang tau apa yang terjadi di masa depan, dan gue adalah salah satu orang yang berdiri di ujung.
Decentralized DNS, literally
Ingat tentang Root Server yang pernah disinggung sebelumnya?
Dalam setiap kasus “decentralized”, berarti setiap orang dapat melakukan hal tersebut, tanpa izin. Ingin menjalankan Authoritative Name Server sendiri? Sure, deploy PowerDNS dan nikmati perjalanan anda dalam mengatur ribuan permintaan masuk dari DNS Recursor dan orang jahat yang mencoba untuk melakukan DNS Poisoning.
Bagaimana bila ingin berpartisipasi dalam Root Server juga?
Di sistem internet sekarang, jawabannya adalah hampir tidak mungkin karena yang bertanggung jawab untuk menjalankan Root Server hanyalah ICANN.
Meskipun ada *community-effort *terkait alternative operasional Root Server yakni Open NIC yang tidak bergantung dengan ICANN, namun tetap inti dari “desentraliasi” disini tidak terpenuhi.
Gue sudah lama mengikuti informasi terkait Handshake, salah satu alternatif dari Root DNS, community-effort juga namun ter-desentralisasi. Gue sebelumnya belum tertarik dengan Handshake karena pada saat itu ada blockchain-based Root DNS lain seperti Namecoin, tapi melihat masa depan Handshake yang menurut gue lebih cerah dari yang lain, gue tertarik untuk memperdalam tentang protokol tersebut.
Untuk lebih mempermudah memahami Handshake, anggap Handshake adalah Root Server dan Zone file nya berada di Blockchain.
Blockchain pada dasarnya hanyalah sebuah *merkle-tree *namun dengan gaya, anyway.
Salah satu entitas (di level registrar) yang mendukung misi Handshake adalah Namebase, siapapun dapat mendaftarkan gTLD nya sendiri di blockchain Handshake.
Perlu diingat ketika ada yang membahas tentang “blockchain” kita harus mengetahui blockchain “yang mana” yang dimaksud. Dalam konteks disini, blockchain tersebut adalah di protokol Handshake dan “mata uang” yang digunakan di blockchain tersebut adalah HNS.
Gue mencoba membeli gTLD gue sendiri di Handshake, yakni rizaldy. Proses pembelian memakan waktu sekitar 2 minggu dan gue *bid *sekitar 2 HNS karena gue yakin tidak ada yang tertarik lagi membeli nama tersebut. Karena gue menjalankan DNS Resolver sendiri, tentu gue bisa saja membuat DNS Rewrite dengan memberikan jawaban 143.198.198.198 setiap kali ada request A record ke rizaldy. Namun tidak semua pengguna internet menggunakan DNS Resolver gue, kan?
Ini percobaan ketika gue mencoba resolve hi.rizaldy baik menggunakan Handshake Resolver langsung maupun ke DNS Resolver yang mendukung Handshake (NextDNS).
45.90.28.92 adalah DNS Server dari NextDNS
And it just fucking works!
edgyDNS is supporting Handshake domains!
Bagi kamu yang tertarik dengan Handshake, kamu bisa menggunakan DNS Resolver yang gue (melalui edgy.network) tawarkan melalui:
- DoH: https://dns.edgy.network/dns-query
- DoT: tls://dns.edgy.network:853
- DoQ: quic://dns.edgy.network:784
Untuk pengguna MacOS Big Sur & iOS 14, bisa menggunakan “Profile” yang bisa diunduh disini:
Gue lebih memilih menggunakan Profile karena berjalan di level OS dan tanpa bantuan program lainnya seperti dnsproxy misalnya. Anyway.
Tentu saja kita menggunakan DNS Upstream sendiri melalui HNSD nya yang dibangun diatas Unbound. Gue sudah melakukan pengujian selama 1-2 minggu, dan perbedaan (latensi) nya daripada menggunakan Unbound murni (upstream 1) dan PowerDNS (upstream 2) hanya sekitar 8-15ms untuk root domain yang dikelola oleh ICANN, yang gue rasa sangat kecil.
Handshake, ENS, Unstoppable Domains, Namecoin
Tentu saja gue sudah *aware *dengan hal ini dan gue akan ceritakan sedikit kenapa gue memilih Handshake.
Meskipun sama-sama proyek eksperimental, pembeda paling kontras antar keempat nya sejauh yang gue tau adalah di Blockchain, penggunaan & cara “client” me-resolve domain name.
Namecoin dan Handshake berada di blockchain sendiri-sendiri, sedangkan ENS dan Unstoppable Domains diatas blockchain Ethereum.
ENS, Unstoppable Domains dan Namecoin adalah “registry” untuk gTLD yang mereka tawarkan (.eth, .bit, .ens, .crypto) sedangkan Handshake adalah di Root domain (.rizaldy, .evilfactorylabs, dll).
ENS, Unstoppable Domains dan Namecoin tidak memiliki “light client” atau yang sederhananya adalah untuk dapat menjalankan non-full node terkait operasional dengan blockchain. Di Handshake dapat menjalankan mode SPV node yang fokus ke “name resolution” daripada berpartisipasi penuh dalam operasional blockchain tersebut (menjadi miner misalnya).
Dan terakhir, misi Handshake bukan hanya tentang DNS, melainkan di (decentralized) Certificate Authority juga meskipun sekarang sudah ada organisasi non-profit yang dapat menerbitkan sertifikat secara gratis yakni Let’s Encrypt.
Namun sekali lagi, bukan disitu poinnya. Bukan di non-profit, gratis, ataupun community-effort, melainkan di desentralisasi.
Salah satu Handshake co-founder adalah Andrew Lee
Tentu saja gue udah *aware *juga tentang ini. Mungkin beberapa sudah tidak asing dengan Andrew Lee, namun jika pernah mendengar Private Internet Access (layanan VPN) dan Freenode (jaringan IRC) salah satu orang dibalik 2 organisasi tersebut adalah si Andrew ini.
Akhir-akhir ini terdapat kontroversi terkait si Andrew khususnya tentang Freenode. Andrew bukanlah orang yang baru di teknologi terkait “desentraliasi” ini mengingat dia adalah co-founder dari Mt. Gox, salah satu *exchange *Bitcoin terbesar yang pernah beroperasi.
Selain itu, dia juga dikenal sebagai salah satu “long-time privacy advocate” yang sepertinya menjadi panduan yang pas antara “desentralisasi” dan “privasi”.
Bagaimanapun Handshake hanyalah sebuah protocol dan setiap orang dapat menjalankan Handshake (name) resolver nya sendiri sebagaimana salah satu benefit dari sistem yang ter-desentralisasi.
Gue tertarik untuk mengenal lebih dalam dengan Handshake dan potensinya, khususnya dibagian Certificate Authority juga.
Sejauh ini beberapa klien memiliki “trust store” nya tersendiri seperti daftar yang ada di Mozilla, Chromium, dan Apple. Jika sertifikat diterbitkan oleh CA yang “tidak diketahui” maka klien akan menampilkan peringatan sebagaimana ketika kamu mengakses https://hi.rizaldy yang menggunakan minica sebagai penerbit sertifikat.
Warning di Firefox karena penerbit sertifikat tidak diketahui (minica)
It’s all about ownership, isn’t it?
Ketika kamu mengakses faultable.dev menggunakan protokol HTTPS, peramban (klien) menganggap koneksi tersebut aman selain karena koneksi antara komputer kamu ke server tempat blog ini berada terenkripsi, juga karena kamu benar-benar berkomunikasi dengan server yang bertanggung jawab terkait domain faultable.dev
Jika kamu menggunakan DNS yang ditawarkan oleh Biznet, kamu tidak akan bisa mengakses https://reddit.com (per 5/6/21) karena 1) Alamat IP dari reddit.com berbeda dengan hasil yang diberikan oleh DNS Server nya Biznet dan 2) Karena poin pertama tersebut, CA (misal Let’s Encrypt) tidak bisa menerbitkan sertifikat untuk reddit.com yang bila menggunakan DNS Biznet memiliki alamat IP 202.169.44.80.
Berbeda dengan situs yang menggunakan protokol HTTP, setiap server dapat berpura-pura sebagai pengelola domain tersebut karena tidak ada cara yang bisa dilakukan di level peramban untuk memvalidasi, seperti, apakah reddit.com yang diakses oleh pengguna memiliki alamat IP 202.169.44.80.
Tapi lihat poinnya disitu: Certificate Authority, yang berada di Trust Store nya peramban.
Membuktikan “ownership” terkait alamat domain disini seharusnya bisa juga dilakukan dengan cara lain misal seperti menggunakan DNSSEC yang diatur di registry dan authoritative name server yang mana beda dengan menggunakan pendekatan sertifikat yang membutuhkan pihak ketiga yakni CA.
Penutup
Inti dari tulisan ini sebenarnya hanya 1: Sekarang edgyDNS mendukung Handshake domains! Selain memblokir permintaan ke jaringan pengiklan, pelacak, scam, dsb, sekarang edgyDNS mendukung permintaan ke nama yang didaftarkan di sistem ter-desentralisasi di blockchain Handshake!
Silahkan gunakan edgyDNS, sebuah DNS resolver yang pribadi (bahkan menggunakan DNS Recursor sendiri DNS Upsteam!), aman (setiap query divalidasi menggunakan DNSSEC, jika mendukung), cepat (server berada di Singapura), gratis, serta memblokir permintaan kepada segala sesuatu yang membuat internet menjadi menyebalkan.
Untuk ber-eksperimen ke jaringan Handshake, silahkan akses https://hi.rizaldy, and see you there!