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

2020-09-03 Thread Matus UHLAR - fantomas
On 02.09.20 15:00, Taylor Vierrether via bind-users wrote: 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.co

Re: bind 9.16.6 on FreeBSD - Assert

2020-09-03 Thread Ingeborg Hellemo
s...@stofa.dk said: > It is bind 9.16.6, built from ports on FreeBSD 11.3. Same server combination here but different error. Aug 27 01:36:25 chuck named[11975]: resolver.c:5125: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace Aug 27 01:36:25 chuck named[11975]: #0

Re: bind 9.16.6 on FreeBSD - Assert

2020-09-03 Thread Borja Marcos
> On 3 Sep 2020, at 11:13, Ingeborg Hellemo wrote: > The server is dualstack and serves DNS via both IPv4 and IPv6. > > Has anyone observed something similar? No, I haven’t seen this one. If you have used the ports subsystem, can you recompile the port with the WITH_DEBUG option? Doing tha

Official BIND 9 Docker images (Technology Preview)

2020-09-03 Thread Ondřej Surý
Hello everyone, ISC is proud to announce an official Docker images for BIND 9 versions 9.11 (Extended Support Version), 9.16 (Stable Version) and 9.17 (Development Version). Here’s the link to the official docker repository: https://hub.docker.com/repository/docker/internetsystemsconsortium/bind9

RE: Upgrading from 9.14.12 to 9.16.4 - with existing DNSSEC zones

2020-09-03 Thread Duncan
I think, I 've found the problem... Read in the documentation: "UDP network ports used for listening can no longer simultaneously be used for sending traffic." I had listen-on, notify-source and transfer-source all set to the same IP and Port (53). Setting notify-source and transfer-source to d

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

2020-09-03 Thread Kevin Darcy
[ Classification Level: GENERAL BUSINESS ] Or, if you absolutely *must* use the same namespace internally and externally (oftentimes you can't talk the business out of that), your internal version should be a more-or-less a superset of your external version. How you keep those in sync is up to yo

Re: [DNSfirewalls] Response Policy Zone: disabling "leaking" of lookups

2020-09-03 Thread pvm_job via bind-users
It is a well known behaviour.  This is the way how your DNS client works (not DNS server). Get rid of the search list or block requests to the domains in the search lists by RPZ (e.g. if it is pushed by ISP).   BR, Vadim >Четверг, 3 сентября 2020, 19:04 +03:00 от Fred Morris : >  >It comes to m

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

2020-09-03 Thread Fred Morris
Carl Byington wrote: > 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;" > You are correct! I got confused and the doc didn't help. The logic is tri-state: *Default* (no