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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
