Nếu một máy chủ DNS tìm kiếm một bản ghi và nó bị thiếu, nó thường sẽ "lưu trữ tiêu cực" thực tế là bản ghi này bị thiếu và không cố gắng tìm kiếm lại trong một thời gian. Tôi không thấy bất cứ điều gì trong RFC về TTL trên bộ nhớ đệm tiêu cực, vì vậy tôi đoán nó hơi tùy tiện. Trong thế giới thực, những hồ sơ tiêu cực này tồn tại trong bao lâu?

TTL cho bộ nhớ đệm âm không phải là tùy ý. Nó được lấy từ bản ghi SOA ở đầu khu vực mà bản ghi được yêu cầu sẽ thuộc về nó, nếu nó tồn tại. Ví dụ:

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

Giá trị cuối cùng trong bản ghi SOA ("86400") là lượng thời gian khách hàng được yêu cầu lưu trữ kết quả âm tính theo example.org..

Nếu một khách hàng yêu cầu doesnotexist.example.org., nó sẽ lưu trữ kết quả trong 86400 giây.

Điều này phụ thuộc vào định nghĩa chính xác của bạn về "truy vấn phủ định", nhưng trong cả hai trường hợp, điều này được ghi lại trong rfc2308 «Bộ nhớ đệm tiêu cực của truy vấn DNS (DNS NCACHE)» :

NXDOMAIN

• Nếu độ phân giải thành công và có kết quả NXDOMAIN, phản hồi sẽ đi kèm với một SOAbản ghi, trong đó có chứa NXDOMAINTTL (theo truyền thống được gọi là MINIMUMtrường). rfc2308#section-4

SERVFAIL

• Nếu độ phân giải không thành công và dẫn đến thời gian chờ ( SERVFAIL) , thì nó cũng có thể không được lưu trong bộ nhớ cache và trong mọi trường hợp PHẢI KHÔNG được lưu trong bộ nhớ cache lâu hơn 5 phút. rfc2308#section-7.1

  Lưu ý rằng trong thực tế, lưu trữ các kết quả như vậy trong 5 phút cho phép đầy đủ là một cách tuyệt vời để giảm bớt trải nghiệm của khách hàng nếu máy chủ bộ đệm của họ thỉnh thoảng gặp sự cố kết nối ngắn (và thực sự dễ bị ảnh hưởng bởi khuếch đại Từ chối dịch vụ, trong đó một vài giây thời gian chết sẽ dẫn đến một số phần nhất định của DNS bị ngừng hoạt động trong năm phút đầy đủ).

  Trước BIND 9.9.6-S1 (phát hành năm 2014), rõ ràng, SERVFAILhoàn toàn không được lưu trữ. a878301(2014-09-04)

  Ví dụ, tại thời điểm câu hỏi của bạn và trong tất cả các phiên bản BIND được phát hành trước năm 2014, bộ giải quyết đệ quy BIND không lưu bộ nhớ cache SERVFAIL, nếu cam kết trên và tài liệu về giới thiệu đầu tiên trong 9.9.6-S1 được tin tưởng .

  Trong BIND mới nhất, mặc định servfail-ttllà 1svà cài đặt được mã hóa cứng ở mức trần 30s(thay cho trần bắt buộc của RFC 300s). 90174e6(2015-10-17)

  Hơn nữa, sau đây là một số trích dẫn đáng chú ý về vấn đề này:

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

  Kết quả của các phản hồi của bộ nhớ cache đã bao gồm một số tình huống gây bất lợi cho trải nghiệm của khách hàng, đặc biệt là khi các nguyên nhân của SERVFAIL được trình bày cho khách hàng là tạm thời và từ một kịch bản mà việc thử lại ngay lập tức truy vấn sẽ là một hành động phù hợp hơn.

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

  Chiến thuật thứ hai là tuyên bố rằng các máy khách DNS phổ biến sẽ làm điều gì đó đặc biệt là Ác ma khi chúng không thể truy cập tất cả các máy chủ DNS. Vấn đề với lập luận này là tuyên bố là sai. Bất kỳ ứng dụng khách nào như vậy rõ ràng là có lỗi và sẽ không thể tồn tại trên thị trường: xem xét điều gì xảy ra nếu bộ định tuyến của khách hàng bị hỏng trong thời gian ngắn hoặc nếu mạng của khách hàng bị ngập tạm thời.

Tóm lại, một NXDOMAINphản hồi sẽ được lưu trong bộ nhớ cache như được chỉ định trong vùng SOAáp dụng, trong khi SERVFAILkhông có khả năng được lưu vào bộ đệm, hoặc, nếu được lưu vào bộ đệm, nó sẽ có nhiều nhất là một số hai chữ số.

