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 host-record=owncloud.local.lan,x.x.x.x overrides address=/owncloud.local.lan/192.168.1.y 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. auth-server=owncloud.local.lan,wan host-record=owncloud.local.lan,x.x.x.x host-record=owncloud.local.lan,192.168.1.y auth-zone=owncloud.local.lan,x.x.x.x/32 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 localise-queries 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? Cheers, Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqfirstname.lastname@example.org http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss