<html><head></head><body><span title="email@example.com">Simon Kelley</span><span class="detail"> <firstname.lastname@example.org></span> , 21-10-2013 15:37:<br><div><blockquote class="mori" style="margin:0 0 0 .8ex;border-left:2px blue solid;padding-left:1ex;">I've just pushed a change to git that removes this filtering for
<br>internal clients, and that should solve Rene's problem. It does change
<br>behaviour in the case that an auth-zone is not the same as an internal
<br>zone: before, queries for that would go upstream, and be subject to
<br>subnet filtering, now, they're answered locally, (good) and not filtered
<br>(maybe good). For a concrete example, I have an auth zone called
<br>lan.thekelleys.org.uk and my internal domain is thekelleys.org.uk. This
<br>machine is always resolvable as spike.thekelleys.org.uk internally, but
<br>not externally. It is resolvable as spike.lan.thekelleys.org.uk
<br>externally and internally (try it) but only for IPV6, since it's IPv4
<br>address is RFC1918. With the change, spike.lan.thekelleys.org.uk _does_
<br>return the RFC1918 address for clients within my LAN, but not for
<br>external clients. That's probably a sensible change.
<br>Rene, does the latest git commit fix your problem OK?
<br></blockquote></div><br>Yes, it is working. Thanks for the effort.<br><br><div><blockquote class="mori" style="margin:0 0 0 .8ex;border-left:2px blue solid;padding-left:1ex;"></blockquote></div></body></html>