Có một RFC dành riêng cho chủ đề này: RFC 2308 - Bộ nhớ đệm tiêu cực của các truy vấn DNS (DNS NCACHE) .

Phần có liên quan để đọc là 5 - Bộ đệm Câu trả lời phủ định có ghi:

Giống như câu trả lời bình thường, câu trả lời tiêu cực có thời gian để sống (TTL). Vì không có bản ghi nào trong phần câu trả lời mà TTL này có thể được áp dụng, nên phải thực hiện TTL bằng phương pháp khác. Điều này được thực hiện bằng cách bao gồm bản ghi SOA từ vùng trong phần thẩm quyền của câu trả lời. Khi máy chủ có thẩm quyền tạo bản ghi này, TTL của nó được lấy từ mức tối thiểu của trường SOA.MINIMUM và TTL của SOA. Điều này suy giảm theo cách tương tự với câu trả lời được lưu trong bộ nhớ cache thông thường và khi đạt đến 0 (0) cho thấy câu trả lời phủ định được lưu trong bộ nhớ cache KHÔNG được sử dụng lại.

Trước hết, hãy xác định SOA.MINIMUMvà SOA TTL được mô tả trong RFC. TTL là số trước loại bản ghi IN( 900giây trong ví dụ bên dưới). Trong khi mức tối thiểu là trường cuối cùng trong bản ghi ( 86400giây trong ví dụ bên dưới).

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

Bây giờ hãy xem xét một số ví dụ, serverfault.comkhu vực này có tính minh họa vì nó có các máy chủ có thẩm quyền từ hai nhà cung cấp khác nhau được cấu hình khác nhau.

Cho phép tìm các máy chủ tên có thẩm quyền cho serverfault.comkhu vực:

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

Sau đó kiểm tra bản ghi SOA bằng máy chủ tên 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

Từ đó, chúng ta có thể thấy rằng TTL của bản ghi SOA là 900giây trong khi giá trị TTL âm là 86400giây. Giá trị của SOA 900là thấp hơn nên chúng tôi hy vọng giá trị này sẽ được sử dụng.

Bây giờ nếu chúng ta truy vấn một máy chủ có thẩm quyền cho một miền không tồn tại, chúng ta sẽ nhận được phản hồi mà không có câu trả lời và với bản ghi SOA trong phần thẩm quyền:

$ 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

Khi trình phân giải đệ quy (bộ đệm) nhận được câu trả lời này, nó sẽ phân tích bản ghi SOA trong AUTHORITY SECTIONvà sử dụng TTL của bản ghi này để xác định thời gian lưu bộ đệm kết quả âm tính trong bao lâu (trong trường hợp này là 900vài giây).

Bây giờ, hãy làm theo quy trình tương tự với máy chủ tên 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

Bạn có thể thấy rằng các máy chủ tên google có các giá trị khác nhau cho cả hai giá trị TTL và các giá trị TTL âm. Trong trường hợp này, TTL âm của 300thấp hơn so với TTL của 21600. Do đó, máy chủ google nên sử dụng giá trị thấp hơn trong AUTHORITY SECTIONbản ghi SOA khi trả về NXDOMAINphản hồi:

$ 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

Như mong đợi, bản ghi TTL của bản ghi SOA trong NXDOMAINphản hồi là 300giây.

Ví dụ trên cũng cho thấy việc dễ dàng nhận được các câu trả lời khác nhau cho cùng một truy vấn. Câu trả lời mà một bộ giải quyết bộ đệm ẩn riêng lẻ kết thúc bằng cách sử dụng máy chủ nam có thẩm quyền đã được truy vấn.

Trong thử nghiệm của tôi, tôi cũng đã quan sát thấy rằng một số bộ giải quyết đệ quy (bộ đệm) không trả về một AUTHORITY SECTIONbản ghi SOA với một bộ giảm dần cho các yêu cầu tiếp theo trong khi các bộ khác làm.

Ví dụ: trình phân giải đám mây thực hiện (lưu ý giá trị TTL giảm dần):

$ 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

Mặc dù trình phân giải mặc định trong VPC AWS sẽ chỉ phản hồi với phần quyền hạn theo yêu cầu đầu tiên:

$ 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

Lưu ý: Câu trả lời này giải quyết hành vi của NXDOMAINcâu trả lời.

Bảng chú giải:

• Khu
• SOA
• TTL
• Máy chủ tên đệ quy
• Máy chủ tên có thẩm quyền