Apakah CNAME lebih dulu, atau record A lebih dulu

 (blog.cloudflare.com)
13 poin oleh GN⁺ 2026-01-20 | 1 komentar | Bagikan ke WhatsApp
  • Pada 8 Januari 2026, pembaruan layanan 1.1.1.1 milik Cloudflare mengubah urutan record dalam respons DNS, sehingga menyebabkan kegagalan resolusi DNS bagi sebagian pengguna di seluruh dunia
  • Akar masalahnya adalah perubahan kode yang memindahkan record CNAME ke belakang record A/AAAA, sementara sebagian implementasi klien DNS bergantung pada urutan
  • Secara khusus, fungsi getaddrinfo milik glibc dan proses DNSC pada switch Cisco terdampak; untuk kasus yang terakhir, bahkan terjadi loop reboot
  • RFC 1034 hanya menyatakan bahwa “CNAME dapat muncul di depan (possibly preface)”, sehingga tidak ada standar yang jelas mengenai urutan record
  • Cloudflare kembali ke pendekatan yang selalu menempatkan CNAME lebih dulu, dan mengajukan Internet-Draft ke IETF untuk mendefinisikan standar yang lebih jelas

1. Ringkasan insiden

  • Pada 8 Januari 2026, saat pembaruan pengurangan penggunaan memori untuk 1.1.1.1 dirilis, terjadi perubahan urutan record dalam respons DNS
    • Perubahan ini dimasukkan ke codebase pada 2 Desember 2025, didistribusikan ke lingkungan pengujian pada 10 Desember, dan mulai dirilis secara global pada 7 Januari 2026
    • Insiden diumumkan pada 8 Januari pukul 18:19 UTC, rollback dimulai pada 18:27, dan pemulihan selesai pada 19:55
  • Sebagian besar klien DNS modern mengabaikan urutan record dalam respons, tetapi beberapa implementasi mengasumsikan CNAME harus selalu muncul lebih dulu
  • Ketika urutan ini berubah, sebagian klien memperlakukan respons seolah kosong, sehingga terjadi kegagalan resolusi

2. Rantai CNAME dan cara kerja cache

  • Saat melakukan kueri domain, misalnya www.example.com, nama tersebut dapat diresolusikan ke IP akhir melalui beberapa rantai CNAME
    • Contoh: www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1
  • Setiap tautan CNAME memiliki TTL (Time-To-Live), dan sebagian di antaranya bisa saja kedaluwarsa lebih dulu
  • 1.1.1.1 hanya mengkueri ulang bagian yang kedaluwarsa lalu menggabungkan cache yang ada dengan record baru untuk membentuk respons

3. Rincian perubahan kode

  • Pada kode lama, rantai CNAME dimasukkan lebih dulu, lalu record A/AAAA ditambahkan setelahnya
    • answer_rrs.extend_from_slice(&self.records); // CNAMEs first
  • Pada kode yang diubah, CNAME ditambahkan paling akhir
    • entry.answer.extend(self.records); // CNAMEs last
  • Akibatnya, CNAME berpindah ke bagian bawah respons, dan beberapa klien gagal memprosesnya

4. Contoh implementasi yang terdampak

  • Fungsi getaddrinfo milik glibc mem-parsing respons secara berurutan, sehingga CNAME harus muncul lebih dulu agar nama berikutnya bisa dilacak
    • Jika CNAME muncul belakangan, “nama yang diharapkan” tidak diperbarui dan hasilnya menjadi kosong
  • Proses DNSC pada tiga model switch Cisco Catalyst juga terdampak; jika menggunakan 1.1.1.1, hal ini dapat menyebabkan loop reboot akibat error fatal
    • Cisco telah menerbitkan dokumen layanan terkait

5. Implementasi yang tidak terdampak

  • systemd-resolved mem-parsing respons ke dalam struktur OrderedSet, sehingga bisa menelusuri seluruh himpunan tanpa bergantung pada posisi CNAME
    • Karena itu, perubahan urutan record tidak memengaruhi operasinya

