DNSSEC Pasca-Kuantum Kini Menjadi Nyata: Runbook 2.420-Byte untuk Operator Backend Game

Resolusi DNS kini 38x lebih besar

Setiap milidetik game Anda menunggu resolusi DNS sebelum menghubungkan pemain ke backend adalah milidetik yang mereka habiskan menatap layar loading. Pada 3 September, resolver 1.1.1.1 milik Cloudflare mulai memvalidasi tanda tangan DNSSEC yang dibuat dengan ML-DSA-44 — algoritma tanda tangan pasca-kuantum yang distandardisasi oleh NIST. Setiap tanda tangan ML-DSA-44 berukuran 2.420 byte, hampir 38 kali ukuran tanda tangan ECDSA P-256 (64 byte) yang digunakan sebagian besar zona aman-DNSSEC saat ini.

Jika Anda mengoperasikan domain kustom untuk backend game, matchmaker, CDN, atau endpoint pengiriman aset, perubahan ini pada akhirnya akan mengubah bentuk infrastruktur DNS Anda. Dampak konkretnya:

• Respons DNS yang saat ini nyaman muat dalam satu paket UDP akan melampaui batas payload UDP konservatif sebesar 1.232 byte
• Server otoritatif akan mengembalikan respons terpotong, memaksa percobaan ulang TCP
• Zona yang menjalankan algoritma ganda selama masa migrasi memperkenalkan permukaan serangan downgrade
• Semua ini menambah latensi pada hop jaringan pertama yang dilakukan pemain Anda

Ini adalah runbook untuk mendeteksi, memitigasi, dan mempersiapkan DNSSEC pasca-kuantum dalam infrastruktur backend game.

Mengapa backend game peduli dengan ukuran tanda tangan DNSSEC

Dinding ukuran UDP

DNS melalui UDP memiliki sejarah panjang dalam hal batasan ukuran paket:

Batas	Sumber	Byte
Maks UDP DNS asli	RFC 1035 (1987)	512
Default umum EDNS(0)	Berbagai implementasi	1.232
Maksimum yang direkomendasikan	RFC 9715 (2025)	1.400
Tanda tangan ML-DSA-44 saja	NIST ML-DSA-44	2.420
Kunci publik ML-DSA-44	RRset DNSKEY	1.312

Satu tanda tangan ML-DSA-44 saja melampaui setiap batasan ini, sebelum ditambah RRset yang ditandatangani, nama domain, header, dan rekaman DNSSEC lainnya. UDP terfragmentasi tidak dapat diandalkan — Cloudflare dan lainnya secara eksplisit merekomendasikan untuk menghindarinya sejak DNS Flag Day 2020 — sehingga fallback praktisnya adalah TCP.

Berapa biaya fallback TCP bagi pemain Anda

Menurut Cloudflare Radar, sekitar 85% kueri ke 1.1.1.1 tiba melalui UDP. Di semua layanan pada platform Big Pineapple mereka (yang juga mendukung Gateway DNS), sekitar 60% tiba melalui UDP. Artinya 15–40% lalu lintas DNS sudah menggunakan TCP, DoT, atau DoH — tetapi itu adalah koneksi non-UDP yang sukarela.

Ketika UDP gagal dan klien mencoba ulang melalui TCP, Anda membayar penalti jabat tangan TCP penuh: ~1 RTT untuk SYN/SYN-ACK/ACK sebelum resolver bahkan mengirim kueri. Untuk pemain yang terhubung ke backend game Anda dari jarak 80ms, itu berarti tambahan 80ms waktu koneksi sebelum autentikasi bahkan dimulai.

Dalam praktiknya, fallback TCP terjadi antara resolver dan nameserver otoritatif, dan resolver menyimpan hasilnya dalam cache. Dampak terburuk terjadi ketika:

1. Cache dingin — pencarian pertama setelah TTL kedaluwarsa, atau pemain baru terhubung di wilayah tanpa lalu lintas sebelumnya
2. Respons DNSKEY zona besar — persis seperti kasus selama periode migrasi algoritma ganda
3. Beberapa delegasi menghasilkan respons besar — rantai 3–4 zona, masing-masing membawa kunci konvensional dan pasca-kuantum

