DNS 서버가 레코드를 조회하고 누락 된 경우 종종이 레코드가 누락되었다는 사실을 "부정적으로 캐시"하고 잠시 동안 다시 찾지 않습니다. 네거티브 캐싱의 TTL에 대한 RFC의 어떤 것도 보지 못 하므로 다소 임의적이라고 생각합니다. 실제 세계에서 이러한 부정적인 기록은 얼마나 오래 지속됩니까?

네거티브 캐싱의 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 쿼리의 부정 캐싱 (DNS NCACHE)»에 설명되어 있습니다 .

NXDOMAIN

• 해결에 성공하고 결과가 NXDOMAIN이면 응답 SOA에 NXDOMAINTTL (전통적으로 MINIMUM필드 라고 함) 이 포함 된 레코드 가 제공됩니다 . rfc2308#section-4

SERVFAIL

• 해결에 실패하고 시간 초과 ( SERVFAIL) 가 발생하면 전혀 캐시되지 않을 수 있으며 모든 상황에서 5 분 이상 캐시해서는 안됩니다. rfc2308#section-7.1

  실제로, 허용 가능한 5 분 동안 이러한 결과를 캐싱하는 것은 캐시 서버가 때때로 짧은 연결 문제를 겪고 클라이언트가 서비스 거부 증폭에 쉽게 취약하게된다면 클라이언트 경험을 줄이는 좋은 방법입니다. 몇 초의 다운 타임으로 인해 DNS의 특정 부분이 5 분 동안 다운 될 수 있습니다.

  BIND 9.9.6-S1 (2014 년에 릴리스) 이전에는 SERVFAIL전혀 캐시되지 않았습니다. a878301(2014-09-04)

  예를 들어, 질문과 2014 년 이전에 릴리스 된 모든 버전의 BIND SERVFAIL에서 위의 커밋과 9.9.6-S1의 첫 번째 소개에 대한 문서 가 믿어 지면 BIND 재귀 해결 프로그램 은 전혀 캐시하지 않습니다. .

  최신 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 클라이언트가 모든 DNS 서버에 도달 할 수 없을 때 특히 악한 일을 할 것이라고 주장하는 것입니다. 이 주장의 문제점은 그 주장이 거짓이라는 것입니다. 그러한 클라이언트는 분명히 버그가 있으며 시장에서 살아남을 수 없습니다. 클라이언트의 라우터가 잠깐 동안 중단되거나 클라이언트의 네트워크가 일시적으로 넘치면 어떻게 될지 고려하십시오.

요약하면 NXDOMAIN응답은 SOA적용 가능한 영역에 지정된대로 캐시 되지만 SERVFAIL캐시되지 않을 가능성이 높으며 최대 두 자리 수 (초)입니다.

RFC 2308-DNS 쿼리의 네거티브 캐싱 (DNS NCACHE) 주제 전용 RFC가 있습니다 .

읽어야 할 관련 섹션은 5-부정적인 답변 캐싱입니다 .

일반적인 답변과 마찬가지로 부정적인 답변은 TTL (Time to Live)이 있습니다. 이 TTL을 적용 할 수있는 답변 섹션에 레코드가 없으므로 TTL은 다른 방법으로 수행해야합니다. 응답의 권한 섹션에 영역의 SOA 레코드를 포함시켜 수행합니다. 권한있는 서버가이 레코드를 작성할 때 TTL은 최소 SOA.MINIMUM 필드와 SOA의 TTL에서 가져옵니다. 이 TTL은 일반 캐시 응답과 유사한 방식으로 감소하며 0에 도달하면 캐시 된 네거티브 응답을 다시 사용해서는 안된다는 것을 나타냅니다.

먼저 SOA.MINIMUMRFC에 설명 된 및 SOA TTL을 식별 할 수 있습니다 . 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.

그런 다음 aws 네임 서버를 사용하여 SOA 레코드를 확인하십시오.

$ 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

이것으로부터 SOA 레코드의 TTL은 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초) 을 결정합니다 .

이제 구글 네임 서버로 같은 절차를 따르십시오 :

$ 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 네임 서버는 SOA TTL과 Negative TTL 값에 대해 서로 다른 값을 가지고 있음을 알 수 있습니다. 이 경우 음의 TTL은의 300SOA 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

예상 한대로 NXDOMAIN응답 에서 SOA 레코드의 TTL 은 300초입니다.

위의 예는 또한 동일한 쿼리에 대해 다른 답변을 얻는 것이 얼마나 쉬운지를 보여줍니다. 개별 캐싱 리졸버가 사용하는 대답은 정식 namserver를 쿼리 한 것입니다.

내 테스트에서 일부 재귀 적 (캐싱) 리졸버는 AUTHORITY SECTION후속 요청에 대해 TTL이 감소하는 SOA 레코드를 반환하지 않는 반면 다른 요청은 반환합니다 .

예를 들어 cloudflare 리졸버는 다음을 수행합니다 (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
• 재귀 이름 서버
• 신뢰할 수있는 네임 서버