Re: Different answer when querying @server from different clients
On 3/6/2015 4:52 PM, bind-users-requ...@lists.isc.org wrote: I don't think it is views. The same thing happens against Google's public DNS. The two hosts route to the Internet differently and that seems to at the root of the issue somehow. [root@dc01 ~]# dig +short ns1.mediture.com 74.113.249.135 [root@dc01 ~]# dig +short ns2.mediture.com 107.23.33.118 [root@dc01 ~]# dig @8.8.8.8 +trace great.truchart.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.1 <<>> @8.8.8.8 +trace great.truchart.com ; (1 server found) ;; global options: +cmd . 18851 IN NS h.root-servers.net. . 18851 IN NS c.root-servers.net. . 18851 IN NS f.root-servers.net. . 18851 IN NS k.root-servers.net. . 18851 IN NS j.root-servers.net. . 18851 IN NS m.root-servers.net. . 18851 IN NS l.root-servers.net. . 18851 IN NS a.root-servers.net. . 18851 IN NS g.root-servers.net. . 18851 IN NS e.root-servers.net. . 18851 IN NS b.root-servers.net. . 18851 IN NS i.root-servers.net. . 18851 IN NS d.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 144 ms com.172800 IN NS j.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. ;; Received 496 bytes from 192.228.79.201#53(192.228.79.201) in 146 ms truchart.com. 172800 IN NS ns1.mediture.com. truchart.com. 172800 IN NS ns2.mediture.com. ;; Received 113 bytes from 192.52.178.30#53(192.52.178.30) in 129 ms great.truchart.com. 3600IN A 192.168.168.225 truchart.com. 86400 IN NS ns1.mediture.com. truchart.com. 86400 IN NS ns2.mediture.com. ;; Received 129 bytes from 107.23.33.118#53(107.23.33.118) in 31 ms [root@www02 ~]# dig @8.8.8.8 +trace great.truchart.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @8.8.8.8 +trace great.truchart.com ; (1 server found) ;; global options: +cmd . 18813 IN NS h.root-servers.net. . 18813 IN NS c.root-servers.net. . 18813 IN NS f.root-servers.net. . 18813 IN NS k.root-servers.net. . 18813 IN NS j.root-servers.net. . 18813 IN NS m.root-servers.net. . 18813 IN NS l.root-servers.net. . 18813 IN NS a.root-servers.net. . 18813 IN NS g.root-servers.net. . 18813 IN NS e.root-servers.net. . 18813 IN NS b.root-servers.net. . 18813 IN NS i.root-servers.net. . 18813 IN NS d.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 94 ms com.172800 IN NS f.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. ;; Received 508 bytes from 192.58.128.30#53(192.58.128.30) in 220 ms
Re: Different answer when querying @server from different clients
On 8 March 2015 at 13:50, Barry S. Finkel wrote: > Using "+trace" with "@8.8.8.8" ignores the "@8.8.8.8", as > that server is never queried when the query starts at the root > and moves down the DNS tree to authorized servers. Incorrect, specifying @8.8.8.8 means that dig +trace will use 8.8.8.8 to find the root servers and then continue to query the authoritative nameservers directly for any subsequent queries. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.10 IPv6 performance
Hi,
I'm doing some performance tests on some modern Haswell CPU machines (20
cores) using Ubuntu Linux 14.04 (Kernel 3.13.0-46-generic) using BIND
9.10.1-P2 compiled with "--with-tuning=large".
With using 8 worker threads I get near 400K QPS via IPv4 UDP (from a hot
cache without resolving), which is a good. CPU utilization as seen by
"top" is near 800%, as expected (8 cores fully used).
When I switch BIND 9 to listen on IPv6 only, the performance drops to
less than 60K QPS.
When I run the tests using Unbound (same machine, same OS, 8 threads), I
do not see a significant difference between the IPv4 and IPv6
performance, which should rule out an issue in the kernel or with the
DNS load generation.
Testing with 9.9.6-P2 shows a similar pattern.
The configuration is simple:
options {
directory "/var/named";
listen-on { none; };
listen-on-v6 { any; };
recursive-clients 1;
tcp-clients 1000;
allow-recursion { 2001:db8::/48; };
};
zone "." {
type hint;
file "root.hint";
};
Has anyone seen such an performance drop on IPv6?
Carsten
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
BIND9 statistics vs. BIND8 statistics
Hello, In BIND8, I can find statistics every hour in the log file (see here below) It was the default for BIND8 But in BIND9 I do not find same statistics in the log file. I know statistics-channels usage in named.conf or rndc stats with dump statistics file I define with statistics-file statement. I am curious why statistics every hour is not default in BIND9 Does BIND9 have performance issue or something else? Oct 31 07:11:37 dnszone001 named[19854]: NSTATS 1320041497 1301566457 TYPE0=50862 A=1764510765 NS=24977921 CNAME=5164425 SOA=8419048 MG=1 MR=1000 NULL=1 WKS=43 PTR=121163683 HINFO=16119 MINFO=3 MX=497037649 TXT=46163614 RP=3 X25=7 ISDN=2 RT=1 SIG=1 KEY=9 PX=24 =450246677 LOC=117 NXT=1 SRV=14855440 NAPTR=42769 A6=14181975 SINK=1 TYPE43=32907 TYPE46=3100 TYPE47=2864 TYPE48=85413 TYPE51=676 TYPE55=8 TYPE69=1 TYPE72=1 TYPE99=14892632 TKEY=85936 IXFR=2583 AXFR=301179 MAILB=7 ANY=37471162 Thank you in advance for your help. Dowon Kim, ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
