[Dnsmasq-discuss] dnsmasq queries external dns servers even if dnsmasq is the authorized server for that domain.
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:
> I do not know how dnsmasq could be used in this fashion.
> 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