6. Ambiguitas RFC 1034

  • RFC 1034 (1987) menyebut bahwa “respons dapat diawali (preface) oleh satu atau lebih CNAME”
    • Namun, karena tidak ada kata kunci normatif seperti MUST/SHOULD, itu bukan persyaratan eksplisit
  • Baru setelah RFC 2119 (1997), kata kunci semacam itu distandardisasi, sehingga dokumen lama tersebut tidak memiliki ungkapan kewajiban yang jelas
  • Cloudflare memang menempatkan CNAME lebih dulu pada implementasi awal, tetapi tidak menjaminnya lewat pengujian

7. Perbedaan antara RRset dan section pesan

  • RFC 1034 §3.6 menyatakan bahwa urutan RRset (himpunan record dengan nama, tipe, dan kelas yang sama) tidak penting
  • Namun, tidak ada pembahasan mengenai urutan antar RRset yang berbeda
  • Contoh pada §6.2.1 juga hanya membahas dua record A dengan nama yang sama, bukan urutan relatif antara CNAME dan A
  • Karena itu, definisi urutan antara CNAME dan record A masih kosong

8. Masalah urutan di dalam rantai CNAME

  • Jika CNAME memiliki beberapa tahap, urutan rantai itu sendiri yang tercampur juga dapat membuat parsing berurutan gagal
    • Contoh: jika cdn.example.com CNAME server.cdn-provider.com muncul lebih dulu, maka www.example.com CNAME cdn.example.com tidak akan ditemukan
  • RFC 1034 juga tidak menetapkan persyaratan untuk urutan dalam rantai CNAME

9. Kriteria perilaku resolver

  • RFC 1034 §5.2.2 menyatakan bahwa “resolver harus memulai ulang kueri dengan nama baru ketika menemukan CNAME”
  • Namun, ini adalah penjelasan untuk resolver penuh (misalnya 1.1.1.1), sementara
    stub resolver seperti glibc tidak mengimplementasikan logika tersebut
  • Akibatnya, sebagian stub resolver tidak mengikuti perilaku yang diharapkan oleh RFC

10. Perbandingan dengan aturan eksplisit DNSSEC

  • RFC 4035 (DNSSEC) secara eksplisit menyatakan prioritas penyertaan record RRSIG dengan kata “MUST”
    • Meski begitu, itu adalah aturan tentang “apakah harus disertakan”, bukan tentang “urutan”
  • DNSSEC memberikan aturan penyertaan yang jelas, tetapi pada zona unsigned ambiguitas RFC 1034 tetap ada

11. Kesimpulan dan tindakan Cloudflare

  • Walaupun menurut RFC urutan CNAME bukan keharusan, sebagian klien mengandalkannya, sehingga
    Cloudflare kembali ke kebijakan selalu menempatkan CNAME lebih dulu
  • Untuk mencegah masalah serupa di masa depan, Cloudflare mengajukan Internet-Draft ke IETF
  • Melalui insiden ini, Cloudflare menegaskan bahwa ambiguitas protokol berusia 40 tahun masih berdampak pada praktik nyata saat ini

