Re: Logging to syslog
On Tue, 2016-12-06 at 13:23 +0100, Ivan Fabris wrote: > I set up some dns logging to syslog ( rsyslog actually ), which > forwards local1.* and local2.* to a remote rsyslog [...] > Both syslog, and journalctl, have all the rate limits set to infinite > ( all that I could find ) Urgh... journalctl. Remember to also set "RateLimitInterval=0" in the "[Journal]" section of journald.conf. And since journald picks up and stores _everything_, including debug messages from "execute", you might want "Storage=volatile" there as well. You probably already have rsyslog write things to disk, no need for it to be written two places. > Did anyone find some slow down under heavy load with such a config, > due to syslog ? e.g, no slow downs with file logging > Or when the local o remote syslog are not available ( I configured > the local rsyslog with a disk cache ) What exactly does "slow down" mean here? Are you missing messages in the log files? Or are requests not answered in a timely fashion? What is heavy load for you? I have a set of 2 vCPU / 4G RAM virtual machines that service a hotspot network and logs around 3 million lines per day each. Without RateLimitInterval=0 it routinely drops messages. -- Peter ___ 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
Moving dynamic zones to new master+slave pair without interruptions
We currently have two internal DNS servers that are both authoritative for a range of internal zones and caching resolvers for our clients. We would like to split this so authorizative and caching roles exist on different servers. And we would like to do this with as little down time as possible, also for dynamic zones. Moving static zones is of course trivial. Moving dynamic zones is what I cannot quite wrap my head around. I think I want to set up a new slave and AXFR from the existing master. Then I can point delegations and "forwarders" at this new slave only,. Together with having the configured "masters" pointing at a not yet running master server this would make it "stand alone". Next step in my head would be to re-create the master from this slave. I thought that I could just copy the zone files from the slave, since that slave would not have made any changes, seeing as it is only the master that can do that. (I am fine with rejecting changes to the dynamic zones during the move exercise.) However, I see that the current slave also has ".jnl" files for the dynamic zones and "rndc freeze " is invalid except on the zone master. With journal files present I guess that I cannot trust the zone files to actually be valid/complete. So... What do I do then? Is there another way of committing the journal to disk on a slave? Is there a "best practice" for re-creating a lost master when dealing dynamic zones? I may of course have started out completely wrong. If there are better ways to acheive what I want then I am all ears! :-) This is all a thought exercise right now, I have not actually tried to move anything yet. If BIND versions are relevant then we plan on using the CentOS 6 default which is BIND 9.8.2 (with some patches, so it's bind-9.8.2- 0.37.rc1.el6_7.5.x86_64) on the new servers. Building from sources is a hassle we would rather avoid, but since we are already doing this with ISC DHCP we could also do it with BIND if necessary. Current master is _quite_ old, BIND 9.3.6 (bind-9.3.6-25.P1.el5_11.5). So the setup is really in need of a refresh. :-) Thank you in advance! -- Peter Rathlev ___ 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: Moving dynamic zones to new master+slave pair without interruptions
On Wed, 2016-01-06 at 18:04 +, Darcy Kevin (FCA) wrote: > I'd just like to note in passing that the "separate authoritative and > recursive" herd mentality reaches the ultimate point of absurdity > when you only have 2 servers and you're going to create single points > of failure (apparently, unless I'm misinterpreting "stand alone") to > conform to this so-called "best practice". [...] I'm not religious about either model, but in this case the load on the recursive caching servers merits them being their own instances. We are not splitting the functions based on security concerns. > Needless to say, I don't subscribe to the (apparently popular) notion > that the roles need to exist on separate *hardware*. [...] One of two authoritative servers and two of three recursing will be virtual servers. So it's not as much a waste of hardware as it could be. :-) > View-level separation is, in my opinion, sufficient to meet the > security requirements. [...] Certainly. We use views on the resolvers for our public "guest" network and have had not concerns about this. [...] > Speaking of availability, as your network evolves, you might want to > consider running recursive service on Anycast addresses [...] We already use anycasting on the recursive servers and would prefer a simple configuration that can easily be replicated to new instances. As part of this pending transition we will introduce an extra recursing server. Keeping things simple, even if that means running more servers, helps me sleep at night. It helps my colleagues handling things without having to call me. :-) -- Peter Rathlev ___ 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: Moving dynamic zones to new master+slave pair without interruptions
Hi Tony, Thank you for the suggestions! On Wed, 2016-01-06 at 16:05 +, Tony Finch wrote: > * Set up a new hidden master, with copies of your zones. (See below) > > * Change your existing servers to slave from the new hidden master > instead of the old master. Reconfigure the old master to be a slave > of the new one. Wouldn't this ruin dynamic updates from the DHCP servers? These updates need to be sent to the master. I could of course configur™e "allow- update-forwarding". Manually specifying the hidden master in the DHCP configuration seems clumsy. > You don't need to worry about the data on disk on your existing > slaves. They will continue to serve the same data, they will just > xfer changes from a different master. This made my think... Maybe I could just AXFR from the running slave and use the output as zone files on the master. As far as I can see this should Just Work™. > My program nsdiff (http://dotat.at/prog/nsdiff) is useful for copying > dynamic zones from from an existing master to a new master without > faffing around with `rndc freeze`. Nice. :-) Perfect for copying changes without touching the files. I'll take a thorough look at it. -- Peter Rathlev ___ 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
