<html><head></head><body><span title="simon@thekelleys.org.uk">Simon Kelley</span><span class="detail"> <simon@thekelleys.org.uk></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>

<br>

<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>