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

• Previous message: Paolo Alexis Falcone: "Re: How to debug a PCMCIA modem"
• In reply to: Chris Evans: "Re[3]: 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: Sat, 15 Jan 2005 15:26:22 -0800
To: debian-user@lists.debian.org

I don't think I quite understand your setup - please help me out here.

You have a ADSL connection to the Internet. That connection is known to
your firewall as eth0.
You have a connection to your LAN - that connection is known to your
firewall as eth1.
And you have a connection to your server - that connection is known to
your firewall as eth2.

Is this correct?

If so . . .

In my unauthoritative opinion, this is how I would setup this network/DNS:

Underlying assumption - there is no physical connection between the
192.168.1/24 and 192.168.2/24 subnets - other than at the firewall
machine. Second assumption - all Internet traffic passes through the
firewall machine.

A note: I use djbdns, not bind9. Not because I'm a fanatic for or
against either one - but I've had much better luck getting djbdns to
work in a predictable and understandable manner than bind. YMMV.

1. I'm assuming somewhere on your eth1/192.168.1.0 subnet you have a
server machine. There should be a DNS server that is authoritative for
this subnet.
2. I'm inferring from your references to "server" that the
eth2/192.168.2.0 subnet has only one machine on it. You may or may not
want an authoritative DNS server for this subnet. I would just for
consistency - and will then be ready should you add backup machines.
3. On the firewall machine, there should be one or more caching DNS
servers - depending on whether or not your two subnets are allowed to
see each other. If they are, then just a single caching server that
looks to each of your subnet's authoritative servers along with your
ISP's servers. Then each of your internal machines - including the
firewall machine - should look to this one DNS server. If not - it gets
a little more complicated.

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.

That doesn't make sense to me. Both your routing table and your
/etc/networks/interfaces show that eth2 is the 192.168.2.0 subnet.
There is nothing on that subnet that shows a 217.34.100 address. If you
have a machine on that subnet that needs to be reachable via that IP
address - that should be translated via the firewall machine. If,
however, you actually have access to the 217.34.100 subnet via eth2 -
then there should be a gateway entry in your routing table. Even if
there's only one machine in that subnet - I believe you should still
have a gateway entry. Otherwise you are showing two subnets on the
same interface - and I don't think that's right.

Chris Evans wrote:

>Huge thanks to those who have helped on this who may find this
>interesting, and to those who have put up with the bandwidth. I put
>all this to the list because increasingly I find that linux/debian
>documentation is either so out of date, so incomplete, or so much
>written by experts for experts, that I come to debug things from
>searches of list archives.
>
>
You are helping to write the documentation by generating these posts.

>My problem was that DNS lookups from and through my debian firewall
>out through my ADSL router to my ISP's DNS servers were slow,
>sometimes cripplingly slow. Lookups from my proxy arp server in a dmz
>but which goes through the same firewall seemed to be fine.
>
>
I just saw something. Please define "Proxy ARP Server". Is this
another Debian machine or something else? What DNS servers (ip
addresses) is this machine using?

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

• Previous message: Paolo Alexis Falcone: "Re: How to debug a PCMCIA modem"
• In reply to: Chris Evans: "Re[3]: 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 ]