Belajar Calico - DNS & FQDN Policy
Episode 11 of 23

Belajar Calico - DNS & FQDN Policy

Episode ini membahas DNS dan FQDN policy: kontrol egress berbasis domain untuk integrasi layanan eksternal, kombinasi policy DNS dan IP dalam kebijakan aplikasi, serta jebakan yang sering muncul saat memakai domain.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Menulis policy egress berbasis IP untuk aplikasi yang memanggil layanan cloud itu menyebalkan: IP berubah, dan kalian harus memutakhirkan policy terus-menerus. Episode 11 memperkenalkan solusinya: FQDN policy — kebijakan yang menulis domain alih-alih IP, dan Calico yang menerjemahkannya menjadi rule IP di dataplane.

FQDN policy adalah bahan yang hampir selalu dipakai produksi, karena hampir tidak ada aplikasi yang hanya bicara ke IP statis. Di episode ini kalian belajar menulis policy domain, memadukan dengan rule IP, dan menghindari jebakan DNS yang membuat aplikasi timeout.

FQDN Policy

Konsep Domain Selector

Kebijakan berbasis domain ditulis lewat field domainSelector pada aturan egress. Calico menonton DNS yang di-query workload, lalu membuat rule IP dari hasil resolve tersebut. Karena itu, policy ini bekerja paling baik untuk FQDN yang stabil.

Egress berbasis FQDN
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: api-egress-external
  namespace: payments
spec:
  selector: app == 'api'
  types:
    - Egress
  egress:
    - action: Allow
      protocol: TCP
      destination:
        domainSelector: 'api.external.example.com'
        ports:
          - 443

domainSelector di atas mengizinkan traffic keluar hanya ke api.external.example.com. Wildcard dengan * juga didukung, misalnya '*.example.com' untuk semua subdomain.

Cara Kerja di Balik Layar

Saat pod resolve nama api.external.example.com via CoreDNS, Calico menangkap hasilnya, menambahkan IP tersebut ke kumpulan tujuan yang diizinkan, lalu memprogram rule di node:

Alur resolusi FQDN policy
pod query DNS -> CoreDNS -> Calico menangkap jawaban
      -> rule IP ditambahkan ke dataplane -> egress diizinkan

Karena rule dibuat dari hasil query, pastikan workload benar-benar melakukan DNS resolve di dalam klaster — bukan hardcode IP di aplikasi. Kalau IP di-hardcode, Calico tidak tahu nama domainnya.

Memadukan Policy DNS dan IP

Satu Policy, Dua Jenis Tujuan

Sering kali aplikasi butuh dua jenis akses keluar sekaligus: ke IP statis (misalnya database internal) dan ke domain (misalnya API eksternal). Keduanya bisa ditulis dalam satu policy:

Kombinasi IP dan FQDN
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: api-egress-mix
  namespace: payments
spec:
  selector: app == 'api'
  types:
    - Egress
  egress:
    - action: Allow
      protocol: TCP
      destination:
        nets:
          - 198.51.100.0/24
        ports:
          - 5432
    - action: Allow
      protocol: TCP
      destination:
        domainSelector: '*.payments.example.com'
        ports:
          - 443

Rule pertama memakai nets untuk IP statis, rule kedua memakai domainSelector untuk domain. Calico menggabungkan keduanya tanpa konflik.

DNS Kudu Diizinkan Lebih Dulu

Rule egress ke domain hanya berguna jika DNS itu sendiri bisa di-resolve. Jadi pastikan ada aturan allow ke CoreDNS. Pola yang paling sering dipakai:

Allow DNS ke CoreDNS
egress:
  - action: Allow
    protocol: UDP
    destination:
      namespaceSelector: k8s-app == 'kube-dns'
      selector: k8s-app == 'kube-dns'
      ports:
        - 53

Tanpa rule ini, resolve gagal, dan FQDN policy tidak pernah mendapat IP tujuan.

Jebakan DNS yang Sering Terjadi

TTL dan Cache

IP tujuan bisa berubah setelah TTL habis. Calico memegang hasil resolve sesuai TTL; jika aplikasi terus memakai IP lama, koneksi bisa gagal. Solusinya bukan menaikkan TTL sembarangan, tapi memastikan aplikasi melakukan re-resolve sesuai kebiasaan.

Sertifikat dan SNI

Perhatikan bahwa FQDN policy bekerja di level IP/port — dia tidak memeriksa SNI atau host header. Dua domain yang resolve ke IP yang sama akan tunduk pada rule yang sama. Untuk pengendalian L7 yang melihat nama domain sebenarnya, butuh Application Layer Policy — bahan episode 12.

Nama dengan Titik Akhir

Pastikan penulisan domain tidak punya titik di akhir (api.example.com. vs api.example.com). Perbedaan kecil ini sering membuat policy tidak pernah cocok.

Praktik Penerapan dan Verifikasi

Alur Kerja Lengkap

Mulai dari memastikan DNS bekerja, lalu tambahkan FQDN policy, lalu verifikasi:

Terapkan dan verifikasi FQDN policy
calicoctl apply -f allow-dns.yaml
calicoctl apply -f api-egress-external.yaml
kubectl exec -n payments deploy/api -- nslookup api.external.example.com
kubectl exec -n payments deploy/api -- curl -sS https://api.external.example.com

kubectl exec ... nslookup memastikan resolve berhasil di dalam klaster, dan curl -sS menguji akses nyata ke domain.

Melihat Rule FQDN di Dataplane

Untuk memastikan IP domain sudah masuk ke dataplane:

Cek rule FQDN di node
kubectl exec -n calico-system ds/calico-node -- iptables -L cali-FWR-IN-3 -n
calicoctl get networkpolicy -n payments -o yaml | grep -A3 domainSelector

Penutup

Episode 11 melengkapi kalian dengan egress berbasis domain: menulis domainSelector, memadukan rule DNS dan IP, serta menghindari jebakan TTL, SNI, dan format nama yang membuat policy diam-diam gagal.

Inti yang harus dibawa pulang:

  • domainSelector mengizinkan egress berbasis FQDN; wildcard * didukung.
  • Calico menangkap hasil resolve DNS untuk membangun rule IP.
  • Rule DNS (port 53 ke CoreDNS) wajib ada sebelum FQDN policy.
  • Gabungkan nets dan domainSelector dalam satu policy sesuai kebutuhan.
  • FQDN policy bekerja di level IP/port, bukan SNI — untuk L7 tunggu episode 12.
  • Hindari titik akhir di nama domain dan hardcode IP di aplikasi.

Di episode 12 selanjutnya kita membahas service mesh dan app layer — ApplicationLayerPolicy dengan integrasi Envoy, visibilitas L7, deteksi aksi HTTP, dan posisi Calico dalam traffic service mesh.