[Dnsmasq-discuss] split-horizon

[Ermanno Scaglione]

Hi to everybody, I use dnsmasq on my small home router (and find it great
btw), and I am attempting to use it also as an authoritative DNS for a
freedns.afraid.org subdomain I host on my home server. I'd like to
configure the dns in a way that the domain resolves to address x.x.x.x when
queried over the external interface and to 192.168.1.y when queried over
the internal one, this because if I access the home server from inside the
lan using the external address x.x.x.x all traffic goes through the nat
layer of the small router and will slow down a lot. The home server is
running owncloud over a Gbit network so  especially when up/downloading
large files it is important to access it using the internal address
192.168.1.y.
Currently I have an auth-only dns listening only to the external interface
that resolves the domain owncloud.local.lan to x.x.x.x, dnsmasq is
listening on the bridge and the directive
address=/owncloud.local.lan/192.168.1.y
effectively creates the split-horizon since when internal hosts query the
dns for owncloud.local.lan get 192.168.1.y as answer and are able to access
the home server at full switch speed while hosts qerying over the external
interface get x.x.x.x and I am able to access the home server from outside.
I had expected the same setup to work using the authoritative dns
capabilities of dnsmasq but it doesn't, if I put

auth-server=owncloud.local.lan,wan
host-record=owncloud.local.lan,x.x.x.x
auth-zone=owncloud.local.lanm,x.x.x.x/32
address=/owncloud.local.lan/192.168.1.y

also hosts inside the lan are answered x.x.x.x when querying for
owncloud.local.lan, it is like
the address directive is overriden by the auth-zone one. IMHO this is
wrong and address=// should
take precedence over auth-zone if the query comes from an interface
not listed in the auth-server
directive.

Maybe I just doing it wrong and there is  a better way of doing it
..... in that case please tell me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150606/5a9dedf1/attachment.html>