Bir DNS sunucusu bir kayda bakarsa ve eksikse, bu kaydın eksik olduğu gerçeğini sıklıkla "olumsuz bir şekilde önbelleğe alır" ve bir süre tekrar aramaya çalışmaz. RFC'de olumsuz önbelleğe alma konusunda TTL hakkında bir şey görmüyorum , bu yüzden biraz keyfi olduğunu tahmin ediyorum. Gerçek dünyada, bu olumsuz kayıtlar ne kadar süre dayanıyor?

Negatif önbellekleme için TTL keyfi değildir. İstenilen kaydın ait olacağı bölgenin üstündeki SOA kaydından alınmış olması şartıyla alınmıştır. Örneğin:

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

SOA kaydındaki son değer ("86400"), istemcilerin negatif sonuçları önbelleğe almasının istendiği süredir example.org..

Bir müşteri talep ederse doesnotexist.example.org., sonucu 86400 saniye önbelleğe alır.

Bu, "negatif sorgu" ifadesinin tam olarak tanımlanmasına bağlıdır, ancak her iki durumda da, bu, rfc2308 «DNS Sorgularının Negatif Önbelleğe Alınması (DNS NCACHE)» bölümünde belgelenmiştir :

NXDOMAIN

• Çözünürlük başarılı olursa ve sonuçlanırsa NXDOMAIN, yanıt TTL'yi (geleneksel olarak alan olarak bilinir ) SOAiçeren bir kayıtla gelecektir . NXDOMAINMINIMUMrfc2308#section-4

SERVFAIL

• Çözünürlük başarılı olmazsa ve zaman aşımına uğrarsa ( SERVFAIL) , o zaman hiç önbelleklenmeyebilir ve her koşulda 5 dakikadan uzun süre önbelleklenmemelidir. rfc2308#section-7.1

  Uygulamada, izin verilen 5 dakika boyunca bu tür sonuçları önbelleğe almanın, bir müşterinin önbellek sunucusu ara sıra kısa bağlantı sorunlarıyla karşılaşması durumunda (ve etkili bir şekilde Hizmet Reddi yükseltmesine karşı savunmasız kalması durumunda) deneyimini azaltmak için harika bir yol olduğunu unutmayın. birkaç saniyelik aksama süresi, DNS'nin belirli kısımlarının beş tam dakika boyunca bozulmasına neden olacaktır.

  BIND'den önce 9.9.6-S1 (2014'te yayınlandı), görünüşe göre, SERVFAILhiçbir şekilde önbelleğe alınmadı. a878301(2014/09/04)

  Örneğin, sorunuzun zamanında ve 2014'ten önce yayımlanan BIND'in tüm sürümlerinde SERVFAIL, yukarıdakilerin 9.9.6-S1’deki ilk giriş ile ilgili belgelerine inanılması gerekiyorsa , BIND özyinelemeli çözümleyici önbelleklemedi . .

  Son BIND, varsayılan servfail-ttlolduğunu 1sve ayar tavanına kodlanma 30s(RFC zorunlu tavan yerine 300s). 90174e6(2015/10/17)

  Ayrıca, aşağıdakiler, konuyla ilgili bazı önemli alıntılardır:

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

  SERVFAIL yanıtlarını önbelleğe almanın sonucu, özellikle SERVFAIL'ın müşteriye sunulmasının nedenleri geçici olduğunda ve sorgunun derhal yeniden denenmesinin bir senaryo olacağı durumlarda, müşteri deneyimine zararlı olduğu görülen bazı durumları içermiştir. daha uygun eylem.

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

  İkinci taktik, yaygın DNS istemcilerinin, tüm DNS sunucularına erişemediklerinde Özellikle Kötü bir şey yapacağını iddia etmektir. Bu argümanla ilgili sorun, iddiaların yanlış olmasıdır. Bu tür herhangi bir müşteri açık bir şekilde can sıkıcıdır ve pazarda hayatta kalamaz: Müşterinin yönlendiricileri kısa bir süre aşağı inerse veya müşterinin ağı geçici olarak su altında kalırsa ne olacağını düşünün.

Özetle, geçerli bölge NXDOMAINiçinde belirtildiği gibi bir yanıt önbelleğe alınır SOA, oysa SERVFAILönbelleğe alınması pek mümkün değildir veya önbelleklenirse en fazla iki basamaklı bir saniye olacaktır.

