Re: What can make DNS lookups slow? [semi-solved]

• Previous message: Forrest Smith: "Re: Debian startup program question"
• In reply to: Chris Evans: "Re[2]: What can make DNS lookups slow? [semi-solved]"
• Next in thread: Chris Evans: "Re[2]: What can make DNS lookups slow? [semi-solved]"
• Reply: Chris Evans: "Re[2]: What can make DNS lookups slow? [semi-solved]"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sun, 16 Jan 2005 17:26:48 -0800
To: debian-user@lists.debian.org

Chris Evans wrote:

>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.
>
>
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.

>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.
>
>
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
resolve from.

>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.
>
>
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.

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
are SNATed.
       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
>>>>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.
>>>
>>>
I'm gonna come back to this.

>
>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.
>
>
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> 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 still don't understand how your firewall is blocking DNS REPLIES -
unless something is really messed up!

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?

Daniel

-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

• Previous message: Forrest Smith: "Re: Debian startup program question"
• In reply to: Chris Evans: "Re[2]: What can make DNS lookups slow? [semi-solved]"
• Next in thread: Chris Evans: "Re[2]: What can make DNS lookups slow? [semi-solved]"
• Reply: Chris Evans: "Re[2]: What can make DNS lookups slow? [semi-solved]"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]