Sorry, my bad. (Actually it doesn’t matter because it serves well as example
that static-stub configuration fails when the servers are unreachable and it
doesn’t recurse.)
But even with server-addresses it properly servfails when the static-stub
addresses are unreachable.
Perhaps it behaves differently when there’s already cached content?
I suggest you run test BIND instance with -d 99 to see what’s happening.
Ondřej
--
Ondřej Surý — ISC
> On 15 May 2020, at 18:22, Chris Palmer <chr...@cpalmer.me.uk> wrote:
>
> Hi Ondřej
>
> At first glance your suggestion looked like what I had done. But...
> I used:
>
> view "a" {
> match-clients { 172.16.n.n/24; }
> allow-recursion { any; };
> zone "x.y.zzz" {
> type static-stub;
> server-addresses {
> 10.n.n.n;
> 10.n.n.m;
> };
> };
> };
>
> If the 10.n.n.n addresses are not reachable, it still recurses and does a
> public query resulting in an NXDOMAIN. However, I don't know what I have done
> differently this time, but the NXDOMAIN is no longer being cached. Each
> attempt causes it to query upstream, and when I bring the VPN up it uses the
> 10.n.n.n server correctly. Which is acceptable, although I'm still unsure why
> it is recursing at all (or at least why I can't prevent it).
>
> Out of curiosity I then changed to what you suggested:
>
> view "a" {
> match-clients { 172.16.n.n/24; }
> allow-recursion { any; };
> zone "x.y.zzz" {
> type static-stub;
> server-names {
> "10.n.n.n";
> "10.n.n.m";
> };
> };
> };
>
> This ALWAYS gives a SERVFAIL though regardless of whether the 10.n.n.n
> addresses are reachable or not...
>
> So I have something that works, although it is sub-optimal when the VPN is
> down.
>
> Cheers, Chris
>
>> On 15/05/2020 14:26, Ondřej Surý wrote:
>> Hi Chris,
>> why don’t you just delegate the x.y.zzz to the server in the VPN?
>> Generally, the static-stub should work in this case, but your email doesn’t
>> have
>> enough details why it would not.
>> I properly get SERVFAILs with this minimal config:
>> zone "sury.org" {
>> type static-stub;
>> server-names {
>> "192.168.1.1";
>> };
>> };
>> and named -g reports:
>> 15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1/A/IN':
>> 2001:503:c27::2:30#53
>> 15-May-2020 15:25:00.015 network unreachable resolving
>> '192.168.1.1/AAAA/IN': 2001:503:c27::2:30#53
>> Cheers,
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>>>> On 15 May 2020, at 14:40, Chris Palmer <chr...@cpalmer.me.uk> wrote:
>>>
>>> Hi Ondřej
>>>
>>> That could work for eliminating the caching delay when the VPN comes up.
>>> I'd just have to get that into the VPN config so people didn't have to do
>>> it manually.
>>>
>>> Is there any way to stop the recursion for that domain happening in the
>>> first place though?
>>>
>>> Thanks, Chris
>>>
>>>
>>> On 15/05/2020 13:34, Ondřej Surý wrote:
>>>> Hi Chris,
>>>> when your vpn comes up, you need to issue:
>>>> rndc flushtree <domain>
>>>> command to the BIND 9 instance.
>>>> Ondrej
>>>> --
>>>> Ondřej Surý
>>>> ond...@isc.org
>>>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users
>>>>> <bind-users@lists.isc.org> wrote:
>>>>>
>>>>> There is much discussion about recursion but I can't find anything that
>>>>> matches this use case...
>>>>>
>>>>> - In-house Bind-9.11.14 server, master for some local zones, recursion
>>>>> enabled; not accessible from external networks
>>>>> - Two views for in-house networks
>>>>> - Intermittent VPN access from in-house network to another private
>>>>> network that is master for DNS zone x.y.zzz; this network is not publicly
>>>>> reachable
>>>>> - Need queries from one of our views for x.y.zzz to be sent to the static
>>>>> address for the x.y.zzz server that is only reachable via the VPN
>>>>> - When the VPN is not connected, need the lookup on to fail/timeout
>>>>> rather than go through the recursion path
>>>>> - When the VPN is again connected need lookups to succeed without undue
>>>>> delay.
>>>>>
>>>>> Within the required view I have tried a zone with type forward
>>>>> (specifying forwarders and forward only), and also a zone of type
>>>>> static-stub (specifying server-addresses). Both work fine when the VPN is
>>>>> up. Both have two problems though when the VPN is disconnected:
>>>>> (a) the queries are recursed and an NXDOMAIN response cached.
>>>>> (b) When the VPN comes back up the cached NXDOMAIN is served until
>>>>> it expires.
>>>>>
>>>>> I have been trying to force a SERVFAIL when the specified servers for
>>>>> that domain are unreachable, rather than recursing. And presumably that
>>>>> would then cause the queries to quickly flow to the required servers once
>>>>> they are reachable again. Is that possible, or is there another approach
>>>>> to this problem?
>>>>>
>>>>> Many thanks, Chris
>>>>> _______________________________________________
>>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>>>> unsubscribe from this list
>>>>>
>>>>> ISC funds the development of this software with paid support
>>>>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>>>>> information.
>>>>>
>>>>>
>>>>> bind-users mailing list
>>>>> bind-users@lists.isc.org
>>>>> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
