2012-02-09 - Re: [GRASE-Hotspot] Changes for grase-conf-squid3 - Force squid to use dnsmasq

Header Data

From: Tim White <ti***8@gmail.com>
Message Hash: 119e1493fb0ad3ea882ff67a370046622b512e485c7c3fd83bd46563453cdb19
Message ID: <4F3435A4.6060500@gmail.com>
Reply To: <201202091235.28353.solbu@solbu.net>
UTC Datetime: 2012-02-09 14:07:48 UTC
Raw Date: Fri, 10 Feb 2012 07:07:48 +1000

Raw message 

On 09/02/12 21:34, Johnny Solbu wrote:
>> --- Changes for grase-conf-squid3 ---
>> grase-conf-squid3 (1.3) purewhite; urgency=low
>>
>>    * Force squid to use dnsmasq as nameserver as some upstream nameservers cause timeout issues
> What about those of us who need to use bind locally on the server?
> This is not an upstream server but the LOCAL server on the same computer as grase is installed on.
>
> In one location where this system might be installed, if my friends testing is sucessfull, is the home network of his parents, a server which have -3- ethernet cards. Both eth1 and eth2 are the local network, one is a physically wired network and the other is connected to a wireless access point, which is in bridge mode.
>
> On both networks we have a local domain, using ".lan" as TLD, to identify the various computers. We intend to keep using this domain on the wired network to identify among other things an ip phone and a GNU/Linux based television receiver. We use bind localy on the server to accomplish this. we also use bind to block specific domains, such as all the domains of doubleclick, google syndication, google analytics and the like.
> If GRASE has been installed on this server, we would have lost our local domain on the wired network after this update, which would have been replaced with ".local", and the wired network would have failed to reach the local dns based services.
>
> It should be possible for the system administrator to override this.

As part of the Grase Hotspot system, we need dnsmasq to be installed and 
used. It is currently dnsmasq that allows us to change network settings 
in the admin interface, and to apply them. This allows all clients on 
the network to be forced to use the DNS server on the Hotspot, which can 
then enforce DNS things, like blocking domains. One of the main features 
we have in dnsmasq that I couldn't find in bind was "bogus nx". This 
feature allows us to use for example, an ISP DNS server upstream, that 
returns "valid" results when a domain doesn't exist, so they can 
redirect you to their advertising filled search page. It also allows us 
the ability to change what upstream DNS server we use easily.

In theory, we could do the same thing with bind, however, as bind is 
designed more for a DNS main server, than a recursive resolver, dnsmasq 
was choosen. If you wish to assist in writing an alternative 
"grase-conf-bind" package that will allow you to use bind instead of 
dnsmasq, I'll happily help you with guidance of what does what, and what 
needs to be where.

I would like to suggest though, that bind is overkill for a home 
network. Dnsmasq will easily allow you to have a .lan local domain 
(infact, the hotspot has hotspot.lan by default), and will certainly 
allow you to block things. I personally use dnsmasq on my home network 
to server a local domain, and because I have it handling DHCP as well 
(not on my hotspot, on my home network), there was nothing needed to 
setup to get dhcp3 and bind talking, as it was all inside dnsmasq (which 
is running on my lightweight NAS).

Assuming your local .lan domain uses static (DHCP assigned) addresses, 
you can just drop a file in /etc/dnsmasq.d/ with 
address=/hostname.lan/x.x.x.x entries and not have to change anything 
else about your setup (other than stopping bind). The same format can be 
used to block domains (by ether directing them to 127.0.0.1 or to a 
local webserver that always answers with a blank page/picture for all 
requests).

I'm in the process of writing up a "Quick Start list" for sys admins, so 
will look at including some of this information there as well. Part of 
the Hotspots aim has always been to be a complete install requiring no 
more tinkering of system stuff, just change things in the admin 
interface to suit. For this reason, I had to choose to make some 
software "needed", and as time goes by, will allow alternatives to 
replace things. For example, Squid3 is required, Squid2 will not work 
due to some things we use in squid3. In theory, any proxy server would 
work, but supporting other servers is a lot of work. Again, if someone 
writes a debian package ("grase-conf-xxxx") that is a drop in 
replacement, then it allows us to change what we can support. I recently 
split the Apache config out of the grase-www-portal package, and we now 
support Nginx and Apache2 as web servers. (Was mostly so I could see 
what worked best on small embedded devices.)

I hope you don't feel like I'm trying to push my software preferences on 
other system admins, however I can't support ever server software, 
especially when things are integrated deeply. Please take a look at 
dnsmasq, and you may discover lots of features that are better suited to 
a home network (or any private network) that are difficult to do with a 
dhcp3/bind combination.

Tim

Thread