Timeout peluncuran sesi sudah menjadi momok bagi backend multipemain dalam kondisi DNS normal — kami membahas diagnostik untuk masalah timeout tingkat jaringan Unreal Engine dalam pembahasan mendalam sebelumnya. DNSSEC pasca-kuantum akan membuat timeout ini semakin sering terjadi jika Anda tidak merencanakan respons yang lebih besar.

Jebakan migrasi algoritma ganda

ML-DSA-44 tidak dapat sepenuhnya menggantikan algoritma penandatanganan konvensional dalam semalam. Zona harus menerbitkan kunci konvensional (ECDSA/RSA) dan pasca-kuantum (ML-DSA-44) untuk kompatibilitas mundur. Selama periode ini, respons DNSKEY untuk sebuah zona dapat berisi:

• Kunci publik konvensional (mis., 91 byte untuk ECDSA P-256)
• Kunci publik ML-DSA-44 (1.312 byte)
• Tanda tangan konvensional atas RRset DNSKEY (64 byte)
• Tanda tangan ML-DSA-44 atas RRset DNSKEY (2.420 byte)

Itu kira-kira 3.900 byte materi DNSSEC saja, jauh melampaui batas payload UDP mana pun. Key rollover membuatnya semakin besar. Resolver harus melakukan fallback ke TCP.

Permukaan serangan downgrade

Inilah masalah keamanan yang membuat ini lebih dari sekadar masalah latensi. RFC 6840 menyatakan validator "SHOULD accept any single valid path." Artinya jika sebuah zona menerbitkan set validator ECDSA dan ML-DSA-44, resolver yang mendukung keduanya akan menerima salah satunya.

Begitu komputer kuantum dapat memecahkan kunci ECDSA, penyerang dapat memalsukan respons khusus-ECDSA dan resolver berkemampuan pasca-kuantum masih akan menerimanya. Inilah serangan downgrade:

1. Resolver pemain melakukan kueri api.your-game-backend.com dan menerima respons yang ditandatangani hanya dengan ECDSA
2. Resolver menerima tanda tangan ECDSA karena ada dalam daftar "jalur valid mana pun"
3. Penyerang telah memalsukan respons ini menggunakan kunci privat turunan-kuantum
4. Pemain terhubung ke server penyerang, bukan server Anda

Ini bukan sekadar kekhawatiran teoretis. Kebocoran data Star Citizen menunjukkan bagaimana satu kompromi infrastruktur dapat mengalir menjadi kebocoran kredensial besar-besaran. Kompromi tingkat DNS lebih buruk: ia mengarahkan setiap pemain yang me-resolve hostname Anda ke endpoint yang dikendalikan penyerang.

1.1.1.1 mengatasi ini dengan menggunakan rekaman DS sebagai sinyal terautentikasi: jika RRset DS zona induk berisi rekaman untuk algoritma pasca-kuantum yang didukung, resolver menerapkan kebijakan lebih ketat yang mewajibkan setidaknya satu jalur validasi pasca-kuantum yang valid. Jika tidak ada jalur ML-DSA-44 yang berhasil divalidasi, validasi gagal seluruhnya.

Ini bagus — tetapi berarti zona yang berniat menawarkan keamanan pasca-kuantum perlu menerbitkan rekaman DS ML-DSA-44, dan setiap delegasi di atasnya dalam rantai harus melakukan hal yang sama. Kunci yang dikompromikan di mana pun dalam rantai memungkinkan penyerang memalsukan semua yang ada di bawahnya: "sekali bobol, palsukan semua."

Mendeteksi dampak DNSSEC pasca-kuantum pada infrastruktur Anda

Langkah 1: Periksa ukuran respons DNS saat ini

Sebelum Anda dapat mengukur dampaknya, Anda memerlukan baseline. Gunakan dig dengan flag +dnssec untuk melihat ukuran respons saat ini untuk domain game Anda:

# Measure current DNSKEY response size for your authoritative zone
dig +dnssec +bufsize=4096 NS your-game-backend.com @your-ns.example.com +short

# Check the full DNSKEY response with size tracking
dig +dnssec +bufsize=4096 DNSKEY your-game-backend.com @your-ns.example.com
# Look at the MSG SIZE stat near the bottom of the output

# Measure a typical A-record query with DNSSEC signatures attached
dig +dnssec +bufsize=4096 A api.your-game-backend.com @your-ns.example.com

Sebagai referensi, respons DNSKEY dengan ECDSA P-256 menghasilkan sekitar 200–400 byte. Dengan ML-DSA-44 yang diterbitkan bersamaan, perkirakan 3.500–5.000 byte. Catat angka Anda saat ini — Anda akan membutuhkannya untuk mendeteksi degradasi.

Langkah 2: Periksa algoritma yang digunakan zona Anda

# Extract algorithm numbers from your DNSKEY records
dig +dnssec DNSKEY your-game-backend.com @your-ns.example.com | \
  grep -E "DNSKEY|RRSIG" | awk '{print $5}' | sort -u

Nomor algoritma memberi tahu algoritma penandatanganan yang digunakan:

Algoritma	Nomor	Status
RSA/SHA-256	8	Banyak digunakan, rentan-kuantum
ECDSA P-256/SHA-256	13	Pilihan modern paling umum, rentan-kuantum
ED448	16	Rentan-kuantum tetapi besar (~114 byte)
ML-DSA-44	18	Pasca-kuantum, 2.420 byte, baru ditetapkan oleh IANA

Jika zona Anda saat ini menggunakan algoritma 13 (ECDSA P-256), Anda berada di jalur modern yang paling umum. Migrasi ke algoritma 18 masih dalam tahap perencanaan untuk sebagian besar ekosistem DNS — tetapi Anda harus memahami garis waktunya.

Langkah 3: Pantau tingkat fallback TCP dengan penganalisis log kueri

Jika Anda menjalankan nameserver otoritatif atau memiliki akses log resolver, lacak rasio kueri TCP terhadap UDP. Ini adalah sinyal awal paling jelas bahwa ukuran respons sedang menabrak dinding UDP.

#!/usr/bin/env python3
"""
Post-Quantum DNSSEC TCP Fallback Monitor.
Tracks TCP/UDP query ratios from BIND-style query logs
as a proxy for large-response fallback pressure.

Usage:
    python3 pq_dns_monitor.py --log /var/log/named/queries.log --window 2
"""

import re
import argparse
from collections import Counter
from datetime import datetime, timedelta

LOG_PATTERN = re.compile(
    r"(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2})\.\d+Z"
    r"\s+(\w+)\s+query:\s+\S+\s+(\S+)\s+(\S+)"
)

def analyze_dns_traffic(log_path: str, window_hours: int = 1) -> None:
    cutoff = datetime.utcnow() - timedelta(hours=window_hours)
    transport_counts = Counter()
    rrtype_counts = Counter()
    tcp_by_qtype: Counter = Counter()

    with open(log_path, "r") as f:
        for line in f:
            m = LOG_PATTERN.search(line)
            if not m:
                continue
            ts_str, transport, qname, qtype = m.groups()
            try:
                ts = datetime.strptime(ts_str, "%Y-%m-%dT%H:%M:%S")
                if ts < cutoff:
                    continue
            except ValueError:
                continue

            transport_counts[transport] += 1
            rrtype_counts[qtype] += 1
            if transport == "tcp":
                tcp_by_qtype[qtype] += 1

    total = sum(transport_counts.values())
    if total == 0:
        print("No queries found in the specified time window.")
        return

    tcp_count = transport_counts.get("tcp", 0)
    tcp_pct = (tcp_count / total) * 100

    print(f"=== DNS Transport Breakdown (last {window_hours}h) ===")
    print(f"  UDP: {transport_counts.get('udp', 0):>8} ({100 - tcp_pct:.1f}%)")
    print(f"  TCP: {tcp_count:>8} ({tcp_pct:.1f}%)")
    print(f"  Total: {total:>6}")
    print()

    if tcp_pct > 15.0:
        print(f"  ⚠  ALERT: TCP fallback rate is {tcp_pct:.1f}%.")
        print("     Large DNSSEC responses may be forcing TCP retries.")
        print("     Check whether any upstream zones have added post-quantum keys.")
    elif tcp_pct > 8.0:
        print(f"  ⚡ NOTICE: TCP fallback rate is {tcp_pct:.1f}%. Monitor for increases.")
    else:
        print(f"  ✓  TCP fallback rate ({tcp_pct:.1f}%) is within normal range.")

    # Show which query types incur the most TCP fallback
    if tcp_by_qtype:
        print()
        print("=== TCP Fallback by Query Type ===")
        for qtype, count in tcp_by_qtype.most_common(5):
            pct = (count / rrtype_counts[qtype]) * 100 if rrtype_counts[qtype] else 0
            print(f"  {qtype:<10} {count:>5} TCP / {rrtype_counts[qtype]:>5} total  ({pct:.0f}%)")

    print()
    print("=== Query Type Breakdown ===")
    for qtype, count in rrtype_counts.most_common(10):
        print(f"  {qtype:<10} {count:>6}")

    # Recommendation
    print()
    if tcp_by_qtype.get("DNSKEY", 0) > tcp_by_qtype.get("A", 0) * 0.5:
        print("  ➜  DNSKEY queries have a notably high TCP fallback rate.")
        print("     Your zones or upstream zones may already be publishing")
        print("     large post-quantum keys alongside conventional ones.")


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="DNS TCP fallback monitor for PQ-DNSSEC readiness")
    parser.add_argument("--log", required=True, help="Path to BIND query log file")
    parser.add_argument("--window", type=int, default=1, help="Time window in hours")
    args = parser.parse_args()
    analyze_dns_traffic(args.log, args.window)

