Re: Response Policy Zone: disabling "leaking" of lookups

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2020-09-02 at 17:47 -0700, Fred Morris wrote:
> how do I disable the (useless) resolution directed at upstream
> servers?

Isn't that just "qname-wait-recurse no;"


-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCX1BhpBUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsFe7gCfVN8JVwC8eQ5RExIYVJkOVf3Ywc4A
n1pCBkinzCzqBH9IYlXfp5sNeNh1
=Zfin
-END PGP SIGNATURE-


___
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

Response Policy Zone: disabling "leaking" of lookups

[Fred Morris]

It comes to my attention that when an unresolvable query occurs, it gets
forwarded to the authoritative zone regardless of anything I can set in
named.conf. Closest I can come is qname-wait-recurse which has the
/opposite/ effect sort of, namely waiting for recursion to complete. If
I have something in an RPZ, I want it to accept that; period, full stop,
no outwardly visible effects.

Ironically the text surrounding this option in the ARM is to the effect
that "... not resolving the requested name can leak the fact that
response policy rewriting is in use..." and leaking the fact that it is
in use by not leaking the query in the first place is what I'm trying to
achieve: how do I disable the (useless) resolution directed at upstream
servers?

Here is a use case:

 1. A search list is in place for example.com. This means that if
"foo.bar" fails to resolve then "foo.bar.example.com" will be tried,
followed by "foo.bar.com".
 2. In addition to the foregoing a rule is placed in the RPZ that
"com.example.com" and "*.com.example.com" are NXDOMAIN.
 3. An additional rule is present in the RPZ that
"my-outhouse-example.com" is NXDOMAIN.

In this case:

  * "my-outhouse-example.com.example.com" will return NXDOMAIN (it does!)
  * There should be /no/ upstream (pointless) query for
my-outhouse-example.com.example.com. (oops!)

Let's stop the leaks.

--

Fred Morris


___
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

"forward first" set on a master zone not working as expected

[Taylor Vierrether via bind-users]

Hello,

I am attempting to set up an internal DNS server that is authoritative for 
internal resources, but also will respond for external resources on the same 
domain that it does not have records for.

For example, I have a domain sub.example.com , and I 
want to have internal entries in the BIND zone file for host1.sub.example.com 
 and host2.sub.example.com 
. That part is working fine. However, there is a 
publicly available DNS entry for sub.example.com  that 
I want my internal clients to be able to resolve, but I don’t want to have the 
IP in the BIND zone file, because the IP is dynamic. There are also some hosts 
(host3.sub.example.com ) and 
(host4.sub.example.com ) that are externally 
resolvable that I don’t want to put in my internal BIND file because they are 
not controlled by me. (Think CNAME to a SaaS application)

I’ve attempted to do this as follows, and it seems to make sense that it would 
work, but it does not. 


named.conf:

zone “sub.example.com" IN {
type master;
file "/etc/bind/sub.example.com.zone";
forward first;
forwarders { 1.1.1.1; 1.0.0.1; };
};

sub.example.com .zone:

$ORIGIN sub.example.com.
$ttl 600
@  300 SOA   dns.sub.example.com. (
  taylor.viertaxa.com.  ; address of 
responsible party
  2020090101; serial number
  300   ; refresh period
  300   ; retry period
  604800; expire time
  300 ) ; minimum ttl
  300 NSelinore.ns.cloudflare.com.
  300 NShal.ns.cloudflare.com.
host1   60  A 10.x.x.x
host2   60  A 10.x.x.x

