Re[2]: What can make DNS lookups slow? [semi-solved]
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?
Yes.
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.
Correct
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
now.
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.
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.
DLM> Now, routing on the firewall.
DLM>> route -n
>>>Kernel IP routing table
>>>Destination Gateway Genmask Flags Metric Ref Use Iface
>>>217.34.100.194 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
>>>217.34.100.192 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 217.34.100.198 0.0.0.0 UG 0 0 0 eth0
>>>
>>>
DLM>> execute:
DLM>> route del 217.34.100.194
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
>>recently.
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 217.34.100.194 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 195.82.119.192
> ns0.blackcatnetworks.co.uk. 21190 IN A 193.201.200.34
> ns1.blackcatnetworks.co.uk. 21188 IN A 69.55.225.40
That has to be accessible from the outside world for http, https and
smtp.
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.
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.
Let me know if this makes any more sense. For now, I have a slightly
slow DNS system that just about works and another "just about": I'm
just about out of time for this and have to return to my main job for
a week or so with fingers crossed!!
Yuck!
C
Reply to: