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