Jalankan ini terhadap log nameserver otoritatif Anda secara rutin. Jika kueri TCP untuk rekaman DNSKEY atau DS trennya di atas 10%, resolver Anda sedang menabrak dinding UDP dan respons berukuran pasca-kuantum adalah penyebab yang paling mungkin.

Langkah 4: Benchmark latensi resolver-ke-otoritatif

Gunakan dnsperf untuk stress-test waktu respons server otoritatif Anda di bawah beban, termasuk kueri yang memicu respons besar:

# Create a test query file focused on DNSSEC-heavy queries
cat > /tmp/dnssec-bench.txt << 'EOF'
your-game-backend.com DNSKEY
your-game-backend.com DNS
api.your-game-backend.com A
match.your-game-backend.com A
assets.your-game-backend.com A
EOF

# Run with 20 concurrent clients for 20 seconds
dnsperf -s your-ns-ip -d /tmp/dnssec-bench.txt -l 20 -c 20

Bandingkan latensi rata-rata dan tingkat trunaksi TCP sebelum dan sesudah menambahkan rekaman ML-DSA-44 ke zona uji. Anda menginginkan angka yang terukur, bukan tebakan.

Remediasi: Memperkuat DNS Anda untuk respons pasca-kuantum

1. Maksimalkan ukuran buffer EDNS(0) di server otoritatif

Nameserver otoritatif Anda harus mengiklankan payload UDP terbesar yang mereka dukung. Ini tidak mencegah fallback TCP untuk respons DNSKEY — tanda tangan ML-DSA-44 memang terlalu besar — tetapi memastikan respons non-DNSSEC dan tanda tangan yang lebih kecil tetap muat di UDP, dan sinyal trunaksi sampai ke klien lebih cepat.

# BIND 9 — named.conf
options {
    edns-udp-size 1232;
    max-udp-size 1232;
    tcp-fast-open 256;
};

Pengaturan 1.232 byte dipilih secara spesifik: 1.280 (MTU minimum IPv6) − 40 (header IPv6) − 8 (header UDP) = 1.232. Ini mencegah fragmentasi di jalur mana pun yang mendukung MTU minimum IPv6.

# NSD — nsd.conf
server:
    ipv4-edns-size: 1232
    ipv6-edns-size: 1232

2. Aktifkan TCP Fast Open di semua nameserver yang Anda kontrol

TCP Fast Open (TFO) memungkinkan resolver mengirim kueri DNS dalam paket SYN, menghilangkan satu round trip dari penyiapan koneksi TCP. Ini memotong fallback TCP dari ~2 RTT (jabat tangan + kueri/respons) menjadi ~1 RTT.

# Linux: enable TFO for both inbound and outbound connections (mode 3)
sudo sysctl -w net.ipv4.tcp_fastopen=3

# Verify
cat /proc/sys/net/ipv4/tcp_fastopen
# Expected output: 3

TFO juga harus diaktifkan di perangkat lunak DNS Anda. BIND 9 (9.18+) dan Knot Resolver mendukungnya. Periksa dokumentasi versi Anda. Untuk Unbound, fitur ini aktif secara default di build terbaru.

Efek bersihnya: kueri DNS TCP yang sebelumnya memakan ~160ms (dua round trip 80ms) kini memakan ~80ms (satu round trip). Ini masih lebih buruk daripada UDP (~80ms), tetapi penaltinya berkurang setengah.