12. Informasi tambahan

  • Melalui Connectivity Cloud, termasuk 1.1.1.1, Cloudflare menyediakan
    perlindungan jaringan perusahaan, akselerasi aplikasi skala internet, pertahanan DDoS, dan dukungan penerapan Zero Trust
  • Aplikasi gratis 1.1.1.1 memungkinkan akses internet yang lebih cepat dan lebih aman

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-20
Komentar Hacker News

  • Saya merasa redaksi RFC itu tidak terlalu ambigu
    Ungkapan “possibly preface” terbaca sebagai “jika ada record CNAME, letakkan itu dulu”, bukan berarti “kalau mau bisa ditaruh di mana saja”

    • Saya juga berpikir begitu. “Bisa diprefix” tidak berarti “boleh juga disuffix”
      Tapi ini bukan sekadar soal penafsiran kalimat, melainkan fakta bahwa tim yang mengoperasikan salah satu server DNS terpenting di dunia mengubah logika respons CNAME
      Ini pasti terlihat rusak di pengujian, jadi mengejutkan bahwa tidak ada yang bertanya, “apakah urutan ini penting?”
      Cloudflare belakangan cukup transparan saat mengungkap masalah, tetapi kali ini terdengar seperti “berbagi fakta menarik”
      Bahwa hal seperti ini lolos pengujian di sistem berskala besar tampak seperti kesalahan yang cukup besar
    • Artikel itu menjelaskan bahwa ambiguitas berasal dari kalimat lain — yaitu frasa “perbedaan urutan RR di bagian jawaban tidak penting”
      Contohnya bisa digeneralisasi, sehingga ada ruang untuk salah paham menjadi “urutan tidak penting dalam semua kasus”
      Pada akhirnya, “pemahaman yang jelas” menurut satu orang bisa terlihat sebagai “apa kamu benar-benar membaca dokumennya?” bagi orang lain
      Kasus seperti ini menunjukkan pentingnya bahasa normatif (normative language)
    • Kamu mungkin merasa itu tidak ambigu, tetapi dalam praktiknya memang ambigu, dan bahkan ada upaya untuk memperbaikinya
      Diskusi terkait bisa dilihat di milis IETF
    • Saya juga setuju dengan pendapatmu. Interpretasi contoh 6.2.1 di RFC tampaknya keliru
      Pernyataan “perbedaan urutan tidak penting” hanya berlaku untuk contoh tertentu itu, bukan berarti aturan umum boleh diabaikan
      Meski ada klaim bahwa RFC 1034 mendefinisikan RRset, sebenarnya tidak ada definisi istilah seperti itu
      Interpretasi Cloudflare tampak sebagai salah paham atas klausul pengecualian sebagai aturan umum
      Namun, memang tidak ada ketentuan yang benar-benar jelas soal urutan dalam rantai CNAME, jadi sedikit ambiguitas masih tersisa
    • Itu juga disebutkan di artikel. Artikel tersebut menyoroti bahwa RFC itu adalah dokumen dari sebelum kata-kata normatif (MUST, SHOULD) distandardisasi

  • Ini tampak seperti kasus ketika Hyrum’s Law dan Postel’s Law bekerja bersamaan
    Hasil benturan antara prinsip “jika pengguna API cukup banyak, seseorang akan bergantung pada setiap perilaku sistem yang bisa diamati” dan
    “konservatif saat mengirim, toleran saat menerima”

    • Namun, hukum Postel sekarang makin dianggap sebagai prinsip yang berbahaya
    • Benar, tetapi inti Hyrum’s Law adalah bahwa ada sangat banyak edge case di dunia nyata
      Poin penting kali ini adalah resolver glibc yang rusak — ini sama sekali bukan situasi langka
      Berita sebenarnya adalah Cloudflare tidak menguji dengan semestinya
    • Pada akhirnya ini adalah masalah abstraksi bocor (leaky abstraction) di tingkat manusia
    • Ada komik xkcd yang menggambarkan Hyrum’s Law dengan sempurna

  • Bug ini mengingatkan saya pada kenangan lama
    Tahun 2011 saat Cloudflare mengabaikan RFC dan mengizinkan CNAME di apex domain
    Jika melihat posting blog saat itu, mereka mengatakan akan “mengabaikan RFC dan menyelesaikan masalah dunia nyata”
    Tetapi CNAME adalah konsep alias di level nama, jadi jika diletakkan di apex, caching NS, MX, dan SOA bisa rusak
    Banyak engineer sudah memperingatkan waktu itu, tetapi pendekatannya adalah “move fast and break things”
    Meski begitu, kali ini mereka sampai membahas detail urutan rantai CNAME dan record A, jadi tetap ada perkembangan

    • Saya setuju denganmu. Dulu di BIND saya tak terhitung berapa kali melihat error “cannot have CNAME and other data”
      Konsep CNAME dan alias memang sudah lama membingungkan, dan bahasa non-normatif di RFC1034 memperparah kebingungan itu
      Ini memang hasil akumulasi ambiguitas seperti itu, tetapi tetap sulit diterima bahwa penyedia layanan besar melakukan kesalahan seperti ini
    • Tapi kalau spesifikasinya memang sengaja dilanggar, apakah itu benar-benar “bug”?
      Saya justru pikir spesifikasinya sendiri yang bermasalah

  • Mengejutkan bahwa lookup DNS umum di glibc bergantung pada urutan record
    Aneh juga bahwa tidak ada masalah besar selama lebih dari 20 tahun
    Mungkin sebagian besar operator DNS sudah tahu secara empiris saat pengujian bahwa urutan itu penting

    • Mungkin masalah seperti ini sering terjadi, tetapi pada layanan berskala kecil hanya dibiarkan lewat begitu saja
      Ini jadi sorotan karena mungkin baru kali ini kasusnya memengaruhi ratusan juta perangkat di seluruh dunia seperti Cloudflare
      Tapi saya penasaran apakah Cloudflare kali ini mengirim patch ke resolver open source seperti glibc
    • Umumnya sisi server memang mempertahankan urutan, dan server yang tidak melakukan itu cepat diperbaiki karena masalah kompatibilitas
      CNAME memang benar-benar makhluk yang sulit ditangani (catatan DJB bisa dilihat)
    • Internet pada praktiknya bergantung pada beberapa implementasi authoritative server utama, jadi semuanya mengikuti aturan urutan yang sama
    • Untuk menghilangkan batasan urutan, dibutuhkan struktur data yang bisa mencari nama DNS dengan cepat
      Resolver sederhana seperti glibc tidak punya cache, jadi untuk menerapkannya perlu perubahan kode yang besar

  • Klaim Cloudflare bahwa “RFC tidak mewajibkan urutan CNAME” terdengar seperti memainkan celah bahasa
    Hanya karena tidak ada kata “MUST”, bukan berarti “semua urutan boleh”
    Saya rasa mengakui kesalahan dan lanjut memperbaikinya akan membuat dunia lebih baik
    Menghindari tanggung jawab lewat perdebatan bahasa justru membuat kepercayaan menurun

  • Cloudflare tampaknya tidak benar-benar memahami RFC1034
    Antarmuka DNS mereka memblokir A dan AAAA jika ada CNAME, tetapi masih mengizinkan record lain
    Karena itu, saat CNAME dan TXT ada bersamaan, muncul hasil yang bergantung pada cache
    internet.nl juga menemukan masalah seperti ini
    Sebagian pengguna mengatur konfigurasi mengikuti panduan mxtoolbox, dan itu bertentangan dengan RFC1034

    • Panduan itu tampaknya mencampur dua penjelasan yang berbeda
      Yang satu tentang “cara mendelegasikan layanan DMARC dengan CNAME”, dan yang lain tentang “cara meng-host sendiri”
      Sepertinya screenshot-nya yang menimbulkan kebingungan

  • Bahwa pada akhirnya Cloudflare sampai pada kesimpulan bahwa CNAME harus datang lebih dulu daripada record lain terdengar masuk akal

    • Saya juga senang dengan kesimpulan itu. Sekalipun semua orang salah, kadang kita memang harus menyesuaikan diri dengan kenyataan

  • Saat mengelola DNS di perusahaan, saya merasakan berbagai keterbatasan DNS
    Khususnya jika SERVFAIL terjadi, klien tidak bisa membedakan server mana yang bermasalah
    Akibatnya, banyak server DNS dan lapisan cache memicu lonjakan retry yang tidak perlu
    Selain itu, search path membuat kueri NXDOMAIN ke domain yang salah terus berulang

    • Saya juga pernah mengalami masalah serupa. Saya menghabiskan lebih dari sehari hanya melihat caching server dan tidak menemukan penyebabnya, lalu ternyata masalahnya ada di authoritative server
    • BIND 9 punya opsi servfail-ttl untuk meredakan ini
      Menurut RFC2308 bagian 7.1, me-cache respons SERVFAIL memang diperbolehkan
      Ini standar lama, tetapi masih merupakan pendekatan yang valid

  • Cloudflare cukup sering merusak standar, lalu membenarkannya dengan menulis RFC baru
    Contoh seperti RFC 8482 menurut saya adalah aib bagi industri
    Ucapan “kali ini juga kami mengajukan Internet-Draft baru untuk mencegah kebingungan” terdengar ironis

  • Untuk server DNS berskala besar seperti 1.1.1.1, seharusnya ada pengujian integrasi yang mencakup resolver nyata seperti glibc
    Jadi saya bertanya-tanya kenapa masalah seperti ini baru ditemukan di produksi

    • Mungkin ini hanya muncul pada kombinasi langka ketika urutan kedaluwarsa cache berantakan lalu glibc melakukan kueri ulang
      Pengujian individual mungkin lolos, tetapi besar kemungkinan kasus saat dua kondisi itu bertumpuk terlewat