Kegagalan verifikasi domain kustom atau tantangan ACME DNS-01 sering kali bukan disebabkan oleh kesalahan konfigurasi pengguna, melainkan fenomena propagasi asimetris antar-resolver DNS. Ketika sistem backend memverifikasi kepemilikan via recursive resolver lokal, query dapat menghasilkan NXDOMAIN atau nilai usang karena cache TTL, sementara authoritative nameserver milik pengguna sudah memuat data terbaru. Kondisi split-view semu ini menyebabkan verifikasi webhook atau pendaftaran domain gagal secara prematur.

Akar Masalah: Asimetri Authoritative vs Recursive Resolver

Saat pengguna menambahkan record TXT atau CNAME pada penyedia DNS mereka, pembaruan langsung aktif di cluster authoritative nameserver. Namun, recursive resolver publik (seperti Google 8.8.8.8, Cloudflare 1.1.1.1, atau Quad9 9.9.9.9) memiliki lapisan caching bertingkat, penanganan negative caching (RFC 2308), dan rute anycast yang berbeda-beda.

Jika backend verifikasi Anda mengeksekusi lookup hanya ke satu vantage point (misalnya resolver default bawaan container OS), tiga masalah berikut kerap muncul:

  • Negative Cache Pollution: Query yang masuk beberapa milidetik sebelum record dibuat akan di-cache sebagai NXDOMAIN sesuai SOA MINIMUM TTL authoritative zone, memblokir query sukses selama rentang waktu tersebut.
  • BGP Anycast Routing Divergence: Resolver IP publik yang sama dapat mengarahkan request backend Anda ke edge data center A, sementara sistem eksternal lain mengakses edge data center B yang belum menyinkronkan cache.
  • TTL Clamping / Wild TTLs: Sejumlah upstream recursive resolver mengabaikan TTL rendah (misal 1 detik) dan memaksakan batas minimum 60-300 detik untuk efisiensi caching mereka sendiri.

Arsitektur Validasi Multi-Vantage Point Berbasis Kuorum

Solusi deterministik untuk masalah ini adalah memvalidasi record secara paralel ke beberapa recursive resolver geografis dan langsung ke authoritative nameserver zone terkait. Verifikasi dianggap sah hanya jika ambang batas kuorum (misalnya $M$ dari $N$ resolver) terpenuhi secara konsisten.

+-------------------------------------------------------------+
|                     Verification Worker                     |
+-------------------------------------------------------------+
       |                  |                  |             |
       v                  v                  v             v
 [Cloudflare]          [Google]           [Quad9]    [Authoritative NS]
   1.1.1.1             8.8.8.8            9.9.9.9       ns1.user.com
       |                  |                  |             |
       +------------------+------------------+-------------+
                          |
             Quorum Evaluator (>= 3 of 4 Match)
                          |
             +------------+------------+
             |                         |
       [Quorum Met]            [Quorum Failed]
             |                         |
       Mark Verified            Retry Backoff Pool

Implementasi Kode: Go DNS Multi-Vantage Validator

Berikut adalah implementasi idiomatik menggunakan Go dan pustaka standard net / custom resolver lookup. Implementasi ini mengeksekusi query serentak dengan batasan timeout independen per resolver, mendeteksi konsistensi nilai, dan mengevaluasi kuorum.

package main

import (
	"context"
	"errors"
	"fmt"
	"net"
	"strings"
	"sync"
	"time"
)

type VantagePoint struct {
	Name string
	Addr string // format "IP:53"
}

type VerificationEngine struct {
	VantagePoints []VantagePoint
	Quorum        int
	QueryTimeout  time.Duration
}

func NewEngine(quorum int, timeout time.Duration) *VerificationEngine {
	return &VerificationEngine{
		Quorum: quorum,
		QueryTimeout: timeout,
		VantagePoints: []VantagePoint{
			{Name: "Cloudflare", Addr: "1.1.1.1:53"},
			{Name: "Google", Addr: "8.8.8.8:53"},
			{Name: "Quad9", Addr: "9.9.9.9:53"},
			{Name: "OpenDNS", Addr: "208.67.222.222:53"},
		},
	}
}

func (e *VerificationEngine) queryResolver(ctx context.Context, vp VantagePoint, domain string) ([]string, error) {
	r := &net.Resolver{
		PreferGo: true,
		Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
			d := net.Dialer{Timeout: e.QueryTimeout}
			return d.DialContext(ctx, "udp", vp.Addr)
		},
	}
	return r.LookupTXT(ctx, domain)
}

func (e *VerificationEngine) VerifyToken(ctx context.Context, domain, expectedToken string) error {
	ctxTimeout, cancel := context.WithTimeout(ctx, e.QueryTimeout*2)
	defer cancel()

	type result struct {
		vpName  string
		matched bool
		err     error
	}

	resChan := make(chan result, len(e.VantagePoints))
	var wg sync.WaitGroup

	for _, vp := range e.VantagePoints {
		wg.Add(1)
		go func(vp VantagePoint) {
			defer wg.Done()
			records, err := e.queryResolver(ctxTimeout, vp, domain)
			if err != nil {
				resChan <- result{vpName: vp.Name, matched: false, err: err}
				return
			}

			matched := false
			for _, txt := range records {
				if strings.TrimSpace(txt) == expectedToken {
					matched = true
					break
				}
			}
			resChan <- result{vpName: vp.Name, matched: matched, err: nil}
		}(vp)
	}

	wg.Wait()
	close(resChan)

	successCount := 0
	for res := range resChan {
		if res.err == nil && res.matched {
			successCount++
		}
	}

	if successCount < e.Quorum {
		return fmt.Errorf("kuorum tidak terpenuhi: %d/%d resolver valid, target: %d",
			successCount, len(e.VantagePoints), e.Quorum)
	}

	return nil
}

func main() {
	// ponytail: upgrade to jittered exponential backoff retry pool for production.
	engine := NewEngine(3, 2*time.Second)
	err := engine.VerifyToken(context.Background(), "_auth.example.com", "token-secret-123")
	if err != nil {
		fmt.Printf("Validasi tertunda: %v\n", err)
		return
	}
	fmt.Println("Verifikasi berhasil memenuhi kuorum multi-vantage point.")
}

Mitigasi Caching TTL Liar dan Negative Cache

Untuk menghindari deadlock verifikasi saat recursive resolver terlanjur men-cache negative response (record belum siap saat pertama dicek):

  1. Authoritative Fallback Pre-flight: Lakukan lookup NS record authoritative zona target terlebih dahulu via net.LookupNS. Arahkan kueri awal langsung ke IP nameserver otoritatif pelanggan. Jika authoritative belum mengembalikan token, batalkan propagasi publik dan tunda proses tanpa memicu cache pada resolver publik.
  2. Unique Token per Verification Attempt: Hindari pengecekan berulang pada satu subdomain statis jika proses gagal berulang kali. Jika arsitektur memungkinkan, sertakan nonces unik pada prefix subdomain (contoh: _verify-a8f1b.example.com) guna memotong rantai stale negative cache.
  3. Exponential Backoff dengan Jitter: Jangan polling dengan interval linear. Gunakan interval acak berbobot (misal: 10s, 30s, 90s, 300s) agar paket probe tidak terus-menerus memperpanjang window SOA MINIMUM TTL pada intermediate cache.

Trade-offs dan Kesimpulan

Pola retry multi-vantage point menambah overhead latensi jaringan dan konsumsi socket UDP pada backend verifikasi. Pola ini tidak ideal untuk synchronous fast-path (seperti blocking HTTP request client langsung). Gunakan arsitektur asinkron berbasis job queue (misalnya Redis queue, Celery, atau RabbitMQ), di mana state mesin domain ditahan pada status pending_verification hingga sistem kuorum berhasil memvalidasi konsistensi record.