3. Resolve dan cache hostname saat startup game — jangan pernah saat gameplay berlangsung

Mitigasi paling efektif untuk latensi DNS di klien game adalah menghindari pencarian DNS selama jalur kritis gameplay. Resolve semua hostname backend saat inisialisasi dan cache alamat IP yang telah di-resolve selama masa sesi.

// Unreal Engine C++ — resolve game backend hostnames at startup
// and cache IP addresses so players never wait for DNS during connect

void UGameBackendSubsystem::Initialize(FSubsystemCollectionBase& Collection)
{
    Super::Initialize(Collection);

    // All hostnames the game needs during a session
    TArray<FString> Hostnames = {
        TEXT("api.your-game-backend.com"),
        TEXT("match.your-game-backend.com"),
        TEXT("assets.cdn.your-game-backend.com"),
    };

    ISocketSubsystem* Sockets = ISocketSubsystem::Get();

    for (const FString& Host : Hostnames)
    {
        // Resolve at startup — resolves once, not on first connect
        FResolveInfo* ResolveInfo = Sockets->GetHostByName(
            TCHAR_TO_ANSI(*Host)
        );

        // Block until resolution completes (acceptable during loading screen)
        ResolveInfo->WaitUntilComplete(5.0f);

        FInternetAddr Result;
        if (ResolveInfo->GetErrorCode() == 0)
        {
            Result = ResolveInfo->GetResolvedAddress();
            FString ResolvedIP = Result.ToString(false);
            CachedEndpoints.Add(Host, ResolvedIP);
            UE_LOG(LogGameBackend, Log,
                TEXT("Pre-resolved %s -> %s (cached for session)"),
                *Host, *ResolvedIP);
        }
        else
        {
            UE_LOG(LogGameBackend, Warning,
                TEXT("DNS resolution failed for %s (error %d)"),
                *Host, ResolveInfo->GetErrorCode());
            // Store empty — will re-resolve on demand with exponential backoff
            CachedEndpoints.Add(Host, FString());
        }
    }
}

FString UGameBackendSubsystem::GetResolvedAddress(const FString& Hostname) const
{
    const FString* Cached = CachedEndpoints.Find(Hostname);
    if (Cached && !Cached->IsEmpty())
    {
        return *Cached;
    }
    return Hostname; // Fallback to hostname (will trigger real DNS)
}

Ini berarti pemain Anda tidak pernah menunggu DNS selama alur koneksi-ke-server atau unduhan aset. Bahkan jika resolusi DNS memakan 200ms karena fallback TCP dan cache dingin, prosesnya terjadi diam-diam selama layar loading — bukan selama hitung mundur matchmaking.

4. Gunakan DNS-over-HTTPS untuk kueri infrastruktur

DoH berjalan di atas HTTP/2 atau HTTP/3 (berbasis TCP atau QUIC di lapisan transport), sehingga sepenuhnya melewati batasan ukuran UDP. Jika server backend game, skrip deployment, atau pipeline CI/CD Anda melakukan kueri DNS secara terprogram, konfigurasikan untuk menggunakan DoH:

# Resolve a hostname using Cloudflare's DoH endpoint
# (requires curl 7.76+)
curl -sS \
  "https://cloudflare-dns.com/dns?name=api.your-game-backend.com&type=A" \
  -H "Accept: application/dns-json" | jq -r '.Answer[0].data'

# For Kubernetes pods, configure CoreDNS to forward to a DoH-capable
# recursive resolver. In practice, this means setting upstream to
# a resolver that natively supports DoH, such as 1.1.1.1 or 8.8.8.8

Ini sangat relevan untuk skrip health-check yang memantau ketersediaan backend, pipeline verifikasi deployment, dan sistem orkestrasi kontainer di mana pod menggunakan konfigurasi resolver node secara default.

5. Audit rekaman DS zona dan kesiapan algoritma Anda

Jika Anda mengoperasikan zona otoritatif sendiri, periksa bahwa rekaman DS Anda cocok dengan algoritma saat ini dan Anda tidak membawa data delegasi basi.

# Check DS records from the parent zone
dig +short DS your-game-backend.com

# Compare with actual DNSKEY data in your zone
dig +short DNSKEY your-game-backend.com

