LAN configured by DHCP

I have a LAN with and a gateway running Linux acting as a Firewall and
NAT, it acts as a dhcp server as well. My question is about what are
the differences or what is better, configure the dhcp server to
configure the clients with the "public" dns server (the one that my
ISP provides), or to configure a DNS server in the machine that acts
as a gateway and configure the DNS of the other machines with the
gateway machine adress?

Thanks

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Camps wrote:
| I have a LAN with and a gateway running Linux acting as a Firewall and
| NAT, it acts as a dhcp server as well. My question is about what are
| the differences or what is better, configure the dhcp server to
| configure the clients with the "public" dns server (the one that my
| ISP provides), or to configure a DNS server in the machine that acts
| as a gateway and configure the DNS of the other machines with the
| gateway machine adress?

Originally DNS was designed on the assumption that all DNS servers
have the same "view" of the DNS. So in a logical sense caching DNS
servers should be fungible (I love that word), so the only criteria
are technical consideration such as performance, reliability etc.

Obviously if your DNS servers have specific information about your
network not in the public "view" of the DNS, you only want to list
your DNS servers. i.e. only ever list DNS servers with a consistent
"view" of the DNS in resolv.conf. Never for example include an ISP
nameserver in resolv.conf "just in case", if the local DNS has extra
info that matters, because you really can't guarantee much about how
and in which order clients query DNS servers.

In general it is advisable to list more than one DNS server, in case
that service stops. So unless there is a specific reason not to
(i.e. one has private information the other doesn't) I'd list my
gateway machine, and one (or possibly two) of the ISPs DNS servers.

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFBrkLvGFXfHI9FVgYRAhHlAJ9lrB0zkqqQ64K0C9CwEN zK4x2NHACgt04U
39MbaXr+RWdnfsDlPBlIQac=
=0FiM
-----END PGP SIGNATURE-----

> I have a LAN with and a gateway running Linux acting as a Firewall and
> NAT, it acts as a dhcp server as well. My question is about what are
> the differences or what is better, configure the dhcp server to
> configure the clients with the "public" dns server (the one that my
> ISP provides), or to configure a DNS server in the machine that acts
> as a gateway and configure the DNS of the other machines with the
> gateway machine adress?

I recommend you use dnsmasq as both your DHCP and DNS server and then tell
your clients to use the gateway for DNS.
This way you can give local names to your machines,


Stefan

> I have a LAN with and a gateway running Linux acting as a Firewall and
> NAT, it acts as a dhcp server as well. My question is about what are
> the differences or what is better, configure the dhcp server to
> configure the clients with the "public" dns server (the one that my
> ISP provides), or to configure a DNS server in the machine that acts
> as a gateway and configure the DNS of the other machines with the
> gateway machine adress?

Much of the decision depends on the bandwidth and latency of your
connection to your ISP, and the reliability of the ISP's name server. If
you have a low-latency pipe with bandwidth to spare, and you trust your ISP
to keep a reliable name server, then go ahead and have your clients use the
ISP's name server if that suits your fancy.

If, on the other hand, you have a congested or high-latency connection to
the ISP, or you don't trust your ISP to keep the name servers running and/or
properly configured, then go ahead and run your own caching name server.

On a security note, remember that a compromised name server is an
incredibly powerful tool, allowing a hacker to redirect traffic to important
sites to one of their choosing. Take that into account both in determining
whether you trust your ISP's name server, and whether you trust yourself in
administering a name server.

steve

Stefan Monnier wrote:
>>I have a LAN with and a gateway running Linux acting as a Firewall and
>>NAT, it acts as a dhcp server as well. My question is about what are
>>the differences or what is better, configure the dhcp server to
>>configure the clients with the "public" dns server (the one that my
>>ISP provides), or to configure a DNS server in the machine that acts
>>as a gateway and configure the DNS of the other machines with the
>>gateway machine adress?
>
>
> I recommend you use dnsmasq as both your DHCP and DNS server and then tell
> your clients to use the gateway for DNS.
> This way you can give local names to your machines,
>
>
> Stefan

Another vote to dnsmasq.

Stay away from bind - it's too heavy for this kind of work.

--

Tauno Voipio
tauno voipio (at) iki fi

> On a security note, remember that a compromised name server is an
> incredibly powerful tool, allowing a hacker to redirect traffic to
important
> sites to one of their choosing. Take that into account both in
determining
> whether you trust your ISP's name server, and whether you trust yourself
in
> administering a name server.

Not to mention when you trust your ISPs DNS server you open yourself up to
being mislead even if the DNS server isn't compromised. This is especially
easy to do in most cable-modem networks because the entire neighborhood is
on "broadcast" where everyone in the neighborhood sees all the traffic from
each other. Here's a scenario, your neighbor has his box set up to listen
for your dns requests going out. When his box sees your request go out it
crafts a response that looks like it is coming from the DNS server feeding
it a bogus IP, thus redirecting your computer to the wrong IP.

What advantage does dnsmasq have when coming down to this type of attack?
None. dnsmasq still requests DNS info from your ISP's DNS servers. As will
any other DNS cache/forwarder.

So if you don't trust your ISPs DNS, where will dnsmasq get it's DNS from?
Just pull it out of empty ethernet?

> Not to mention when you trust your ISPs DNS server you open yourself up to
> being mislead even if the DNS server isn't compromised. This is
especially
> easy to do in most cable-modem networks because the entire neighborhood is
> on "broadcast" where everyone in the neighborhood sees all the traffic
from
> each other. Here's a scenario, your neighbor has his box set up to listen
> for your dns requests going out. When his box sees your request go out it
> crafts a response that looks like it is coming from the DNS server feeding
> it a bogus IP, thus redirecting your computer to the wrong IP.
>
> What advantage does dnsmasq have when coming down to this type of attack?
> None. dnsmasq still requests DNS info from your ISP's DNS servers. As
will
> any other DNS cache/forwarder.
>
> So if you don't trust your ISPs DNS, where will dnsmasq get it's DNS from?
> Just pull it out of empty ethernet?

In a hostile network (like your aforementioned cable-modem network), it's
hard to trust much of anything. They can impersonate the root name servers
(to which your cache will look when resolving) just as easily as they can
impersonate your ISP's name servers.

steve

> > So if you don't trust your ISPs DNS, where will dnsmasq get it's DNS
from?
> > Just pull it out of empty ethernet?
>
> In a hostile network (like your aforementioned cable-modem network),
it's
> hard to trust much of anything. They can impersonate the root name
servers
> (to which your cache will look when resolving) just as easily as they can
> impersonate your ISP's name servers.

That was my point.

You said:

>>
On a security note, remember that a compromised name server is an
incredibly powerful tool, allowing a hacker to redirect traffic to important
sites to one of their choosing. Take that into account both in determining
whether you trust your ISP's name server, and whether you trust yourself in
administering a name server.
<<

But it doesn't matter if you trust yourself or your ISPs name server.
Whether they are compromised or not and whether you run your own DNS or not
you can still be dns spoofed. So your statement doesn't make a lot of
sense.