How to disable recursion on ONE domain? (Bind-9.11.14)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How to disable recursion on ONE domain? (Bind-9.11.14)

Bind-Users forum mailing list
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: How to disable recursion on ONE domain? (Bind-9.11.14)

Ondřej Surý
Hi Chris,

when your vpn comes up, you need to issue:

rndc flushtree <domain>

command to the BIND 9 instance.

Ondrej
--
Ondřej Surý
[hidden email]

> On 15 May 2020, at 14:16, Chris Palmer via bind-users <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to disable recursion on ONE domain? (Bind-9.11.14)

Bind-Users forum mailing list
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ý
> [hidden email]
>
>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <[hidden email]> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: How to disable recursion on ONE domain? (Bind-9.11.14)

Ondřej Surý
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ý
[hidden email]

> On 15 May 2020, at 14:40, Chris Palmer <[hidden email]> 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ý
>> [hidden email]
>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <[hidden email]> 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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to disable recursion on ONE domain? (Bind-9.11.14)

Bind-Users forum mailing list
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ý
> [hidden email]
>
>> On 15 May 2020, at 14:40, Chris Palmer <[hidden email]> 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ý
>>> [hidden email]
>>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <[hidden email]> 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
>>>> [hidden email]
>>>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: How to disable recursion on ONE domain? (Bind-9.11.14)

Bob Harold

On Fri, May 15, 2020 at 12:22 PM Chris Palmer via bind-users <[hidden email]> 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...

"server-names" must be given a list of NAMES, not addresses.  "10.n.n.n" is probably not the right name, looks more like an address.

-- 
Bob Harold
 

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ý
> [hidden email]
>
>> On 15 May 2020, at 14:40, Chris Palmer <[hidden email]> 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ý
>>> [hidden email]
>>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

re: How to disable recursion on ONE domain? (Bind-9.11.14)

Bob McDonald
In reply to this post by Bind-Users forum mailing list
Would adding the following to the zone config work?

forwarders {};

Regards,

Bob

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: How to disable recursion on ONE domain? (Bind-9.11.14)

Ondřej Surý
In reply to this post by Bind-Users forum mailing list
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 <[hidden email]> 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ý
>> [hidden email]
>>>> On 15 May 2020, at 14:40, Chris Palmer <[hidden email]> 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ý
>>>> [hidden email]
>>>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <[hidden email]> 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
>>>>> [hidden email]
>>>>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users