# Use delv to trace the full DNSSEC validation chain
delv +rtrace api.your-game-backend.com A

Jika Anda melihat rekaman DS yatim untuk algoritma yang tidak lagi Anda gunakan, hal itu dapat menyebabkan logika fallback yang tidak perlu di resolver. Bersihkan saat window pemeliharaan berikutnya.

Praktik terbaik: Checklist kesiapan DNSSEC pasca-kuantum

1. Buat baseline ukuran respons DNS Anda hari ini. Jalankan dig +dnssec terhadap semua zona yang menjadi sandaran infrastruktur Anda. Catat MSG SIZE untuk kueri DNSKEY, DS, dan rekaman-A yang umum. Anda memerlukan angka-angka ini untuk mendeteksi degradasi di masa depan ketika zona hulu mulai menerbitkan rekaman pasca-kuantum.

2. Aktifkan TCP Fast Open di setiap nameserver yang Anda kontrol. Perubahan satu flag kernel ini memotong latensi fallback TCP sebanyak satu round trip penuh (~80–160ms tergantung geografi). Dikombinasikan dengan caching DNS yang agresif, fallback TCP menjadi hampir tidak terlihat oleh pemain.

3. Resolve hostname saat startup game, jangan pernah saat gameplay. Semua endpoint backend, CDN, dan matchmaker harus di-resolve selama layar loading dan di-cache di memori. Refresh latar belakang setiap beberapa menit menangani kedaluwarsa TTL tanpa memblokir gameplay.

4. Pantau tingkat fallback TCP setiap minggu. Siapkan penganalisis log kueri di atas atau yang setara. Tingkat TCP yang bertahan di atas 10% untuk kueri DNSKEY menandakan bahwa ukuran respons melampaui batas UDP. Perlakukan ini seperti pelanggaran SLA latensi.

5. Rencanakan garis waktu migrasi algoritma DNSSEC Anda. Jika Anda menandatangani zona sendiri, mulailah menguji ML-DSA-44 di subdomain staging. Terbitkan kunci algoritma ganda dan ukur dampak ukuran respons. Jangan menunggu ancaman kuantum muncul — migrasi di DNS diukur dalam hitungan tahun, bukan sprint. Migrasi algoritma di DNSSEC adalah masalah tingkat infrastruktur, dan keamanan akun, leaderboard, serta data cloud save Anda bergantung pada integritas jalur resolusi yang mengantarkan pemain ke layanan tersebut sejak awal.

Garis waktu: Kapan ini penting bagi Anda

Pengaktifan validasi ML-DSA-44 oleh 1.1.1.1 Cloudflare adalah deployment resolver besar pertama. Berikut perkiraan garis waktunya:

Periode	Yang terjadi
Sekarang (2025)	Cloudflare 1.1.1.1 memvalidasi ML-DSA-44; pengadopsi awal mulai menguji
2025–2027	Lebih banyak resolver menambahkan validasi; zona awal mulai menerbitkan kunci algoritma ganda
2027–2029	Adopsi zona lebih luas; resolver dapat memberlakukan kebijakan perlindungan downgrade yang lebih ketat
2029+	Cloudflare menargetkan keamanan pasca-kuantum penuh; algoritma konvensional dianggap tidak aman

Tidak ada satu pun dari ini yang akan merusak server game Anda besok. Tetapi pola migrasinya jelas.

Operator backend game yang mulai bersiap sekarang — melakukan caching DNS, mengaktifkan TFO, mengaudit algoritma zona, memantau tingkat fallback TCP — tidak akan menyadari saat transisi ini selesai. Mereka yang menunggu akan sibuk men-debug latensi fallback TCP dan kegagalan validasi DNSSEC saat peluncuran game live, yang justru merupakan momen paling tidak ideal untuk itu.

Siap fokus membangun gameplay daripada mengelola infrastruktur? horizOn menangani autentikasi akun, cloud save, leaderboard, dan pelaporan crash sehingga Anda dapat mengalokasikan upaya infrastruktur ke lapisan DNS, jaringan, dan keamanan yang membutuhkan perhatian Anda. Lihat dokumentasi horizOn untuk melihat apa saja yang tersedia langsung di dalamnya.

---

Sumber: 1.1.1.1 kini mendukung DNSSEC pasca-kuantum, lengkap dengan 2.420 byte-nya