erm967 at gmail.com
Mon Sep 7 12:45:45 BST 2015
Sorry for the late answer but I was on holiday. I tested the patch from git
and it works as expected. Thank you a lot.
On Sun, Aug 9, 2015 at 6:46 PM, Simon Kelley <simon at thekelleys.org.uk>
> On 06/06/15 09:59, Ermanno Scaglione wrote:
> > 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.
> OK, I poked around with this a bit more, and the problem is that
> This is always true, no auth-zone is required to make it happen and it's
> quite sensible, since the --address config is actually a wildcard for
> the whole zone.
> host-record=myserver.thekelleys.org.uk,<real IP>
> address=/thekelleys.org.uk/,<wildcard IP>
> is a sane and sensible thing to do.
> Gives the correct answer to the auth query, since the 192.168.1.y record
> is filtered out. It gives the wrong answer to the non-auth query, since
> both A records are returned.
> However, if then add
> to the config, that will filter the x.x.x.x A record in the non-auth
> query, as long as 192.168.1.x is on the same subnet as the address to
> which the query was sent. This actually needs a little patch to work,
> which I've just pushed to the git repo.
> Is that a reasonable solution?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dnsmasq-discuss