Bu konuya adanmış bir RFC vardır: RFC 2308 - DNS Sorgularının Negatif Önbelleğe Alınması (DNS NCACHE) .

Okuma alakalı bölümdür 5 - Negatif Yanıtlar önbelleğe alma durumları:

Normal cevaplar gibi olumsuz cevaplar da yaşamaya başlar (TTL). Bu TTL'nin uygulanabileceği cevap bölümünde kayıt olmadığından, TTL başka bir yöntemle taşınmalıdır. Bu, bölgedeki SOA kaydını cevabın yetkili bölümüne dahil etmek suretiyle yapılır. Yetkili sunucu bu kaydı oluşturduğunda, TTL'si SOA.MINIMUM alanının ve SOA'nın TTL'sinin minimumundan alınır. Bu TTL normal bir önbelleğe alınmış cevaba benzer şekilde azalır ve sıfıra (0) ulaşıldığında önbelleklenen negatif cevabın tekrar kullanılmaması GEREKİR.

Öncelikle SOA.MINIMUMRFC'de açıklanan ve SOA TTL'yi tanımlayalım. TTL, kayıt türünden önceki sayıdır IN( 900aşağıdaki örnekte saniyeler). Minimum kayıtta son alan olmasına rağmen ( 86400aşağıdaki örnekte saniyeler).

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

Şimdi bazı örneklere bakalım, serverfault.combölge farklı yapılandırılmış iki farklı sağlayıcıdan gelen yetkili sunuculara sahip olduğu için açıklayıcıdır.

serverfault.comBölge için yetkili ad sunucularını bulalım :

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

Ardından, bir aws nameserver kullanarak SOA kaydını kontrol edin:

$ 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

Bundan, SOA kaydının 900TTL’sinin saniye, negatif TTL değerinin 86400saniyeler olduğunu görebiliriz. SOA TTL değeri 900daha düşük olduğundan, bu değerin kullanılmasını bekliyoruz.

Şimdi, var olmayan bir etki alanı için yetkili bir sunucuyu sorgularsak, otorite bölümünde yanıtsız ve SOA kaydı olan bir yanıt almalıyız:

$ 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

Özyinelemeli (önbellekleme) bir çözümleyici bu cevabı aldığında, SOA kaydını ayrıştırır AUTHORITY SECTIONve negatif sonucun ne kadar süreyle önbelleğe alınması gerektiğini belirlemek için bu kaydın TTL'sini kullanır (bu durumda 900saniye).

Şimdi aynı prosedürü bir google nameserver ile izleyelim:

$ 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 ad sunucularının hem SOA TTL hem de Negatif TTL değerleri için farklı değerlere sahip olduğunu görebilirsiniz. Bu durumda, negatif TTL 300, SOA TTL'den daha düşüktür 21600. Bu nedenle google sunucusu alt değeri kullanması gerektiğini AUTHORITY SECTIONbir döndürürken SOA kaydının NXDOMAINyanıtı:

$ 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

Beklendiği gibi NXDOMAINyanıttaki SOA kaydının TTL'si 300saniyedir.

Yukarıdaki örnekte, aynı sorguya farklı cevaplar almanın ne kadar kolay olduğu gösterilmektedir. Bireysel önbellek çözümleyicinin kullanarak sona erdiği yanıtı, yetkili adlandırma sunucusunun sorgulandığı sorundur.

Testlerimde, bazı özyinelemeli (önbellekleme) çözümleyicilerin AUTHORITY SECTION, diğerleri tarafından yapılan taleplerde sonraki TTL için azalan bir TTL'ye sahip bir SOA kaydıyla geri dönmediğini gözlemledim .

Örneğin, cloudflare çözümleyicisi şunları yapar (azalan TTL değerine dikkat edin):

$ 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

Bir AWS VPC'deki varsayılan çözümleyici yalnızca ilk talepte yetkili bölüme cevap verirken:

$ 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

Not: Bu cevap, NXDOMAINcevapların davranışına yöneliktir .

Sözlük:

• bölge
• SOA
• TTL
• Özyinelemeli NameServer
• Yetkili Ad Sunucusu