9.16.13 overwrote master files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I just updated from 9.16.12 to 9.16.13.
zone "naturediscovery.org" { type master; file
"named.naturediscovery.org"; };
9.16.13 has overwritten the master file with the current zone contents,
replacing the $INCLUDE statements with the contents of the included
files.
Is there some new config item to prevent this?
-BEGIN PGP SIGNATURE-
iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYF+vMBUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsHjeQCfRQ9MOrPma6hoUpYycgb3zbTSVhUA
n3GNG6lyTPbYZ4W2w8EVPrL7Ltra
=5yyq
-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
Re: Dnssec delegation NS RRset
> I am getting the following warning: > > The following NS name(s) were found in the authoritative NS > RRset, but not in the delegation NS RRset (i.e., in the com > zone): (a DNS server) This sounds like there is a mismatch between the NS RRset for the zone on the authoritative NSes for the zone and the delegation NS RRset from the parent zone. For a proper setup, these two NS RRsets needs to be identical, and it's the zone owner's duty to ensure that is the case. Updating the NS RRset in the parent is often done using other means than the DNS protocol itself. > Missing glue records? Maybe I'm splitting hairs here... https://tools.ietf.org/html/rfc8499 says about "glue records": A later definition is that glue "includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub-zones (NS records), address records that accompany those NS records (A, , etc), and any other stray data that might appear." (Quoted from [RFC2181], Section 5.4.1) So... According to that wider definition of "glue records", yes, there may be missing NS records in the delegation NS RRset in the delegating zone. If you use the more narrow definition of "glue records", that it only consists of address records for the names corresponding to the NS records in delegations, I would say "probably not". Regards, - Håvard ___ 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: Dnssec delegation NS RRset
You may find people can give better answers if you tell us the domain name. The issue does not sound like glue, but there is not enough informmation to go on. Best wishes, Matthew -- >From: "@lbutlr via bind-users" >To: bind-users >Cc: >Date: Sat, 27 Mar 2021 03:30:09 -0600 >Subject: Dnssec delegation NS RRset >I am getting the following warning: > >The following NS name(s) were found in the authoritative NS RRset, but not in >the delegation NS RRset (i.e., in the com zone): (a DNS server) > >The DNS server exists and is used by other domains, so This is something >specific to this one domain and not to the DNS servers, so I think it must be >something on the registrar. > >Missing glue records? ___ 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
Dnssec delegation NS RRset
I am getting the following warning: The following NS name(s) were found in the authoritative NS RRset, but not in the delegation NS RRset (i.e., in the com zone): (a DNS server) The DNS server exists and is used by other domains, so This is something specific to this one domain and not to the DNS servers, so I think it must be something on the registrar. Missing glue records? -- You have the effrontery to be squeamish, it thought at him. But we were dragons. We were supposed to be cruel, cunning, heartless, and terrible. But this much I can tell you, you ape - the great face pressed even closer, so that Wonse was staring into the pitiless depths of his eyes - we never burned and tortured and ripped one another apart and called it morality. --Guards! Guards! ___ 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: Advice on Bind9/ISC DHCP cluster
On 3/25/21 9:19 AM, Olivier wrote: Hello, Hi, I would like to implement a 3 hosts cluster with the following features: I don't see anything conceptually wrong with what you've outlined. Though I wouldn't call it a "cluster". To me a cluster is something that is (as largely as possible) self redundant meaning no Single Point of Failure. You are SPoFed on host1. 1- host1 is a bind9 master 2- host2 is a bind9 slave/ISC DHCP primary 3- host3 is a bind9 slave/ISC DHCP secondary 4- primary ISC DHCP instance sends dynamic updates to bind9 master 5- secondary ISC DHCP instance sends dynamic updates to bind9 master 6- DNS clients queries Bind9 slaves (hosts 2 and 3) 7- DNS updates are made on Bind9 master I assume that you are thinking that the DHCP server will be sending the updates. It's probably worth pointing out that the bind9 secondaries (host2 & host3) can be configured to forward any dynamic updates which they receive on to the primary (host1). This is germane when clients send dynamic updates to the DNS server(s) that they are querying. IMHO Windows is (at least used to be) notorious for doing this. I can accept to loose (either static or dynamic) updates if host1 is down This is the SPoF that I was talking about. You also need to be mindful of your expiration timers on your zone(s). What if the primary server is down for 8 days (for reasons) and the secondaries honor a zone expiration time of 7 days? 1. Is it possible to implement both 4 and 5 ? I would assume that #4 can be done. I would expect that #5 can be done. 2. Any alternative architecture (I can use up to 5 hosts) ? I /think/ that BIND has some options to use something else, a (traditional) DB and / or LDAP for zone information via Dynamically Loadable Zones. Thus you can use replications features in the DB / LDAP servers that work to avoid the SPoF of a single primary. I would highly recommend that you consider VRRP et al. for VIPs that clients point to. That way you can move them between servers as you need to have one down for maintenance. -- I've seen some clients get really crochety and not fall back to their second configured DNS server nearly as gracefully as I would have hoped. Having the preferred DNS server's VIP re-homed on an alternate system would have allowed the client to think that it's preferred server is and responding like normal, even if the real host is out of the rack and in pieces on the floor. Depending on your needed scale you might consider some form of load balancing. -- You can look at some form of ""hardware / ""appliance[1] based load balancer or you can look at a host based software solution. -- There are a number of solutions in this space. But they are somewhat platform dependent and I don't see any information on what platform you're using. [1] What is ""hardware / ""appliance other than a different host that runs software. Good luck. -- Grant. . . . unix || die 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
