From Newsgroup: comp.protocols.dns.bind
--000000000000925fb005a5b2e98b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, May 15, 2020 at 12:22 PM Chris Palmer via bind-users <
bind-users@lists.isc.org> wrote:
Hi Ond=C5=99ej
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.
--=20
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=C5=99ej Sur=C3=BD wrote:
Hi Chris,
why don=E2=80=99t you just delegate the x.y.zzz to the server in the VP=
N?
Generally, the static-stub should work in this case, but your email
doesn=E2=80=99t 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/I=
N':
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=C5=99ej Sur=C3=BD
ondrej@isc.org
On 15 May 2020, at 14:40, Chris Palmer <chris9@cpalmer.me.uk> wrote:
Hi Ond=C5=99ej
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 t=
o
do it manually.
Is there any way to stop the recursion for that domain happening in th=
e
first place though?
Thanks, Chris
On 15/05/2020 13:34, Ond=C5=99ej Sur=C3=BD wrote:
Hi Chris,
when your vpn comes up, you need to issue:
rndc flushtree <domain>
command to the BIND 9 instance.
Ondrej
--
Ond=C5=99ej Sur=C3=BD
ondrej@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 fo=
r
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
--000000000000925fb005a5b2e98b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
dir=3D"ltr" class=3D"gmail_attr">On Fri, May 15, 2020 at 12:22 PM Chris Pa= lmer via bind-users <<a href=3D"mailto:
bind-users@lists.isc.org">bind-us=
ers@lists.isc.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex">Hi Ond=C5=99ej<br>
At first glance your suggestion looked like what I had done. But...<br>
I used:<br>
view "a" {<br>
=C2=A0 =C2=A0match-clients { 172.16.n.n/24; }<br>
=C2=A0 =C2=A0allow-recursion { any; };<br>
=C2=A0 =C2=A0zone "x.y.zzz" {<br>
=C2=A0 =C2=A0 =C2=A0type static-stub;<br>
=C2=A0 =C2=A0 =C2=A0server-addresses {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A010.n.n.n;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A010.n.n.m;<br>
=C2=A0 =C2=A0 =C2=A0};<br>
=C2=A0 =C2=A0};<br>
};<br>
If the 10.n.n.n addresses are not reachable, it still recurses and does <br=
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 <br> cached. Each attempt causes it to query upstream, and when I bring the <br>
VPN up it uses the 10.n.n.n server correctly. Which is acceptable, <br> although I'm still unsure why it is recursing at all (or at least why I=
can't prevent it).<br>
Out of curiosity I then changed to what you suggested:<br>
view "a" {<br>
=C2=A0 =C2=A0match-clients { 172.16.n.n/24; }<br>
=C2=A0 =C2=A0allow-recursion { any; };<br>
=C2=A0 =C2=A0zone "x.y.zzz" {<br>
=C2=A0 =C2=A0 =C2=A0type static-stub;<br>
=C2=A0 =C2=A0 =C2=A0server-names {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0"10.n.n.n";<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0"10.n.n.m";<br>
=C2=A0 =C2=A0 =C2=A0};<br>
=C2=A0 =C2=A0};<br>
};<br>
This ALWAYS gives a SERVFAIL though regardless of whether the 10.n.n.n <br> addresses are reachable or not...<br></blockquote><div><br></div><div>"= ;server-names" must be given a list of NAMES, not addresses.=C2=A0 &qu= ot;10.n.n.n" is probably not the right name, looks more like an addres= s.</div><div><br></div><div>--=C2=A0</div><div>Bob Harold</div><div>=C2=A0<= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex">
So I have something that works, although it is sub-optimal when the VPN <br=
is down.<br>
Cheers, Chris<br>
On 15/05/2020 14:26, Ond=C5=99ej Sur=C3=BD wrote:<br>
> Hi Chris,<br>
> <br>
> why don=E2=80=99t you just delegate the x.y.zzz to the server in the V= PN?<br>
> <br>
> Generally, the static-stub should work in this case, but your email do= esn=E2=80=99t have<br>
> enough details why it would not.<br>
> <br>
> I properly get SERVFAILs with this minimal config:<br>
> <br>
> zone "<a href=3D"
http://sury.org" rel=3D"noreferrer" target=3D"_b= lank">sury.org</a>" {<br>
>=C2=A0 =C2=A0 type static-stub;<br>
>=C2=A0 =C2=A0 server-names {<br>
>=C2=A0 =C2=A0 =C2=A0 "192.168.1.1";<br>
>=C2=A0 =C2=A0 };<br>
> };<br>
> <br>
> and named -g reports:<br>
> <br>
> 15-May-2020 15:25:00.015 network unreachable resolving '<a href=3D= "
http://192.168.1.1/A/IN" rel=3D"noreferrer" target=3D"_blank">192.168.1.1/= A/IN</a>': 2001:503:c27::2:30#53<br>
> 15-May-2020 15:25:00.015 network unreachable resolving '<a href=3D= "
http://192.168.1.1/AAAA/IN" rel=3D"noreferrer" target=3D"_blank">192.168.1= .1/AAAA/IN</a>': 2001:503:c27::2:30#53<br>
> <br>
> Cheers,<br>
> Ondrej<br>
> --<br>
> Ond=C5=99ej Sur=C3=BD<br>
> <a href=3D"mailto:
ondrej@isc.org" target=3D"_blank">
ondrej@isc.org</a>=
> <br>
>> On 15 May 2020, at 14:40, Chris Palmer <<a href=3D"mailto:chris=
9@cpalmer.me.uk" target=3D"_blank">
chris9@cpalmer.me.uk</a>> wrote:<br> >><br>
>> Hi Ond=C5=99ej<br>
>><br>
>> That could work for eliminating the caching delay when the VPN com=
es up. I'd just have to get that into the VPN config so people didn'=
;t have to do it manually.<br>
>><br>
>> Is there any way to stop the recursion for that domain happening i=
n the first place though?<br>
>><br>
>> Thanks, Chris<br>
>><br>
>><br>
>> On 15/05/2020 13:34, Ond=C5=99ej Sur=C3=BD wrote:<br>
>>> Hi Chris,<br>
>>> when your vpn comes up, you need to issue:<br>
>>> rndc flushtree <domain><br>
>>> command to the BIND 9 instance.<br>
>>> Ondrej<br>
>>> --<br>
>>> Ond=C5=99ej Sur=C3=BD<br>
>>> <a href=3D"mailto:
ondrej@isc.org" target=3D"_blank">ondrej@isc= .org</a><br>
>>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <=
<a href=3D"mailto:
bind-users@lists.isc.org" target=3D"_blank">bind-users@li= sts.isc.org</a>> wrote:<br>
>>>><br>
>>>> There is much discussion about recursion but I can't f= ind anything that matches this use case...<br>
>>>><br>
>>>> - In-house Bind-9.11.14 server, master for some local zone=
s, recursion enabled; not accessible from external networks<br> >>>> - Two views for in-house networks<br>
>>>> - Intermittent VPN access from in-house network to another=
private network that is master for DNS zone x.y.zzz; this network is not p= ublicly reachable<br>
>>>> - Need queries from one of our views for x.y.zzz to be sen=
t to the static address for the x.y.zzz server that is only reachable via t=
he VPN<br>
>>>> - When the VPN is not connected, need the lookup on to fai= l/timeout rather than go through the recursion path<br>
>>>> - When the VPN is again connected need lookups to succeed = without undue delay.<br>
>>>><br>
>>>> Within the required view I have tried a zone with type for= ward (specifying forwarders and forward only), and also a zone of type stat= ic-stub (specifying server-addresses). Both work fine when the VPN is up. B= oth have two problems though when the VPN is disconnected:<br> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (a) the queries are recursed an=
d an NXDOMAIN response cached.<br>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (b) When the VPN comes back up = the cached NXDOMAIN is served until it expires.<br>
>>>><br>
>>>> I have been trying to force a SERVFAIL when the specified = servers for that domain are unreachable, rather than recursing. And presuma= bly that would then cause the queries to quickly flow to the required serve=
rs once they are reachable again. Is that possible, or is there another app= roach to this problem?<br>
>>>><br>
>>>> Many thanks, Chris<br><br>
</blockquote></div></div>
--000000000000925fb005a5b2e98b--
--- Synchronet 3.18a-Linux NewsLink 1.113