Nameserver performance (was: Re: Bind 9.1.3 stop resolving but is still running.)
Brad Knowles
brad.knowles at skynet.be
Sun Sep 9 21:15:42 UTC 2001
At 4:03 AM +0200 9/8/01, Brad Knowles wrote:
> However, when looking at authoritative answers, I've seen some
> pretty impressive numbers from a.root-servers.net and the nameservers
> for AOL -- 4000-5000 queries per second (65536 queries in something
> like 13 seconds), on real-world servers with real-world load, and
> across WAN connections.
I've been casting about, looking for other zones and servers I
can test. I've specifically been looking for a zone that is run on a
nameserver running tinydns. So, I start with looking at tinydns.org:
% dig tinydns.org. any
; <<>> DiG 9.1.2 <<>> tinydns.org. any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24458
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;tinydns.org. IN ANY
;; ANSWER SECTION:
tinydns.org. 170811 IN NS ANGEL.HEAVEN.NET.
tinydns.org. 170811 IN NS NS.CRYNWR.COM.
tinydns.org. 86063 IN A 192.203.178.19
;; AUTHORITY SECTION:
tinydns.org. 170811 IN NS ANGEL.HEAVEN.NET.
tinydns.org. 170811 IN NS NS.CRYNWR.COM.
;; ADDITIONAL SECTION:
ANGEL.HEAVEN.NET. 21308 IN A 198.69.28.2
NS.CRYNWR.COM. 116658 IN A 192.203.178.2
;; Query time: 2 msec
;; WHEN: Sun Sep 9 16:32:38 2001
;; MSG SIZE rcvd: 162
Checking out NS.CRYNWR.COM, it would seem reasonably likely that
they are running tinydns:
% dig @NS.CRYNWR.COM. version.bind chaos txt
; <<>> DiG 9.1.2 <<>> @NS.CRYNWR.COM. version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 8220
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; Query time: 238 msec
;; WHEN: Sun Sep 9 16:33:17 2001
;; MSG SIZE rcvd: 30
However, interestingly enough, it appears that ANGEL.HEAVEN.NET
might be running BIND:
% dig @ANGEL.HEAVEN.NET. version.bind chaos txt
; <<>> DiG 9.1.2 <<>> @ANGEL.HEAVEN.NET. version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32027
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
VERSION.BIND. 0 CH TXT "8.2.3-REL"
;; Query time: 21 msec
;; WHEN: Sun Sep 9 16:33:54 2001
;; MSG SIZE rcvd: 64
However, if NS.CRYNWR.COM is running tinydns, they appear to have
gone to extra effort to turn on support for TCP:
% dig @NS.CRYNWR.COM. tinydns.org. +vc
; <<>> DiG 9.1.2 <<>> @NS.CRYNWR.COM. tinydns.org. +vc
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9718
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;tinydns.org. IN A
;; ANSWER SECTION:
tinydns.org. 86400 IN A 192.203.178.19
;; AUTHORITY SECTION:
tinydns.org. 259200 IN NS angel.heaven.net.
tinydns.org. 259200 IN NS ns.crynwr.com.
;; ADDITIONAL SECTION:
ns.crynwr.com. 86400 IN A 192.203.178.2
;; Query time: 381 msec
;; WHEN: Sun Sep 9 16:34:35 2001
;; MSG SIZE rcvd: 118
And even zone transfers:
% dig @NS.CRYNWR.COM. tinydns.org. axfr
; <<>> DiG 9.1.2 <<>> @NS.CRYNWR.COM. tinydns.org. axfr
;; global options: printcmd
tinydns.org. 2560 IN SOA ns.crynwr.com.
hostmaster.tinydns.org. 971797267 16384 2048 1048576 2560
tinydns.org. 259200 IN NS angel.heaven.net.
tinydns.org. 259200 IN NS ns.crynwr.com.
tinydns.org. 86400 IN A 192.203.178.19
web.tinydns.org. 86400 IN A 192.203.178.19
www.tinydns.org. 86400 IN A 192.203.178.19
tinydns.org. 2560 IN SOA ns.crynwr.com.
hostmaster.tinydns.org. 971797267 16384 2048 1048576 2560
;; Query time: 1491 msec
;; WHEN: Sun Sep 9 16:35:27 2001
;; XFR size: 8 records
Interestingly, ANGEL.HEAVEN.NET allows TCP, but not zone transfers:
% dig @ANGEL.HEAVEN.NET. tinydns.org. +vc
; <<>> DiG 9.1.2 <<>> @ANGEL.HEAVEN.NET. tinydns.org. +vc
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4465
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;tinydns.org. IN A
;; ANSWER SECTION:
tinydns.org. 86400 IN A 192.203.178.19
;; AUTHORITY SECTION:
tinydns.org. 259200 IN NS angel.heaven.net.
tinydns.org. 259200 IN NS ns.crynwr.com.
;; ADDITIONAL SECTION:
angel.heaven.net. 86400 IN A 198.69.28.2
ns.crynwr.com. 86400 IN A 192.203.178.2
;; Query time: 32 msec
;; WHEN: Sun Sep 9 16:36:09 2001
;; MSG SIZE rcvd: 134
% dig @ANGEL.HEAVEN.NET. tinydns.org. axfr
; <<>> DiG 9.1.2 <<>> @ANGEL.HEAVEN.NET. tinydns.org. axfr
;; global options: printcmd
; Transfer failed.
I do note that ANGEL.HEAVEN.NET also appears to be a publicly
accessible recursive/caching nameserver:
% dig @ANGEL.HEAVEN.NET. stop.mail-abuse.org. any
; <<>> DiG 9.1.2 <<>> @ANGEL.HEAVEN.NET. stop.mail-abuse.org. any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1393
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;stop.mail-abuse.org. IN ANY
;; ANSWER SECTION:
stop.mail-abuse.org. 86400 IN MX 10 stop1.mail-abuse.org.
stop.mail-abuse.org. 86400 IN A 204.152.184.88
;; AUTHORITY SECTION:
mail-abuse.org. 86400 IN NS west1.mail-abuse.org.
mail-abuse.org. 86400 IN NS east1.mail-abuse.org.
mail-abuse.org. 86400 IN NS europe1.mail-abuse.org.
mail-abuse.org. 86400 IN NS ns-ext.vix.com.
;; ADDITIONAL SECTION:
stop1.mail-abuse.org. 86400 IN A 204.152.184.88
west1.mail-abuse.org. 86400 IN A 204.152.186.193
east1.mail-abuse.org. 86400 IN A 204.152.186.192
europe1.mail-abuse.org. 86400 IN A 204.152.186.195
ns-ext.vix.com. 3600 IN A 204.152.184.64
;; Query time: 123 msec
;; WHEN: Sun Sep 9 16:38:28 2001
;; MSG SIZE rcvd: 245
% dig @ANGEL.HEAVEN.NET. stop.mail-abuse.org. any
; <<>> DiG 9.1.2 <<>> @ANGEL.HEAVEN.NET. stop.mail-abuse.org. any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39043
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;stop.mail-abuse.org. IN ANY
;; ANSWER SECTION:
stop.mail-abuse.org. 86381 IN A 204.152.184.88
stop.mail-abuse.org. 86381 IN MX 10 stop1.mail-abuse.org.
;; AUTHORITY SECTION:
mail-abuse.org. 86381 IN NS west1.mail-abuse.org.
mail-abuse.org. 86381 IN NS east1.mail-abuse.org.
mail-abuse.org. 86381 IN NS europe1.mail-abuse.org.
mail-abuse.org. 86381 IN NS ns-ext.vix.com.
;; ADDITIONAL SECTION:
stop1.mail-abuse.org. 86381 IN A 204.152.184.88
west1.mail-abuse.org. 86381 IN A 204.152.186.193
east1.mail-abuse.org. 86381 IN A 204.152.186.192
europe1.mail-abuse.org. 86381 IN A 204.152.186.195
ns-ext.vix.com. 172776 IN A 204.152.184.64
;; Query time: 34 msec
;; WHEN: Sun Sep 9 16:38:47 2001
;; MSG SIZE rcvd: 245
To give me further proof that NS.CRYNWR.COM is running tinydns, I
tried asking it a question that it should not be authoritative for
(by default, tinydns does not hand out referrals):
% dig @ns.crynwr.com. stop.mail-abuse.org. any
; <<>> DiG 9.1.2 <<>> @ns.crynwr.com. stop.mail-abuse.org. any
;; global options: printcmd
;; connection timed out; no servers could be reached
To try and make sure that this wasn't an issue of my query being
lost, I bracketed a "normal" query with two "bad" queries:
dig @ns.crynwr.com. stop.mail-abuse.org. any; dig @ns.crynwr.com.
ns.crynwr.com. any; dig @ns.crynwr.com. stop.mail-abuse.org. any
; <<>> DiG 9.1.2 <<>> @ns.crynwr.com. stop.mail-abuse.org. any
;; global options: printcmd
;; connection timed out; no servers could be reached
; <<>> DiG 9.1.2 <<>> @ns.crynwr.com. ns.crynwr.com. any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10275
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 1
;; QUESTION SECTION:
;ns.crynwr.com. IN ANY
;; ANSWER SECTION:
ns.crynwr.com. 86400 IN MX 12801 pdam.crynwr.com.
ns.crynwr.com. 86400 IN MX 12816 pdam.crynwr.com.
ns.crynwr.com. 86400 IN A 192.203.178.2
;; AUTHORITY SECTION:
crynwr.com. 259200 IN NS angel.heaven.net.
crynwr.com. 259200 IN NS asylum.sf.ca.us.
crynwr.com. 259200 IN NS ns.crynwr.com.
;; ADDITIONAL SECTION:
pdam.crynwr.com. 86400 IN A 192.203.178.8
;; Query time: 245 msec
;; WHEN: Sun Sep 9 16:43:23 2001
;; MSG SIZE rcvd: 173
; <<>> DiG 9.1.2 <<>> @ns.crynwr.com. stop.mail-abuse.org. any
;; global options: printcmd
;; connection timed out; no servers could be reached
Now, I wanted to create a test zone, but I had to make sure that
it was appropriately sized. So, I needed to know how much IP address
space was delegated to NS.CRYNWR.COM:
% dig -x 192.203.178.2
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56803
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;2.178.203.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
2.178.203.192.in-addr.arpa. 84729 IN PTR ns.crynwr.com.
;; AUTHORITY SECTION:
178.203.192.in-addr.arpa. 257529 IN NS angel.heaven.net.
178.203.192.in-addr.arpa. 257529 IN NS asylum.sf.ca.us.
178.203.192.in-addr.arpa. 257529 IN NS ns.crynwr.com.
;; ADDITIONAL SECTION:
angel.heaven.net. 14515 IN A 198.69.28.2
asylum.sf.ca.us. 433071 IN A 192.48.232.17
ns.crynwr.com. 94607 IN A 192.203.178.2
;; Query time: 2 msec
;; WHEN: Sun Sep 9 16:40:04 2001
;; MSG SIZE rcvd: 192
So, I created a file with the IP addresses
0.178.203.192.in-addr.arpa through 255.178.203.192.in-addr.arpa
listed 256 times (so that I'd have 65536 queries), and fired this at
NS.CRYNWR.COM:
% queryperf -d testrev -s ns.crynwr.com.
DNS Query Performance Testing Tool
Version: $Id: queryperf.c,v 1.1.1.2 2001/07/18 23:33:04 gson Exp $
[Status] Processing input data
[Status] Sending queries
[Timeout] Query timed out: msg id 25301
[Timeout] Query timed out: msg id 25300
[ ... deletia ... ]
[Timeout] Query timed out: msg id 34052
[Timeout] Query timed out: msg id 49271
[Status] Testing complete
Statistics:
Parse input file: once
Ended due to: reaching end of file
Queries sent: 65536 queries
Queries completed: 65403 queries
Queries lost: 133 queries
Percentage completed: 99.80%
Percentage lost: 0.20%
Started at: Sun Sep 9 16:23:04 2001
Finished at: Sun Sep 9 16:39:15 2001
Ran for: 970.673198 seconds
Queries per second: 67.379011 qps
Now, it just so happens that angel.heaven.net has an equal size
network assigned to it:
% dig -x 198.69.28.2
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1782
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;2.28.69.198.in-addr.arpa. IN PTR
;; ANSWER SECTION:
2.28.69.198.in-addr.arpa. 86400 IN PTR angel.heaven.net.
;; AUTHORITY SECTION:
28.69.198.in-addr.arpa. 86400 IN NS angel.heaven.net.
28.69.198.in-addr.arpa. 86400 IN NS ns1-auth.sprintlink.net.
28.69.198.in-addr.arpa. 86400 IN NS ns2-auth.sprintlink.net.
28.69.198.in-addr.arpa. 86400 IN NS ns3-auth.sprintlink.net.
;; ADDITIONAL SECTION:
angel.heaven.net. 86400 IN A 198.69.28.2
ns1-auth.sprintlink.net. 86400 IN A 206.228.179.10
ns2-auth.sprintlink.net. 86400 IN A 144.228.254.10
ns3-auth.sprintlink.net. 86400 IN A 144.228.255.10
;; Query time: 11 msec
;; WHEN: Sun Sep 9 16:46:41 2001
;; MSG SIZE rcvd: 230
So, I aimed a similar sized test at it, but for the /24 network
belonging to it instead:
% queryperf -d testrev -s angel.heaven.net
DNS Query Performance Testing Tool
Version: $Id: queryperf.c,v 1.1.1.2 2001/07/18 23:33:04 gson Exp $
[Status] Processing input data
[Status] Sending queries
[Status] Testing complete
Statistics:
Parse input file: once
Ended due to: reaching end of file
Queries sent: 65536 queries
Queries completed: 65536 queries
Queries lost: 0 queries
Percentage completed: 100.00%
Percentage lost: 0.00%
Started at: Sun Sep 9 16:50:38 2001
Finished at: Sun Sep 9 16:54:22 2001
Ran for: 224.851566 seconds
Queries per second: 291.463391 qps
Fascinating. Not a query dropped, and more than four times as
fast. Of course, we don't know anything about these two machines --
NS.CRYNWR.COM might be an ancient 486 running NetBSD 1.2 from 1996,
while ANGEL.HEAVEN.NET might be a twelve processor HP V-Class server
capable of handling tens of thousands of DNS queries per second (or
whatever). In addition, the server where I ran these tests could be
very close to ANGEL.HEAVEN.NET (and/or across relatively few
high-speed/low-latency/low-congestion links) and very far away from
NS.CRYNWR.COM (and/or across a lot of
low-speed/high-latency/high-congestion links).
Hmm, let's try aiming the test set for NS.CRYNWR.COM at
ANGEL.HEAVEN.NET, and see how well it copes with caching data very
fast:
% queryperf -d testrev -s angel.heaven.net
DNS Query Performance Testing Tool
Version: $Id: queryperf.c,v 1.1.1.2 2001/07/18 23:33:04 gson Exp $
[Status] Processing input data
[Status] Sending queries
[Status] Testing complete
Statistics:
Parse input file: once
Ended due to: reaching end of file
Queries sent: 65536 queries
Queries completed: 65536 queries
Queries lost: 0 queries
Percentage completed: 100.00%
Percentage lost: 0.00%
Started at: Sun Sep 9 17:02:04 2001
Finished at: Sun Sep 9 17:05:27 2001
Ran for: 202.430245 seconds
Queries per second: 323.746088 qps
Holy Toledo! It's actually *faster* answering out of cache!?!
Could the load on this machine changed so quickly (to explain the
cost differential of having to go get the information the first time
and then provide those answers for the other 255 queries)?!?
Okay, so this is a completely and totally unscientific test. No
one anywhere is going to argue with that statement. But I still find
it very interesting that by *far* the fastest nameserver for the
tinydns.org domain is one that is running BIND 8, and moreover is a
public recursive/caching nameserver to boot.
It seems to me that if the tinydns crowd really want to be able
to prove their claim that tinydns is faster and better than BIND,
they'd want to put up a number of publicly accessible/abuse-able
tinydns nameservers that are as fast as they can possibly make them,
and then invite people to run their own benchmarks across the public
Internet.
Now, to find some BIND 9 servers, and see how fast they are....
--
Brad Knowles, <brad.knowles at skynet.be>
H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA
More information about the bind-users
mailing list