I can see exactly why it's behaving this way. The code attempts to answer directly queries from internal hosts for auth domains that would otherwise be forwarded, and then return to the authoritative side of dnsmasq. This is a performance hack.
I don't think you ingenious use of address= was considered when that was done. It's not wrong, just - unexpected. If you add host-record=owncloud.local.lan,192.168.1.y then that record will be excluded from external queries, but allowed in internal queries. (I think - I've not tested this.) Internal queries will still get the external address too, so that may not be enough. I think that maybe a flag to turn off this performance hack might be the right answer. Simon. On 06/06/15 09:59, Ermanno Scaglione wrote: > 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 > externaldhcp-host = fred, 192.168.0.3 > 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. > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasqfirstname.lastname@example.org > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss