DNS 재귀 바인딩 속도가 느림


9

최신 Bind 9.10 릴리스를 사용하여 재귀 DNS 서버를 설정했습니다.

우리는 재귀 DNS 조회가 상당히 느리다는 것을 발견했습니다. 1 ~ 3 초 조회가 캐시에 있으면 DNS는 예상대로 밀리 초 안에 해결됩니다.

우리는 재귀 적 조회를 위해 ROOT 힌트를 사용하고 있으며 이것이 느려진 곳 인 것처럼 보입니다. 전달자를 구성하면 DNS 확인은 100-300ms의 재귀 시간으로 나타납니다.

우리가 설정하는 서비스의 경우 전달자에 의존하고 싶지 않으므로 루트 힌트를 사용하는 것이 좋습니다.

다음은 named.conf 파일 의 기본 구성입니다 . 성능 향상에 도움이되는 내용이 있으면 좋을 것입니다.

options{
allow-recursion  { any; };
allow-query-cache  { any; };
allow-query  { any; };

listen-on  port 53  { any; };
listen-on-v6  port 53  { any; };

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

zone-statistics yes;
max-cache-ttl 3600;
max-ncache-ttl 3600;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";

directory  "/var/named";
dump-file  "/var/named/data/cache_dump.db";
statistics-file  "/var/named/stats/named_stats.txt";
memstatistics-file  "/var/named/stats/named_mem_stats.txt";

rate-limit {
    responses-per-second 10;
    log-only yes;
};

prefetch 5;};

zone "." {
type hint;
file "named.ca";};

include "/var/named/conf/logging.conf";

5
tcpdump를 사용하고 느린 요청 중에 실제로 무슨 일이 일어나고 있는지 확인합니다.
yoonix

로그에 아무것도 없습니까?
Håkan Lindqvist

답변:


6

문제를 발견했습니다. NIC 하드웨어 오프로드 문제였습니다.

Running 은 각 DNS 쿼리에 대해 tcpdump -vvv -s 0 -l -n port 53몇 가지 [bad udp cksum 6279!]오류를 발견했습니다 .

Google을 조금만 탐색하면 올바른 방향으로 나를 가리 켰습니다. XenServer에서 VM으로 실행되는 CentOS 시스템 (VMWare 등에서보고 된 유사한 문제)으로 인해 NIC 하드웨어 오프로드가 기본적으로 활성화되어 있습니다.

달리는 ethtool -k eth0 | grep on것은 다음을 보여 주었다

x-checksumming: on
tx-checksum-ipv4: on
scatter-gather: on
tx-scatter-gather: on
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off
tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
tx-gso-robust: on [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]

ethtool -K eth0 tx off rx off비활성화 된 TCP TX 오프 로딩을 실행 중 입니다. 좋은 측정을 위해 네트워킹 서비스를 다시 시작했습니다.

service network restart

BIND를 테스트했습니다. 우리는 지금 BIND로부터 매우 빠른 응답 시간을 받고 있습니다

dig centos.org

; <<>> DiG 9.10.2-P4-RedHat-9.10.2-P4.el6 <<>> centos.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61933
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;centos.org.INA

;; ANSWER SECTION:
centos.org.60INA85.12.30.227

;; Query time: 268 msec
;; SERVER: 192.168.10.25#53(192.168.10.25)
;; WHEN: Thu Sep 17 08:25:39 AEST 2015
;; MSG SIZE  rcvd: 55

2

물리적 CentOS 7 BIND 서버에서 매우 느린 재귀 쿼리와 동일한 문제가 발생하여 다양한 스레드 주변 에서이 답변 (TX Offloading)과 많은 IPv6 지향 수정 사항을 찾았습니다.

문제의 서버 위치에 이전 Cisco ASA 방화벽이있어 UDP 응답 패킷의 크기를 512 바이트로 제한하는 것으로 나타났습니다. 요즘 DNS 쿼리에 대한 UDP 응답은 최대 약 2000 바이트까지 훨씬 더 큽니다. 여기에 대한 페이지가 있습니다.

UDP를 통한 DNS에 512 바이트 제한이있는 이유는 무엇입니까?

이 문제를 해결 한 더 큰 UDP 응답 패킷 (특정 수정 명령이 있음)을 허용하도록 ASA를 구성했습니다.

https://supportforums.cisco.com/t5/getting-started-with-lans/dns-dropped-because-packets-to-big-for-configured-512/td-p/861718

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.