☰

바인딩이 공용 DNS 공급자보다 느린 이유

tag-icon • tag-icon bind
바인딩이 공용 DNS 공급자보다 느린 이유

우리는 우분투 12.04에 바인드 9.8.1.dfsg.P1-4ubuntu0.13을 가지고 있는데, 이는 부하가 많지 않은 서버(부하 평균: 0.19, 0.12, 0.13)에서 실행되고 macos 및 우분투 워크스테이션이 있는 소규모 사무실 네트워크에 대한 요청을 처리합니다.

DNS 서버로 실행되는 컨테이너의 스크립트에서 일부 DNS 테스트를 실행하고 결과를 influxdb에 푸시했습니다.

#!/bin/bash
while true
do
        rndc flush

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=yes value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=yes value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=yes value=$yandex_timeout" &
        wait

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=no value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=no value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=no value=$yandex_timeout" &
        wait

        sleep 5
done

바인드가 요청에 대해 느리게 응답하는 것을 발견했습니다.8.8.8.8그리고77.88.8.8. 이는 그래프에서 확인할 수 있습니다.

. rndc flush​바인딩은 Google을 사용합니다.8.8.8.8그리고8.8.4.4전달자로서:

여기에 이미지 설명을 입력하세요

실행 중인 바인드의 캐시를 플러시하지 마십시오. 바인딩은 Google을 사용합니다.8.8.8.8그리고8.8.4.4전달자로서:

여기에 이미지 설명을 입력하세요

. rndc flush​Bind는 업데이트된 루트 서버 목록을 전달자로 사용합니다.

여기에 이미지 설명을 입력하세요

실행 중인 바인드의 캐시를 플러시하지 마십시오. Bind는 업데이트된 루트 서버 목록을 전달자로 사용합니다.

여기에 이미지 설명을 입력하세요

Google 공개 DNS를 사용한 최대 쿼리 시간(첫 번째 그래프에서는 약 5k, 세 번째 그래프에서는 2.5k)이 루트 서버보다 큰 이유는 무엇입니까?

바인드를 통한 쿼리가 공개 DNS 서버의 직접 쿼리보다 느린 이유는 무엇입니까?

내 테스트에 문제가 있는 것일까요?

업데이트 1

그래프에는 20초 TTL이 있습니다. 이는 잘못된 것입니다. redhat.com의 TTL은 60초입니다.

답변1

테스트에서는 다음을 포함하여 쿼리를 수행하는 데 소요되는 총 시간을 측정하고 있습니다.

  • 테스트 스크립트를 실행하는 머신과의 네트워크 지연
  • 테스트 중인 네임서버의 처리 시간
  • 테스트 중인 네임서버가 다른 네임서버의 응답을 기다리는 데 소비하는 시간입니다. 재귀 하위 쿼리를 수행하는 데 걸리는 시간

결과는 예상과 거의 일치합니다.

  • 캐시를 플러시하지 않고 로컬 BIND 서버에 쿼리하면 대부분의 경우 응답은 캐시에서 나옵니다. A RR의 TTL이 만료된 경우에도 NS RR은 여전히 ​​캐시에 있으므로 A RR 자체만 외부에서 요청하면 됩니다.
  • 캐시를 플러시한 후 로컬 BIND 서버에 쿼리하고~ 아니다전달자가 구성된 경우 로컬 BIND 서버는 루트 서버부터 아래쪽으로 시작하여 재귀 쿼리를 수행합니다.
  • 캐시를 비운 후 로컬 BIND 서버에 쿼리하고 Google 서버를 전달자로 구성한 경우 로컬 BIND 서버는 쿼리를 있는 그대로 Google 서버 중 하나로 전달한 다음 Google 서버에서 해당 캐시의 쿼리에 응답하거나 재귀 쿼리를 수행합니다. 귀하는 Google 서버의 캐시를 제어할 수 없습니다.

결과적으로 캐시를 먼저 지우지 않고 로컬 BIND 서버에 대한 쿼리가 가장 빠르며 전달자 구성의 영향을 받지 않습니다. 캐시를 지운 후 전달자로 구성된 Google 서버를 사용하여 로컬 BIND 서버에 대한 쿼리는 로컬 BIND 서버를 먼저 통과하는 오버헤드를 후자에 추가하기 때문에 Google 서버에 대한 직접 쿼리보다 느립니다.

관련 정보