[Dnsmasq-discuss] Suggestion/Feature Request: Disable only DNS on an interface

[Albert ARIBAUD]

Hi again Ryan,

Le Wed, 13 Apr 2016 11:28:08 +0200
Ryan Zev Solomon <ryzenold at gmail.com> a écrit:

> On 13/04/2016 08:19, Albert ARIBAUD wrote:
>  > Hi Ryan,
>  >
>  > Le Tue, 12 Apr 2016 22:41:45 +0200
>  > Ryan Zev Solomon <ryzenold at gmail.com> a écrit:
>  >
>  >> Good day,
>  >>
>  >> I think it would be useful to disable serving DNS queries on an
>  >> interface on which TFTP, and DHCP are still provided. My use case:
>  >> - TFTP and DHCP are provided by Dnsmasq.
>  >> - Unbound is used as the DNS recursive resolver/cache.
>  >> - Dnsmasq is used as a stub resolver for the addresses handed out
>  >> via DHCP.
>  >>
>  >> Currently this can be partially achieved by moving Dnsmasq to a
>  >> different port, and blocking that port.
>  >
>  > What do you mean exactly by "stub resolver"? Apparently you want
>  > unbound to manage the local zone, so dnsmasq won't have any name
>  > serving to do at all.
>  >
>  > If so, then completely disabling DNS is possible with '-p 0' as
>  > per the man page.
> Thanks, but I do want dnsmasq to handle the local zone, as this ties
> in with DHCP. Unbound sends any queries for the local domain to
> dnsmasq, but handles all other queries itself. Stub resolver is
> likely not the correct terminology, apologies for the confusion.
> Unbound's behaviour in this case is configured to act much like 
> dnsmasq's server=/domain/nameserver configuration directive.
>  >
>  > Of course this will implicitly turn off dnsmasq's capability to
>  > fill in its local DNS records with names from DHCP leases, but I
>  > supect you do not use this feature since you want the local zone
>  > managed by unbound, not dnsmasq.
> I do want dnsmasq to handle the local names from DHCP leases, the
> local zone is not managed by unbound. (Unbound has various zone
> types, and can be used to add in records which the upstream
> nameserver does not have.)
> 
> In short:
> - Unbound is used as a DNS cache, and recursive resolver.
> - dnsmasq is the pseudo authoritative server for the local domain.
> - Unbound sends queries for the local domain to dnsmasq, this allows 
> names from DHCP leases to be served.
> 
> I do not want to disable dnsmasq's DNS completely, merely on an 
> interface where dnsmasq continues to provide DHCP, and TFTP.
> 
> Please let me know if my explanation is unclear.

On the contrary, it makes it clearer to me what your intended
setup is.

So, IIUC :

- Your dnsmasq (obviously) and unbound both run on the same machine
  which has a single interfce to the LAN (let's call it eth0). Of
  course, it also has a loopback interface (let's call it lo0).

- DHCP requests on eth0 should be answered authoritatively on eth0
  by dnsmasq.

- DNS requests on eth0 and standard port should be answered by unbound.

- Unbound should be the only one able to query dnsmasq for names that
  are assigned based on DHCP.

If so, then I would suggest:

1. That dnsmasq be configured to answer for DHCP only (-p 0) on eth0;

2. That dnsmasq be configured to answer for DNS only (no --dhcp-range)
   on lo0.

3. That unbound be configured to answer for DNS requests on eth0.

4. That unbound be configured to forward queries for local domain to
   the DNS server on lo0.

5. (optional) if you want the system that runs dnsmasq and unbound to
   resolve names exactly like other hosts on the LAN, then dnsmasq
   and unbound should use a non-standard port on lo0 to communicate,
   and unbound should be configured to answer on the standard port on
   both eth0 and lo0 (and your system should list lo0 as a nameserver
   in its resolv.conf).

This setting will ensure that only the machine that runs dnsmasq can
ever query dnsmasq directly, and all other hosts will be forced to
query unbound (which will possibly query dnsmasq locally) -- I think
this is what you want.

P.S. I have the opposite setup, where dnsmasq does DHCP and DNS for
local net and caching, and it delegates the rest to unbound which does
recursion and no caching. Are there perf numbers out there which I
could look at and decide whether I should switch to a setup similar to
yours?

Amicalement,
-- 
Albert.