On Fri, May 15, 2020 at 12:22 PM Chris Palmer via bind-users <
bind-users@lists.isc.org> 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ý
> > 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
