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 <
bind-users at 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ý
> > ondrej at isc.org
> >
> >> On 15 May 2020, at 14:40, Chris Palmer <chris9 at 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ý
> >>> ondrej at isc.org
> >>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <
> bind-users at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200515/4dbcc399/attachment.htm>