หากเซิร์ฟเวอร์ DNS ค้นหาระเบียนและหายไปมักจะ "แคชลบ" ความจริงที่ว่าระเบียนนี้หายไปและไม่พยายามค้นหาอีกครั้งในขณะที่ ฉันไม่เห็นสิ่งใดในRFCเกี่ยวกับ TTL เกี่ยวกับการแคชเชิงลบดังนั้นฉันจึงคาดเดาว่ามันค่อนข้างจะไม่เจาะจง ในโลกแห่งความจริงบันทึกเชิงลบเหล่านี้ติดอยู่นานแค่ไหน?

TTL สำหรับการแคชเชิงลบนั้นไม่ได้กำหนดเอง มันถูกนำมาจากระเบียน SOA ที่ด้านบนสุดของโซนที่ระเบียนที่ร้องขอจะเป็นของมีอยู่จริงหรือไม่ ตัวอย่างเช่น:

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

ค่าสุดท้ายในระเบียน SOA ( "86400") example.org.เป็นจำนวนเงินของลูกค้าของเวลาที่จะขอให้แคชผลลัพธ์เชิงลบภายใต้

หากลูกค้าร้องขอdoesnotexist.example.org.มันจะทำการแคชผลลัพธ์เป็นเวลา 86400 วินาที

ขึ้นอยู่กับคำจำกัดความที่แน่นอนของคุณของ " คิวรีเชิงลบ " แต่ในกรณีใดกรณีนี้จะมีการบันทึกไว้ในrfc2308 «แคชเชิงลบของ DNS Queries (DNS NCACHE) » :

NXDOMAIN

• หากความละเอียดประสบความสำเร็จและส่งผลNXDOMAINให้การตอบสนองจะมาพร้อมกับSOAบันทึกซึ่งจะมีNXDOMAINTTL (ประเพณีที่รู้จักกันเป็นMINIMUMสนาม) rfc2308#section-4

SERVFAIL

• หากการแก้ปัญหาไม่สำเร็จและส่งผลให้หมดเวลา ( SERVFAIL)อาจไม่ถูกแคชเลยและในทุกกรณีจะต้องไม่ถูกแคชนานกว่า 5 นาที rfc2308#section-7.1

  โปรดทราบว่าในทางปฏิบัติการแคชผลลัพธ์ดังกล่าวเป็นเวลา 5 นาทีเต็มรูปแบบเป็นวิธีที่ดีในการลดประสบการณ์ของไคลเอนต์หากเซิร์ฟเวอร์แคชของพวกเขาประสบปัญหาการเชื่อมต่อสั้น ๆ เป็นครั้งคราว (และทำให้มีประสิทธิภาพ โดยที่การหยุดทำงานไม่กี่วินาทีจะส่งผลให้บางส่วนของ DNS หยุดทำงานเป็นเวลาห้านาทีเต็ม)

  ก่อนหน้า BIND 9.9.6-S1 (เปิดตัวในปี 2014) เห็นได้ชัดSERVFAILว่าไม่ได้แคชเลย a878301(2014/09/04)

  เช่นในช่วงเวลาของคำถามของคุณและในทุกรุ่นของการผูกที่ปล่อยออกมาก่อนที่จะปี 2014, ห่วงจำแนก recursive ไม่แคชSERVFAILที่ทั้งหมดถ้าข้างต้นกระทำและเอกสารเกี่ยวกับการเปิดตัวครั้งแรกใน 9.9.6-S1จะเชื่อ .

  ใน BIND ล่าสุดค่าเริ่มต้นservfail-ttlคือ1sและการตั้งค่าจะฮาร์ดโค้ดเป็นเพดานของ30s(แทนที่เพดานที่ได้รับคำสั่งจาก RFC 300s) 90174e6(2015/10/17)

  นอกจากนี้ต่อไปนี้เป็นคำพูดที่น่าจดจำเกี่ยวกับเรื่องนี้:

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

  ผลลัพธ์ของการแคชการตอบสนองของ SERVFAIL ได้รวมบางสถานการณ์ที่เห็นว่าเป็นอันตรายต่อประสบการณ์ของลูกค้าโดยเฉพาะอย่างยิ่งเมื่อสาเหตุของการเสนอ SERVFAIL ไปยังลูกค้านั้นชั่วคราวและจากสถานการณ์ที่การลองสืบค้นใหม่ทันทีจะเป็น การกระทำที่เหมาะสมมากขึ้น

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

  กลยุทธ์ที่สองคือการอ้างว่าไคลเอนต์ DNS ที่แพร่หลายจะทำบางสิ่งโดยเฉพาะอย่างยิ่ง Evil เมื่อพวกเขาไม่สามารถเข้าถึงเซิร์ฟเวอร์ DNS ทั้งหมด ปัญหาเกี่ยวกับการโต้แย้งนี้คือการเรียกร้องเป็นเท็จ ลูกค้าดังกล่าวมีข้อผิดพลาดอย่างชัดเจนและจะไม่สามารถอยู่รอดได้ในตลาด: พิจารณาว่าเกิดอะไรขึ้นถ้าเราเตอร์ของลูกค้าลงไปชั่วครู่หรือเครือข่ายของลูกค้าถูกน้ำท่วมชั่วคราว

โดยสรุปการNXDOMAINตอบสนองจะถูกแคชตามที่ระบุในSOAโซนที่ใช้งานได้ในขณะที่SERVFAILไม่น่าจะถูกแคชหรือถ้าแคชจะมีจำนวนหลักสองหลักเป็นวินาที

มี RFC ทุ่มเทให้กับเรื่องนี้คือ: RFC 2308 - แคชเชิงลบของ DNS แบบสอบถาม (DNS NCACHE)

ส่วนที่เกี่ยวข้องในการอ่านคือ5 - แคชคำตอบเชิงลบซึ่งระบุ:

เช่นเดียวกับคำตอบปกติคำตอบเชิงลบมีเวลาอยู่ (TTL) เนื่องจากไม่มีบันทึกในส่วนคำตอบที่สามารถใช้ TTL นี้ได้จึงต้องดำเนินการด้วยวิธีอื่น TTL สิ่งนี้ทำได้โดยการรวมเรกคอร์ด SOA จากโซนในส่วนสิทธิ์ของการตอบกลับ เมื่อเซิร์ฟเวอร์ที่มีสิทธิ์สร้างเรคคอร์ดนี้ TTL จะถูกนำมาจากขั้นต่ำของฟิลด์ SOA.MINIMUM และ TTL ของ SOA การลดลงของ TTL ในลักษณะที่คล้ายกับคำตอบที่แคชปกติและเมื่อถึงศูนย์ (0) หมายถึงคำตอบเชิงลบที่แคชไว้จะต้องไม่ถูกใช้อีกครั้ง

ก่อนอื่นให้ระบุSOA.MINIMUMและ SOA TTL ที่อธิบายไว้ใน RFC TTL คือหมายเลขก่อนประเภทบันทึกIN( 900วินาทีในตัวอย่างด้านล่าง) ในขณะที่ค่าต่ำสุดคือฟิลด์สุดท้ายในบันทึก ( 86400วินาทีในตัวอย่างด้านล่าง)

$ 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)
                )

ตอนนี้ลองมาดูตัวอย่างserverfault.comโซนเป็นตัวอย่างเนื่องจากมีเซิร์ฟเวอร์ที่เชื่อถือได้จากผู้ให้บริการสองรายที่มีการกำหนดค่าแตกต่างกัน

ให้ค้นหาเนมเซิร์ฟเวอร์สิทธิ์สำหรับserverfault.comโซน:

$ 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.

จากนั้นตรวจสอบบันทึก SOA โดยใช้เนมเซิร์ฟเวอร์ 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

จากนี้เราจะเห็นได้ว่า TTL ของระเบียน SOA เป็น900วินาทีในขณะที่ค่าลบ TTL เป็น86400วินาที ค่า SOA TTL ของ900ต่ำกว่าดังนั้นเราจึงคาดหวังให้ใช้ค่านี้

ตอนนี้ถ้าเราสอบถามเซิร์ฟเวอร์เผด็จการสำหรับโดเมนที่ไม่มีอยู่เราควรได้รับการตอบสนองโดยไม่มีคำตอบและบันทึก SOA ในส่วนอำนาจ:

$ 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

เมื่อตัวแก้ปัญหาแบบเรียกซ้ำ (แคช) ได้รับคำตอบนี้จะแยกวิเคราะห์เรคคอร์ด SOA ในAUTHORITY SECTIONและใช้ TTL ของเรคคอร์ดนี้เพื่อกำหนดระยะเวลาที่แคชผลลัพธ์ที่เป็นค่าลบ (ในกรณีนี้เป็น900วินาที)

ตอนนี้ให้ทำตามขั้นตอนเดียวกันกับ google nameserver:

$ 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

คุณจะเห็นว่า google nameservers มีค่าแตกต่างกันสำหรับทั้ง SOA TTL และค่าลบ TTL ในกรณีนี้ TTL เชิงลบของการ300ต่ำกว่า SOA TTL 21600ของ ดังนั้นเซิร์ฟเวอร์ google ควรใช้ค่าที่ต่ำกว่าในAUTHORITY SECTIONบันทึก SOA เมื่อส่งคืนการNXDOMAINตอบกลับ:

$ 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

ตามที่คาดไว้ TTL ของระเบียน SOA ในการNXDOMAINตอบสนองคือไม่300กี่วินาที

ตัวอย่างข้างต้นยังแสดงให้เห็นว่าการได้รับคำตอบที่แตกต่างจากแบบสอบถามเดียวกันนั้นง่ายเพียงใด คำตอบที่ตัวแก้ไขการแคชแต่ละรายการจบลงด้วยการใช้งานซึ่งลงไปที่การสอบถามเซิร์ฟเวอร์ที่เชื่อถือได้

ในการทดสอบของฉันฉันได้สังเกตเห็นว่าตัวแก้ไขแบบเรียกซ้ำ (แคช) บางตัวไม่ส่งคืนAUTHORITY SECTIONระเบียน SOA ที่มี TTL ที่ลดลงสำหรับคำขอถัดไปในขณะที่คนอื่นทำ

ตัวอย่างเช่นตัวแก้ไขคลาวด์แฟลทำ (สังเกตค่า TTL ที่ลดลง):

$ 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

ในขณะที่โปรแกรมแก้ไขค่าเริ่มต้นใน AWS VPC จะตอบกลับด้วยส่วนสิทธิ์ในคำขอแรกเท่านั้น:

$ 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

หมายเหตุ: คำตอบนี้กล่าวถึงพฤติกรรมของNXDOMAINคำตอบ

คำศัพท์:

• โซน
• SOA
• TTL
• Recursive NameServer
• เนมเซิร์ฟเวอร์ที่เชื่อถือได้