What I would expect to happen, is that BIND sees “forward first” and attempts 
to look up the hostname host3.sub.example.com  
on the listed forwarders, and succeeds (there’s an entry publicly available for 
that one. 

What actually happens, is if I query for sub.example.com 
 I get the following from nslookup:
*** Can't find sub.example.com: No answer

And if I query for host3.example.com , I get the 
following from nslookup:
** server can't find host3.sub.example.com: NXDOMAIN


BIND version:

Package: bind9
Version: 1:9.11.5.P4+dfsg-5.1+deb10u2


Thank you in advance for any help you might be able to provide. 

signature.asc
Description: OpenPGP digital signature
___
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

Re: bind 9.16.6 on FreeBSD - Assert

[Borja Marcos]

> On 2 Sep 2020, at 09:15, Søren Andersen  wrote:
> 
> It looks like the same bug to me. - Did you try to patch your source code 
> with the path isc just made?

No, I am not aware of a patch. I have rolled it back to 9.11 for now, it’s a 
production server.


Thanks,




Borja.

___
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

Re: bind 9.16.6 on FreeBSD - Assert

[Søren Andersen]

It looks like the same bug to me. - Did you try to patch your source code with 
the path isc just made?

From: Borja Marcos 
Sent: Wednesday, September 2, 2020 08:39
To: Søren Andersen 
Cc: bind-users@lists.isc.org 
Subject: Re: bind 9.16.6 on FreeBSD - Assert

[EXTERNAL MAIL]


> On 1 Sep 2020, at 19:48, Søren Andersen  wrote:
>
> hmm.. I think you hit this bug right here: 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2104

Looks like that. I compiled bind with debug symbols and it crashed again.

No way to append this to your bug report, it’s closed.




Borja.


——
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - rbt.c:2355:
 REQUIRE(newbits <= rbt->maxhashbits) failed, back trace
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #0 0x43fe19
 in assertion_failed()+0x59
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #1 0x7ba3d8
 in isc_assertion_failed()+0x38
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #2 0x5cbb8f
 in rehash()+0x9f
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #3 0x5c2dc7
 in maybe_rehash()+0x47
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #4 0x5c5574
 in hash_node()+0xd4
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #5 0x5c5089 in 
dns_rbt_addnode()+0xf19
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #6 0x5e6bd0 in 
findnodeintree()+0x260
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #7 0x5d1c60 in 
findnode()+0xa0
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #8 0x5201a0 in 
dns_db_findnode()+0x130
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #9 0x6a8351 in 
cache_name()+0x3a1
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #10 0x6a240f in 
cache_message()+0x16f
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #11 0x69f4a6 in 
resquery_response()+0xd06
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #12 0x804d03 in 
dispatch()+0xc63
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #13 0x800751 in 
run()+0x41
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #14 0x80245e036 in 
_fini()+0x801c3a35e
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - exiting (due to 
assertion failure)
<6>1 2020-09-02T04:30:04.407121+00:00 host1 kernel - - - pid 49310 (named), jid 
0, uid 53: exited on signal 6
——

___
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

Re: bind 9.16.6 on FreeBSD - Assert

[Borja Marcos]

> On 1 Sep 2020, at 19:48, Søren Andersen  wrote:
> 
> hmm.. I think you hit this bug right here: 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2104

Looks like that. I compiled bind with debug symbols and it crashed again.

No way to append this to your bug report, it’s closed.




Borja.


——
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - rbt.c:2355:
 REQUIRE(newbits <= rbt->maxhashbits) failed, back trace
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #0 0x43fe19
 in assertion_failed()+0x59
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #1 0x7ba3d8
 in isc_assertion_failed()+0x38
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #2 0x5cbb8f
 in rehash()+0x9f
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #3 0x5c2dc7
 in maybe_rehash()+0x47
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #4 0x5c5574
 in hash_node()+0xd4
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #5 0x5c5089 in 
dns_rbt_addnode()+0xf19
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #6 0x5e6bd0 in 
findnodeintree()+0x260
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #7 0x5d1c60 in 
findnode()+0xa0
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #8 0x5201a0 in 
dns_db_findnode()+0x130
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #9 0x6a8351 in 
cache_name()+0x3a1
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #10 0x6a240f in 
cache_message()+0x16f
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #11 0x69f4a6 in 
resquery_response()+0xd06
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #12 0x804d03 in 
dispatch()+0xc63
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #13 0x800751 in 
run()+0x41
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - #14 0x80245e036 in 
_fini()+0x801c3a35e
<26>1 2020-09-02T04:30:04.00+00:00 host1 named 49310 - - exiting (due to 
assertion failure)
<6>1 2020-09-02T04:30:04.407121+00:00 host1 kernel - - - pid 49310 (named), jid 
0, uid 53: exited on signal 6
——

___
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