DDNS propagation between views
Are there any tunable's to speed up the propagation of dynamic updates between views without manually freezing and thawing the zone? Thanks! jlc ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: DDNS propagation between views
>Hm, are you using the same zonefile for both your versions of the zone, >trying to share it between multiple views? If you are - don't. Views are >an abomination, giving people plenty of rope to hang themself with AND >plenty of chances to shoot themselves in the feet :D Ahh, yes you are right, I am sharing a zone file between views. How does one achieve acl matches without the use of views? I have a split dns setup specifically on this bind instance and don't know how to achieve this without views? Thanks! jlc ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: DDNS propagation between views
>You can have views and separate zone files. You need to plan and it >helps to read the FAQs at ISC about this. > >http://www.isc.org/faq/item/191 Didn't even think about it that way, ok. >http://www.isc.org/faq/item/182 How does one actually do away with views if that was an approach? Docs suggest acl's can be used outside a views clause, so I presume the use of allow-query directives would facilitate this. Just curious as it was mentioned... Thanks for the pointers! jlc ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Master and slave on same host
I have an RHEL server running Bind 9.7 that needs to have a zone set to master and slave between two views. I don't have the luxury of an additional IP, is this still possible with a single ip address? Thanks! jlc ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Master and slave on same host
>What do you mean you can’t have additional IPs? Even if you don’t >have other network connections you can use virtual IPs on a single >NIC. I have one server (not DNS) that has 30 virtual IPs on a single NIC. Well, there is other software I was hoping to avoid reconfiguring if I add a virtual ip. To confirm, it is possible with just keys on one instance? Thanks guys, jlc ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Master and slave on same host
>If one view or the other communicates exclusively with other devices on >the same link, you could probably get away with using an IPv6 link-local >address, which is likely already present on your system (if you're >running a modern OS), and is probably "invisible" to the other apps >you're running on the box, and thus wouldn't require them to be >reconfigured. Ah. no luck. It is RHEL 6.1, but had ipv6 explicitly removed during deployment. I take it its a pre-req to have different ip's, so I will work around this. Thanks for the guidance, jlc ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Master and slave on same host
>Bad decision on the deployment option, IMO. Not sure even what you mean >by "removed", since it's deeply integrated into all modern networking >stacks. Either you severely crippled your networking subsystem, or it's >not as "removed" as you were told it was. Disabled with all the correct measures. Not really bad, its not in a ipv6 environment and this was the first use case for it:) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Master/slave issues
Got around to adding a virtual interface on the production box (I never could get this working with keys alone), I had labbed this up previously in reverse of what I needed but transfers were broken on the production box when I reversed the views that contained the master/slave. The following works on the lab box, but when I swap master and zone between views It breaks. What I wanted was: view "internal" -> match-clients { localnets; }; -> slave zones view "external" -> match-clients { any; }; -> master zones I suppose it makes sense, but none the less, I think I have been staring at this too long. Any have any insight? All the dynamic clients reside on the public side. view "internal" { match-clients { localhost; }; server 10.0.0.4 { keys { external; }; }; recursion yes; zone "foo.local" { type master; allow-update { key dhcpd_ddns; }; also-notify { 172.16.0.1; }; allow-query { any; }; file "/var/named/foo.local.zone.db"; }; }; view "external" { match-clients { any; }; recursion yes; zone "foo.local" { type slave; masters { 10.0.0.4; }; allow-update { key external; }; file "dynamic/foo.local.slave_zone.db"; }; }; key external { algorithm hmac-md5; secret "..."; }; ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Problems with caching server that forwards to an internal split-brain authoritative server
I am trying to replicate a working configuration on an older host that has a caching server that forwards to an Active Directory DNS server at 172.18.0.2 that is part of a split-brain setup with a public copy of its zone hosted with Goggle. When I attempt to resolve a record on the new caching server, it works fine only if the record is not part of the zone hosted by the Active Directory server. For example, `dig lists.isc.org` works fine. When I attempt to resolve a record in the zone hosted on the forwarder, it fails with SERVFAIL and I get the following errors in the logs: named[1158]: chase DS servers resolving 'example.com/DS/IN': 172.18.0.2#53 named[1158]: no valid DS resolving 'name.example.com/A/IN': 172.18.0.2#53 The configuration I am using is shown below, any ideas as to what I am overlooking? options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; secroots-file "/var/named/data/named.secroots"; recursing-file "/var/named/data/named.recursing"; allow-query { localhost; }; recursion yes; forward only; forwarders { 172.18.0.2; }; dnssec-enable yes; dnssec-validation yes; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; include "/etc/crypto-policies/back-ends/bind.config"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; -- 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: Problems with caching server that forwards to an internal split-brain authoritative server
On Thu, Mar 10, 2022 at 7:48 PM Mark Andrews wrote: > > To answer your question about what you are overlooking the answer is “DNSSEC”. Thank you for the detailed response Mark. -- 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