Re: What can make DNS lookups slow? [semi-solved]
Chris Evans wrote:
I had a miserable time working my way through bind, djbdns, dnsmasq,
maradns, and powerdns - until I finally found some reference materials
and some support from the djbdns group. I may actually understand it
now! If you wanna try again let me know.
If there are wizards who know iptables, proxy arp, SNAT, DNAT and
perhaps shorewall who could spare time to read this, it may help
Daniel and I build the emerging FAQ here on what I think is probably
going to hit other people in the future....
Saturday, January 15, 2005, 11:26:22 PM, Daniel wrote:
DLM> I don't think I quite understand your setup - please help me out here.
DLM> You have a ADSL connection to the Internet. That connection is known to
DLM> your firewall as eth0.
DLM> You have a connection to your LAN - that connection is known to your
DLM> firewall as eth1.
DLM> And you have a connection to your server - that connection is known to
DLM> your firewall as eth2.
DLM> Is this correct?
DLM> If so . . .
DLM> In my unauthoritative opinion, this is how I would setup this network/DNS:
DLM> Underlying assumption - there is no physical connection between the
DLM> 192.168.1/24 and 192.168.2/24 subnets - other than at the firewall
DLM> machine. Second assumption - all Internet traffic passes through the
DLM> firewall machine.
DLM> A note: I use djbdns, not bind9. Not because I'm a fanatic for or
DLM> against either one - but I've had much better luck getting djbdns to
DLM> work in a predictable and understandable manner than bind. YMMV.
Understood. I tried djbdns and, though I'm not taken with bind
documentation, for some reason couldn't get djbdns working, hence bind
OK. Bind9 acts as both a caching server and an authoritative server. I
would setup DNS zones on your firewall server for each of your two
subnets, and have each of your interior computers (both subnets) look to
the firewall server. So you wind up with a single physical DNS server,
and via Bind9, a single (sort of) DNS process for all your computers to
DLM> 1. I'm assuming somewhere on your eth1/192.168.1.0 subnet you have a
DLM> server machine. There should be a DNS server that is authoritative for
DLM> this subnet.
No, only two machines in that network, both Windoze, no server and
static IP addresses set for the machines suffice.
DLM> 2. I'm inferring from your references to "server" that the
DLM> eth2/192.168.2.0 subnet has only one machine on it. You may or may not
DLM> want an authoritative DNS server for this subnet. I would just for
DLM> consistency - and will then be ready should you add backup machines.
Correct, again, my understanding was that its own /etc/hosts content
suffices here as it's the only machine here.
DLM> 3. On the firewall machine, there should be one or more caching DNS
DLM> servers - depending on whether or not your two subnets are allowed to
DLM> see each other. If they are, then just a single caching server that
DLM> looks to each of your subnet's authoritative servers along with your
DLM> ISP's servers. Then each of your internal machines - including the
DLM> firewall machine - should look to this one DNS server. If not - it gets
DLM> a little more complicated.
Here again - I have trouble, because I don't use shorewall! Not that
I'm trying to change the tools you've been using - but I've been using
firehol with great success. But since shorewall is also iptables based
- this shouldn't be TOO much of a problem. We may have to look a bit
more at your firewall config. I don't understand what you need NAT for
- in regards to DNS.
I would have liked to have done that, but the way that the ISP is
returning replies from its DNS servers makes this impossible. They
come back from various different private IP addresses (10.10.11.11 and
10.10.11.31 so far) and are routed to the mac address of the firewall
machine. BT assume I am not running NAT hence I guess they're in
their rights to do this but I am running NAT here and that means the
poor old firewall iptables, as far as I can see, can't know what to do
with these replies. I may be wrong about that, probably am, but can't
see how to instruct it that all replies from port 53 addresses should
be assumed to be replies to its own requests even if the requests went
out to different IP address than is sending back the response.
You have a firewall/DNS server directly connected to your ADSL on eth0.
That interface has an Internet IP. There should be nothing to NAT
here. Maybe you're doing something different - the basic premise my own
firewall operates on is:
1. Allow OUT anything from my internal network - outbound requests
1a. Allow IN anything specifically requested.
2. Allow IN via DNAT specific services - such as http, imap, etc.
3. Flatly block anything else.
Unless you need to allow inbound queries for DNS (and you haven't
indicated that) - NAT should have nothing to do with your DNS.
DLM> Now, routing on the firewall.
DLM>> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
126.96.36.199 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
188.8.131.52 0.0.0.0 255.255.255.248 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 184.108.40.206 0.0.0.0 UG 0 0 0 eth0
DLM>> route del 220.127.116.11
DLM>> that should kill the bogus eth2 entry.
Nothing bogus about that entry at all and I really don't want to
delete it but can confirm that the system has the same problems when I
do. That has to be there to route things to and from the
http/https/smtp server in the dmz beyond eth2. That is served
separately from the internal network which has no need to be visible
from the outside at all. This is a pretty standard three card
hardware firewall I believe and has worked fine for some years until
I'm gonna come back to this.
I don't know anything about proxy arp - maybe someone out there laughing
at us want's to chime in here? I use DNAT - never had a problem.
DLM> That doesn't make sense to me. Both your routing table and your
DLM> /etc/networks/interfaces show that eth2 is the 192.168.2.0 subnet.
DLM> There is nothing on that subnet that shows a 217.34.100 address. If you
DLM> have a machine on that subnet that needs to be reachable via that IP
DLM> address - that should be translated via the firewall machine. If,
DLM> however, you actually have access to the 217.34.100 subnet via eth2 -
DLM> then there should be a gateway entry in your routing table. Even if
DLM> there's only one machine in that subnet - I believe you should still
DLM> have a gateway entry. Otherwise you are showing two subnets on the
DLM> same interface - and I don't think that's right.
I may be wrong, I have a sense that there are people watching our
exchange with quiet amusement (well, would if they read this far) who
really know this stuff ... but ...
That server has to be addressable as 18.104.22.168 as I have the
domain psyctc.org (and several others) matched to this IP address:
;; AUTHORITY SECTION:
psyctc.org. 15186 IN NS ns0.intercityuk.com.
psyctc.org. 15186 IN NS ns0.blackcatnetworks.co.uk.
psyctc.org. 15186 IN NS ns1.blackcatnetworks.co.uk.
;; ADDITIONAL SECTION:
ns0.intercityuk.com. 83318 IN A 22.214.171.124
ns0.blackcatnetworks.co.uk. 21190 IN A 126.96.36.199
ns1.blackcatnetworks.co.uk. 21188 IN A 188.8.131.52
That has to be accessible from the outside world for http, https and
My understanding is that there are two ways of doing this on the
firewall: proxy arp, which I have used which uses mac addresses, and
SNAT. I simply went for proxy arp years ago when I first installed
the firewall machine and shorewall and it's always run fine. That
machine can get to the outside and v.v. I find it hard to believe
that the routing table is wrong.
I still don't understand how your firewall is blocking DNS REPLIES -
unless something is really messed up!
DLM> I just saw something. Please define "Proxy ARP Server". Is this
DLM> another Debian machine or something else? What DNS servers (ip
DLM> addresses) is this machine using?
Perhaps that was a bad term, I meant that server and that it is
"served" to the outside world for those three ports (http, https and
smtp only I think) by "proxy arp" which I believe means that any
package it sends to the firewall (and there's nowhere else it can send
anything) is passed on with the firewall putting the IP address and
the mac address of that machine, not its own eth0 mac address, on all
the packages it transfers. When a package comes back for that mac
address, the firewall knows to send it to that server. I think that's
different from NAT where the packages go out with the IP address and
mac address of the eth0 firewall interface and the kernel, through
iptables magic, works out where to send reply packages on the basis of
their IP address and what machine inside the firewall was talking to
that port and that IP address. That system is being messed up for the
firewall by my ISP's way of sending DNS replies.
I'm also concerned about something else you stated in your original post
- that just clicked. You said this config has been working fine - and
just started to have problems. What changed?