[Dnsmasq-discuss] split-horizon

[Ermanno Scaglione]

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 <simon at 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 at lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150607/7cb1e4fa/attachment.html>