Jika server DNS mencari catatan dan itu hilang, sering kali akan "secara negatif menyimpan" fakta bahwa catatan ini hilang, dan tidak mencoba mencarinya lagi untuk sementara waktu. Saya tidak melihat apa pun di RFC tentang TTL pada caching negatif seharusnya, jadi saya kira itu agak sewenang-wenang. Di dunia nyata, berapa lama catatan negatif ini bertahan?

TTL untuk caching negatif tidak sewenang-wenang. Ini diambil dari catatan SOA di bagian atas zona dimana catatan yang diminta akan menjadi milik, seandainya ada. Sebagai contoh:

example.org.    IN      SOA     master-ns1.example.org. Hostmaster.example.org. (
            2012091201 43200 1800 1209600 86400 )

Nilai terakhir dalam catatan SOA ("86400") adalah jumlah waktu yang diminta klien untuk menyimpan hasil negatif example.org..

Jika klien meminta doesnotexist.example.org., itu akan men-cache hasil selama 86400 detik.

Ini tergantung pada definisi pasti Anda dari "permintaan negatif", tetapi dalam kedua kasus, ini didokumentasikan dalam rfc2308 «Caching Negatif atas Pertanyaan DNS (DNS NCACHE)» :

NXDOMAIN

• Jika resolusi berhasil, dan menghasilkan NXDOMAIN, respons akan datang dengan SOAcatatan, yang akan berisi NXDOMAINTTL (secara tradisional dikenal sebagai MINIMUMbidang). rfc2308#section-4

SERVFAIL

• Jika resolusi tidak berhasil, dan menghasilkan batas waktu ( SERVFAIL) , maka itu mungkin juga tidak akan di-cache sama sekali, dan dalam semua keadaan TIDAK HARUS di-cache selama lebih dari 5 menit. rfc2308#section-7.1

  Perhatikan bahwa dalam praktiknya, caching hasil seperti itu selama 5 menit penuh yang diijinkan adalah cara yang bagus untuk mengurangi pengalaman klien jika server cache mereka kadang-kadang mengalami masalah konektivitas singkat (dan secara efektif membuatnya mudah rentan terhadap amplifikasi Denial-of-Service, di mana beberapa detik downtime akan mengakibatkan bagian-bagian tertentu dari DNS turun selama lima menit penuh).

  Sebelum ke BIND 9.9.6-S1 (dirilis pada 2014), tampaknya, SERVFAILtidak di-cache sama sekali. a878301(2014-09-04)

  Misalnya, pada saat pertanyaan Anda dan di semua versi BIND dirilis sebelum 2014, penyelesai rekursif BIND tidak melakukan cache SERVFAILsama sekali, jika komitmen di atas dan dokumentasi tentang pengantar pertama dalam 9,9.6-S1 dapat dipercaya .

  Dalam BIND terbaru, standarnya servfail-ttladalah 1s, dan pengaturannya dikodekan ke langit-langit 30s(menggantikan langit-langit yang diamanatkan oleh RFC 300s). 90174e6(2015-10-17)

  Selain itu, berikut adalah beberapa kutipan penting tentang masalah ini:

  • https://kb.isc.org/article/AA-01178/ (2014 / 2016-01-07)

  Hasil dari caching tanggapan SERVFAIL telah mencakup beberapa situasi di mana itu dianggap merugikan pengalaman klien, terutama ketika penyebab SERVFAIL yang disajikan kepada klien bersifat sementara dan dari skenario di mana coba kembali permintaan akan menjadi tindakan yang lebih tepat.

  • http://cr.yp.to/djbdns/third-party.html (2003-01-11)

  Taktik kedua adalah mengklaim bahwa klien DNS yang tersebar luas akan melakukan sesuatu yang khususnya Jahat ketika mereka tidak dapat menjangkau semua server DNS. Masalah dengan argumen ini adalah bahwa klaim tersebut salah. Klien semacam itu jelas-jelas bermasalah, dan tidak akan dapat bertahan di pasar: pertimbangkan apa yang terjadi jika router klien turun sebentar, atau jika jaringan klien dibanjiri sementara.

Singkatnya, NXDOMAINrespons akan di-cache seperti ditentukan dalam SOAzona yang berlaku, sedangkan SERVFAILkemungkinan tidak akan di-cache, atau, jika di-cache, paling banyak berupa angka dua digit detik.

Ada RFC yang didedikasikan untuk topik ini: RFC 2308 - Caching Negatif atas Pertanyaan DNS (DNS NCACHE) .

Bagian yang relevan untuk dibaca adalah 5 - Caching Jawaban Negatif yang menyatakan:

Seperti jawaban normal, jawaban negatif punya waktu untuk hidup (TTL). Karena tidak ada catatan di bagian jawaban yang dapat diterapkan TTL ini, TTL harus dilakukan dengan metode lain. Ini dilakukan dengan memasukkan catatan SOA dari zona di bagian otoritas balasan. Ketika server otoritatif membuat catatan ini, TTL diambil dari minimum bidang SOA.MINIMUM dan TTL SOA. Penurunan TTL ini dengan cara yang mirip dengan jawaban yang di-cache normal dan setelah mencapai nol (0) menunjukkan jawaban negatif yang di-cache TIDAK HARUS digunakan lagi.

Pertama mari kita mengidentifikasi SOA.MINIMUMdan SOA TTL yang dijelaskan dalam RFC. TTL adalah angka sebelum tipe catatan IN( 900detik dalam contoh di bawah). Sedangkan minimum adalah bidang terakhir dalam catatan ( 86400detik dalam contoh di bawah).

$ dig serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline
;; global options: +cmd
serverfault.com.    900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. (
                1          ; serial
                7200       ; refresh (2 hours)
                900        ; retry (15 minutes)
                1209600    ; expire (2 weeks)
                86400      ; minimum (1 day)
                )

Sekarang mari kita lihat beberapa contoh, serverfault.comzona ini ilustratif karena memiliki server otoritatif dari dua penyedia berbeda yang dikonfigurasi secara berbeda.

Mari kita menemukan server nama resmi untuk serverfault.comzona:

$ host -t ns serverfault.com
serverfault.com name server ns-860.awsdns-43.net.
serverfault.com name server ns-1135.awsdns-13.org.
serverfault.com name server ns-cloud-c1.googledomains.com.
serverfault.com name server ns-cloud-c2.googledomains.com.

Kemudian periksa catatan SOA menggunakan server aws:

$ dig serverfault.com soa @ns-1135.awsdns-13.org | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Dari ini kita dapat melihat bahwa TTL dari catatan SOA adalah 900detik sedangkan nilai TTL negatif adalah 86400detik. Nilai SOA TTL 900lebih rendah sehingga kami berharap nilai ini digunakan.

Sekarang jika kita meminta server otoritatif untuk domain yang tidak ada, kita harus mendapatkan respons tanpa jawaban dan dengan catatan SOA di bagian otoritas:

$ dig nxdomain.serverfault.com @ns-1135.awsdns-13.org

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-1135.awsdns-13.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51948
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    900 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 125 msec
;; SERVER: 205.251.196.111#53(205.251.196.111)
;; WHEN: Tue Aug 20 15:49:47 NZST 2019
;; MSG SIZE  rcvd: 135

Ketika resolver rekursif (caching) menerima jawaban ini, ia akan mengurai catatan SOA di AUTHORITY SECTIONdan menggunakan TTL catatan ini untuk menentukan berapa lama ia harus menyimpan hasil negatif (dalam kasus ini 900detik).

Sekarang mari ikuti prosedur yang sama dengan server nama google:

$ dig serverfault.com soa @ns-cloud-c2.googledomains.com | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com.    21600   IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

Anda dapat melihat bahwa server nama google memiliki nilai yang berbeda untuk nilai TTL SOA dan negatif TTL. Dalam hal ini TTL negatif 300lebih rendah daripada SOA TTL 21600. Karena itu server google harus menggunakan nilai yang lebih rendah dalam AUTHORITY SECTIONcatatan SOA ketika mengembalikan NXDOMAINrespons:

$ dig nxdomain.serverfault.com @ns-cloud-c2.googledomains.com

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-cloud-c2.googledomains.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25920
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nxdomain.serverfault.com.  IN  A

;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 130 msec
;; SERVER: 216.239.34.108#53(216.239.34.108)
;; WHEN: Tue Aug 20 16:05:24 NZST 2019
;; MSG SIZE  rcvd: 143

Seperti yang diharapkan, TTL dari catatan SOA dalam NXDOMAINrespons adalah 300detik.

Contoh di atas juga menunjukkan betapa mudahnya mendapatkan jawaban yang berbeda untuk permintaan yang sama. Jawaban yang akhirnya diselesaikan oleh seorang penyelesai caching adalah ke mana namserver otoritatif ditanyai.

Dalam pengujian saya, saya juga telah mengamati bahwa beberapa resolvers (caching) rekursif tidak mengembalikan sebuah AUTHORITY SECTIONdengan catatan SOA dengan TTL menurun untuk permintaan berikutnya sedangkan yang lain melakukannya.

Sebagai contoh, resolver cloudflare tidak (perhatikan nilai TTL yang mengurangi):

$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    674 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    668 IN  SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Sementara resolver default di AWS VPC akan merespons dengan bagian otoritas hanya pada permintaan pertama:

$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com.    300 IN  SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0

Catatan: Jawaban ini membahas perilaku NXDOMAINjawaban.

Glosarium:

• Daerah
• SOA
• TTL
• NameServer Rekursif
• Nameserver yang Berwenang