Re: "forward first" set on a master zone not working as expected
[ 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 you. For us, we have a centralized
management system that makes the relevant updates in parallel. The big
caveat with that is, those few situations where the DNS needs to be
"schizophrenic", i.e. resolve differently in the internal versus external
versions of the zones. We try to keep that nonsense to a minimum, but when
we can't talk people out of it, we handle it on an exception basis.
I suppose another approach is to have a backend database which tags each
record as being "internal", "external" or "both", and then the respective
versions of the zones get generated accordingly. You'd need something to
ensure referential integrity, though, otherwise you might end up with
dangling references (e.g. CNAME/MX/SRV targets), bad delegations, etc.
- Kevin
P.S. No offense to schizophrenics. I guess a more accurate term would be
"multiple personality".
On Thu, Sep 3, 2020 at 3:52 AM Matus UHLAR - fantomas
wrote:
> 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.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.
>
> you can delegate that entry elsewhere.
>
> > 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)
>
> you can delegate those records somewhere.
>
> >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; };
> >};
>
> forwarding is not used for zone other than "type forward".
>
> >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
>
> if you search for "sub.example.com" record, you can not delegate that one,
> of course.
>
> you apparently should use redesign your DNS. Easiest way would be using
> different domain internally.
>
> >And if I query for host3.example.com , I get the following from nslookup:
> >** server can't find host3.sub.example.com: NXDOMAIN
>
> note that nslookup is very bad program for tracking DNS errors.
> use "host" or "dig" for that case.
>
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> I just got lost in thought. It was unfamiliar territory.
> ___
> 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
>
___
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: Response Policy Zone: disabling "leaking" of lookups
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* (not present): The lookup is performed, but isn't waited for. *Yes*: Resolution waits for the lookup to complete. *No*: Resolution is not performed. Verified by testing. :-) Thanks for the sanity check. -- 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
Re: [DNSfirewalls] Response Policy Zone: disabling "leaking" of lookups
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 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: >* 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". >* In addition to the foregoing a rule is placed in the RPZ that >"com.example.com" and "*.com.example.com" are NXDOMAIN. >* 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 > >___ >DNSfirewalls mailing list >dnsfirewa...@lists.redbarn.org >http://lists.redbarn.org/mailman/listinfo/dnsfirewalls > ___ 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...@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(>name, >domain)) failed, back trace Aug 27 01:36:25 chuck named[11975]: #0 0x43ba00 in ?? Aug 27 01:36:25 chuck named[11975]: #1 0x61ad8a in ?? Aug 27 01:36:25 chuck named[11975]: #2 0x5689bb in ?? Aug 27 01:36:25 chuck named[11975]: #3 0x56e979 in ?? Aug 27 01:36:25 chuck named[11975]: #4 0x5760b0 in ?? Aug 27 01:36:25 chuck named[11975]: #5 0x573bc2 in ?? Aug 27 01:36:25 chuck named[11975]: #6 0x64084c in ?? Aug 27 01:36:25 chuck named[11975]: #7 0x80206e036 in ?? Aug 27 01:36:25 chuck named[11975]: exiting (due to assertion failure) Upgraded to bind916-9.16.6_1 om Sep 1, but then once more Sep 2 20:20:22 chuck named[51566]: resolver.c:5125: INSIST(dns_name_issubdomain(>name, >domain)) failed, back trace Sep 2 20:20:22 chuck named[51566]: #0 0x43d2a0 in ?? Sep 2 20:20:22 chuck named[51566]: #1 0x62039a in ?? Sep 2 20:20:22 chuck named[51566]: #2 0x56d84b in ?? Sep 2 20:20:22 chuck named[51566]: #3 0x573809 in ?? Sep 2 20:20:22 chuck named[51566]: #4 0x57b260 in ?? Sep 2 20:20:22 chuck named[51566]: #5 0x578d50 in ?? Sep 2 20:20:22 chuck named[51566]: #6 0x645e5c in ?? Sep 2 20:20:22 chuck named[51566]: #7 0x80246e036 in ?? Sep 2 20:20:22 chuck named[51566]: exiting (due to assertion failure) The server is dualstack and serves DNS via both IPv4 and IPv6. Has anyone observed something similar? --Ingeborg -- Ingeborg Østrem Hellemo -- ingeborg.hell...@uit.no Dep. of Information Technology --- Univ. of Tromsø ___ 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: "forward first" set on a master zone not working as expected
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.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.
you can delegate that entry elsewhere.
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)
you can delegate those records somewhere.
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; };
};
forwarding is not used for zone other than "type forward".
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
if you search for "sub.example.com" record, you can not delegate that one,
of course.
you apparently should use redesign your DNS. Easiest way would be using
different domain internally.
And if I query for host3.example.com , I get the following from nslookup:
** server can't find host3.sub.example.com: NXDOMAIN
note that nslookup is very bad program for tracking DNS errors.
use "host" or "dig" for that case.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I just got lost in thought. It was unfamiliar territory.
___
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
> 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 that the backtrace will include the function names. Best regards, 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
Official BIND 9 Docker images (Technology Preview)
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/general The images are built on top of Ubuntu 20.04 LTS and BIND 9 packages from official ISC PPA (https://launchpad.net/~isc) and will be updated every time there’s a new BIND 9 releases. This is in the phase of technology preview, so I would invite people to test the docker images and provide feedback (both constructive praise and constructive critique are welcome). The feedback could be sent here (the mailing list), or if you think you found an issue to the official repository Please be aware that while this is fairly simple, we would not recommend running this in the production unless you are actually accept that if you run into any problems you are on your own and you will have to do any debugging on your own. Here’s the quickstart: # Recursive DNS Server ## BIND 9.11 docker run \ --name=bind9 \ --restart=always \ --publish 53:53/udp \ --publish 53:53/tcp \ --publish 127.0.0.1:953:953/tcp \ internetsystemsconsortium/bind9:9.11 # BIND 9.16 docker run \ --name=bind9 \ --restart=always \ --publish 53:53/udp \ --publish 53:53/tcp \ --publish 127.0.0.1:953:953/tcp \ internetsystemsconsortium/bind9:9.16 ## Authoritative DNS Server Here you will actually want to provide the desired configuration in /etc/bind/named.conf and primary zones, etc… (e.g. it’s not magic, you will have to configure it). # BIND 9.11 docker run \ --name=bind9 \ --restart=always \ --publish 53:53/udp \ --publish 53:53/tcp \ --publish 127.0.0.1:953:953/tcp \ --volume /etc/bind \ --volume /var/cache/bind \ --volume /var/lib/bind \ --volume /var/log \ internetsystemsconsortium/bind9:9.11 # BIND 9.16 docker run \ --name=bind9 \ --restart=always \ --publish 53:53/udp \ --publish 53:53/tcp \ --publish 127.0.0.1:953:953/tcp \ --volume /etc/bind \ --volume /var/cache/bind \ --volume /var/lib/bind \ --volume /var/log \ internetsystemsconsortium/bind9:9.16 Thanks for any feedback you might have, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org ___ 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: Upgrading from 9.14.12 to 9.16.4 - with existing DNSSEC zones
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 different ports seems to solve my problems. Under 9.14.12 there were no problems - that's the difference to 9.16.4, which caused my problems. -Original Message- From: Mark Andrews Sent: Wednesday, September 2, 2020 12:38 AM To: dun...@isn-portal.de Cc: bind-users@lists.isc.org Subject: Re: Upgrading from 9.14.12 to 9.16.4 - with existing DNSSEC zones Do you go to your mechanic and not take the car when you have a problem you don’t understand with the car? BIND 9.16.4 should be a drop in replacement for 9.14.12. As you are seeing issues you will need to supply more details like the name of the zone so people can actually try and figure out what the issue is. Mark > On 2 Sep 2020, at 01:06, Duncan wrote: > > I am using DNSSEC for more than 5 years now (never had a problem so far), but > after upgrading to the latest bind-9.16.4 the verification fails using > Verisign's DNSSEC Validator. > > I reverted back to 9.14.12 and everything works as expected. > > First I started upgrading my secondary DNS-Server (primary left untouched > !!!) to 9.16.4 - restarted named and everything seems to be OK. > > So I tested with Verisign's DNSSEC Validator > https://dnssec-analyzer.verisignlabs.com/ before upgrading my primary DNS. > > And Verisign reported an error -> All Queries to > secondary.my-dnsserver-domain.com for my-domain.com/Atimed out or failed > > Test Results: https://ibb.co/7QLVJsC > > Any ideas? …or should I upgrade both servers before I do my first test (not > only the secondary server)? As I said, I only updated my secondary server and > left my primary server untouched! > > Are there any related upgrade issues from from 9.14.12 to 9.16.4, which I > should take care first (do I have to update something in my configs)? Is it > possible to keep my already signed zones of my 9.14.12 installation? Or do I > have to re-sign anything? > > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org smime.p7s Description: S/MIME cryptographic 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
