[Dnsmasq-discuss] dnsmasq queries external dns servers even if dnsmasq is the authorized server for that domain.

Simon Kelley simon at thekelleys.org.uk
Mon Oct 21 14:35:23 BST 2013

On 21/10/13 14:00, Jim Alles wrote:
> On Mon, Oct 21, 2013 at 5:33 AM, René van Dorst<opensource at vdorst.com>  wrote:
>>> I am using a real domain and using dnsmasq a master authorized server.
>>> Dnsmasq syncs it data to a slave nameserver on the internet.
>>> The slave nameserver get all the all the routerable IPv6 address that are
>>> handout by dnsmasq.
>>> So I am able to ping my wifi router by it's ipv6 address.
>>> I think the "auth-zone" is enough to disable the external look-up.
>> Jim Alles<kb3tbx at gmail.com>  , 20-10-2013 3:54:
>> Other possibly useful settings:
> Sorry to cloud the issue.
>> bogus-priv #blocks private address forwarding
> This probably would not be helpful at all, in your case, even though
> it is a good idea, in general.
> And I am afraid I am not set up to use IPv6 just yet, so I will have
> to defer to others, at this point.
> Other than I am here to learn, and I just read about this:
> http://www.isaserver.org/articles-tutorials/installation-planning/You_Need_to_Create_a_Split_DNS.html
> http://en.wikipedia.org/wiki/Split-horizon_DNS
> I do not know how dnsmasq could be used in this fashion.
> Peace,
> Jim A.

So, the dnsmasq auth-* system does split-horizon DNS, at lease after a 


Creates a DNS zone, *.lan.example.com which contains data from

--mx-host, --srv-host, --dns-rr, --txt-record, --naptr-record, as long 
as the record names are in *.lan.example.com

  --cname as long as the record name is in  the authoritative domain. If 
the target of the CNAME is unqualified, then it  is  qualified  with 
the  authoritative zone name.

IPv4 and IPv6 addresses from /etc/hosts (and --addn-hosts ) and 
--host-record provided as long as the record names are in *.lan.example.com.

Addresses specified by --interface-name.

Names from DHCP leases. Note that DHCP leases have names, so internally 
a machine may be resovable just with it's name, or with name.<domain> 
where the name comes from --domain config. In the auth zone, the same 
host will be name.lan.example.com

Now the interesting bit: A and AAAA records (ie IPv4 and IPv6 addresses 
are filtered using the subnet(s) in the auth-zone. If the address 
doesn't appear in a subnet, it doesn't appear in the zone. This is 
really useful, for example to avoid exporting RFC1918 names.

The probem Rene has is that he's configured his auth-zone to be the same 
as the internal domain. This is OK, but the first change I made means 
that name.<domain>, which used to be resolved internally, is now treated 
as being in the auth zone, and it's being filtered by the subnet rule.

I've just pushed a change to git that removes this filtering for 
internal clients, and that should solve Rene's problem. It does change 
behaviour in the case that an auth-zone is not the same as an internal 
zone: before, queries for that would go upstream, and be subject to 
subnet filtering, now, they're answered locally, (good) and not filtered 
(maybe good). For a concrete example, I have an auth zone called 
lan.thekelleys.org.uk and my internal domain is thekelleys.org.uk. This 
machine is always resolvable as spike.thekelleys.org.uk internally, but 
not externally. It is resolvable as spike.lan.thekelleys.org.uk 
externally and internally (try it) but only for IPV6, since it's IPv4 
address is RFC1918. With the change, spike.lan.thekelleys.org.uk _does_ 
return the RFC1918 address for clients within my LAN, but not for 
external clients. That's probably a sensible change.

Rene, does the latest git commit fix your problem OK?



More information about the Dnsmasq-discuss mailing list