Yes adding an host record with an internal address cause dnsmasq to reply alternately the internal and external record to internal queries, useless, also --localise-queries has no effect. Maybe the new flag should be called localise-auth-queries :-) It would be a great small split-horizon for home networks :-)
On Sat, Jun 6, 2015 at 11:33 PM, Simon Kelley <si...@thekelleys.org.uk> wrote: > 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 > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss