Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #185812 > unrolled thread

Re: DHCP server that itself gets an IP address by DHCP

Back to article view | Back to linux.debian.user

Contents

  Re: DHCP server that itself gets an IP address by DHCP Reco <recoverym4n@gmail.com> - 2017-08-24 11:40 +0200
    threading, was Re: DHCP server that itself gets an IP address by DHCP David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 15:30 +0200
      Re: threading, was Re: DHCP server that itself gets an IP address  by DHCP Reco <recoverym4n@gmail.com> - 2017-08-24 17:10 +0200
    Re: DHCP server that itself gets an IP address by DHCP Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-08-24 22:30 +0200
      Re: DHCP server that itself gets an IP address by DHCP Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-24 22:40 +0200
        Re: DHCP server that itself gets an IP address by DHCP Mark Fletcher <mark27q1@gmail.com> - 2017-08-25 00:40 +0200
          Re: DHCP server that itself gets an IP address by DHCP Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-25 14:20 +0200
            Re: DHCP server that itself gets an IP address by DHCP Mark Fletcher <mark27q1@gmail.com> - 2017-08-25 15:20 +0200
              Re: DHCP server that itself gets an IP address by DHCP Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-25 16:00 +0200
      Re: DHCP server that itself gets an IP address by DHCP Reco <recoverym4n@gmail.com> - 2017-08-24 22:40 +0200
        Re: DHCP server that itself gets an IP address by DHCP Mark Fletcher <mark27q1@gmail.com> - 2017-08-25 00:30 +0200
          Re: DHCP server that itself gets an IP address by DHCP Reco <recoverym4n@gmail.com> - 2017-08-25 10:20 +0200
          Re: DHCP server that itself gets an IP address by DHCP Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-25 14:20 +0200

#185812 — Re: DHCP server that itself gets an IP address by DHCP

	Hi.

In-Reply-To: <20170824074515.y4z2ummdigk2fcbn@kazuki.local>

On Thu, Aug 24, 2017 at 04:45:15PM +0900, Mark Fletcher wrote:
> Is there any clever way to pass through the name server settings 
> the DHCP server provides, so that if the ISP should change its name 
> server IP addresses in the future, my local DHCP server would pass along 
> the new addresses when next asked?
> 
> In other words, instead of specifying the name server addresses 
> explicitly in the dhcp.conf file, is there a way to specify that they 
> should be taken from the host the DHCP server is running on?

Somewhat hackish, but straightforward way to achieve this is to redirect
DNS requests from your LAN to correct DNS. Something like this should do
the trick:

iptables -t nat -A OUTPUT -i <LAN Port> -p udp --dport 53 \
-j DNAT --to-destination <ISP DNS>:53

iptables -t nat -A OUTPUT -i <LAN Port> -p tcp --dport 53 \
-j DNAT --to-destination <ISP DNS>:53

iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -p udp --dport 53 -j ACCEPT

iptables -A FORWARD -p tcp --dport 53 -j ACCEPT


PS Being in the similar situation I said 'screw it' and installed
caching DNS alongside with DHCP on a firewall. It simplified that setup
immensely.

Reco

[toc] | [next] | [standalone]

#185823 — threading, was Re: DHCP server that itself gets an IP address by DHCP

On Thu 24 Aug 2017 at 12:30:35 (+0300), Reco wrote:
> 	Hi.
> 
> In-Reply-To: <20170824074515.y4z2ummdigk2fcbn@kazuki.local>
> 
[...]

If you type:

    :
    set edit_headers

you should get the headers included in your composition window,
and you can then stick the In-Reply-To: amongst its peers.
(I'm assuming neomutt honours this mutt switch.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#185831 — Re: threading, was Re: DHCP server that itself gets an IP address by DHCP

	Hi.

On Thu, 24 Aug 2017 08:25:16 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:

> On Thu 24 Aug 2017 at 12:30:35 (+0300), Reco wrote:
> > 	Hi.
> > 
> > In-Reply-To: <20170824074515.y4z2ummdigk2fcbn@kazuki.local>
> > 
> [...]
> 
> If you type:
> 
>     :
>     set edit_headers
> 
> you should get the headers included in your composition window,
> and you can then stick the In-Reply-To: amongst its peers.
> (I'm assuming neomutt honours this mutt switch.)

Thanks, I have 'edit_headers' enabled already. I merely put 'Hi' two
lines above I was aiming at.

Reco

[toc] | [prev] | [next] | [standalone]

#185860

Le 24/08/2017 à 11:30, Reco a écrit :
> 
> Somewhat hackish, but straightforward way to achieve this is to redirect
> DNS requests from your LAN to correct DNS. Something like this should do
> the trick:

Not so straightforward because you still need to get the ISP's DNS and 
update the iptables rules whenever the DNS change.

> iptables -t nat -A OUTPUT -i <LAN Port> -p udp --dport 53 \
> -j DNAT --to-destination <ISP DNS>:53
> 
> iptables -t nat -A OUTPUT -i <LAN Port> -p tcp --dport 53 \
> -j DNAT --to-destination <ISP DNS>:53

You mean "-A PREROUTING".

[toc] | [prev] | [next] | [standalone]

#185862

On Thu, Aug 24, 2017 at 10:21:04PM +0200, Pascal Hambourg wrote:
> Le 24/08/2017 à 11:30, Reco a écrit :
> > 
> > Somewhat hackish, but straightforward way to achieve this is to redirect
> > DNS requests from your LAN to correct DNS. Something like this should do
> > the trick:
> 
> Not so straightforward because you still need to get the ISP's DNS and
> update the iptables rules whenever the DNS change.

I strongly recommend just running your own caching DNS resolver on the
DHCP server host.  ISP nameservers are often slow and unreliable.

[toc] | [prev] | [next] | [standalone]

#185869

On Thu, Aug 24, 2017 at 04:39:13PM -0400, Greg Wooledge wrote:
> On Thu, Aug 24, 2017 at 10:21:04PM +0200, Pascal Hambourg wrote:
> > Le 24/08/2017 à 11:30, Reco a écrit :
> > > 
> > > Somewhat hackish, but straightforward way to achieve this is to redirect
> > > DNS requests from your LAN to correct DNS. Something like this should do
> > > the trick:
> > 
> > Not so straightforward because you still need to get the ISP's DNS and
> > update the iptables rules whenever the DNS change.
> 
> I strongly recommend just running your own caching DNS resolver on the
> DHCP server host.  ISP nameservers are often slow and unreliable.
> 

OK, thanks for the advice. One possibly stupid question though... 
whenever a DNS server running on my own firewall doesn't have an answer 
to a DHCP query, it is going to broadcast it out... to the ISP's DNS 
servers, no? So I'm not actually getting away from the ostensibly slow 
(which I could easily believe) and/or unreliable (which I've never seen 
evidence of) ISP DNS servers, just by installing my own.

I suppose I could override my resolv.conf somehow on my firewall machine 
to use DNS servers regarded as fast and reliable. But I doubt any of 
those are physically close to me here in Japan -- eg Google's are no 
doubt in the US, about as far away from me as it is possible to get 
while still being on planet Earth. Hard to imagine that is going to be 
faster. Or am I missing the point?

And, in terms of a local caching DNS server -- would BIND be the 
recommended solution?

Thanks

Mark

[toc] | [prev] | [next] | [standalone]

#185902

On Fri, Aug 25, 2017 at 07:34:16AM +0900, Mark Fletcher wrote:
> On Thu, Aug 24, 2017 at 04:39:13PM -0400, Greg Wooledge wrote:
> > I strongly recommend just running your own caching DNS resolver on the
> > DHCP server host.  ISP nameservers are often slow and unreliable.
> 
> OK, thanks for the advice. One possibly stupid question though... 
> whenever a DNS server running on my own firewall doesn't have an answer 
> to a DHCP query, it is going to broadcast it out... to the ISP's DNS 
> servers, no?

DHCP and DNS are two separate things.

DHCP is what your clients systems on your Local Area Network use to
get their IP addresses and netmasks and default gateways.  And possibly
also their list of DNS nameserver IP addresses, if you don't just
configure that locally.

DNS is the protocol used to look up domain names and get back IP
addreses, or vice versa.

If your firewall box is running a nameserver (i.e. a caching DNS
resolver), and if the LAN clients are configured to use that
nameserver, then no queries are ever sent to your ISP's nameservers
at all.  Your caching resolver does all the work, talking directly
to the root servers, and the .COM servers, and so on.

[toc] | [prev] | [next] | [standalone]

#185909

On Fri, Aug 25, 2017 at 08:14:29AM -0400, Greg Wooledge wrote:
> On Fri, Aug 25, 2017 at 07:34:16AM +0900, Mark Fletcher wrote:
> > On Thu, Aug 24, 2017 at 04:39:13PM -0400, Greg Wooledge wrote:
> > > I strongly recommend just running your own caching DNS resolver on the
> > > DHCP server host.  ISP nameservers are often slow and unreliable.
> > 
> > OK, thanks for the advice. One possibly stupid question though... 
> > whenever a DNS server running on my own firewall doesn't have an answer 
> > to a DHCP query, it is going to broadcast it out... to the ISP's DNS 
> > servers, no?
> 
> DHCP and DNS are two separate things.

Sorry, that was a typo, I meant "DNS query" not "DHCP query". I do 
understand the difference although I recognise that what I wrote above 
would seem to imply I don't.
> 
> If your firewall box is running a nameserver (i.e. a caching DNS
> resolver), and if the LAN clients are configured to use that
> nameserver, then no queries are ever sent to your ISP's nameservers
> at all.  Your caching resolver does all the work, talking directly
> to the root servers, and the .COM servers, and so on.
> 

Strictly speaking the LAN clients will be using the AirStation's 
nameserver, and I'd be configuring it to use this hypothetical new 
nameserver on the firewall box by having the DHCP server on my firewall 
send it the internal IP of the firewall as its nameserver. Why? Because 
the AirStation is already providing a nameserver to my LAN, and as I 
mentioned I want to futz minimally with the AirStation's configuration.

Thanks for the clarification about what the nameserver would do -- I had 
imagined it would answer DNS queries from the AirStation that it knows 
the answers to, and pass through queries it didn't know the answer to to 
some "upstream" nameserver, presumably noting the response so it knows 
next time. I assumed that is what the nameserver on the AirStation is 
doing, otherwise it wouldn't need to be told the ISP's nameservers, and 
I know from early misconfigurations of my firewall's DHCP server that if 
I give the AirStation bollix nameservers in response to its DHCP 
request, its ability to resolve anything breaks...

However, now, based on your response I am thinking the AirStation is 
just forwarding the DNS queries on to the nameservers it is given in 
response to its DHCP query, and not actually caching anything... So in 
your proposed configuration, a DNS query from a machine on my LAN would 
be picked up by the AirStation, forwarded to the firewall machine 
(because the AirStation was given the address of the firewall machine as 
a nameserver in response to its DHCP query), and that machine would 
actually be runnning a proper nameserver which would either already know 
the answer to the query or would interact with other DNS servers to get 
it. Right?

If that is actually caching everything by talking to root servers, .com 
servers etc, doesn't that take up a lot of space? The firewall box isn't 
a particularly beefy machine, by any measure -- memory, disk space, etc. 
It's enough to do the firewall job, and answer the occasional DHCP 
query, but would a nameserver need a lot of memory / disk space? The 
machine has a 32GB SSD, of which about 15GB is free, and 4GB of RAM, of 
which according to top about 1.8GB is free... And as I say, it is my 
firewall, a very light-load DHCP server, and does a cameo role as my 
OpenVPN server when I'm travelling on business.

Thanks for your patience in explaining this -- I'm learning a lot.

Mark

[toc] | [prev] | [next] | [standalone]

#185915

On Fri, Aug 25, 2017 at 10:12:07PM +0900, Mark Fletcher wrote:
> However, now, based on your response I am thinking the AirStation is 
> just forwarding the DNS queries on to the nameservers it is given in 
> response to its DHCP query, and not actually caching anything...

Very likely, yes.

> would a nameserver need a lot of memory / disk space? The 
> machine has a 32GB SSD, of which about 15GB is free, and 4GB of RAM, of 
> which according to top about 1.8GB is free...

That is plenty of memory for a caching resolver.  Luxury!

As a real-world example, <https://cr.yp.to/djbdns/dnscache.html> (which
is what I use) uses about 2 MB of RAM in a small-network configuration.
It doesn't say so on that page, but the default value of CACHESIZE is
1000000 (a million bytes).  So, figure about 1 MB plus however high you
set the CACHESIZE variable.

I can't speak for other DNS resolvers.  BIND in particular may be quite
bloated, and would not be my choice for a new setup.

[toc] | [prev] | [next] | [standalone]

#185863

	Hi.

On Thu, 24 Aug 2017 22:21:04 +0200
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

> Le 24/08/2017 à 11:30, Reco a écrit :
> > 
> > Somewhat hackish, but straightforward way to achieve this is to redirect
> > DNS requests from your LAN to correct DNS. Something like this should do
> > the trick:
> 
> Not so straightforward because you still need to get the ISP's DNS and 
> update the iptables rules whenever the DNS change.

Appropriate dhclient hook should do this trick.
I'd start with copying and modifying resolvconf one.


> > iptables -t nat -A OUTPUT -i <LAN Port> -p udp --dport 53 \
> > -j DNAT --to-destination <ISP DNS>:53
> > 
> > iptables -t nat -A OUTPUT -i <LAN Port> -p tcp --dport 53 \
> > -j DNAT --to-destination <ISP DNS>:53
> 
> You mean "-A PREROUTING".

My mistake indeed. OUTPUT is unsuitable here.

Reco

[toc] | [prev] | [next] | [standalone]

#185867

On Thu, Aug 24, 2017 at 11:35:25PM +0300, Reco wrote:
> On Thu, 24 Aug 2017 22:21:04 +0200
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> 
> > Le 24/08/2017 à 11:30, Reco a écrit :
> > > 
> > > Somewhat hackish, but straightforward way to achieve this is to redirect
> > > DNS requests from your LAN to correct DNS. Something like this should do
> > > the trick:
> > 
> > Not so straightforward because you still need to get the ISP's DNS and 
> > update the iptables rules whenever the DNS change.
> 
> Appropriate dhclient hook should do this trick.
> I'd start with copying and modifying resolvconf one.
> 
> 

I think the concept of "appropriate dhclient hook" might be exactly what 
I was after -- could an "appropriate dhclient hook" perhaps be used to 
update the name servers being offered by the DHCP server? And would that 
be done by updating dhcp.conf and restarting the dhcp server, or would 
that cause other problems?

And, is dhclient a separate piece of software from systemd.networkd? 
Because I am using the latter at the moment to get the IP address from 
the ISP on the firewall machine, although I am not married to that 
method, it's just that it was super-easy to set up and worked first 
time, so I never had reason to look for an alternative.

Mark

[toc] | [prev] | [next] | [standalone]

#185889

	Hi.

On Fri, 25 Aug 2017 07:28:00 +0900
Mark Fletcher <mark27q1@gmail.com> wrote:

> On Thu, Aug 24, 2017 at 11:35:25PM +0300, Reco wrote:
> > On Thu, 24 Aug 2017 22:21:04 +0200
> > Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> > 
> > > Le 24/08/2017 à 11:30, Reco a écrit :
> > > > 
> > > > Somewhat hackish, but straightforward way to achieve this is to redirect
> > > > DNS requests from your LAN to correct DNS. Something like this should do
> > > > the trick:
> > > 
> > > Not so straightforward because you still need to get the ISP's DNS and 
> > > update the iptables rules whenever the DNS change.
> > 
> > Appropriate dhclient hook should do this trick.
> > I'd start with copying and modifying resolvconf one.
> > 
> I think the concept of "appropriate dhclient hook" might be exactly what 
> I was after -- could an "appropriate dhclient hook" perhaps be used to 
> update the name servers being offered by the DHCP server? 

Sure it can. What you need is to
copy /etc/dhcp/dhclient-enter-hooks.d/resolvconf under a different name
and make changes in make_resolv_conf shell function.


> And would that 
> be done by updating dhcp.conf and restarting the dhcp server, or would 
> that cause other problems?

I don't see why it should. I still prefer iptables approach as that way
you whole internal network will get new DNS immediately and not after
the Airstation decide to renew DHCP lease.


> And, is dhclient a separate piece of software from systemd.networkd? 

I was referring to a reference implementation - isc-dhcp-client.
I honestly do not know if systemd-networkd utilizes these hooks.


> Because I am using the latter at the moment to get the IP address from 
> the ISP on the firewall machine, although I am not married to that 
> method, it's just that it was super-easy to set up and worked first 
> time, so I never had reason to look for an alternative.

Utilizing any other DHCP client is as simple as adding two lines
in /etc/network/interfaces:

auto <WAN interface>
inet <WAN interface> inet dhcp

Reco

[toc] | [prev] | [next] | [standalone]

#185903

On Fri, Aug 25, 2017 at 07:28:00AM +0900, Mark Fletcher wrote:
> And, is dhclient a separate piece of software from systemd.networkd? 

Yes.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web