nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Slow BIND performance

oscarBravo

I'm running a couple of BIND9 nameservers, to act as both caching DNS servers for the networks behind them and to be authorative for some domains. I've noticed that they are quite slow in resolving names that are not already cached. For example:

[root@piglet etc]# time dig +trace isc.org

; <<>> DiG 9.2.4 <<>> +trace isc.org
;; global options:  printcmd
.                       359014  IN      NS      j.root-servers.net.
.                       359014  IN      NS      k.root-servers.net.
.                       359014  IN      NS      l.root-servers.net.
.                       359014  IN      NS      m.root-servers.net.
.                       359014  IN      NS      a.root-servers.net.
.                       359014  IN      NS      b.root-servers.net.
.                       359014  IN      NS      c.root-servers.net.
.                       359014  IN      NS      d.root-servers.net.
.                       359014  IN      NS      e.root-servers.net.
.                       359014  IN      NS      f.root-servers.net.
.                       359014  IN      NS      g.root-servers.net.
.                       359014  IN      NS      h.root-servers.net.
.                       359014  IN      NS      i.root-servers.net.
;; Received 436 bytes from 127.0.0.1#53(127.0.0.1) in 3 ms

org.                    172800  IN      NS      TLD1.ULTRADNS.NET.
org.                    172800  IN      NS      TLD2.ULTRADNS.NET.
org.                    172800  IN      NS      TLD3.ULTRADNS.org.
org.                    172800  IN      NS      TLD4.ULTRADNS.org.
org.                    172800  IN      NS      TLD5.ULTRADNS.INFO.
org.                    172800  IN      NS      TLD6.ULTRADNS.CO.UK.
;; Received 283 bytes from 192.58.128.30#53(j.root-servers.net) in 125 ms

isc.org.                86400   IN      NS      ns-ext.sth1.isc.org.
isc.org.                86400   IN      NS      ns-ext.nrt1.isc.org.
isc.org.                86400   IN      NS      ns-ext.lga1.isc.org.
isc.org.                86400   IN      NS      ns-ext.isc.org.
;; Received 188 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 104 ms

isc.org.                3600    IN      A       204.152.184.88
isc.org.                3600    IN      NS      ns-ext.sth1.isc.org.
isc.org.                3600    IN      NS      ns-ext.isc.org.
isc.org.                3600    IN      NS      ns-ext.lga1.isc.org.
isc.org.                3600    IN      NS      ns-ext.nrt1.isc.org.
;; Received 232 bytes from 192.228.89.19#53(ns-ext.sth1.isc.org) in 8243 ms


real    0m14.991s
user    0m0.015s
sys     0m0.025s
[root@piglet etc]#

The first couple of steps go quite briskly, but notice the time on the last query: 8.2 seconds. The next time I look this up, it returns a reply instantly from the cache.

Any idea what I can do to make this process quicker?

Find more posts tagged with

Quick Links

Comments

oscarBravo

Digging ('scuse the pun) a little further: I notice that when I follow that query with one to (say) ftp.isc.org, the response is very quick, even though it isn't cached. I'm led to suspect that the problem is with the authoritative nameservers for the isc.org domain - the list of servers returned are all specified as domain names, and all are in the isc.org domain. But I don't have IP addresses yet for isc.org! What does BIND do in this situation, and why does it take so long?

niallb

Have you tried disabling ipv6 lookups?
The command line option -4 tells bind9
to only do ipv4 lookups, and sped things up a lot for me.

Debian puts this in /etc/default/bind9:
OPTIONS="-4 -u bind"

Hope that helps,
NiallB

oscarBravo

Not an option in this version of bind (9.2.4), unfortunately.

niallb

oscarBravo wrote:

Not an option in this version of bind (9.2.4), unfortunately.

If upgrading to 9.3 is not an option,
and you're not using ipv6 for anything,
you could try disabling ipv6 in the kernel.

The easiest way is to look for the module aliases and change
alias net-pf-10 ipv6 to alias net-pf-10 off

Debian and similar use the file /etc/modprobe.d/aliases for this.

Alternatively you might be able to roll back to 9.2.3,
as a 4-6 second delay due to ipv6 resolution is a known
bug in 9.2.4.

What distributions or operating systems are involved?

Good luck,
NiallB

bminish

niallb wrote:

The easiest way is to look for the module aliases and change
alias net-pf-10 ipv6 to alias net-pf-10 off

What distributions or operating systems are involved?

Thanks, that did the trick nicely.
BTW it's Centos 4.2

Myself and oscarBravo are both minding the same box