On 21/10/13 14:00, Jim Alles wrote:
On Mon, Oct 21, 2013 at 5:33 AM, René van Dorst<[email protected]> 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<[email protected]> , 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
fashion.
auth-zone=lan.example.com,1.2.3/24
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?
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
